From 6lowpan-bounces@ietf.org Sat Dec 01 18:40:48 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 1Iybwu-0003Ju-2i; Sat, 01 Dec 2007 18:40:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iybwt-0003Jo-7S for 6lowpan@lists.ietf.org; Sat, 01 Dec 2007 18:40:39 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iybwq-0000cj-QZ for 6lowpan@lists.ietf.org; Sat, 01 Dec 2007 18:40:39 -0500 Received: from [192.168.2.38] (c-24-4-149-226.hsd1.ca.comcast.net [24.4.149.226]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id lB1NeWpo020715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 1 Dec 2007 15:40:34 -0800 (PST) Message-ID: <4751F0F9.6000402@eecs.berkeley.edu> Date: Sat, 01 Dec 2007 15:40:41 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Hui Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> In-Reply-To: <474F0DB8.6080706@archrock.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gateway0.EECS.Berkeley.EDU id lB1NeWpo020715 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: 6lowpan <6lowpan@lists.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 A 16 bit checksum at L4 is redundant if every L2 hop has a 32 bit MIC. A 16 bit checksum at L4 is not sufficient protection against bit errors=20 without a 32 bit MIC somewhere (either L2 or L4/5, or both as in HART). If you run 15.4 networks without a 32 bit MIC, I guarantee you that you=20 will get valid checksums on corrupted packets. Depending on the network=20 traffic, that might happen once per day per network. If a node knows that it's going to send a packet with a 32 bit L2 MIC,=20 can't it be smart enough to compress out the 16 bit checksum? Is that=20 really violating the requirement? (It's a simple enough change - we've=20 got another bit in the HC2 header.) Put another way, which do you think is safer from an L3/L4 header error=20 detection perspective: A) sending packets over 10 hops with a 32 bit MIC at each hop and no 16=20 bit checksum B) sending packets over 1 hop with no MIC and a 16 bit checksum The math is pretty clear. The measured data fits the math. ksjp Jonathan Hui wrote: > > Note that L2 message integrity doesn't provide end-to-end message=20 > integrity, which L4 checksums (that cover the L3 header) provide. > > --=20 > Jonathan Hui > > > Kris Pister wrote: >> Geoff - ooh, I like exceptions. >> Did we try to get an exception on the UDP checksum? It's painful to=20 >> leave that in the compressed header if we have L2 message integrity. >> >> ksjp >> >> Geoff Mulligan wrote: >>> We have already received an exception from the IESG to IPsec on 6lowp= an >>> devices. >>> >>> geoff >>> >>> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote: >>> =20 >>>> Hum... >>>> I had missed that; Seems that we have to make an exception :) If=20 >>>> you consider ISA100.11a, they already have security at L2 and L5,=20 >>>> it makes little sense to MUST IPSec on top of that. >>>> >>>> Pascal >>>> >>>> =20 >>>>> -----Original Message----- >>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>> Sent: Wednesday, November 28, 2007 8:03 PM >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan >>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>> >>>>> Hmm. From 4294: >>>>> >>>>> "However, while authentication and encryption can each be NULL, the= y >>>>> MUST NOT both be NULL." >>>>> >>>>> ksjp >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>> =20 >>>>>> Hi Kris: >>>>>> >>>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL=20 >>>>>> encryption and authentication for >>>>>> =20 >>>>> interoperability reasons. >>>>> =20 >>>>>> On the general question of RFC 4294 itself: I'm not sure the work=20 >>>>>> was ever done. I hope someone >>>>>> =20 >>>> >from the list can help? >>>> =20 >>>>>> If the answer is unclear, and considering that we are=20 >>>>>> re-chartering the group, maybe we could have >>>>>> =20 >>>>> a work item to specify the instantiation of RFC 4294 for LoWPAN=20 >>>>> nodes? >>>>> =20 >>>>>> Pascal >>>>>> ________________________________________ >>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: 6lowpan >>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>>> >>>>>> Is there an email thread somewhere that discusses the impact on=20 >>>>>> 6LoWPAN of the security >>>>>> =20 >>>>> requirements of 4294 and 4303? >>>>> =20 >>>>>> My first quick readthrough makes me very uncomfortable that some=20 >>>>>> of the mandates are going to be >>>>>> =20 >>>>> ugly from a header standpoint. >>>>> =20 >>>>>> ksjp >>>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>> Hi JP: >>>>>> >>>>>> Thanks a bunch for this charter. I'll try not to rephrase what=20 >>>>>> was already discussed with Christian, >>>>>> =20 >>>>> Anders, Philip and Misha. >>>>> =20 >>>>>> There's an additional item I'd wish to see either in ROLL or=20 >>>>>> 6LoWPAN and I do not know exactly >>>>>> =20 >>>>> where it belongs, maybe both. The question is whether we need to=20 >>>>> and can document how RFC 4294 >>>>> applies for sensors, and M2M devices in general, whether they act=20 >>>>> as hosts or as routers. >>>>> =20 >>>>>> I've seen IPv6 presented as a Pandora box that drags just too=20 >>>>>> much stuff to be incorporated in a >>>>>> =20 >>>>> sensory device. For instance, at the moment, SP100.11a endorses=20 >>>>> 6LoWPAN formats but it's not so clear >>>>> at all that IPv6 itself is mandated. A clear spec with=20 >>>>> well-documented implementation could be a >>>>> formidable tool to despond to Fear, Uncertainty and Defiance. >>>>> =20 >>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do=20 >>>>>> without multicast at all if ND is >>>>>> =20 >>>>> supported some other way (such as suggested in:=20 >>>>> http://www.ietf.org/internet-drafts/draft-thubert- >>>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and=20 >>>>> authentication is enough etc, etc... >>>>> =20 >>>>>> Being able to define one minimum set and maybe a few other=20 >>>>>> profiles for the use cases that we >>>>>> =20 >>>>> selected could help tremendously. >>>>> =20 >>>>>> Otherwise I find the charter real well written and easy to=20 >>>>>> digest. >>From the MANEMO experience, I >>>>>> =20 >>>>> expect that some arguments about the relative applicability of=20 >>>>> existing MANET protocols will be >>>>> difficult to prove without some good simulation work running=20 >>>>> agreed-upon scenarios. >>>>> =20 >>>>>> Finally, I'm a bit confused that it seems that both IPv4 and IPv6=20 >>>>>> seem supported. Ipv4 comes with a >>>>>> =20 >>>>> lot of overhead like DHCP. I suggest that when trouble comes and=20 >>>>> things can not be done in a common >>>>> fashion for both IP protocols, hen we prioritize IPv6. >>>>> =20 >>>>>> Unfortunately, I can not make it to Vancouver, but I do feel that=20 >>>>>> the work is really needed so >>>>>> =20 >>>>> please count my vote in for the adoption of the WG. >>>>> =20 >>>>>> Cheers, >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Jean Philippe Vasseur (jvasseur) >>>>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>>>> To: rsn@ietf.org >>>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>>>> >>>>>> Dear all, >>>>>> >>>>>> As promised, here is the new proposed Working Group, which=20 >>>>>> reflects the >>>>>> number of comments/suggestions that we received, the pre-WG=20 >>>>>> consensus, ... >>>>>> >>>>>> Thanks to Dave Ward (RTD AD) for his input. >>>>>> >>>>>> Proposed RL2N WG Charter >>>>>> >>>>>> Description of Working Group >>>>>> >>>>>> L2Ns (Low power and Lossy networks) are typically composed of=20 >>>>>> many embedded >>>>>> devices with limited power, memory, and processing resources=20 >>>>>> interconnected >>>>>> by a variety of wireless links, such as IEEE 802.15.4, Bluetooth,=20 >>>>>> Low Power >>>>>> WiFi. >>>>>> >>>>>> L2Ns are transitioning to an end-to-end IP-based solution to=20 >>>>>> avoid the >>>>>> problems of non-interoperable networks interconnected by protocol >>>>>> translation gateways and proxies. In addition, L2Ns have specific=20 >>>>>> routing >>>>>> requirements that are not currently met by existing routing=20 >>>>>> protocols, such >>>>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be=20 >>>>>> designed to take >>>>>> into consideration the specific power, capabilities, attributes an= d >>>>>> functional characteristics of the links and nodes in the network. >>>>>> >>>>>> >>>>>> There is a wide scope of application areas for L2Ns, including=20 >>>>>> industrial >>>>>> monitoring, building automation (HVAC, lighting/access control),=20 >>>>>> connected >>>>>> home, healthcare, environmental monitoring, agricultural, smart=20 >>>>>> cities, >>>>>> logistics, assets tracking, and refrigeration. The L2N WG will=20 >>>>>> focus on >>>>>> routing solutions for a subset of these deployment scenarios, name= ly >>>>>> industrial, connected home/building and urban applications. The=20 >>>>>> Working >>>>>> Group will determine the routing requirements for these scenarios. >>>>>> >>>>>> >>>>>> The Working Group will provide a routing framework for these=20 >>>>>> application >>>>>> scenarios that provides high reliability in the presence of time=20 >>>>>> varying >>>>>> loss characteristics and connectivity while permitting low-power=20 >>>>>> operation >>>>>> with very modest memory and CPU pressure. >>>>>> >>>>>> >>>>>> The Working Group will pay a particular attention to routing=20 >>>>>> security and >>>>>> manageability (e.g self managing/configuration) issues, which are >>>>>> particularly critical for L2Ns. >>>>>> >>>>>> Work Items: >>>>>> >>>>>> - Produce use cases documents for Industrial, Connected Home,=20 >>>>>> Building and >>>>>> urban application networks. Each document will describe the use=20 >>>>>> case and the >>>>>> associated routing protocol requirements. The documents will=20 >>>>>> progress in >>>>>> collaboration with the 6lowpan Working Group (INT area). >>>>>> >>>>>> >>>>>> - Survey the applicability of existing protocols to L2Ns. The aim=20 >>>>>> of this >>>>>> document will be to analyze the scaling and characteristics of=20 >>>>>> existing >>>>>> protocols and identify whether or not they meet the routing=20 >>>>>> requirements of >>>>>> the L2Ns applications identified above. Existing IGPs, MANET,=20 >>>>>> NEMO, DTN >>>>>> routing protocols will be part of evaluation. >>>>>> >>>>>> - Specification of routing metrics used in path calculation. This=20 >>>>>> includes >>>>>> static and dynamic link/nodes attributes required for routing in=20 >>>>>> L2Ns. >>>>>> >>>>>> - Provide an architectural framework for routing and path=20 >>>>>> selection at Layer >>>>>> 3 (Routing for L2N Architecture) >>>>>> * Decide whether the L2Ns routing protocol require a distributed, >>>>>> centralized path computation models or both. >>>>>> * Decide whether the L2N routing protocol requires a hierarchical=20 >>>>>> routing >>>>>> approach. >>>>>> >>>>>> - Produce a security framework for routing in L2Ns. >>>>>> >>>>>> Goals And Milestones: >>>>>> >>>>>> >>>>>> April 2008 Submit Use case/Routing requirements for Industrial,=20 >>>>>> Connected >>>>>> Home, Building and Urban networks applications to the IESG to be=20 >>>>>> considered >>>>>> as an Informational RFC. >>>>>> >>>>>> August 2008: Submit Routing metrics for L2Ns document to the IESG=20 >>>>>> to be >>>>>> considered as an Informational RFC. >>>>>> >>>>>> September 2008: Submit first draft of the Routing for L2Ns=20 >>>>>> Architecture >>>>>> document (summary of requirements, path computation model, >>>>>> flat/hierarchy,=C5=A0). >>>>>> >>>>>> November 2008: Submit Protocol Survey to the IESG to be=20 >>>>>> considered as an >>>>>> Informational RFC. >>>>>> >>>>>> January 2009 Submit Security Framework for L2Ns to the IESG to be=20 >>>>>> considered >>>>>> as an Informational RFC >>>>>> >>>>>> February 2009: Submit the Routing for L2Ns Architecture document =20 >>>>>> (summary >>>>>> of requirements, metrics and attributes, path selection model) to=20 >>>>>> the IESG >>>>>> as an Informational RFC. >>>>>> >>>>>> March 2009: Recharter. >>>>>> >>>>>> >>>>>> Please comment/suggest/... >>>>>> >>>>>> See you in Vancouver. >>>>>> >>>>>> JP and David. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> RSN mailing list >>>>>> RSN@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> RSN mailing list >>>>>> RSN@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>> >>>>>> >>>>>> =20 >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/6lowpan >>>> =20 >>> >>> =20 >> >> _______________________________________________ >> 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 Dec 01 19:03: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 1IycJQ-00019J-7I; Sat, 01 Dec 2007 19:03:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IycJP-00019B-3d for 6lowpan@lists.ietf.org; Sat, 01 Dec 2007 19:03:55 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IycJM-0001J1-In for 6lowpan@lists.ietf.org; Sat, 01 Dec 2007 19:03:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 46044A961E; Sat, 1 Dec 2007 16:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-10 required=6.6 tests=[AWL=-0.052, BAYES_00=-2.599, RCVD_IN_SORBS_DUL=2.046] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG2LadxpsDa2; Sat, 1 Dec 2007 16:03:49 -0800 (PST) Received: from [192.168.1.143] (adsl-71-142-72-108.dsl.pltn13.pacbell.net [71.142.72.108]) by mail.sf.archrock.com (Postfix) with ESMTP id 83A94A9618; Sat, 1 Dec 2007 16:03:49 -0800 (PST) Message-ID: <4751F662.1080907@archrock.com> Date: Sat, 01 Dec 2007 16:03:46 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> In-Reply-To: <4751F0F9.6000402@eecs.berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 89ebdf268eceaeaf784b3acb625dc20e Cc: 6lowpan <6lowpan@lists.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 Yes, its clear that a 32-bit MIC is stronger than a 16 bit checksum.=20 However, a MIC at L2 no matter how many bits it is is not end-to-end and=20 does not negate the need for L4 integrity checks. Wanting to use a=20 stronger checksum at L4 sounds like you want a different transport=20 layer. You mentioned earlier on this list that losses apply to every=20 link, even wired ones. So if you want stronger end-to-end integrity=20 checks, use a transport layer other than UDP. That's the beauty of IP. -- Jonathan Hui Kris Pister wrote: > A 16 bit checksum at L4 is redundant if every L2 hop has a 32 bit MIC. > A 16 bit checksum at L4 is not sufficient protection against bit errors= =20 > without a 32 bit MIC somewhere (either L2 or L4/5, or both as in HART). >=20 > If you run 15.4 networks without a 32 bit MIC, I guarantee you that you= =20 > will get valid checksums on corrupted packets. Depending on the networ= k=20 > traffic, that might happen once per day per network. >=20 > If a node knows that it's going to send a packet with a 32 bit L2 MIC,=20 > can't it be smart enough to compress out the 16 bit checksum? Is that=20 > really violating the requirement? (It's a simple enough change - we've= =20 > got another bit in the HC2 header.) >=20 > Put another way, which do you think is safer from an L3/L4 header error= =20 > detection perspective: > A) sending packets over 10 hops with a 32 bit MIC at each hop and no 16= =20 > bit checksum > B) sending packets over 1 hop with no MIC and a 16 bit checksum >=20 > The math is pretty clear. The measured data fits the math. >=20 > ksjp >=20 > Jonathan Hui wrote: >> >> Note that L2 message integrity doesn't provide end-to-end message=20 >> integrity, which L4 checksums (that cover the L3 header) provide. >> >> --=20 >> Jonathan Hui >> >> >> Kris Pister wrote: >>> Geoff - ooh, I like exceptions. >>> Did we try to get an exception on the UDP checksum? It's painful to=20 >>> leave that in the compressed header if we have L2 message integrity. >>> >>> ksjp >>> >>> Geoff Mulligan wrote: >>>> We have already received an exception from the IESG to IPsec on 6low= pan >>>> devices. >>>> >>>> geoff >>>> >>>> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote: >>>> =20 >>>>> Hum... >>>>> I had missed that; Seems that we have to make an exception :) If=20 >>>>> you consider ISA100.11a, they already have security at L2 and L5,=20 >>>>> it makes little sense to MUST IPSec on top of that. >>>>> >>>>> Pascal >>>>> >>>>> =20 >>>>>> -----Original Message----- >>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>> Sent: Wednesday, November 28, 2007 8:03 PM >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: 6lowpan >>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>>> >>>>>> Hmm. From 4294: >>>>>> >>>>>> "However, while authentication and encryption can each be NULL, th= ey >>>>>> MUST NOT both be NULL." >>>>>> >>>>>> ksjp >>>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>> =20 >>>>>>> Hi Kris: >>>>>>> >>>>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL=20 >>>>>>> encryption and authentication for >>>>>>> =20 >>>>>> interoperability reasons. >>>>>> =20 >>>>>>> On the general question of RFC 4294 itself: I'm not sure the work= =20 >>>>>>> was ever done. I hope someone >>>>>>> =20 >>>>> >from the list can help? >>>>> =20 >>>>>>> If the answer is unclear, and considering that we are=20 >>>>>>> re-chartering the group, maybe we could have >>>>>>> =20 >>>>>> a work item to specify the instantiation of RFC 4294 for LoWPAN=20 >>>>>> nodes? >>>>>> =20 >>>>>>> Pascal >>>>>>> ________________________________________ >>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>>>>> To: Pascal Thubert (pthubert) >>>>>>> Cc: 6lowpan >>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>> >>>>>>> Is there an email thread somewhere that discusses the impact on=20 >>>>>>> 6LoWPAN of the security >>>>>>> =20 >>>>>> requirements of 4294 and 4303? >>>>>> =20 >>>>>>> My first quick readthrough makes me very uncomfortable that some=20 >>>>>>> of the mandates are going to be >>>>>>> =20 >>>>>> ugly from a header standpoint. >>>>>> =20 >>>>>>> ksjp >>>>>>> >>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> Hi JP: >>>>>>> >>>>>>> Thanks a bunch for this charter. I'll try not to rephrase what=20 >>>>>>> was already discussed with Christian, >>>>>>> =20 >>>>>> Anders, Philip and Misha. >>>>>> =20 >>>>>>> There's an additional item I'd wish to see either in ROLL or=20 >>>>>>> 6LoWPAN and I do not know exactly >>>>>>> =20 >>>>>> where it belongs, maybe both. The question is whether we need to=20 >>>>>> and can document how RFC 4294 >>>>>> applies for sensors, and M2M devices in general, whether they act=20 >>>>>> as hosts or as routers. >>>>>> =20 >>>>>>> I've seen IPv6 presented as a Pandora box that drags just too=20 >>>>>>> much stuff to be incorporated in a >>>>>>> =20 >>>>>> sensory device. For instance, at the moment, SP100.11a endorses=20 >>>>>> 6LoWPAN formats but it's not so clear >>>>>> at all that IPv6 itself is mandated. A clear spec with=20 >>>>>> well-documented implementation could be a >>>>>> formidable tool to despond to Fear, Uncertainty and Defiance. >>>>>> =20 >>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do= =20 >>>>>>> without multicast at all if ND is >>>>>>> =20 >>>>>> supported some other way (such as suggested in:=20 >>>>>> http://www.ietf.org/internet-drafts/draft-thubert- >>>>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and=20 >>>>>> authentication is enough etc, etc... >>>>>> =20 >>>>>>> Being able to define one minimum set and maybe a few other=20 >>>>>>> profiles for the use cases that we >>>>>>> =20 >>>>>> selected could help tremendously. >>>>>> =20 >>>>>>> Otherwise I find the charter real well written and easy to=20 >>>>>>> digest. >>From the MANEMO experience, I >>>>>>> =20 >>>>>> expect that some arguments about the relative applicability of=20 >>>>>> existing MANET protocols will be >>>>>> difficult to prove without some good simulation work running=20 >>>>>> agreed-upon scenarios. >>>>>> =20 >>>>>>> Finally, I'm a bit confused that it seems that both IPv4 and IPv6= =20 >>>>>>> seem supported. Ipv4 comes with a >>>>>>> =20 >>>>>> lot of overhead like DHCP. I suggest that when trouble comes and=20 >>>>>> things can not be done in a common >>>>>> fashion for both IP protocols, hen we prioritize IPv6. >>>>>> =20 >>>>>>> Unfortunately, I can not make it to Vancouver, but I do feel that= =20 >>>>>>> the work is really needed so >>>>>>> =20 >>>>>> please count my vote in for the adoption of the WG. >>>>>> =20 >>>>>>> Cheers, >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Jean Philippe Vasseur (jvasseur) >>>>>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>>>>> To: rsn@ietf.org >>>>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>> >>>>>>> Dear all, >>>>>>> >>>>>>> As promised, here is the new proposed Working Group, which=20 >>>>>>> reflects the >>>>>>> number of comments/suggestions that we received, the pre-WG=20 >>>>>>> consensus, ... >>>>>>> >>>>>>> Thanks to Dave Ward (RTD AD) for his input. >>>>>>> >>>>>>> Proposed RL2N WG Charter >>>>>>> >>>>>>> Description of Working Group >>>>>>> >>>>>>> L2Ns (Low power and Lossy networks) are typically composed of=20 >>>>>>> many embedded >>>>>>> devices with limited power, memory, and processing resources=20 >>>>>>> interconnected >>>>>>> by a variety of wireless links, such as IEEE 802.15.4, Bluetooth,= =20 >>>>>>> Low Power >>>>>>> WiFi. >>>>>>> >>>>>>> L2Ns are transitioning to an end-to-end IP-based solution to=20 >>>>>>> avoid the >>>>>>> problems of non-interoperable networks interconnected by protocol >>>>>>> translation gateways and proxies. In addition, L2Ns have specific= =20 >>>>>>> routing >>>>>>> requirements that are not currently met by existing routing=20 >>>>>>> protocols, such >>>>>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be=20 >>>>>>> designed to take >>>>>>> into consideration the specific power, capabilities, attributes a= nd >>>>>>> functional characteristics of the links and nodes in the network. >>>>>>> >>>>>>> >>>>>>> There is a wide scope of application areas for L2Ns, including=20 >>>>>>> industrial >>>>>>> monitoring, building automation (HVAC, lighting/access control),=20 >>>>>>> connected >>>>>>> home, healthcare, environmental monitoring, agricultural, smart=20 >>>>>>> cities, >>>>>>> logistics, assets tracking, and refrigeration. The L2N WG will=20 >>>>>>> focus on >>>>>>> routing solutions for a subset of these deployment scenarios, nam= ely >>>>>>> industrial, connected home/building and urban applications. The=20 >>>>>>> Working >>>>>>> Group will determine the routing requirements for these scenarios= . >>>>>>> >>>>>>> >>>>>>> The Working Group will provide a routing framework for these=20 >>>>>>> application >>>>>>> scenarios that provides high reliability in the presence of time=20 >>>>>>> varying >>>>>>> loss characteristics and connectivity while permitting low-power=20 >>>>>>> operation >>>>>>> with very modest memory and CPU pressure. >>>>>>> >>>>>>> >>>>>>> The Working Group will pay a particular attention to routing=20 >>>>>>> security and >>>>>>> manageability (e.g self managing/configuration) issues, which are >>>>>>> particularly critical for L2Ns. >>>>>>> >>>>>>> Work Items: >>>>>>> >>>>>>> - Produce use cases documents for Industrial, Connected Home,=20 >>>>>>> Building and >>>>>>> urban application networks. Each document will describe the use=20 >>>>>>> case and the >>>>>>> associated routing protocol requirements. The documents will=20 >>>>>>> progress in >>>>>>> collaboration with the 6lowpan Working Group (INT area). >>>>>>> >>>>>>> >>>>>>> - Survey the applicability of existing protocols to L2Ns. The aim= =20 >>>>>>> of this >>>>>>> document will be to analyze the scaling and characteristics of=20 >>>>>>> existing >>>>>>> protocols and identify whether or not they meet the routing=20 >>>>>>> requirements of >>>>>>> the L2Ns applications identified above. Existing IGPs, MANET,=20 >>>>>>> NEMO, DTN >>>>>>> routing protocols will be part of evaluation. >>>>>>> >>>>>>> - Specification of routing metrics used in path calculation. This= =20 >>>>>>> includes >>>>>>> static and dynamic link/nodes attributes required for routing in=20 >>>>>>> L2Ns. >>>>>>> >>>>>>> - Provide an architectural framework for routing and path=20 >>>>>>> selection at Layer >>>>>>> 3 (Routing for L2N Architecture) >>>>>>> * Decide whether the L2Ns routing protocol require a distributed, >>>>>>> centralized path computation models or both. >>>>>>> * Decide whether the L2N routing protocol requires a hierarchical= =20 >>>>>>> routing >>>>>>> approach. >>>>>>> >>>>>>> - Produce a security framework for routing in L2Ns. >>>>>>> >>>>>>> Goals And Milestones: >>>>>>> >>>>>>> >>>>>>> April 2008 Submit Use case/Routing requirements for Industrial,=20 >>>>>>> Connected >>>>>>> Home, Building and Urban networks applications to the IESG to be=20 >>>>>>> considered >>>>>>> as an Informational RFC. >>>>>>> >>>>>>> August 2008: Submit Routing metrics for L2Ns document to the IESG= =20 >>>>>>> to be >>>>>>> considered as an Informational RFC. >>>>>>> >>>>>>> September 2008: Submit first draft of the Routing for L2Ns=20 >>>>>>> Architecture >>>>>>> document (summary of requirements, path computation model, >>>>>>> flat/hierarchy,=C5=A0). >>>>>>> >>>>>>> November 2008: Submit Protocol Survey to the IESG to be=20 >>>>>>> considered as an >>>>>>> Informational RFC. >>>>>>> >>>>>>> January 2009 Submit Security Framework for L2Ns to the IESG to be= =20 >>>>>>> considered >>>>>>> as an Informational RFC >>>>>>> >>>>>>> February 2009: Submit the Routing for L2Ns Architecture document = =20 >>>>>>> (summary >>>>>>> of requirements, metrics and attributes, path selection model) to= =20 >>>>>>> the IESG >>>>>>> as an Informational RFC. >>>>>>> >>>>>>> March 2009: Recharter. >>>>>>> >>>>>>> >>>>>>> Please comment/suggest/... >>>>>>> >>>>>>> See you in Vancouver. >>>>>>> >>>>>>> JP and David. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> RSN mailing list >>>>>>> RSN@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> RSN mailing list >>>>>>> RSN@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>> >>>>>>> >>>>>>> =20 >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/6lowpan >>>>> =20 >>>> >>>> =20 >>> >>> _______________________________________________ >>> 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 Mon Dec 03 10:33:54 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 1IzDIp-0007JI-FG; Mon, 03 Dec 2007 10:33:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDIo-0007E0-Ho for 6lowpan@ietf.org; Mon, 03 Dec 2007 10:33:46 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzDIo-0005UJ-B3 for 6lowpan@ietf.org; Mon, 03 Dec 2007 10:33:46 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Dec 2007 10:33:46 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB3FXjsU030036 for <6lowpan@ietf.org>; Mon, 3 Dec 2007 10:33:45 -0500 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 lB3FXj0m009976 for <6lowpan@ietf.org>; Mon, 3 Dec 2007 15:33:45 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 10:33:43 -0500 Received: from 10.86.104.180 ([10.86.104.180]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 3 Dec 2007 15:33:43 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 03 Dec 2007 10:33:40 -0500 From: JP Vasseur To: <6lowpan@ietf.org> Message-ID: Thread-Topic: Any Agenda for the 6lowpan WG meeting ? Thread-Index: Acg1weEBH7tt6KG1Edyp5QANk8WjQA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 15:33:43.0754 (UTC) FILETIME=[E33E72A0:01C835C1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2; t=1196696025; x=1197560025; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Any=20Agenda=20for=20the=206lowpan=20WG=20meeting=20? |Sender:=20 |To:=20<6lowpan@ietf.org>; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=a7vrfVBfu9zAvtvVcA4lOr8wh72JUOEXrtiQOAgCkwlT0+TAwnnZPwP8b44cKiEPwfGcFkZ3 IGEriRFZaJAoK+//72Fd8XeGCXgFl+CULOld+pNmYIaLjDmFoZtFqLeN; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [6lowpan] Any Agenda for the 6lowpan WG meeting ? 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 03 11:16:57 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 1IzDyW-0000rz-Eo; Mon, 03 Dec 2007 11:16:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDyU-0000nU-H8 for 6lowpan@ietf.org; Mon, 03 Dec 2007 11:16:50 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzDyS-0001y9-SU for 6lowpan@ietf.org; Mon, 03 Dec 2007 11:16:50 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lB3GGj9R008005; Mon, 3 Dec 2007 09:16:45 -0700 (MST) Subject: Re: [6lowpan] Any Agenda for the 6lowpan WG meeting ? From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: Content-Type: text/plain Date: Mon, 03 Dec 2007 09:16:58 -0700 Message-Id: <1196698618.5871.44.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 This is my fault. I'm working on the agenda right now. geoff On Mon, 2007-12-03 at 10:33 -0500, JP Vasseur wrote: > > _______________________________________________ > 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 Mon Dec 03 11:52: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 1IzEWx-0007hn-6h; Mon, 03 Dec 2007 11:52:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzEWw-0007he-EC for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 11:52:26 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzEWv-0006La-Vi for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 11:52:26 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lB3GqOpo008234 for <6lowpan@lists.ietf.org>; Mon, 3 Dec 2007 09:52:25 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: multipart/mixed; boundary="=-QPhKLnqCT7TtQZ+CLcYJ" Date: Mon, 03 Dec 2007 09:52:38 -0700 Message-Id: <1196700758.5871.49.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [6lowpan] 6lowpan agenda 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 --=-QPhKLnqCT7TtQZ+CLcYJ Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, Attached is the current agenda for the meeting. Sorry for the late notice for the agenda. If there are other presentations or talks, please notify either Carsten or myself as soon as possible. geoff --=-QPhKLnqCT7TtQZ+CLcYJ Content-Disposition: attachment; filename=agenda.txt Content-Type: text/plain; name=agenda.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Wednesday, December 5, 2007 1300-1500 Afternoon Session I, Salon 3 6LoWPAN Draft Agenda - IETF 70 ------------------------------ 1. Administrivia -- Chairs (5 min) 2. Rechartering Status -- Chairs (10 min) 3. Current I-Ds -- Chairs (15 min) 3. Commissioning and Bootstrapping Issues (30 min) 4. Architecture Document (20 min) 5. Security Analysis (20 min) --=-QPhKLnqCT7TtQZ+CLcYJ 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 --=-QPhKLnqCT7TtQZ+CLcYJ-- From 6lowpan-bounces@ietf.org Mon Dec 03 12:36:32 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 1IzFDb-00042J-Gx; Mon, 03 Dec 2007 12:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFDa-0003zu-7W for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 12:36:30 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFDZ-0002sw-SI for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 12:36:30 -0500 Received: by nz-out-0506.google.com with SMTP id i28so2057428nzi for <6lowpan@lists.ietf.org>; Mon, 03 Dec 2007 09:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=rvQHmWNC5CLGuGu03bYh8dlsZCgaQoCLji1/y/vq+fQ=; b=LFAXH0e5rvxWeoo3FZq0ofdcOqxkTef4m/KYuByeF615f4hwfF58+EfmrpeMy9n8I3qM9Y5AY4uNcru5ZtQPQb9lH6pYbS8+UYO229/QtCJ/08qxYSVIYs9D7cu9a9hwgQG+KRltF+jdzxVLuHRdw6K3wfh0nY4hfqeEEWloJS8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lsOpdP0qdJ+VdJ9LJXu/ec41WAieQO9IOJqT1tjCWWVdr5r1f3FxjQmpX6ZF8FTwdza/dURtJ7PK/OPaVL9f+WqVbIS1CpZr5IUiQS5owSCE3p06ui//yBI38IGOecUj3uOqy1KHkF8sgFZY5r+mncDhtVZfUJD1mOHeGTyQr9Q= Received: by 10.142.88.20 with SMTP id l20mr3382381wfb.1196703388345; Mon, 03 Dec 2007 09:36:28 -0800 (PST) Received: by 10.142.105.17 with HTTP; Mon, 3 Dec 2007 09:36:28 -0800 (PST) Message-ID: <77f1dba80712030936m6a64ab44l1687be47ec38842@mail.gmail.com> Date: Tue, 4 Dec 2007 02:36:28 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" Subject: Re: [6lowpan] 6lowpan agenda In-Reply-To: <1196700758.5871.49.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1196700758.5871.49.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 6lowpan <6lowpan@lists.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 Dear Geoff & Carsten, We prepare the following two drafts. Would you include them in the agenda? - Application Recommendation "draft-ekim-6lowpan-scenarios-01.txt" - 6Lowpan Routing Requirement "draft-dokaspar-6lowpan-routreq-03.txt" Thanks, -eunsook On 12/4/07, Geoff Mulligan wrote: > Folks, > Attached is the current agenda for the meeting. > > Sorry for the late notice for the agenda. > > If there are other presentations or talks, please notify either Carsten > or myself as soon as possible. > > geoff > > > _______________________________________________ > 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 Mon Dec 03 12:42: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 1IzFIx-000457-PG; Mon, 03 Dec 2007 12:42:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFIv-00044q-J0 for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 12:42:01 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFIu-0003VQ-0N for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 12:42:01 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lB3HfwtV008594 for <6lowpan@lists.ietf.org>; Mon, 3 Dec 2007 10:41:59 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: multipart/mixed; boundary="=-VoWc1FeSoVPvm5pbl6T7" Date: Mon, 03 Dec 2007 10:42:12 -0700 Message-Id: <1196703732.5871.59.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [6lowpan] updated agenda 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 --=-VoWc1FeSoVPvm5pbl6T7 Content-Type: text/plain Content-Transfer-Encoding: 7bit Folks, I've uploaded and attached the current agenda. geoff --=-VoWc1FeSoVPvm5pbl6T7 Content-Disposition: attachment; filename=agenda.txt Content-Type: text/plain; name=agenda.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Wednesday, December 5, 2007 1300-1500 Afternoon Session I, Salon 3 6LoWPAN Draft Agenda - IETF 70 ------------------------------ 1. Administrivia -- Chairs (5 min) 2. Rechartering Status -- Chairs (10 min) 3. Current I-Ds -- Chairs (15 min) 3. Commissioning and Bootstrapping Issues (30 min) K Kim 4. Architecture Document (20 min) JP Vasseur / D Culler - draft-culler-6lowpan-architecture-00 5. Security Analysis (20 min) D Park - draft-daniel-6lowpan-security-analysis-01 6. Secure ND (10 min) Carl Williams - draft-cansever-6lowpan-integration-00 7. Stateful Header Compression (10 min) Kris Pister --=-VoWc1FeSoVPvm5pbl6T7 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 --=-VoWc1FeSoVPvm5pbl6T7-- From 6lowpan-bounces@ietf.org Mon Dec 03 12:45:24 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 1IzFMC-0006Bb-IY; Mon, 03 Dec 2007 12:45:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFMB-0006BN-Kr for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 12:45:23 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFMB-0003rU-1d for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 12:45:23 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lB3HjKb0008624; Mon, 3 Dec 2007 10:45:20 -0700 (MST) Subject: Re: [6lowpan] 6lowpan agenda From: Geoff Mulligan To: "Eunsook \"Eunah\" Kim" In-Reply-To: <77f1dba80712030936m6a64ab44l1687be47ec38842@mail.gmail.com> References: <1196700758.5871.49.camel@dellx1> <77f1dba80712030936m6a64ab44l1687be47ec38842@mail.gmail.com> Content-Type: text/plain Date: Mon, 03 Dec 2007 10:45:34 -0700 Message-Id: <1196703934.5871.65.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 6lowpan <6lowpan@lists.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 how much time do you need? geoff On Tue, 2007-12-04 at 02:36 +0900, Eunsook "Eunah" Kim wrote: > Dear Geoff & Carsten, > > We prepare the following two drafts. Would you include them in the agenda? > > - Application Recommendation > "draft-ekim-6lowpan-scenarios-01.txt" > > - 6Lowpan Routing Requirement > "draft-dokaspar-6lowpan-routreq-03.txt" > > Thanks, > > -eunsook > > On 12/4/07, Geoff Mulligan wrote: > > Folks, > > Attached is the current agenda for the meeting. > > > > Sorry for the late notice for the agenda. > > > > If there are other presentations or talks, please notify either Carsten > > or myself as soon as possible. > > > > geoff > > > > > > _______________________________________________ > > 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 Mon Dec 03 14:37: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 1IzH74-0007WF-6G; Mon, 03 Dec 2007 14:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzH73-0007W6-1q for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 14:37:53 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzH70-0007b1-As for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 14:37:53 -0500 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id lB3JbkE4009076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 3 Dec 2007 11:37:47 -0800 (PST) Message-ID: <47545B05.2060202@eecs.berkeley.edu> Date: Mon, 03 Dec 2007 11:37:41 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Hui Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> In-Reply-To: <4751F662.1080907@archrock.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gateway0.EECS.Berkeley.EDU id lB3JbkE4009076 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Cc: 6lowpan <6lowpan@lists.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 Jonathan - I'm not arguing for a different transport layer, I'm arguing=20 that there are more bits that can be compressed out of the existing=20 compressed UDP header. HC_UDP bits 3 through 7 are currently reserved. My suggestion is that we take one of them, e.g. bit 3, and use it to=20 indicate whether the 2 byte checksum is compressed. ---------- Checksum (bit 3) : 0: not compressed, carried inline (Section 10.3.2) 1: compressed (L2 MIC assumed). If this option is used, the packet=20 MUST be sent with L2 message integrity. ----------- If the node can't send with an L2 MIC, or it doesn't know if the message=20 will be sent with an L2 MIC, then it sends the checksum. If the packet=20 comes in with the checksum compressed, and the node can't send it that=20 way, then it calculates the checksum. I don't think that you can claim=20 that this is more of a layer violation than some of the other=20 compression that we're specifying already. I stand by my claim that an L2 MIC and no checksum on some or all hops=20 along a path will give you higher end to end integrity than sending the=20 checksum with no L2 MIC. Of course, you can send both, which is what=20 4944 forces you to do now if you want an L2 MIC. But the whole premise=20 of the document, as stated in the introduction, is that header=20 compression is important. If people want to avoid having an L2 MIC, that's fine. But if you use=20 one, then sending the 2 byte UDP checksum is silly. ksjp Jonathan Hui wrote: > > Yes, its clear that a 32-bit MIC is stronger than a 16 bit checksum.=20 > However, a MIC at L2 no matter how many bits it is is not end-to-end=20 > and does not negate the need for L4 integrity checks. Wanting to use a=20 > stronger checksum at L4 sounds like you want a different transport=20 > layer. You mentioned earlier on this list that losses apply to every=20 > link, even wired ones. So if you want stronger end-to-end integrity=20 > checks, use a transport layer other than UDP. That's the beauty of IP. > > --=20 > Jonathan Hui > > > Kris Pister wrote: >> A 16 bit checksum at L4 is redundant if every L2 hop has a 32 bit MIC. >> A 16 bit checksum at L4 is not sufficient protection against bit=20 >> errors without a 32 bit MIC somewhere (either L2 or L4/5, or both as=20 >> in HART). >> >> If you run 15.4 networks without a 32 bit MIC, I guarantee you that=20 >> you will get valid checksums on corrupted packets. Depending on the=20 >> network traffic, that might happen once per day per network. >> >> If a node knows that it's going to send a packet with a 32 bit L2=20 >> MIC, can't it be smart enough to compress out the 16 bit checksum? =20 >> Is that really violating the requirement? (It's a simple enough=20 >> change - we've got another bit in the HC2 header.) >> >> Put another way, which do you think is safer from an L3/L4 header=20 >> error detection perspective: >> A) sending packets over 10 hops with a 32 bit MIC at each hop and no=20 >> 16 bit checksum >> B) sending packets over 1 hop with no MIC and a 16 bit checksum >> >> The math is pretty clear. The measured data fits the math. >> >> ksjp >> >> Jonathan Hui wrote: >>> >>> Note that L2 message integrity doesn't provide end-to-end message=20 >>> integrity, which L4 checksums (that cover the L3 header) provide. >>> >>> --=20 >>> Jonathan Hui >>> >>> >>> Kris Pister wrote: >>>> Geoff - ooh, I like exceptions. >>>> Did we try to get an exception on the UDP checksum? It's painful=20 >>>> to leave that in the compressed header if we have L2 message=20 >>>> integrity. >>>> >>>> ksjp >>>> >>>> Geoff Mulligan wrote: >>>>> We have already received an exception from the IESG to IPsec on=20 >>>>> 6lowpan >>>>> devices. >>>>> >>>>> geoff >>>>> >>>>> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote: >>>>> =20 >>>>>> Hum... >>>>>> I had missed that; Seems that we have to make an exception :) If=20 >>>>>> you consider ISA100.11a, they already have security at L2 and L5,=20 >>>>>> it makes little sense to MUST IPSec on top of that. >>>>>> >>>>>> Pascal >>>>>> >>>>>> =20 >>>>>>> -----Original Message----- >>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>> Sent: Wednesday, November 28, 2007 8:03 PM >>>>>>> To: Pascal Thubert (pthubert) >>>>>>> Cc: 6lowpan >>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>> >>>>>>> Hmm. From 4294: >>>>>>> >>>>>>> "However, while authentication and encryption can each be NULL,=20 >>>>>>> they >>>>>>> MUST NOT both be NULL." >>>>>>> >>>>>>> ksjp >>>>>>> >>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> =20 >>>>>>>> Hi Kris: >>>>>>>> >>>>>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL=20 >>>>>>>> encryption and authentication for >>>>>>>> =20 >>>>>>> interoperability reasons. >>>>>>> =20 >>>>>>>> On the general question of RFC 4294 itself: I'm not sure the=20 >>>>>>>> work was ever done. I hope someone >>>>>>>> =20 >>>>>> >from the list can help? >>>>>> =20 >>>>>>>> If the answer is unclear, and considering that we are=20 >>>>>>>> re-chartering the group, maybe we could have >>>>>>>> =20 >>>>>>> a work item to specify the instantiation of RFC 4294 for LoWPAN=20 >>>>>>> nodes? >>>>>>> =20 >>>>>>>> Pascal >>>>>>>> ________________________________________ >>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>> Cc: 6lowpan >>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>>> >>>>>>>> Is there an email thread somewhere that discusses the impact on=20 >>>>>>>> 6LoWPAN of the security >>>>>>>> =20 >>>>>>> requirements of 4294 and 4303? >>>>>>> =20 >>>>>>>> My first quick readthrough makes me very uncomfortable that=20 >>>>>>>> some of the mandates are going to be >>>>>>>> =20 >>>>>>> ugly from a header standpoint. >>>>>>> =20 >>>>>>>> ksjp >>>>>>>> >>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>> Hi JP: >>>>>>>> >>>>>>>> Thanks a bunch for this charter. I'll try not to rephrase what=20 >>>>>>>> was already discussed with Christian, >>>>>>>> =20 >>>>>>> Anders, Philip and Misha. >>>>>>> =20 >>>>>>>> There's an additional item I'd wish to see either in ROLL or=20 >>>>>>>> 6LoWPAN and I do not know exactly >>>>>>>> =20 >>>>>>> where it belongs, maybe both. The question is whether we need to=20 >>>>>>> and can document how RFC 4294 >>>>>>> applies for sensors, and M2M devices in general, whether they=20 >>>>>>> act as hosts or as routers. >>>>>>> =20 >>>>>>>> I've seen IPv6 presented as a Pandora box that drags just too=20 >>>>>>>> much stuff to be incorporated in a >>>>>>>> =20 >>>>>>> sensory device. For instance, at the moment, SP100.11a endorses=20 >>>>>>> 6LoWPAN formats but it's not so clear >>>>>>> at all that IPv6 itself is mandated. A clear spec with=20 >>>>>>> well-documented implementation could be a >>>>>>> formidable tool to despond to Fear, Uncertainty and Defiance. >>>>>>> =20 >>>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can=20 >>>>>>>> do without multicast at all if ND is >>>>>>>> =20 >>>>>>> supported some other way (such as suggested in:=20 >>>>>>> http://www.ietf.org/internet-drafts/draft-thubert- >>>>>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and=20 >>>>>>> authentication is enough etc, etc... >>>>>>> =20 >>>>>>>> Being able to define one minimum set and maybe a few other=20 >>>>>>>> profiles for the use cases that we >>>>>>>> =20 >>>>>>> selected could help tremendously. >>>>>>> =20 >>>>>>>> Otherwise I find the charter real well written and easy to=20 >>>>>>>> digest. >>From the MANEMO experience, I >>>>>>>> =20 >>>>>>> expect that some arguments about the relative applicability of=20 >>>>>>> existing MANET protocols will be >>>>>>> difficult to prove without some good simulation work running=20 >>>>>>> agreed-upon scenarios. >>>>>>> =20 >>>>>>>> Finally, I'm a bit confused that it seems that both IPv4 and=20 >>>>>>>> IPv6 seem supported. Ipv4 comes with a >>>>>>>> =20 >>>>>>> lot of overhead like DHCP. I suggest that when trouble comes and=20 >>>>>>> things can not be done in a common >>>>>>> fashion for both IP protocols, hen we prioritize IPv6. >>>>>>> =20 >>>>>>>> Unfortunately, I can not make it to Vancouver, but I do feel=20 >>>>>>>> that the work is really needed so >>>>>>>> =20 >>>>>>> please count my vote in for the adoption of the WG. >>>>>>> =20 >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jean Philippe Vasseur (jvasseur) >>>>>>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>>>>>> To: rsn@ietf.org >>>>>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> As promised, here is the new proposed Working Group, which=20 >>>>>>>> reflects the >>>>>>>> number of comments/suggestions that we received, the pre-WG=20 >>>>>>>> consensus, ... >>>>>>>> >>>>>>>> Thanks to Dave Ward (RTD AD) for his input. >>>>>>>> >>>>>>>> Proposed RL2N WG Charter >>>>>>>> >>>>>>>> Description of Working Group >>>>>>>> >>>>>>>> L2Ns (Low power and Lossy networks) are typically composed of=20 >>>>>>>> many embedded >>>>>>>> devices with limited power, memory, and processing resources=20 >>>>>>>> interconnected >>>>>>>> by a variety of wireless links, such as IEEE 802.15.4,=20 >>>>>>>> Bluetooth, Low Power >>>>>>>> WiFi. >>>>>>>> >>>>>>>> L2Ns are transitioning to an end-to-end IP-based solution to=20 >>>>>>>> avoid the >>>>>>>> problems of non-interoperable networks interconnected by protoco= l >>>>>>>> translation gateways and proxies. In addition, L2Ns have=20 >>>>>>>> specific routing >>>>>>>> requirements that are not currently met by existing routing=20 >>>>>>>> protocols, such >>>>>>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be=20 >>>>>>>> designed to take >>>>>>>> into consideration the specific power, capabilities, attributes=20 >>>>>>>> and >>>>>>>> functional characteristics of the links and nodes in the network. >>>>>>>> >>>>>>>> >>>>>>>> There is a wide scope of application areas for L2Ns, including=20 >>>>>>>> industrial >>>>>>>> monitoring, building automation (HVAC, lighting/access=20 >>>>>>>> control), connected >>>>>>>> home, healthcare, environmental monitoring, agricultural, smart=20 >>>>>>>> cities, >>>>>>>> logistics, assets tracking, and refrigeration. The L2N WG will=20 >>>>>>>> focus on >>>>>>>> routing solutions for a subset of these deployment scenarios,=20 >>>>>>>> namely >>>>>>>> industrial, connected home/building and urban applications. The=20 >>>>>>>> Working >>>>>>>> Group will determine the routing requirements for these scenario= s. >>>>>>>> >>>>>>>> >>>>>>>> The Working Group will provide a routing framework for these=20 >>>>>>>> application >>>>>>>> scenarios that provides high reliability in the presence of=20 >>>>>>>> time varying >>>>>>>> loss characteristics and connectivity while permitting=20 >>>>>>>> low-power operation >>>>>>>> with very modest memory and CPU pressure. >>>>>>>> >>>>>>>> >>>>>>>> The Working Group will pay a particular attention to routing=20 >>>>>>>> security and >>>>>>>> manageability (e.g self managing/configuration) issues, which ar= e >>>>>>>> particularly critical for L2Ns. >>>>>>>> >>>>>>>> Work Items: >>>>>>>> >>>>>>>> - Produce use cases documents for Industrial, Connected Home,=20 >>>>>>>> Building and >>>>>>>> urban application networks. Each document will describe the use=20 >>>>>>>> case and the >>>>>>>> associated routing protocol requirements. The documents will=20 >>>>>>>> progress in >>>>>>>> collaboration with the 6lowpan Working Group (INT area). >>>>>>>> >>>>>>>> >>>>>>>> - Survey the applicability of existing protocols to L2Ns. The=20 >>>>>>>> aim of this >>>>>>>> document will be to analyze the scaling and characteristics of=20 >>>>>>>> existing >>>>>>>> protocols and identify whether or not they meet the routing=20 >>>>>>>> requirements of >>>>>>>> the L2Ns applications identified above. Existing IGPs, MANET,=20 >>>>>>>> NEMO, DTN >>>>>>>> routing protocols will be part of evaluation. >>>>>>>> >>>>>>>> - Specification of routing metrics used in path calculation.=20 >>>>>>>> This includes >>>>>>>> static and dynamic link/nodes attributes required for routing=20 >>>>>>>> in L2Ns. >>>>>>>> >>>>>>>> - Provide an architectural framework for routing and path=20 >>>>>>>> selection at Layer >>>>>>>> 3 (Routing for L2N Architecture) >>>>>>>> * Decide whether the L2Ns routing protocol require a distributed= , >>>>>>>> centralized path computation models or both. >>>>>>>> * Decide whether the L2N routing protocol requires a=20 >>>>>>>> hierarchical routing >>>>>>>> approach. >>>>>>>> >>>>>>>> - Produce a security framework for routing in L2Ns. >>>>>>>> >>>>>>>> Goals And Milestones: >>>>>>>> >>>>>>>> >>>>>>>> April 2008 Submit Use case/Routing requirements for Industrial,=20 >>>>>>>> Connected >>>>>>>> Home, Building and Urban networks applications to the IESG to=20 >>>>>>>> be considered >>>>>>>> as an Informational RFC. >>>>>>>> >>>>>>>> August 2008: Submit Routing metrics for L2Ns document to the=20 >>>>>>>> IESG to be >>>>>>>> considered as an Informational RFC. >>>>>>>> >>>>>>>> September 2008: Submit first draft of the Routing for L2Ns=20 >>>>>>>> Architecture >>>>>>>> document (summary of requirements, path computation model, >>>>>>>> flat/hierarchy,=C5=A0). >>>>>>>> >>>>>>>> November 2008: Submit Protocol Survey to the IESG to be=20 >>>>>>>> considered as an >>>>>>>> Informational RFC. >>>>>>>> >>>>>>>> January 2009 Submit Security Framework for L2Ns to the IESG to=20 >>>>>>>> be considered >>>>>>>> as an Informational RFC >>>>>>>> >>>>>>>> February 2009: Submit the Routing for L2Ns Architecture=20 >>>>>>>> document (summary >>>>>>>> of requirements, metrics and attributes, path selection model)=20 >>>>>>>> to the IESG >>>>>>>> as an Informational RFC. >>>>>>>> >>>>>>>> March 2009: Recharter. >>>>>>>> >>>>>>>> >>>>>>>> Please comment/suggest/... >>>>>>>> >>>>>>>> See you in Vancouver. >>>>>>>> >>>>>>>> JP and David. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> RSN mailing list >>>>>>>> RSN@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> RSN mailing list >>>>>>>> RSN@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>> >>>>>>>> >>>>>>>> =20 >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/6lowpan >>>>>> =20 >>>>> >>>>> =20 >>>> >>>> _______________________________________________ >>>> 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 Mon Dec 03 16:21: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 1IzIj0-0002ED-58; Mon, 03 Dec 2007 16:21:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIiy-0002C4-NF for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 16:21:08 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzIiw-0005Pz-6g for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 16:21:08 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id F050DA95F8; Mon, 3 Dec 2007 13:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-10 required=6.6 tests=[BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDNvZm6VgRNl; Mon, 3 Dec 2007 13:21:02 -0800 (PST) Received: from [130.129.17.153] (dhcp-1199.ietf70.org [130.129.17.153]) by mail.sf.archrock.com (Postfix) with ESMTP id A6B72A95E9; Mon, 3 Dec 2007 13:21:02 -0800 (PST) Message-ID: <4754733C.2050001@archrock.com> Date: Mon, 03 Dec 2007 13:21:00 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> In-Reply-To: <47545B05.2060202@eecs.berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Cc: 6lowpan <6lowpan@lists.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 Kris, I'm still not seeing how L2 MICs negate the need for L4 MICs. L2 MICs=20 are verified and recomputed hop by hop, where as L4 MICs are not. There=20 are a couple reasons why L2 MICs do not cover all of the functionality=20 of L4 MICs. First, an intermediate router could incorrectly accept a=20 corrupted packet or incorrectly mutate the L2 payload yet compute a MIC=20 that will indicate the packet is still valid to the next hop. Second,=20 the L2 MIC as currently defined by 802.15.4 only covers the bits=20 contained within the frame. It does not take in any knowledge of the=20 upper layers. An L4 MIC necessarily covers the IPv6 pseudo-header and=20 does so in 6LoWPAN even if some of those bits are elided. The only case I see where the L2 MIC covers every bit of functionality=20 an L4 MIC might provide is if the IPv6 datagram is carried uncompressed=20 within the L2 frame and communication occurs within link-local scope. -- Jonathan Hui Kris Pister wrote: > Jonathan - I'm not arguing for a different transport layer, I'm arguing= =20 > that there are more bits that can be compressed out of the existing=20 > compressed UDP header. > HC_UDP bits 3 through 7 are currently reserved. > My suggestion is that we take one of them, e.g. bit 3, and use it to=20 > indicate whether the 2 byte checksum is compressed. > ---------- > Checksum (bit 3) : > 0: not compressed, carried inline (Section 10.3.2) >=20 > 1: compressed (L2 MIC assumed). If this option is used, the packet= =20 > MUST be sent with L2 message integrity. > ----------- > If the node can't send with an L2 MIC, or it doesn't know if the messag= e=20 > will be sent with an L2 MIC, then it sends the checksum. If the packet= =20 > comes in with the checksum compressed, and the node can't send it that=20 > way, then it calculates the checksum. I don't think that you can claim= =20 > that this is more of a layer violation than some of the other=20 > compression that we're specifying already. > I stand by my claim that an L2 MIC and no checksum on some or all hops=20 > along a path will give you higher end to end integrity than sending the= =20 > checksum with no L2 MIC. Of course, you can send both, which is what=20 > 4944 forces you to do now if you want an L2 MIC. But the whole premise= =20 > of the document, as stated in the introduction, is that header=20 > compression is important. > If people want to avoid having an L2 MIC, that's fine. But if you use=20 > one, then sending the 2 byte UDP checksum is silly. >=20 > ksjp >=20 > Jonathan Hui wrote: >> >> Yes, its clear that a 32-bit MIC is stronger than a 16 bit checksum.=20 >> However, a MIC at L2 no matter how many bits it is is not end-to-end=20 >> and does not negate the need for L4 integrity checks. Wanting to use a= =20 >> stronger checksum at L4 sounds like you want a different transport=20 >> layer. You mentioned earlier on this list that losses apply to every=20 >> link, even wired ones. So if you want stronger end-to-end integrity=20 >> checks, use a transport layer other than UDP. That's the beauty of IP. >> >> --=20 >> Jonathan Hui >> >> >> Kris Pister wrote: >>> A 16 bit checksum at L4 is redundant if every L2 hop has a 32 bit MIC= . >>> A 16 bit checksum at L4 is not sufficient protection against bit=20 >>> errors without a 32 bit MIC somewhere (either L2 or L4/5, or both as=20 >>> in HART). >>> >>> If you run 15.4 networks without a 32 bit MIC, I guarantee you that=20 >>> you will get valid checksums on corrupted packets. Depending on the=20 >>> network traffic, that might happen once per day per network. >>> >>> If a node knows that it's going to send a packet with a 32 bit L2=20 >>> MIC, can't it be smart enough to compress out the 16 bit checksum? =20 >>> Is that really violating the requirement? (It's a simple enough=20 >>> change - we've got another bit in the HC2 header.) >>> >>> Put another way, which do you think is safer from an L3/L4 header=20 >>> error detection perspective: >>> A) sending packets over 10 hops with a 32 bit MIC at each hop and no=20 >>> 16 bit checksum >>> B) sending packets over 1 hop with no MIC and a 16 bit checksum >>> >>> The math is pretty clear. The measured data fits the math. >>> >>> ksjp >>> >>> Jonathan Hui wrote: >>>> >>>> Note that L2 message integrity doesn't provide end-to-end message=20 >>>> integrity, which L4 checksums (that cover the L3 header) provide. >>>> >>>> --=20 >>>> Jonathan Hui >>>> >>>> >>>> Kris Pister wrote: >>>>> Geoff - ooh, I like exceptions. >>>>> Did we try to get an exception on the UDP checksum? It's painful=20 >>>>> to leave that in the compressed header if we have L2 message=20 >>>>> integrity. >>>>> >>>>> ksjp >>>>> >>>>> Geoff Mulligan wrote: >>>>>> We have already received an exception from the IESG to IPsec on=20 >>>>>> 6lowpan >>>>>> devices. >>>>>> >>>>>> geoff >>>>>> >>>>>> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote= : >>>>>> =20 >>>>>>> Hum... >>>>>>> I had missed that; Seems that we have to make an exception :) If=20 >>>>>>> you consider ISA100.11a, they already have security at L2 and L5,= =20 >>>>>>> it makes little sense to MUST IPSec on top of that. >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>> =20 >>>>>>>> -----Original Message----- >>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>>> Sent: Wednesday, November 28, 2007 8:03 PM >>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>> Cc: 6lowpan >>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>>> >>>>>>>> Hmm. From 4294: >>>>>>>> >>>>>>>> "However, while authentication and encryption can each be NULL,=20 >>>>>>>> they >>>>>>>> MUST NOT both be NULL." >>>>>>>> >>>>>>>> ksjp >>>>>>>> >>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>> =20 >>>>>>>>> Hi Kris: >>>>>>>>> >>>>>>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL=20 >>>>>>>>> encryption and authentication for >>>>>>>>> =20 >>>>>>>> interoperability reasons. >>>>>>>> =20 >>>>>>>>> On the general question of RFC 4294 itself: I'm not sure the=20 >>>>>>>>> work was ever done. I hope someone >>>>>>>>> =20 >>>>>>> >from the list can help? >>>>>>> =20 >>>>>>>>> If the answer is unclear, and considering that we are=20 >>>>>>>>> re-chartering the group, maybe we could have >>>>>>>>> =20 >>>>>>>> a work item to specify the instantiation of RFC 4294 for LoWPAN=20 >>>>>>>> nodes? >>>>>>>> =20 >>>>>>>>> Pascal >>>>>>>>> ________________________________________ >>>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>> Cc: 6lowpan >>>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charte= r >>>>>>>>> >>>>>>>>> Is there an email thread somewhere that discusses the impact on= =20 >>>>>>>>> 6LoWPAN of the security >>>>>>>>> =20 >>>>>>>> requirements of 4294 and 4303? >>>>>>>> =20 >>>>>>>>> My first quick readthrough makes me very uncomfortable that=20 >>>>>>>>> some of the mandates are going to be >>>>>>>>> =20 >>>>>>>> ugly from a header standpoint. >>>>>>>> =20 >>>>>>>>> ksjp >>>>>>>>> >>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>> Hi JP: >>>>>>>>> >>>>>>>>> Thanks a bunch for this charter. I'll try not to rephrase what=20 >>>>>>>>> was already discussed with Christian, >>>>>>>>> =20 >>>>>>>> Anders, Philip and Misha. >>>>>>>> =20 >>>>>>>>> There's an additional item I'd wish to see either in ROLL or=20 >>>>>>>>> 6LoWPAN and I do not know exactly >>>>>>>>> =20 >>>>>>>> where it belongs, maybe both. The question is whether we need to= =20 >>>>>>>> and can document how RFC 4294 >>>>>>>> applies for sensors, and M2M devices in general, whether they=20 >>>>>>>> act as hosts or as routers. >>>>>>>> =20 >>>>>>>>> I've seen IPv6 presented as a Pandora box that drags just too=20 >>>>>>>>> much stuff to be incorporated in a >>>>>>>>> =20 >>>>>>>> sensory device. For instance, at the moment, SP100.11a endorses=20 >>>>>>>> 6LoWPAN formats but it's not so clear >>>>>>>> at all that IPv6 itself is mandated. A clear spec with=20 >>>>>>>> well-documented implementation could be a >>>>>>>> formidable tool to despond to Fear, Uncertainty and Defiance. >>>>>>>> =20 >>>>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can=20 >>>>>>>>> do without multicast at all if ND is >>>>>>>>> =20 >>>>>>>> supported some other way (such as suggested in:=20 >>>>>>>> http://www.ietf.org/internet-drafts/draft-thubert- >>>>>>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and=20 >>>>>>>> authentication is enough etc, etc... >>>>>>>> =20 >>>>>>>>> Being able to define one minimum set and maybe a few other=20 >>>>>>>>> profiles for the use cases that we >>>>>>>>> =20 >>>>>>>> selected could help tremendously. >>>>>>>> =20 >>>>>>>>> Otherwise I find the charter real well written and easy to=20 >>>>>>>>> digest. >>From the MANEMO experience, I >>>>>>>>> =20 >>>>>>>> expect that some arguments about the relative applicability of=20 >>>>>>>> existing MANET protocols will be >>>>>>>> difficult to prove without some good simulation work running=20 >>>>>>>> agreed-upon scenarios. >>>>>>>> =20 >>>>>>>>> Finally, I'm a bit confused that it seems that both IPv4 and=20 >>>>>>>>> IPv6 seem supported. Ipv4 comes with a >=20 >>>>>>>>> =20 >>>>>>>> lot of overhead like DHCP. I suggest that when trouble comes and= =20 >>>>>>>> things can not be done in a common >>>>>>>> fashion for both IP protocols, hen we prioritize IPv6. >>>>>>>> =20 >>>>>>>>> Unfortunately, I can not make it to Vancouver, but I do feel=20 >>>>>>>>> that the work is really needed so >>>>>>>>> =20 >>>>>>>> please count my vote in for the adoption of the WG. >>>>>>>> =20 >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Pascal >>>>>>>>> >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Jean Philippe Vasseur (jvasseur) >>>>>>>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>>>>>>> To: rsn@ietf.org >>>>>>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>>>> >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> As promised, here is the new proposed Working Group, which=20 >>>>>>>>> reflects the >>>>>>>>> number of comments/suggestions that we received, the pre-WG=20 >>>>>>>>> consensus, ... >>>>>>>>> >>>>>>>>> Thanks to Dave Ward (RTD AD) for his input. >>>>>>>>> >>>>>>>>> Proposed RL2N WG Charter >>>>>>>>> >>>>>>>>> Description of Working Group >>>>>>>>> >>>>>>>>> L2Ns (Low power and Lossy networks) are typically composed of=20 >>>>>>>>> many embedded >>>>>>>>> devices with limited power, memory, and processing resources=20 >>>>>>>>> interconnected >>>>>>>>> by a variety of wireless links, such as IEEE 802.15.4,=20 >>>>>>>>> Bluetooth, Low Power >>>>>>>>> WiFi. >>>>>>>>> >>>>>>>>> L2Ns are transitioning to an end-to-end IP-based solution to=20 >>>>>>>>> avoid the >>>>>>>>> problems of non-interoperable networks interconnected by protoc= ol >>>>>>>>> translation gateways and proxies. In addition, L2Ns have=20 >>>>>>>>> specific routing >>>>>>>>> requirements that are not currently met by existing routing=20 >>>>>>>>> protocols, such >>>>>>>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be=20 >>>>>>>>> designed to take >>>>>>>>> into consideration the specific power, capabilities, attributes= =20 >>>>>>>>> and >>>>>>>>> functional characteristics of the links and nodes in the networ= k. >>>>>>>>> >>>>>>>>> >>>>>>>>> There is a wide scope of application areas for L2Ns, including=20 >>>>>>>>> industrial >>>>>>>>> monitoring, building automation (HVAC, lighting/access=20 >>>>>>>>> control), connected >>>>>>>>> home, healthcare, environmental monitoring, agricultural, smart= =20 >>>>>>>>> cities, >>>>>>>>> logistics, assets tracking, and refrigeration. The L2N WG will=20 >>>>>>>>> focus on >>>>>>>>> routing solutions for a subset of these deployment scenarios,=20 >>>>>>>>> namely >>>>>>>>> industrial, connected home/building and urban applications. The= =20 >>>>>>>>> Working >>>>>>>>> Group will determine the routing requirements for these scenari= os. >>>>>>>>> >>>>>>>>> >>>>>>>>> The Working Group will provide a routing framework for these=20 >>>>>>>>> application >>>>>>>>> scenarios that provides high reliability in the presence of=20 >>>>>>>>> time varying >>>>>>>>> loss characteristics and connectivity while permitting=20 >>>>>>>>> low-power operation >>>>>>>>> with very modest memory and CPU pressure. >>>>>>>>> >>>>>>>>> >>>>>>>>> The Working Group will pay a particular attention to routing=20 >>>>>>>>> security and >>>>>>>>> manageability (e.g self managing/configuration) issues, which a= re >>>>>>>>> particularly critical for L2Ns. >>>>>>>>> >>>>>>>>> Work Items: >>>>>>>>> >>>>>>>>> - Produce use cases documents for Industrial, Connected Home,=20 >>>>>>>>> Building and >>>>>>>>> urban application networks. Each document will describe the use= =20 >>>>>>>>> case and the >>>>>>>>> associated routing protocol requirements. The documents will=20 >>>>>>>>> progress in >>>>>>>>> collaboration with the 6lowpan Working Group (INT area). >>>>>>>>> >>>>>>>>> >>>>>>>>> - Survey the applicability of existing protocols to L2Ns. The=20 >>>>>>>>> aim of this >>>>>>>>> document will be to analyze the scaling and characteristics of=20 >>>>>>>>> existing >>>>>>>>> protocols and identify whether or not they meet the routing=20 >>>>>>>>> requirements of >>>>>>>>> the L2Ns applications identified above. Existing IGPs, MANET,=20 >>>>>>>>> NEMO, DTN >>>>>>>>> routing protocols will be part of evaluation. >>>>>>>>> >>>>>>>>> - Specification of routing metrics used in path calculation.=20 >>>>>>>>> This includes >>>>>>>>> static and dynamic link/nodes attributes required for routing=20 >>>>>>>>> in L2Ns. >>>>>>>>> >>>>>>>>> - Provide an architectural framework for routing and path=20 >>>>>>>>> selection at Layer >>>>>>>>> 3 (Routing for L2N Architecture) >>>>>>>>> * Decide whether the L2Ns routing protocol require a distribute= d, >>>>>>>>> centralized path computation models or both. >>>>>>>>> * Decide whether the L2N routing protocol requires a=20 >>>>>>>>> hierarchical routing >>>>>>>>> approach. >>>>>>>>> >>>>>>>>> - Produce a security framework for routing in L2Ns. >>>>>>>>> >>>>>>>>> Goals And Milestones: >>>>>>>>> >>>>>>>>> >>>>>>>>> April 2008 Submit Use case/Routing requirements for Industrial,= =20 >>>>>>>>> Connected >>>>>>>>> Home, Building and Urban networks applications to the IESG to=20 >>>>>>>>> be considered >>>>>>>>> as an Informational RFC. >>>>>>>>> >>>>>>>>> August 2008: Submit Routing metrics for L2Ns document to the=20 >>>>>>>>> IESG to be >>>>>>>>> considered as an Informational RFC. >>>>>>>>> >>>>>>>>> September 2008: Submit first draft of the Routing for L2Ns=20 >>>>>>>>> Architecture >>>>>>>>> document (summary of requirements, path computation model, >>>>>>>>> flat/hierarchy,=C5=A0). >>>>>>>>> >>>>>>>>> November 2008: Submit Protocol Survey to the IESG to be=20 >>>>>>>>> considered as an >>>>>>>>> Informational RFC. >>>>>>>>> >>>>>>>>> January 2009 Submit Security Framework for L2Ns to the IESG to=20 >>>>>>>>> be considered >>>>>>>>> as an Informational RFC >>>>>>>>> >>>>>>>>> February 2009: Submit the Routing for L2Ns Architecture=20 >>>>>>>>> document (summary >>>>>>>>> of requirements, metrics and attributes, path selection model)=20 >>>>>>>>> to the IESG >>>>>>>>> as an Informational RFC. >>>>>>>>> >>>>>>>>> March 2009: Recharter. >>>>>>>>> >>>>>>>>> >>>>>>>>> Please comment/suggest/... >>>>>>>>> >>>>>>>>> See you in Vancouver. >>>>>>>>> >>>>>>>>> JP and David. >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> RSN mailing list >>>>>>>>> RSN@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> RSN mailing list >>>>>>>>> RSN@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>>> >>>>>>>>> >>>>>>>>> =20 >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/6lowpan >>>>>>> =20 >>>>>> >>>>>> =20 >>>>> >>>>> _______________________________________________ >>>>> 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 Mon Dec 03 16:22:27 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 1IzIkF-0004PZ-PP; Mon, 03 Dec 2007 16:22:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIkE-0004PS-Q5 for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 16:22:26 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzIkB-0005TK-Q5 for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 16:22:26 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from localhost (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lB3LM7PQ016326; Mon, 3 Dec 2007 22:22:07 +0100 (CET) Message-Id: From: Carsten Bormann To: Kris Pister In-Reply-To: <4751F0F9.6000402@eecs.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Mon, 3 Dec 2007 13:22:05 -0800 References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> X-Mailer: Apple Mail (2.915) X-Spam-Score: 4.5 (++++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Dec 01 2007, at 15:40, Kris Pister wrote: > A 16 bit checksum at L4 is redundant if every L2 hop has a 32 bit MIC. > A 16 bit checksum at L4 is not sufficient protection against bit > errors without a 32 bit MIC somewhere (either L2 or L4/5, or both as > in HART). We *could* do a form of header compression that consumes (i.e. checks) the L4 checksum at the compressing end and reproduces it at the decompressing end (assuming it is not hidden by ESP etc, in which case a IPv4 style zero checksum wouldn't help either); a leaf node decompressor would then do nothing (as the onus of checking the checksum has been moved to the compressing end plus the MIC check). In ROHC, we avoided this, as it runs counter to the end-to-end nature of the checksum; also, the checksum is useful as an additional guard against mis-reconstructed packets due to decompressor confusion. This does not mean that this decision is the right one for 6lowpan; this is one example of what needs to be talked about in "Problem Statement for Stateful Header Compression". Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 03 16:26:09 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 1IzIno-0007g1-Pr; Mon, 03 Dec 2007 16:26:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzInm-0007ft-Mx for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 16:26:06 -0500 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzInj-0005ap-I1 for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 16:26:06 -0500 Received: from [10.0.1.3] (213-216-234-9-Tuira-TR1.suomi.net [213.216.234.9]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id lB3LPrZB014028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 23:25:53 +0200 Message-ID: <47547463.1030705@sensinode.com> Date: Mon, 03 Dec 2007 23:25:55 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [6lowpan] profile References: <750929.34078.qm@web81904.mail.mud.yahoo.com> <1196395279.5692.78.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC04D9DFB1@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D9DFB1@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auth-smtp.nebula.fi id lB3LPrZB014028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 Cc: 6lowpan <6lowpan@lists.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 Pascal, I am on the same line with you here, and would love to see an RFC coming=20 from the WG effort defining a minimum profile of lowpan and IPv6=20 features. Jonathan and I wrote an interop ID, presented in Chicago,=20 which could actually be used as a base for writing a 6lowpan profile ID.=20 I would be willing to work on this. Could you guys please discuss this=20 during the WG meeting.. I know that 802.15.4+lowpan+IPv6+UDP can be implemented on minimal 8-bit=20 uCs, we can achieve interoperability (in vendor groups right now), and=20 other standards bodies would be smart to use 6lowpan; but we have to=20 communicate that clearly outside the WG. RFC 4944 is too cryptic for=20 this purpose, and a lot of information needs to be gathered from many=20 places. - Zach Pascal Thubert (pthubert) wrote: > Hi Geoff: >=20 > It's not just about IPSec though: >=20 > There are a number of companies out there designing and integrating sil= icon for LoWPANs. IPv6 is not necessarily a target for them when it does = not mean immediate sales. Also, they do not necessarily know what support= ing IPv6 means for their devices and what the associated cost will be. Th= ey could use some help and we can provide it in the form of an RFC that s= ummarizes a LoWPAN profile for IPv6.=20 >=20 > That profile should not include IPSec; that profile should include 6LoW= PAN - RFC 4944 is not listed in RFC 4294 for obvious reasons-, and the ND= solution we will come up with. That profile should be designed to enable= very low end embedded systems (an 8-bit processor in my Mc D's toy) to r= un IPv6. >=20 > Once we have that published with IETF stamp of approval, it becomes pos= sible for people out there to: >=20 > - guarantee interoperability > - develop and distribute an opensource stack > - publish actual numbers for footprint and performance on various imple= mentations > - go to standard bodies such as ISA SP100 and present those numbers to = support IPv6 adoption. >=20 > I do think it is worth the effort. If 6MAN is the place, so be it. >=20 > Pascal >> -----Original Message----- >> From: Geoff Mulligan [mailto:geoff@mulligan.com] >> Sent: Friday, November 30, 2007 5:01 AM >> To: gabriel montenegro >> Cc: 6lowpan >> Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working= Charter >> >> I will search back, but m recollection was that we (you) did argue wit= h >> the IESG that devices such as these (small 8bit micro sensors) would n= ot >> be capable of IPsec and after a few emails back a forth we were told >> that 6lowpan devices did not need to support IPsec. >> >> Again I will look back and see if I can find the email exchange and I'= ll >> ask Russ. >> >> geoff >> >> On Thu, 2007-11-29 at 17:13 -0800, gabriel montenegro wrote: >>> Geoff, >>> >>> Could you please provide a pointer to the message or document with >>> that exception? >>> This is an important item and it should be added to the group's Wiki >>> page. >>> >>> My recollection is different, but I may have just forgotten. What I >>> recollect is that back when we >>> were starting the working group and initiating work on the problem >>> statement draft, was that the recommendation >>> was to stay away from issuing our own IPv6 profile, precisely because >>> saying things like ("IPsec is not recommended in lowpan >>> environments") was a sure-fire way to invite controversy at the IESG. >>> E.g., IPv6 mandates IPsec, so how could >>> we ever claim to support IPv6.... This debate probably is better had >>> in 6man in terms of a revision of the hosts >>> requirements, rather than in any particular WG. >>> >>> -gabriel >>> >>> ----- Original Message ---- >>> From: Geoff Mulligan >>> To: Kris Pister >>> Cc: 6lowpan <6lowpan@lists.ietf.org> >>> Sent: Thursday, November 29, 2007 11:09:02 AM >>> Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Workin= g >>> Charter >>> >>> We did not try to get an exception to UDP checksums. >>> >>> geoff >>> >>> On Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote: >>>> Geoff - ooh, I like exceptions. >>>> Did we try to get an exception on the UDP checksum? It's painful >>> to >>>> leave that in the compressed header if we have L2 message integrity. >>>> >>>> ksjp >>>> >>>> Geoff Mulligan wrote: >>>>> We have already received an exception from the IESG to IPsec on >>> 6lowpan >>>>> devices. >>>>> >>>>> geoff >>>>> >>>>> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) >>> wrote: >>>>>> Hum... >>>>>> >>>>>> I had missed that; Seems that we have to make an exception :) If >>> you consider ISA100.11a, they already have security at L2 and L5, it >>> makes little sense to MUST IPSec on top of that. >>>>>> Pascal >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>> Sent: Wednesday, November 28, 2007 8:03 PM >>>>>>> To: Pascal Thubert (pthubert) >>>>>>> Cc: 6lowpan >>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>> >>>>>>> Hmm. From 4294: >>>>>>> >>>>>>> "However, while authentication and encryption can each be NULL, >>> they >>>>>>> MUST NOT both be NULL." >>>>>>> >>>>>>> ksjp >>>>>>> >>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> >>>>>>>> Hi Kris: >>>>>>>> >>>>>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL >>> encryption and authentication for >>>>>>> interoperability reasons. >>>>>>> >>>>>>>> On the general question of RFC 4294 itself: I'm not sure the >>> work was ever done. I hope someone >>>>>> >from the list can help? >>>>>> >>>>>>>> If the answer is unclear, and considering that we are >>> re-chartering the group, maybe we could have >>>>>>> a work item to specify the instantiation of RFC 4294 for LoWPAN >>> nodes? >>>>>>>> Pascal >>>>>>>> ________________________________________ >>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>> Cc: 6lowpan >>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working >>> Charter >>>>>>>> Is there an email thread somewhere that discusses the impact on >>> 6LoWPAN of the security >>>>>>> requirements of 4294 and 4303? >>>>>>> >>>>>>>> My first quick readthrough makes me very uncomfortable that >>> some of the mandates are going to be >>>>>>> ugly from a header standpoint. >>>>>>> >>>>>>>> ksjp >>>>>>>> >>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>> Hi JP: >>>>>>>> >>>>>>>> Thanks a bunch for this charter. I'll try not to rephrase what >>> was already discussed with Christian, >>>>>>> Anders, Philip and Misha. >>>>>>> >>>>>>>> There's an additional item I'd wish to see either in ROLL or >>> 6LoWPAN and I do not know exactly >>>>>>> where it belongs, maybe both. The question is whether we need to >>> and can document how RFC 4294 >>>>>>> applies for sensors, and M2M devices in general, whether they >>> act as hosts or as routers. >>>>>>>> I've seen IPv6 presented as a Pandora box that drags just too >>> much stuff to be incorporated in a >>>>>>> sensory device. For instance, at the moment, SP100.11a endorses >>> 6LoWPAN formats but it's not so clear >>>>>>> at all that IPv6 itself is mandated. A clear spec with >>> well-documented implementation could be a >>>>>>> formidable tool to despond to Fear, Uncertainty and Defiance. >>>>>>> >>>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can >>> do without multicast at all if ND is >>>>>>> supported some other way (such as suggested in: >>> http://www.ietf.org/internet-drafts/draft-thubert- >>>>>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and >>> authentication is enough etc, etc... >>>>>>>> Being able to define one minimum set and maybe a few other >>> profiles for the use cases that we >>>>>>> selected could help tremendously. >>>>>>> >>>>>>>> Otherwise I find the charter real well written and easy to >>> digest. >>From the MANEMO experience, I >>>>>>> expect that some arguments about the relative applicability of >>> existing MANET protocols will be >>>>>>> difficult to prove without some good simulation work running >>> agreed-upon scenarios. >>>>>>>> Finally, I'm a bit confused that it seems that both IPv4 and >>> IPv6 seem supported. Ipv4 comes with a >>>>>>> lot of overhead like DHCP. I suggest that when trouble comes and >>> things can not be done in a common >>>>>>> fashion for both IP protocols, hen we prioritize IPv6. >>>>>>> >>>>>>>> Unfortunately, I can not make it to Vancouver, but I do feel >>> that the work is really needed so >>>>>>> please count my vote in for the adoption of the WG. >>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jean Philippe Vasseur (jvasseur) >>>>>>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>>>>>> To: rsn@ietf.org >>>>>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> As promised, here is the new proposed Working Group, which >>> reflects the >>>>>>>> number of comments/suggestions that we received, the pre-WG >>> consensus, ... >>>>>>>> Thanks to Dave Ward (RTD AD) for his input. >>>>>>>> >>>>>>>> Proposed RL2N WG Charter >>>>>>>> >>>>>>>> Description of Working Group >>>>>>>> >>>>>>>> L2Ns (Low power and Lossy networks) are typically composed of >>> many embedded >>>>>>>> devices with limited power, memory, and processing resources >>> interconnected >>>>>>>> by a variety of wireless links, such as IEEE 802.15.4, >>> Bluetooth, Low Power >>>>>>>> WiFi. >>>>>>>> >>>>>>>> L2Ns are transitioning to an end-to-end IP-based solution to >>> avoid the >>>>>>>> problems of non-interoperable networks interconnected by >>> protocol >>>>>>>> translation gateways and proxies. In addition, L2Ns have >>> specific routing >>>>>>>> requirements that are not currently met by existing routing >>> protocols, such >>>>>>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be >>> designed to take >>>>>>>> into consideration the specific power, capabilities, attributes >>> and >>>>>>>> functional characteristics of the links and nodes in the >>> network. >>>>>>>> >>>>>>>> There is a wide scope of application areas for L2Ns, including >>> industrial >>>>>>>> monitoring, building automation (HVAC, lighting/access >>> control), connected >>>>>>>> home, healthcare, environmental monitoring, agricultural, smart >>> cities, >>>>>>>> logistics, assets tracking, and refrigeration. The L2N WG will >>> focus on >>>>>>>> routing solutions for a subset of these deployment scenarios, >>> namely >>>>>>>> industrial, connected home/building and urban applications. The >>> Working >>>>>>>> Group will determine the routing requirements for these >>> scenarios. >>>>>>>> >>>>>>>> The Working Group will provide a routing framework for these >>> application >>>>>>>> scenarios that provides high reliability in the presence of >>> time varying >>>>>>>> loss characteristics and connectivity while permitting >>> low-power operation >>>>>>>> with very modest memory and CPU pressure. >>>>>>>> >>>>>>>> >>>>>>>> The Working Group will pay a particular attention to routing >>> security and >>>>>>>> manageability (e.g self managing/configuration) issues, which >>> are >>>>>>>> particularly critical for L2Ns. >>>>>>>> >>>>>>>> Work Items: >>>>>>>> >>>>>>>> - Produce use cases documents for Industrial, Connected Home, >>> Building and >>>>>>>> urban application networks. Each document will describe the use >>> case and the >>>>>>>> associated routing protocol requirements. The documents will >>> progress in >>>>>>>> collaboration with the 6lowpan Working Group (INT area). >>>>>>>> >>>>>>>> >>>>>>>> - Survey the applicability of existing protocols to L2Ns. The >>> aim of this >>>>>>>> document will be to analyze the scaling and characteristics of >>> existing >>>>>>>> protocols and identify whether or not they meet the routing >>> requirements of >>>>>>>> the L2Ns applications identified above. Existing IGPs, MANET, >>> NEMO, DTN >>>>>>>> routing protocols will be part of evaluation. >>>>>>>> >>>>>>>> - Specification of routing metrics used in path calculation. >>> This includes >>>>>>>> static and dynamic link/nodes attributes required for routing >>> in L2Ns. >>>>>>>> - Provide an architectural framework for routing and path >>> selection at Layer >>>>>>>> 3 (Routing for L2N Architecture) >>>>>>>> * Decide whether the L2Ns routing protocol require a >>> distributed, >>>>>>>> centralized path computation models or both. >>>>>>>> * Decide whether the L2N routing protocol requires a >>> hierarchical routing >>>>>>>> approach. >>>>>>>> >>>>>>>> - Produce a security framework for routing in L2Ns. >>>>>>>> >>>>>>>> Goals And Milestones: >>>>>>>> >>>>>>>> >>>>>>>> April 2008 Submit Use case/Routing requirements for Industrial, >>> Connected >>>>>>>> Home, Building and Urban networks applications to the IESG to >>> be considered >>>>>>>> as an Informational RFC. >>>>>>>> >>>>>>>> August 2008: Submit Routing metrics for L2Ns document to the >>> IESG to be >>>>>>>> considered as an Informational RFC. >>>>>>>> >>>>>>>> September 2008: Submit first draft of the Routing for L2Ns >>> Architecture >>>>>>>> document (summary of requirements, path computation model, >>>>>>>> flat/hierarchy,=A9). >>>>>>>> >>>>>>>> November 2008: Submit Protocol Survey to the IESG to be >>> considered as an >>>>>>>> Informational RFC. >>>>>>>> >>>>>>>> January 2009 Submit Security Framework for L2Ns to the IESG to >>> be considered >>>>>>>> as an Informational RFC >>>>>>>> >>>>>>>> February 2009: Submit the Routing for L2Ns Architecture >>> document (summary >>>>>>>> of requirements, metrics and attributes, path selection model) >>> to the IESG >>>>>>>> as an Informational RFC. >>>>>>>> >>>>>>>> March 2009: Recharter. >>>>>>>> >>>>>>>> >>>>>>>> Please comment/suggest/... >>>>>>>> >>>>>>>> See you in Vancouver. >>>>>>>> >>>>>>>> JP and David. >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> RSN mailing list >>>>>>>> RSN@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> RSN mailing list >>>>>>>> RSN@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan >=20 --=20 Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 03 16:34:57 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 1IzIwH-0001Yi-6j; Mon, 03 Dec 2007 16:34:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzIwG-0001Yd-N4 for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 16:34:52 -0500 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzIwE-0005sI-Va for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 16:34:52 -0500 Received: by nz-out-0506.google.com with SMTP id i28so2152032nzi for <6lowpan@lists.ietf.org>; Mon, 03 Dec 2007 13:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=6KDjWH7DZZOGnMjgckDojE0Uv6394dwCr4FEx+yk9+8=; b=dHMl4ZgEaqszaNKcZkVPpk2X+q2eXQF2t91DY3Yf8cziBJrqo7/aJmxTNL+Mj0lLSVxaSPOYLSiEMyjGdR0kAW1wgnWFe+0QwwSC/reQH2ujQeAdCG7Z9DEHL9csUARqjeSuwL3lDwLRkHN24mmKVYU+P/Tc0iiVSufoYqRpbgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mzx1T1BcSkoJaL8Ep7OrvBgiIl6wMj65cAXGvbwelJs6P2ykulRgSouUTkkpMCjfxcZleJi+lCekmULi7HAjpSKGtUJpQiXTq5NdVkIZbfgj0JUgy98lun1nnEjgbZgr+xUuS58LPlVmbD+Iy5PFC53zHyDj8GwUkWmm22fmCpY= Received: by 10.142.240.9 with SMTP id n9mr2301678wfh.1196717689812; Mon, 03 Dec 2007 13:34:49 -0800 (PST) Received: by 10.142.105.17 with HTTP; Mon, 3 Dec 2007 13:34:49 -0800 (PST) Message-ID: <77f1dba80712031334u14874688q14d881cef61fc04a@mail.gmail.com> Date: Tue, 4 Dec 2007 06:34:49 +0900 From: "Eunsook \"Eunah\" Kim" To: "Zach Shelby" Subject: Re: [6lowpan] profile In-Reply-To: <47547463.1030705@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <750929.34078.qm@web81904.mail.mud.yahoo.com> <1196395279.5692.78.camel@dellx1> <7892795E1A87F04CADFCCF41FADD00FC04D9DFB1@xmb-ams-337.emea.cisco.com> <47547463.1030705@sensinode.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Cc: 6lowpan <6lowpan@lists.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 I'm in, too. As I said before I already worked to profile it for 6LoWPAN nodes. It must be good to exchange more specific idea. :) If you are in Vancouver, i'd love to meet and discuss. Let me know. -eunah On 12/4/07, Zach Shelby wrote: > Pascal, > > I am on the same line with you here, and would love to see an RFC coming > from the WG effort defining a minimum profile of lowpan and IPv6 > features. Jonathan and I wrote an interop ID, presented in Chicago, > which could actually be used as a base for writing a 6lowpan profile ID. > I would be willing to work on this. Could you guys please discuss this > during the WG meeting.. > > I know that 802.15.4+lowpan+IPv6+UDP can be implemented on minimal 8-bit > uCs, we can achieve interoperability (in vendor groups right now), and > other standards bodies would be smart to use 6lowpan; but we have to > communicate that clearly outside the WG. RFC 4944 is too cryptic for > this purpose, and a lot of information needs to be gathered from many > places. > > - Zach > > Pascal Thubert (pthubert) wrote: > > Hi Geoff: > > > > It's not just about IPSec though: > > > > There are a number of companies out there designing and integrating sil= icon for LoWPANs. IPv6 is not necessarily a target for them when it does no= t mean immediate sales. Also, they do not necessarily know what supporting = IPv6 means for their devices and what the associated cost will be. They cou= ld use some help and we can provide it in the form of an RFC that summarize= s a LoWPAN profile for IPv6. > > > > That profile should not include IPSec; that profile should include 6LoW= PAN - RFC 4944 is not listed in RFC 4294 for obvious reasons-, and the ND s= olution we will come up with. That profile should be designed to enable ver= y low end embedded systems (an 8-bit processor in my Mc D's toy) to run IPv= 6. > > > > Once we have that published with IETF stamp of approval, it becomes pos= sible for people out there to: > > > > - guarantee interoperability > > - develop and distribute an opensource stack > > - publish actual numbers for footprint and performance on various imple= mentations > > - go to standard bodies such as ISA SP100 and present those numbers to = support IPv6 adoption. > > > > I do think it is worth the effort. If 6MAN is the place, so be it. > > > > Pascal > >> -----Original Message----- > >> From: Geoff Mulligan [mailto:geoff@mulligan.com] > >> Sent: Friday, November 30, 2007 5:01 AM > >> To: gabriel montenegro > >> Cc: 6lowpan > >> Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working= Charter > >> > >> I will search back, but m recollection was that we (you) did argue wit= h > >> the IESG that devices such as these (small 8bit micro sensors) would n= ot > >> be capable of IPsec and after a few emails back a forth we were told > >> that 6lowpan devices did not need to support IPsec. > >> > >> Again I will look back and see if I can find the email exchange and I'= ll > >> ask Russ. > >> > >> geoff > >> > >> On Thu, 2007-11-29 at 17:13 -0800, gabriel montenegro wrote: > >>> Geoff, > >>> > >>> Could you please provide a pointer to the message or document with > >>> that exception? > >>> This is an important item and it should be added to the group's Wiki > >>> page. > >>> > >>> My recollection is different, but I may have just forgotten. What I > >>> recollect is that back when we > >>> were starting the working group and initiating work on the problem > >>> statement draft, was that the recommendation > >>> was to stay away from issuing our own IPv6 profile, precisely because > >>> saying things like ("IPsec is not recommended in lowpan > >>> environments") was a sure-fire way to invite controversy at the IESG. > >>> E.g., IPv6 mandates IPsec, so how could > >>> we ever claim to support IPv6.... This debate probably is better had > >>> in 6man in terms of a revision of the hosts > >>> requirements, rather than in any particular WG. > >>> > >>> -gabriel > >>> > >>> ----- Original Message ---- > >>> From: Geoff Mulligan > >>> To: Kris Pister > >>> Cc: 6lowpan <6lowpan@lists.ietf.org> > >>> Sent: Thursday, November 29, 2007 11:09:02 AM > >>> Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Workin= g > >>> Charter > >>> > >>> We did not try to get an exception to UDP checksums. > >>> > >>> geoff > >>> > >>> On Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote: > >>>> Geoff - ooh, I like exceptions. > >>>> Did we try to get an exception on the UDP checksum? It's painful > >>> to > >>>> leave that in the compressed header if we have L2 message integrity. > >>>> > >>>> ksjp > >>>> > >>>> Geoff Mulligan wrote: > >>>>> We have already received an exception from the IESG to IPsec on > >>> 6lowpan > >>>>> devices. > >>>>> > >>>>> geoff > >>>>> > >>>>> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) > >>> wrote: > >>>>>> Hum... > >>>>>> > >>>>>> I had missed that; Seems that we have to make an exception :) If > >>> you consider ISA100.11a, they already have security at L2 and L5, it > >>> makes little sense to MUST IPSec on top of that. > >>>>>> Pascal > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] > >>>>>>> Sent: Wednesday, November 28, 2007 8:03 PM > >>>>>>> To: Pascal Thubert (pthubert) > >>>>>>> Cc: 6lowpan > >>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > >>>>>>> > >>>>>>> Hmm. From 4294: > >>>>>>> > >>>>>>> "However, while authentication and encryption can each be NULL, > >>> they > >>>>>>> MUST NOT both be NULL." > >>>>>>> > >>>>>>> ksjp > >>>>>>> > >>>>>>> Pascal Thubert (pthubert) wrote: > >>>>>>> > >>>>>>>> Hi Kris: > >>>>>>>> > >>>>>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL > >>> encryption and authentication for > >>>>>>> interoperability reasons. > >>>>>>> > >>>>>>>> On the general question of RFC 4294 itself: I'm not sure the > >>> work was ever done. I hope someone > >>>>>> >from the list can help? > >>>>>> > >>>>>>>> If the answer is unclear, and considering that we are > >>> re-chartering the group, maybe we could have > >>>>>>> a work item to specify the instantiation of RFC 4294 for LoWPAN > >>> nodes? > >>>>>>>> Pascal > >>>>>>>> ________________________________________ > >>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] > >>>>>>>> Sent: Wednesday, November 28, 2007 5:42 PM > >>>>>>>> To: Pascal Thubert (pthubert) > >>>>>>>> Cc: 6lowpan > >>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working > >>> Charter > >>>>>>>> Is there an email thread somewhere that discusses the impact on > >>> 6LoWPAN of the security > >>>>>>> requirements of 4294 and 4303? > >>>>>>> > >>>>>>>> My first quick readthrough makes me very uncomfortable that > >>> some of the mandates are going to be > >>>>>>> ugly from a header standpoint. > >>>>>>> > >>>>>>>> ksjp > >>>>>>>> > >>>>>>>> Pascal Thubert (pthubert) wrote: > >>>>>>>> Hi JP: > >>>>>>>> > >>>>>>>> Thanks a bunch for this charter. I'll try not to rephrase what > >>> was already discussed with Christian, > >>>>>>> Anders, Philip and Misha. > >>>>>>> > >>>>>>>> There's an additional item I'd wish to see either in ROLL or > >>> 6LoWPAN and I do not know exactly > >>>>>>> where it belongs, maybe both. The question is whether we need to > >>> and can document how RFC 4294 > >>>>>>> applies for sensors, and M2M devices in general, whether they > >>> act as hosts or as routers. > >>>>>>>> I've seen IPv6 presented as a Pandora box that drags just too > >>> much stuff to be incorporated in a > >>>>>>> sensory device. For instance, at the moment, SP100.11a endorses > >>> 6LoWPAN formats but it's not so clear > >>>>>>> at all that IPv6 itself is mandated. A clear spec with > >>> well-documented implementation could be a > >>>>>>> formidable tool to despond to Fear, Uncertainty and Defiance. > >>>>>>> > >>>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can > >>> do without multicast at all if ND is > >>>>>>> supported some other way (such as suggested in: > >>> http://www.ietf.org/internet-drafts/draft-thubert- > >>>>>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and > >>> authentication is enough etc, etc... > >>>>>>>> Being able to define one minimum set and maybe a few other > >>> profiles for the use cases that we > >>>>>>> selected could help tremendously. > >>>>>>> > >>>>>>>> Otherwise I find the charter real well written and easy to > >>> digest. >>From the MANEMO experience, I > >>>>>>> expect that some arguments about the relative applicability of > >>> existing MANET protocols will be > >>>>>>> difficult to prove without some good simulation work running > >>> agreed-upon scenarios. > >>>>>>>> Finally, I'm a bit confused that it seems that both IPv4 and > >>> IPv6 seem supported. Ipv4 comes with a > >>>>>>> lot of overhead like DHCP. I suggest that when trouble comes and > >>> things can not be done in a common > >>>>>>> fashion for both IP protocols, hen we prioritize IPv6. > >>>>>>> > >>>>>>>> Unfortunately, I can not make it to Vancouver, but I do feel > >>> that the work is really needed so > >>>>>>> please count my vote in for the adoption of the WG. > >>>>>>> > >>>>>>>> Cheers, > >>>>>>>> > >>>>>>>> Pascal > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Jean Philippe Vasseur (jvasseur) > >>>>>>>> Sent: Wednesday, November 21, 2007 9:19 PM > >>>>>>>> To: rsn@ietf.org > >>>>>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter > >>>>>>>> > >>>>>>>> Dear all, > >>>>>>>> > >>>>>>>> As promised, here is the new proposed Working Group, which > >>> reflects the > >>>>>>>> number of comments/suggestions that we received, the pre-WG > >>> consensus, ... > >>>>>>>> Thanks to Dave Ward (RTD AD) for his input. > >>>>>>>> > >>>>>>>> Proposed RL2N WG Charter > >>>>>>>> > >>>>>>>> Description of Working Group > >>>>>>>> > >>>>>>>> L2Ns (Low power and Lossy networks) are typically composed of > >>> many embedded > >>>>>>>> devices with limited power, memory, and processing resources > >>> interconnected > >>>>>>>> by a variety of wireless links, such as IEEE 802.15.4, > >>> Bluetooth, Low Power > >>>>>>>> WiFi. > >>>>>>>> > >>>>>>>> L2Ns are transitioning to an end-to-end IP-based solution to > >>> avoid the > >>>>>>>> problems of non-interoperable networks interconnected by > >>> protocol > >>>>>>>> translation gateways and proxies. In addition, L2Ns have > >>> specific routing > >>>>>>>> requirements that are not currently met by existing routing > >>> protocols, such > >>>>>>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be > >>> designed to take > >>>>>>>> into consideration the specific power, capabilities, attributes > >>> and > >>>>>>>> functional characteristics of the links and nodes in the > >>> network. > >>>>>>>> > >>>>>>>> There is a wide scope of application areas for L2Ns, including > >>> industrial > >>>>>>>> monitoring, building automation (HVAC, lighting/access > >>> control), connected > >>>>>>>> home, healthcare, environmental monitoring, agricultural, smart > >>> cities, > >>>>>>>> logistics, assets tracking, and refrigeration. The L2N WG will > >>> focus on > >>>>>>>> routing solutions for a subset of these deployment scenarios, > >>> namely > >>>>>>>> industrial, connected home/building and urban applications. The > >>> Working > >>>>>>>> Group will determine the routing requirements for these > >>> scenarios. > >>>>>>>> > >>>>>>>> The Working Group will provide a routing framework for these > >>> application > >>>>>>>> scenarios that provides high reliability in the presence of > >>> time varying > >>>>>>>> loss characteristics and connectivity while permitting > >>> low-power operation > >>>>>>>> with very modest memory and CPU pressure. > >>>>>>>> > >>>>>>>> > >>>>>>>> The Working Group will pay a particular attention to routing > >>> security and > >>>>>>>> manageability (e.g self managing/configuration) issues, which > >>> are > >>>>>>>> particularly critical for L2Ns. > >>>>>>>> > >>>>>>>> Work Items: > >>>>>>>> > >>>>>>>> - Produce use cases documents for Industrial, Connected Home, > >>> Building and > >>>>>>>> urban application networks. Each document will describe the use > >>> case and the > >>>>>>>> associated routing protocol requirements. The documents will > >>> progress in > >>>>>>>> collaboration with the 6lowpan Working Group (INT area). > >>>>>>>> > >>>>>>>> > >>>>>>>> - Survey the applicability of existing protocols to L2Ns. The > >>> aim of this > >>>>>>>> document will be to analyze the scaling and characteristics of > >>> existing > >>>>>>>> protocols and identify whether or not they meet the routing > >>> requirements of > >>>>>>>> the L2Ns applications identified above. Existing IGPs, MANET, > >>> NEMO, DTN > >>>>>>>> routing protocols will be part of evaluation. > >>>>>>>> > >>>>>>>> - Specification of routing metrics used in path calculation. > >>> This includes > >>>>>>>> static and dynamic link/nodes attributes required for routing > >>> in L2Ns. > >>>>>>>> - Provide an architectural framework for routing and path > >>> selection at Layer > >>>>>>>> 3 (Routing for L2N Architecture) > >>>>>>>> * Decide whether the L2Ns routing protocol require a > >>> distributed, > >>>>>>>> centralized path computation models or both. > >>>>>>>> * Decide whether the L2N routing protocol requires a > >>> hierarchical routing > >>>>>>>> approach. > >>>>>>>> > >>>>>>>> - Produce a security framework for routing in L2Ns. > >>>>>>>> > >>>>>>>> Goals And Milestones: > >>>>>>>> > >>>>>>>> > >>>>>>>> April 2008 Submit Use case/Routing requirements for Industrial, > >>> Connected > >>>>>>>> Home, Building and Urban networks applications to the IESG to > >>> be considered > >>>>>>>> as an Informational RFC. > >>>>>>>> > >>>>>>>> August 2008: Submit Routing metrics for L2Ns document to the > >>> IESG to be > >>>>>>>> considered as an Informational RFC. > >>>>>>>> > >>>>>>>> September 2008: Submit first draft of the Routing for L2Ns > >>> Architecture > >>>>>>>> document (summary of requirements, path computation model, > >>>>>>>> flat/hierarchy,=8A). > >>>>>>>> > >>>>>>>> November 2008: Submit Protocol Survey to the IESG to be > >>> considered as an > >>>>>>>> Informational RFC. > >>>>>>>> > >>>>>>>> January 2009 Submit Security Framework for L2Ns to the IESG to > >>> be considered > >>>>>>>> as an Informational RFC > >>>>>>>> > >>>>>>>> February 2009: Submit the Routing for L2Ns Architecture > >>> document (summary > >>>>>>>> of requirements, metrics and attributes, path selection model) > >>> to the IESG > >>>>>>>> as an Informational RFC. > >>>>>>>> > >>>>>>>> March 2009: Recharter. > >>>>>>>> > >>>>>>>> > >>>>>>>> Please comment/suggest/... > >>>>>>>> > >>>>>>>> See you in Vancouver. > >>>>>>>> > >>>>>>>> JP and David. > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> RSN mailing list > >>>>>>>> RSN@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> RSN mailing list > >>>>>>>> RSN@ietf.org > >>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www1.ietf.org/mailman/listinfo/6lowpan > > > > > -- > Zach Shelby | CTO | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > > _______________________________________________ > 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 Mon Dec 03 18:57:28 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 1IzLAD-0000mH-NS; Mon, 03 Dec 2007 18:57:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzLAB-0000m1-Rw for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 18:57:23 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzLA9-0001FZ-Kb for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 18:57:23 -0500 Received: by rv-out-0910.google.com with SMTP id k20so2894480rvb for <6lowpan@lists.ietf.org>; Mon, 03 Dec 2007 15:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=eA9c2po3R2E0HSx3UziGm8RZx6EHx9k7gfvsAyaf71Y=; b=Olk4kH9K/o46+WJLvwob26dCoQ+kP6KJVm1tCurfi9dk8oxytsV+FKwyZQlq1wEQlXtAOM+wrCj06LWCTFIFiGBjWrhj17MPvGyFxvHIQ5Ywo3wFU6U12IO4bU26IXvMEQUCSIIl/1pSXaAo4dPW/cKFfIzJYvPebh+KgGHdIUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TISD9m41VjUbdZSixiay/Bq8mI9SFvwEX2N9L3fyYNOP+kt+RumqK7VGgb48zeFT3zZHTTRvG2XZZnSziYhbpOLy3LjpbH/C/q2BZMijC4JHWtcJMl+Tq7uGkOqIda2McVm+Yw1ZUlw8fFUz3vC9GwQ9NTG3oevSgi/0V/YSSHQ= Received: by 10.142.98.18 with SMTP id v18mr1856956wfb.1196726240327; Mon, 03 Dec 2007 15:57:20 -0800 (PST) Received: by 10.142.105.17 with HTTP; Mon, 3 Dec 2007 15:57:20 -0800 (PST) Message-ID: <77f1dba80712031557y6cb4c308n90dc7aa3c6ab3377@mail.gmail.com> Date: Tue, 4 Dec 2007 08:57:20 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" Subject: Re: [6lowpan] 6lowpan agenda In-Reply-To: <1196703934.5871.65.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1196700758.5871.49.camel@dellx1> <77f1dba80712030936m6a64ab44l1687be47ec38842@mail.gmail.com> <1196703934.5871.65.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 6lowpan <6lowpan@lists.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 Geoff, Here's our suggestion. Please let me know if it needs to be modified by WG schedule. - Application Rec. : (10 min) Eunsook Kim & JP Vasseur - Routing Req. (10 min) Dominik Kaspar Thanks, Eunsook On 12/4/07, Geoff Mulligan wrote: > how much time do you need? > > geoff > > On Tue, 2007-12-04 at 02:36 +0900, Eunsook "Eunah" Kim wrote: > > Dear Geoff & Carsten, > > > > We prepare the following two drafts. Would you include them in the agenda? > > > > - Application Recommendation > > "draft-ekim-6lowpan-scenarios-01.txt" > > > > - 6Lowpan Routing Requirement > > "draft-dokaspar-6lowpan-routreq-03.txt" > > > > Thanks, > > > > -eunsook > > > > On 12/4/07, Geoff Mulligan wrote: > > > Folks, > > > Attached is the current agenda for the meeting. > > > > > > Sorry for the late notice for the agenda. > > > > > > If there are other presentations or talks, please notify either Carsten > > > or myself as soon as possible. > > > > > > geoff > > > > > > > > > _______________________________________________ > > > 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 Mon Dec 03 20:45: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 1IzMq8-0006yV-Tg; Mon, 03 Dec 2007 20:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzMq7-0006ts-4O for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 20:44:47 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzMq6-0004GI-HO for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 20:44:47 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from localhost (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lB41icTS011113; Tue, 4 Dec 2007 02:44:38 +0100 (CET) Message-Id: <7B08E4E9-90B4-4E3F-A5FF-286522023C1D@tzi.org> From: Carsten Bormann To: 6lowpan <6lowpan@lists.ietf.org> In-Reply-To: <1196700758.5871.49.camel@dellx1> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [6lowpan] 6lowpan agenda Date: Mon, 3 Dec 2007 17:44:38 -0800 References: <1196700758.5871.49.camel@dellx1> X-Mailer: Apple Mail (2.915) X-Spam-Score: 4.5 (++++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Carsten Bormann 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 Presenters: Please send me your slides by 08:00 on Wednesday (preferably earlier) so we can upload them to the meeting site well before the actual meeting. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 03 23:41:39 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 1IzPbG-0001DW-Jn; Mon, 03 Dec 2007 23:41:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzPbF-0001DN-JJ for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 23:41:37 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzPbD-00027C-UJ for 6lowpan@lists.ietf.org; Mon, 03 Dec 2007 23:41:37 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lB44fY7U012188 for <6lowpan@lists.ietf.org>; Mon, 3 Dec 2007 21:41:34 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: multipart/mixed; boundary="=-jOo6xV1+zOy6LKvABwvn" Date: Mon, 03 Dec 2007 21:41:29 -0700 Message-Id: <1196743289.5880.4.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [6lowpan] new agenda for meeting 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 --=-jOo6xV1+zOy6LKvABwvn Content-Type: text/plain Content-Transfer-Encoding: 7bit Here is the updated agenda for the meeting. It is quite full and we will have to stick to a schedule to get through all of this. geoff --=-jOo6xV1+zOy6LKvABwvn Content-Disposition: attachment; filename=agenda.txt Content-Type: text/plain; name=agenda.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Wednesday, December 5, 2007 1300-1500 Afternoon Session I, Salon 3 6LoWPAN Draft Agenda - IETF 70 ------------------------------ 1. Administrivia -- Chairs (5 min) 2. Rechartering Status -- Chairs (10 min) 3. Current I-Ds -- Chairs (15 min) 4. Architecture Document (15 min) JP Vasseur / D Culler - draft-culler-6lowpan-architecture-00 5. Commissioning and Bootstrapping Issues (15 min) K Kim 6. Security Analysis (15 min) D Park - draft-daniel-6lowpan-security-analysis-01 7. Application Rec. (15 min) Eunsook Kim & JP Vasseur 8. Routing Req. (10 min) Dominik Kaspar 9. Integration of 6LoWPAN into IP networks (10 min) Carl Williams - draft-cansever-6lowpan-integration-00 10. Stateful Header Compression (10 min) Kris Pister --=-jOo6xV1+zOy6LKvABwvn 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 --=-jOo6xV1+zOy6LKvABwvn-- From 6lowpan-bounces@ietf.org Tue Dec 04 07:01:27 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 1IzWSo-0006pG-F1; Tue, 04 Dec 2007 07:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzWSn-0006nn-E5 for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 07:01:21 -0500 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzWSn-0000b7-3R for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 07:01:21 -0500 Received: by an-out-0708.google.com with SMTP id d31so866862and for <6lowpan@lists.ietf.org>; Tue, 04 Dec 2007 04:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=vrc3DaH/XsJNyFvoPZKb77BoFVohow+lU8sGzGlAiBk=; b=w6vq72TM33jEurGpACMbQ5TK8acxK7RapdwB6CoUrbzbs9sznvhI5xhh0DOKu4qa8fhuO1eR4PniuA0tZ/byekk+PtTIpfd3PTNfPAQYT2EQKDWavpEfkcW3kL0LSDrclnM3PrkKcdNxlUN+GDu+X9y0Sc85/zJpa+9cqWz7WlI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Daq9mKDyBPg5nl8vwa+J0dlJ8naHJf/M3T9quN1TEaMdm3mOkKzd4r5OCgUm1mNU+50FaRj3Oz3PuOnbZc/BOF9cMg1/EFn3tFJZr270hmWLqVUemHlDxPpjOwrvfLFkbmYVSC9dB142Gkb/kfuPQByGQ7Y0o9MzrYbBmLCJztw= Received: by 10.100.216.3 with SMTP id o3mr1167593ang.1196769680684; Tue, 04 Dec 2007 04:01:20 -0800 (PST) Received: by 10.90.75.9 with HTTP; Tue, 4 Dec 2007 04:01:20 -0800 (PST) Message-ID: Date: Tue, 4 Dec 2007 21:01:20 +0900 From: "Daniel Park" To: "Geoff Mulligan" Subject: Re: [6lowpan] new agenda for meeting In-Reply-To: <1196743289.5880.4.camel@dellx1> MIME-Version: 1.0 References: <1196743289.5880.4.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 6lowpan <6lowpan@lists.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="===============1101182202==" Errors-To: 6lowpan-bounces@ietf.org --===============1101182202== Content-Type: multipart/alternative; boundary="----=_Part_8112_28473309.1196769680678" ------=_Part_8112_28473309.1196769680678 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I can't see *ND optimization* presentation in the agenda. Is it a missing part or skip over this issue in Vancouver ? Daniel Park On 12/4/07, Geoff Mulligan wrote: > > Here is the updated agenda for the meeting. It is quite full and we > will have to stick to a schedule to get through all of this. > > geoff > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > > ------=_Part_8112_28473309.1196769680678 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I can't see *ND optimization* presentation in the agenda. Is it a missing part or skip over this issue in Vancouver ?
 
Daniel Park

 
On 12/4/07, Geoff Mulligan <geoff@mulligan.com> wrote:
Here is the updated agenda for the meeting.  It is quite full and we
will have to stick to a schedule to get through all of this.

       geoff


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



------=_Part_8112_28473309.1196769680678-- --===============1101182202== 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 --===============1101182202==-- From 6lowpan-bounces@ietf.org Tue Dec 04 09:35:47 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 1IzYsE-00025Q-1o; Tue, 04 Dec 2007 09:35:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzYsC-00021b-IL for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 09:35:44 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzYs8-0003Ye-NI for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 09:35:44 -0500 X-IronPort-AV: E=Sophos;i="4.23,248,1194217200"; d="scan'208,217";a="159533166" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Dec 2007 15:35:40 +0100 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 lB4EZd9O008052; Tue, 4 Dec 2007 15:35:39 +0100 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 lB4EZQ3t016801; Tue, 4 Dec 2007 14:35:39 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 15:35:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [6lowpan] new agenda for meeting Date: Tue, 4 Dec 2007 15:35:32 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04DED78B@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] new agenda for meeting Thread-Index: Acg2baZd5RaAbS0+T66uldpH9NbtwAAFQe9g References: <1196743289.5880.4.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Daniel Park" , "Geoff Mulligan" X-OriginalArrivalTime: 04 Dec 2007 14:35:38.0674 (UTC) FILETIME=[F0633120:01C83682] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7315; t=1196778940; x=1197642940; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20new=20agenda=20for=20meeting |Sender:=20; bh=KHKAM7pTEZHQf4bEBQwOd1M4GOLHmu+y0d4VBMGGHtE=; b=sj5mYXeCGa91gMPwxYzLn8mAEc/le5b4ghN4gEyEDikEbHHMJiuKva5IL859TY4qoC3ecgG4 ZqWG8SE41p+pE6q7khaPQHaeOtnh2tDaI4Ze0uRgOjDbXkZ42wtVuX1g; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: 6lowpan <6lowpan@lists.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="===============1901431287==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1901431287== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83682.F0137150" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83682.F0137150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sustained :-) =20 I'm sorry I can not make it to Chicago to present the Backbone Router I-Draft but I'm certainly favorable discuss adequately the ND issue. =20 Pascal ________________________________ From: Daniel Park [mailto:soohongp@gmail.com]=20 Sent: Tuesday, December 04, 2007 1:01 PM To: Geoff Mulligan Cc: 6lowpan Subject: Re: [6lowpan] new agenda for meeting =20 I can't see *ND optimization* presentation in the agenda. Is it a missing part or skip over this issue in Vancouver ? =20 Daniel Park =20 On 12/4/07, Geoff Mulligan wrote:=20 Here is the updated agenda for the meeting. It is quite full and we will have to stick to a schedule to get through all of this.=20 geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan =20 ------_=_NextPart_001_01C83682.F0137150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sustained J

 

I’m sorry I can not make it = to Chicago to present the Backbone Router I-Draft but I’m certainly = favorable discuss adequately the ND issue.

 

Pascal

From: = Daniel Park [mailto:soohongp@gmail.com]
Sent: Tuesday, December = 04, 2007 1:01 PM
To: Geoff Mulligan
Cc: 6lowpan
Subject: Re: [6lowpan] = new agenda for meeting

 

I can't see *ND optimization* presentation in the agenda. Is it = a missing part or skip over this issue in Vancouver ?

 

Daniel Park

 

On 12/4/07, Geoff Mulligan <geoff@mulligan.com> wrote:

Here is the = updated agenda for the meeting.  It is quite full and we
will have to stick to a schedule to get through all of this.

       geoff


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

 

------_=_NextPart_001_01C83682.F0137150-- --===============1901431287== 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 --===============1901431287==-- From 6lowpan-bounces@ietf.org Tue Dec 04 12:13: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 1IzbLD-0000gr-HR; Tue, 04 Dec 2007 12:13:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbLC-0000gW-Ew for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 12:13:50 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzbLA-00084T-Le for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 12:13:50 -0500 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id lB4HDj4E023920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Dec 2007 09:13:46 -0800 (PST) Message-ID: <47558AC4.9060802@eecs.berkeley.edu> Date: Tue, 04 Dec 2007 09:13:40 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Hui Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> In-Reply-To: <4754733C.2050001@archrock.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gateway0.EECS.Berkeley.EDU id lB4HDj4E023920 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 Cc: 6lowpan <6lowpan@lists.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 Jonathan - until we start to get into stateful header compression, all=20 of the information that is covered in the L4 checksum is covered by the=20 L2 MIC. It may be in a different form, but it's all there. I'm far more concerned about corruption due to RF communication problems=20 than I am about corruption due to incorrect algorithm implementation. =20 No matter what we do, that will always be a problem - what if my mote=20 calculates the checksum properly, but swapped some bytes in the message=20 formation before calculating the checksum, or just generated the wrong=20 command packet in the first place? Those are errors of comparable=20 simplicity to not being able to compress or decompress the 6LoWPAN=20 header properly. There's a long list of simple mistakes that can be=20 made by a node that aren't going to get caught by either an L4 checksum=20 or an L2 MIC. Those aren't the ones that I'm worried about, because we=20 have some control over them. The ones that we can't control are the=20 ones that happen in the ether. So I'll go back to my earlier question: given your concern about people=20 improperly compressing and decompressing, and the realities of low power=20 wireless in a shared ISM band, which do you think will have more end to=20 end errors? A) n hops with L4 checksum B) n hops with L2 MIC Or maybe a better question is: does option B scare you so much that we=20 don't want to allow people to do it because it may corrupt our otherwise=20 flawless networks? ksjp Jonathan Hui wrote: > > Hi Kris, > > I'm still not seeing how L2 MICs negate the need for L4 MICs. L2 MICs=20 > are verified and recomputed hop by hop, where as L4 MICs are not.=20 > There are a couple reasons why L2 MICs do not cover all of the=20 > functionality of L4 MICs. First, an intermediate router could=20 > incorrectly accept a corrupted packet or incorrectly mutate the L2=20 > payload yet compute a MIC that will indicate the packet is still valid=20 > to the next hop. Second, the L2 MIC as currently defined by 802.15.4=20 > only covers the bits contained within the frame. It does not take in=20 > any knowledge of the upper layers. An L4 MIC necessarily covers the=20 > IPv6 pseudo-header and does so in 6LoWPAN even if some of those bits=20 > are elided. > > The only case I see where the L2 MIC covers every bit of functionality=20 > an L4 MIC might provide is if the IPv6 datagram is carried=20 > uncompressed within the L2 frame and communication occurs within=20 > link-local scope. > > --=20 > Jonathan Hui > > > Kris Pister wrote: >> Jonathan - I'm not arguing for a different transport layer, I'm=20 >> arguing that there are more bits that can be compressed out of the=20 >> existing compressed UDP header. >> HC_UDP bits 3 through 7 are currently reserved. >> My suggestion is that we take one of them, e.g. bit 3, and use it to=20 >> indicate whether the 2 byte checksum is compressed. >> ---------- >> Checksum (bit 3) : >> 0: not compressed, carried inline (Section 10.3.2) >> >> 1: compressed (L2 MIC assumed). If this option is used, the=20 >> packet MUST be sent with L2 message integrity. >> ----------- >> If the node can't send with an L2 MIC, or it doesn't know if the=20 >> message will be sent with an L2 MIC, then it sends the checksum. If=20 >> the packet comes in with the checksum compressed, and the node can't=20 >> send it that way, then it calculates the checksum. I don't think=20 >> that you can claim that this is more of a layer violation than some=20 >> of the other compression that we're specifying already. >> I stand by my claim that an L2 MIC and no checksum on some or all=20 >> hops along a path will give you higher end to end integrity than=20 >> sending the checksum with no L2 MIC. Of course, you can send both,=20 >> which is what 4944 forces you to do now if you want an L2 MIC. But=20 >> the whole premise of the document, as stated in the introduction, is=20 >> that header compression is important. >> If people want to avoid having an L2 MIC, that's fine. But if you=20 >> use one, then sending the 2 byte UDP checksum is silly. >> >> ksjp >> >> Jonathan Hui wrote: >>> >>> Yes, its clear that a 32-bit MIC is stronger than a 16 bit checksum.=20 >>> However, a MIC at L2 no matter how many bits it is is not end-to-end=20 >>> and does not negate the need for L4 integrity checks. Wanting to use=20 >>> a stronger checksum at L4 sounds like you want a different transport=20 >>> layer. You mentioned earlier on this list that losses apply to every=20 >>> link, even wired ones. So if you want stronger end-to-end integrity=20 >>> checks, use a transport layer other than UDP. That's the beauty of IP. >>> >>> --=20 >>> Jonathan Hui >>> >>> >>> Kris Pister wrote: >>>> A 16 bit checksum at L4 is redundant if every L2 hop has a 32 bit MI= C. >>>> A 16 bit checksum at L4 is not sufficient protection against bit=20 >>>> errors without a 32 bit MIC somewhere (either L2 or L4/5, or both=20 >>>> as in HART). >>>> >>>> If you run 15.4 networks without a 32 bit MIC, I guarantee you that=20 >>>> you will get valid checksums on corrupted packets. Depending on=20 >>>> the network traffic, that might happen once per day per network. >>>> >>>> If a node knows that it's going to send a packet with a 32 bit L2=20 >>>> MIC, can't it be smart enough to compress out the 16 bit checksum? =20 >>>> Is that really violating the requirement? (It's a simple enough=20 >>>> change - we've got another bit in the HC2 header.) >>>> >>>> Put another way, which do you think is safer from an L3/L4 header=20 >>>> error detection perspective: >>>> A) sending packets over 10 hops with a 32 bit MIC at each hop and=20 >>>> no 16 bit checksum >>>> B) sending packets over 1 hop with no MIC and a 16 bit checksum >>>> >>>> The math is pretty clear. The measured data fits the math. >>>> >>>> ksjp >>>> >>>> Jonathan Hui wrote: >>>>> >>>>> Note that L2 message integrity doesn't provide end-to-end message=20 >>>>> integrity, which L4 checksums (that cover the L3 header) provide. >>>>> >>>>> --=20 >>>>> Jonathan Hui >>>>> >>>>> >>>>> Kris Pister wrote: >>>>>> Geoff - ooh, I like exceptions. >>>>>> Did we try to get an exception on the UDP checksum? It's painful=20 >>>>>> to leave that in the compressed header if we have L2 message=20 >>>>>> integrity. >>>>>> >>>>>> ksjp >>>>>> >>>>>> Geoff Mulligan wrote: >>>>>>> We have already received an exception from the IESG to IPsec on=20 >>>>>>> 6lowpan >>>>>>> devices. >>>>>>> >>>>>>> geoff >>>>>>> >>>>>>> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrot= e: >>>>>>> =20 >>>>>>>> Hum... >>>>>>>> I had missed that; Seems that we have to make an exception :)=20 >>>>>>>> If you consider ISA100.11a, they already have security at L2=20 >>>>>>>> and L5, it makes little sense to MUST IPSec on top of that. >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>> =20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>>>> Sent: Wednesday, November 28, 2007 8:03 PM >>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>> Cc: 6lowpan >>>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charte= r >>>>>>>>> >>>>>>>>> Hmm. From 4294: >>>>>>>>> >>>>>>>>> "However, while authentication and encryption can each be=20 >>>>>>>>> NULL, they >>>>>>>>> MUST NOT both be NULL." >>>>>>>>> >>>>>>>>> ksjp >>>>>>>>> >>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>> =20 >>>>>>>>>> Hi Kris: >>>>>>>>>> >>>>>>>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL=20 >>>>>>>>>> encryption and authentication for >>>>>>>>>> =20 >>>>>>>>> interoperability reasons. >>>>>>>>> =20 >>>>>>>>>> On the general question of RFC 4294 itself: I'm not sure the=20 >>>>>>>>>> work was ever done. I hope someone >>>>>>>>>> =20 >>>>>>>> >from the list can help? >>>>>>>> =20 >>>>>>>>>> If the answer is unclear, and considering that we are=20 >>>>>>>>>> re-chartering the group, maybe we could have >>>>>>>>>> =20 >>>>>>>>> a work item to specify the instantiation of RFC 4294 for=20 >>>>>>>>> LoWPAN nodes? >>>>>>>>> =20 >>>>>>>>>> Pascal >>>>>>>>>> ________________________________________ >>>>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>>>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>>> Cc: 6lowpan >>>>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Chart= er >>>>>>>>>> >>>>>>>>>> Is there an email thread somewhere that discusses the impact=20 >>>>>>>>>> on 6LoWPAN of the security >>>>>>>>>> =20 >>>>>>>>> requirements of 4294 and 4303? >>>>>>>>> =20 >>>>>>>>>> My first quick readthrough makes me very uncomfortable that=20 >>>>>>>>>> some of the mandates are going to be >>>>>>>>>> =20 >>>>>>>>> ugly from a header standpoint. >>>>>>>>> =20 >>>>>>>>>> ksjp >>>>>>>>>> >>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>> Hi JP: >>>>>>>>>> >>>>>>>>>> Thanks a bunch for this charter. I'll try not to rephrase=20 >>>>>>>>>> what was already discussed with Christian, >>>>>>>>>> =20 >>>>>>>>> Anders, Philip and Misha. >>>>>>>>> =20 >>>>>>>>>> There's an additional item I'd wish to see either in ROLL or=20 >>>>>>>>>> 6LoWPAN and I do not know exactly >>>>>>>>>> =20 >>>>>>>>> where it belongs, maybe both. The question is whether we need=20 >>>>>>>>> to and can document how RFC 4294 >>>>>>>>> applies for sensors, and M2M devices in general, whether they=20 >>>>>>>>> act as hosts or as routers. >>>>>>>>> =20 >>>>>>>>>> I've seen IPv6 presented as a Pandora box that drags just too=20 >>>>>>>>>> much stuff to be incorporated in a >>>>>>>>>> =20 >>>>>>>>> sensory device. For instance, at the moment, SP100.11a=20 >>>>>>>>> endorses 6LoWPAN formats but it's not so clear >>>>>>>>> at all that IPv6 itself is mandated. A clear spec with=20 >>>>>>>>> well-documented implementation could be a >>>>>>>>> formidable tool to despond to Fear, Uncertainty and Defiance. >>>>>>>>> =20 >>>>>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe=20 >>>>>>>>>> can do without multicast at all if ND is >>>>>>>>>> =20 >>>>>>>>> supported some other way (such as suggested in:=20 >>>>>>>>> http://www.ietf.org/internet-drafts/draft-thubert- >>>>>>>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and=20 >>>>>>>>> authentication is enough etc, etc... >>>>>>>>> =20 >>>>>>>>>> Being able to define one minimum set and maybe a few other=20 >>>>>>>>>> profiles for the use cases that we >>>>>>>>>> =20 >>>>>>>>> selected could help tremendously. >>>>>>>>> =20 >>>>>>>>>> Otherwise I find the charter real well written and easy to=20 >>>>>>>>>> digest. >>From the MANEMO experience, I >>>>>>>>>> =20 >>>>>>>>> expect that some arguments about the relative applicability of=20 >>>>>>>>> existing MANET protocols will be >>>>>>>>> difficult to prove without some good simulation work running=20 >>>>>>>>> agreed-upon scenarios. >>>>>>>>> =20 >>>>>>>>>> Finally, I'm a bit confused that it seems that both IPv4 and=20 >>>>>>>>>> IPv6 seem supported. Ipv4 comes with a >> >>>>>>>>>> =20 >>>>>>>>> lot of overhead like DHCP. I suggest that when trouble comes=20 >>>>>>>>> and things can not be done in a common >>>>>>>>> fashion for both IP protocols, hen we prioritize IPv6. >>>>>>>>> =20 >>>>>>>>>> Unfortunately, I can not make it to Vancouver, but I do feel=20 >>>>>>>>>> that the work is really needed so >>>>>>>>>> =20 >>>>>>>>> please count my vote in for the adoption of the WG. >>>>>>>>> =20 >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Pascal >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Jean Philippe Vasseur (jvasseur) >>>>>>>>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>>>>>>>> To: rsn@ietf.org >>>>>>>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>>>>> >>>>>>>>>> Dear all, >>>>>>>>>> >>>>>>>>>> As promised, here is the new proposed Working Group, which=20 >>>>>>>>>> reflects the >>>>>>>>>> number of comments/suggestions that we received, the pre-WG=20 >>>>>>>>>> consensus, ... >>>>>>>>>> >>>>>>>>>> Thanks to Dave Ward (RTD AD) for his input. >>>>>>>>>> >>>>>>>>>> Proposed RL2N WG Charter >>>>>>>>>> >>>>>>>>>> Description of Working Group >>>>>>>>>> >>>>>>>>>> L2Ns (Low power and Lossy networks) are typically composed of=20 >>>>>>>>>> many embedded >>>>>>>>>> devices with limited power, memory, and processing resources=20 >>>>>>>>>> interconnected >>>>>>>>>> by a variety of wireless links, such as IEEE 802.15.4,=20 >>>>>>>>>> Bluetooth, Low Power >>>>>>>>>> WiFi. >>>>>>>>>> >>>>>>>>>> L2Ns are transitioning to an end-to-end IP-based solution to=20 >>>>>>>>>> avoid the >>>>>>>>>> problems of non-interoperable networks interconnected by=20 >>>>>>>>>> protocol >>>>>>>>>> translation gateways and proxies. In addition, L2Ns have=20 >>>>>>>>>> specific routing >>>>>>>>>> requirements that are not currently met by existing routing=20 >>>>>>>>>> protocols, such >>>>>>>>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be=20 >>>>>>>>>> designed to take >>>>>>>>>> into consideration the specific power, capabilities,=20 >>>>>>>>>> attributes and >>>>>>>>>> functional characteristics of the links and nodes in the=20 >>>>>>>>>> network. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There is a wide scope of application areas for L2Ns,=20 >>>>>>>>>> including industrial >>>>>>>>>> monitoring, building automation (HVAC, lighting/access=20 >>>>>>>>>> control), connected >>>>>>>>>> home, healthcare, environmental monitoring, agricultural,=20 >>>>>>>>>> smart cities, >>>>>>>>>> logistics, assets tracking, and refrigeration. The L2N WG=20 >>>>>>>>>> will focus on >>>>>>>>>> routing solutions for a subset of these deployment scenarios,=20 >>>>>>>>>> namely >>>>>>>>>> industrial, connected home/building and urban applications.=20 >>>>>>>>>> The Working >>>>>>>>>> Group will determine the routing requirements for these=20 >>>>>>>>>> scenarios. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Working Group will provide a routing framework for these=20 >>>>>>>>>> application >>>>>>>>>> scenarios that provides high reliability in the presence of=20 >>>>>>>>>> time varying >>>>>>>>>> loss characteristics and connectivity while permitting=20 >>>>>>>>>> low-power operation >>>>>>>>>> with very modest memory and CPU pressure. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Working Group will pay a particular attention to routing=20 >>>>>>>>>> security and >>>>>>>>>> manageability (e.g self managing/configuration) issues, which=20 >>>>>>>>>> are >>>>>>>>>> particularly critical for L2Ns. >>>>>>>>>> >>>>>>>>>> Work Items: >>>>>>>>>> >>>>>>>>>> - Produce use cases documents for Industrial, Connected Home,=20 >>>>>>>>>> Building and >>>>>>>>>> urban application networks. Each document will describe the=20 >>>>>>>>>> use case and the >>>>>>>>>> associated routing protocol requirements. The documents will=20 >>>>>>>>>> progress in >>>>>>>>>> collaboration with the 6lowpan Working Group (INT area). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - Survey the applicability of existing protocols to L2Ns. The=20 >>>>>>>>>> aim of this >>>>>>>>>> document will be to analyze the scaling and characteristics=20 >>>>>>>>>> of existing >>>>>>>>>> protocols and identify whether or not they meet the routing=20 >>>>>>>>>> requirements of >>>>>>>>>> the L2Ns applications identified above. Existing IGPs, MANET,=20 >>>>>>>>>> NEMO, DTN >>>>>>>>>> routing protocols will be part of evaluation. >>>>>>>>>> >>>>>>>>>> - Specification of routing metrics used in path calculation.=20 >>>>>>>>>> This includes >>>>>>>>>> static and dynamic link/nodes attributes required for routing=20 >>>>>>>>>> in L2Ns. >>>>>>>>>> >>>>>>>>>> - Provide an architectural framework for routing and path=20 >>>>>>>>>> selection at Layer >>>>>>>>>> 3 (Routing for L2N Architecture) >>>>>>>>>> * Decide whether the L2Ns routing protocol require a=20 >>>>>>>>>> distributed, >>>>>>>>>> centralized path computation models or both. >>>>>>>>>> * Decide whether the L2N routing protocol requires a=20 >>>>>>>>>> hierarchical routing >>>>>>>>>> approach. >>>>>>>>>> >>>>>>>>>> - Produce a security framework for routing in L2Ns. >>>>>>>>>> >>>>>>>>>> Goals And Milestones: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> April 2008 Submit Use case/Routing requirements for=20 >>>>>>>>>> Industrial, Connected >>>>>>>>>> Home, Building and Urban networks applications to the IESG to=20 >>>>>>>>>> be considered >>>>>>>>>> as an Informational RFC. >>>>>>>>>> >>>>>>>>>> August 2008: Submit Routing metrics for L2Ns document to the=20 >>>>>>>>>> IESG to be >>>>>>>>>> considered as an Informational RFC. >>>>>>>>>> >>>>>>>>>> September 2008: Submit first draft of the Routing for L2Ns=20 >>>>>>>>>> Architecture >>>>>>>>>> document (summary of requirements, path computation model, >>>>>>>>>> flat/hierarchy,=C5=A0). >>>>>>>>>> >>>>>>>>>> November 2008: Submit Protocol Survey to the IESG to be=20 >>>>>>>>>> considered as an >>>>>>>>>> Informational RFC. >>>>>>>>>> >>>>>>>>>> January 2009 Submit Security Framework for L2Ns to the IESG=20 >>>>>>>>>> to be considered >>>>>>>>>> as an Informational RFC >>>>>>>>>> >>>>>>>>>> February 2009: Submit the Routing for L2Ns Architecture=20 >>>>>>>>>> document (summary >>>>>>>>>> of requirements, metrics and attributes, path selection=20 >>>>>>>>>> model) to the IESG >>>>>>>>>> as an Informational RFC. >>>>>>>>>> >>>>>>>>>> March 2009: Recharter. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please comment/suggest/... >>>>>>>>>> >>>>>>>>>> See you in Vancouver. >>>>>>>>>> >>>>>>>>>> JP and David. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> RSN mailing list >>>>>>>>>> RSN@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> RSN mailing list >>>>>>>>>> RSN@ietf.org >>>>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> =20 >>>>>>>> _______________________________________________ >>>>>>>> 6lowpan mailing list >>>>>>>> 6lowpan@ietf.org >>>>>>>> https://www1.ietf.org/mailman/listinfo/6lowpan >>>>>>>> =20 >>>>>>> >>>>>>> =20 >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Tue Dec 04 12:21:25 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 1IzbSX-00041J-Cy; Tue, 04 Dec 2007 12:21:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbSW-00041A-Px for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 12:21:24 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzbSW-0000M5-87 for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 12:21:24 -0500 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id lB4HLLXV024123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Dec 2007 09:21:22 -0800 (PST) Message-ID: <47558C8C.8050403@eecs.berkeley.edu> Date: Tue, 04 Dec 2007 09:21:16 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jonathan Hui Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> In-Reply-To: <47558AC4.9060802@eecs.berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 6lowpan <6lowpan@lists.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 Jonathan - until we start to get into stateful header compression, all of the information that is covered in the L4 checksum is covered by the L2 MIC. It may be in a different form, but it's all there. I'm far more concerned about corruption due to RF communication problems than I am about corruption due to incorrect algorithm implementation. No matter what we do, bad implementations will always be a problem - what if my mote calculates the checksum properly, but swapped some bytes in the message formation before calculating the checksum, or just generated the wrong command packet in the first place? Those are errors of comparable simplicity to not being able to compress or decompress the 6LoWPAN header properly. There's a long list of simple mistakes that can be made by a node that aren't going to get caught by either an L4 checksum or an L2 MIC. Intermediate routers will always have an opportunity to incorrectly accept a corrupted packet or transmit a mutated one. Those aren't the errors that I'm worried about, because we have some control over them. The ones that we can't control are the ones that happen in the ether. So I'll go back to my earlier question: given your concern about people improperly compressing and decompressing, and the realities of low power wireless in a shared ISM band, which do you think will have more end to end errors? A) n hops with L4 checksum B) n hops with L2 MIC Or maybe a better question is: does option B scare you so much that we don't want to allow people to do it because it may corrupt our otherwise flawless networks? ksjp > > Jonathan Hui wrote: >> >> Hi Kris, >> >> I'm still not seeing how L2 MICs negate the need for L4 MICs. L2 MICs >> are verified and recomputed hop by hop, where as L4 MICs are not. >> There are a couple reasons why L2 MICs do not cover all of the >> functionality of L4 MICs. First, an intermediate router could >> incorrectly accept a corrupted packet or incorrectly mutate the L2 >> payload yet compute a MIC that will indicate the packet is still >> valid to the next hop. Second, the L2 MIC as currently defined by >> 802.15.4 only covers the bits contained within the frame. It does not >> take in any knowledge of the upper layers. An L4 MIC necessarily >> covers the IPv6 pseudo-header and does so in 6LoWPAN even if some of >> those bits are elided. >> >> The only case I see where the L2 MIC covers every bit of >> functionality an L4 MIC might provide is if the IPv6 datagram is >> carried uncompressed within the L2 frame and communication occurs >> within link-local scope. >> >> -- >> Jonathan Hui > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 04 12:39:48 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 1IzbkK-000460-5Z; Tue, 04 Dec 2007 12:39:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzbkJ-00043l-5Y for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 12:39:47 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzbkF-0002Gj-Hd for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 12:39:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 30C74A964A; Tue, 4 Dec 2007 09:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-10 required=6.6 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arA8mSQh7uqT; Tue, 4 Dec 2007 09:39:34 -0800 (PST) Received: from [192.168.249.177] (unknown [216.18.3.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 0CAD0A9653; Tue, 4 Dec 2007 09:39:33 -0800 (PST) Message-ID: <475590BF.2040403@archrock.com> Date: Tue, 04 Dec 2007 09:39:11 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> In-Reply-To: <47558AC4.9060802@eecs.berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 303e29529f30c23b95ea718537067fd5 Cc: 6lowpan <6lowpan@lists.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 Kris, see comments in line. Kris Pister wrote: > Jonathan - until we start to get into stateful header compression, all=20 > of the information that is covered in the L4 checksum is covered by the= =20 > L2 MIC. It may be in a different form, but it's all there. Ah, I was looking forward as we go into more stateful approaches. If you=20 are concerned only for LOWPAN_HC1/2 as defined in RFC4944, then it is=20 possible for an L2 MIC to cover the same information as an L4 checksum.=20 But even with stateless approaches, the properties they provide are not=20 identical. > I'm far more concerned about corruption due to RF communication problem= s=20 > than I am about corruption due to incorrect algorithm implementation. =20 > No matter what we do, that will always be a problem - what if my mote=20 > calculates the checksum properly, but swapped some bytes in the message= =20 > formation before calculating the checksum, or just generated the wrong=20 > command packet in the first place? Those are errors of comparable=20 > simplicity to not being able to compress or decompress the 6LoWPAN=20 > header properly. There's a long list of simple mistakes that can be=20 > made by a node that aren't going to get caught by either an L4 checksum= =20 > or an L2 MIC. Those aren't the ones that I'm worried about, because we= =20 > have some control over them. The ones that we can't control are the=20 > ones that happen in the ether. The examples you provided are on the end points, not intermediary nodes. > So I'll go back to my earlier question: given your concern about people= =20 > improperly compressing and decompressing, and the realities of low powe= r=20 > wireless in a shared ISM band, which do you think will have more end to= =20 > end errors? > A) n hops with L4 checksum > B) n hops with L2 MIC > Or maybe a better question is: does option B scare you so much that we=20 > don't want to allow people to do it because it may corrupt our otherwis= e=20 > flawless networks? My argument is we need both A and B. -- Jonathan Hui >=20 > ksjp >=20 > Jonathan Hui wrote: >> >> Hi Kris, >> >> I'm still not seeing how L2 MICs negate the need for L4 MICs. L2 MICs=20 >> are verified and recomputed hop by hop, where as L4 MICs are not.=20 >> There are a couple reasons why L2 MICs do not cover all of the=20 >> functionality of L4 MICs. First, an intermediate router could=20 >> incorrectly accept a corrupted packet or incorrectly mutate the L2=20 >> payload yet compute a MIC that will indicate the packet is still valid= =20 >> to the next hop. Second, the L2 MIC as currently defined by 802.15.4=20 >> only covers the bits contained within the frame. It does not take in=20 >> any knowledge of the upper layers. An L4 MIC necessarily covers the=20 >> IPv6 pseudo-header and does so in 6LoWPAN even if some of those bits=20 >> are elided. >> >> The only case I see where the L2 MIC covers every bit of functionality= =20 >> an L4 MIC might provide is if the IPv6 datagram is carried=20 >> uncompressed within the L2 frame and communication occurs within=20 >> link-local scope. >> >> --=20 >> Jonathan Hui >> >> >> Kris Pister wrote: >>> Jonathan - I'm not arguing for a different transport layer, I'm=20 >>> arguing that there are more bits that can be compressed out of the=20 >>> existing compressed UDP header. >>> HC_UDP bits 3 through 7 are currently reserved. >>> My suggestion is that we take one of them, e.g. bit 3, and use it to=20 >>> indicate whether the 2 byte checksum is compressed. >>> ---------- >>> Checksum (bit 3) : >>> 0: not compressed, carried inline (Section 10.3.2) >>> >>> 1: compressed (L2 MIC assumed). If this option is used, the=20 >>> packet MUST be sent with L2 message integrity. >>> ----------- >>> If the node can't send with an L2 MIC, or it doesn't know if the=20 >>> message will be sent with an L2 MIC, then it sends the checksum. If=20 >>> the packet comes in with the checksum compressed, and the node can't=20 >>> send it that way, then it calculates the checksum. I don't think=20 >>> that you can claim that this is more of a layer violation than some=20 >>> of the other compression that we're specifying already. >>> I stand by my claim that an L2 MIC and no checksum on some or all=20 >>> hops along a path will give you higher end to end integrity than=20 >>> sending the checksum with no L2 MIC. Of course, you can send both,=20 >>> which is what 4944 forces you to do now if you want an L2 MIC. But=20 >>> the whole premise of the document, as stated in the introduction, is=20 >>> that header compression is important. >>> If people want to avoid having an L2 MIC, that's fine. But if you=20 >>> use one, then sending the 2 byte UDP checksum is silly. >>> >>> ksjp >>> >>> Jonathan Hui wrote: >>>> >>>> Yes, its clear that a 32-bit MIC is stronger than a 16 bit checksum.= =20 >>>> However, a MIC at L2 no matter how many bits it is is not end-to-end= =20 >>>> and does not negate the need for L4 integrity checks. Wanting to use= =20 >>>> a stronger checksum at L4 sounds like you want a different transport= =20 >>>> layer. You mentioned earlier on this list that losses apply to every= =20 >>>> link, even wired ones. So if you want stronger end-to-end integrity=20 >>>> checks, use a transport layer other than UDP. That's the beauty of I= P. >>>> >>>> --=20 >>>> Jonathan Hui >>>> >>>> >>>> Kris Pister wrote: >>>>> A 16 bit checksum at L4 is redundant if every L2 hop has a 32 bit M= IC. >>>>> A 16 bit checksum at L4 is not sufficient protection against bit=20 >>>>> errors without a 32 bit MIC somewhere (either L2 or L4/5, or both=20 >>>>> as in HART). >>>>> >>>>> If you run 15.4 networks without a 32 bit MIC, I guarantee you that= =20 >>>>> you will get valid checksums on corrupted packets. Depending on=20 >>>>> the network traffic, that might happen once per day per network. >>>>> >>>>> If a node knows that it's going to send a packet with a 32 bit L2=20 >>>>> MIC, can't it be smart enough to compress out the 16 bit checksum? = =20 >>>>> Is that really violating the requirement? (It's a simple enough=20 >>>>> change - we've got another bit in the HC2 header.) >>>>> >>>>> Put another way, which do you think is safer from an L3/L4 header=20 >>>>> error detection perspective: >>>>> A) sending packets over 10 hops with a 32 bit MIC at each hop and=20 >>>>> no 16 bit checksum >>>>> B) sending packets over 1 hop with no MIC and a 16 bit checksum >>>>> >>>>> The math is pretty clear. The measured data fits the math. >>>>> >>>>> ksjp >>>>> >>>>> Jonathan Hui wrote: >>>>>> >>>>>> Note that L2 message integrity doesn't provide end-to-end message=20 >>>>>> integrity, which L4 checksums (that cover the L3 header) provide. >>>>>> >>>>>> --=20 >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> Kris Pister wrote: >>>>>>> Geoff - ooh, I like exceptions. >>>>>>> Did we try to get an exception on the UDP checksum? It's painful= =20 >>>>>>> to leave that in the compressed header if we have L2 message=20 >>>>>>> integrity. >>>>>>> >>>>>>> ksjp >>>>>>> >>>>>>> Geoff Mulligan wrote: >>>>>>>> We have already received an exception from the IESG to IPsec on=20 >>>>>>>> 6lowpan >>>>>>>> devices. >>>>>>>> >>>>>>>> geoff >>>>>>>> >>>>>>>> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wro= te: >>>>>>>> =20 >>>>>>>>> Hum... >>>>>>>>> I had missed that; Seems that we have to make an exception :)=20 >>>>>>>>> If you consider ISA100.11a, they already have security at L2=20 >>>>>>>>> and L5, it makes little sense to MUST IPSec on top of that. >>>>>>>>> >>>>>>>>> Pascal >>>>>>>>> >>>>>>>>> =20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>>>>> Sent: Wednesday, November 28, 2007 8:03 PM >>>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>>> Cc: 6lowpan >>>>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Chart= er >>>>>>>>>> >>>>>>>>>> Hmm. From 4294: >>>>>>>>>> >>>>>>>>>> "However, while authentication and encryption can each be=20 >>>>>>>>>> NULL, they >>>>>>>>>> MUST NOT both be NULL." >>>>>>>>>> >>>>>>>>>> ksjp >>>>>>>>>> >>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>> =20 >>>>>>>>>>> Hi Kris: >>>>>>>>>>> >>>>>>>>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL=20 >>>>>>>>>>> encryption and authentication for >>>>>>>>>>> =20 >>>>>>>>>> interoperability reasons. >>>>>>>>>> =20 >>>>>>>>>>> On the general question of RFC 4294 itself: I'm not sure the=20 >>>>>>>>>>> work was ever done. I hope someone >>>>>>>>>>> =20 >>>>>>>>> >from the list can help? >>>>>>>>> =20 >>>>>>>>>>> If the answer is unclear, and considering that we are=20 >>>>>>>>>>> re-chartering the group, maybe we could have >>>>>>>>>>> =20 >>>>>>>>>> a work item to specify the instantiation of RFC 4294 for=20 >>>>>>>>>> LoWPAN nodes? >>>>>>>>>> =20 >>>>>>>>>>> Pascal >>>>>>>>>>> ________________________________________ >>>>>>>>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>>>>>>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>>>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>>>>> Cc: 6lowpan >>>>>>>>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Char= ter >>>>>>>>>>> >>>>>>>>>>> Is there an email thread somewhere that discusses the impact=20 >>>>>>>>>>> on 6LoWPAN of the security >>>>>>>>>>> =20 >>>>>>>>>> requirements of 4294 and 4303? >>>>>>>>>> =20 >>>>>>>>>>> My first quick readthrough makes me very uncomfortable that=20 >>>>>>>>>>> some of the mandates are going to be >>>>>>>>>>> =20 >>>>>>>>>> ugly from a header standpoint. >>>>>>>>>> =20 >>>>>>>>>>> ksjp >>>>>>>>>>> >>>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>>> Hi JP: >>>>>>>>>>> >>>>>>>>>>> Thanks a bunch for this charter. I'll try not to rephrase=20 >>>>>>>>>>> what was already discussed with Christian, >>>>>>>>>>> =20 >>>>>>>>>> Anders, Philip and Misha. >>>>>>>>>> =20 >>>>>>>>>>> There's an additional item I'd wish to see either in ROLL or=20 >>>>>>>>>>> 6LoWPAN and I do not know exactly >>>>>>>>>>> =20 >>>>>>>>>> where it belongs, maybe both. The question is whether we need=20 >>>>>>>>>> to and can document how RFC 4294 >>>>>>>>>> applies for sensors, and M2M devices in general, whether they=20 >>>>>>>>>> act as hosts or as routers. >>>>>>>>>> =20 >>>>>>>>>>> I've seen IPv6 presented as a Pandora box that drags just too= =20 >>>>>>>>>>> much stuff to be incorporated in a >>>>>>>>>>> =20 >>>>>>>>>> sensory device. For instance, at the moment, SP100.11a=20 >>>>>>>>>> endorses 6LoWPAN formats but it's not so clear >>>>>>>>>> at all that IPv6 itself is mandated. A clear spec with=20 >>>>>>>>>> well-documented implementation could be a >>>>>>>>>> formidable tool to despond to Fear, Uncertainty and Defiance. >>>>>>>>>> =20 >>>>>>>>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe=20 >>>>>>>>>>> can do without multicast at all if ND is >>>>>>>>>>> =20 >>>>>>>>>> supported some other way (such as suggested in:=20 >>>>>>>>>> http://www.ietf.org/internet-drafts/draft-thubert- >>>>>>>>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and=20 >>>>>>>>>> authentication is enough etc, etc... >>>>>>>>>> =20 >>>>>>>>>>> Being able to define one minimum set and maybe a few other=20 >>>>>>>>>>> profiles for the use cases that we >>>>>>>>>>> =20 >>>>>>>>>> selected could help tremendously. >>>>>>>>>> =20 >>>>>>>>>>> Otherwise I find the charter real well written and easy to=20 >>>>>>>>>>> digest. >>From the MANEMO experience, I >>>>>>>>>>> =20 >>>>>>>>>> expect that some arguments about the relative applicability of= =20 >>>>>>>>>> existing MANET protocols will be >>>>>>>>>> difficult to prove without some good simulation work running=20 >>>>>>>>>> agreed-upon scenarios. >>>>>>>>>> =20 >>>>>>>>>>> Finally, I'm a bit confused that it seems that both IPv4 and=20 >>>>>>>>>>> IPv6 seem supported. Ipv4 comes with a >>> >>>>>>>>>>> =20 >>>>>>>>>> lot of overhead like DHCP. I suggest that when trouble comes=20 >>>>>>>>>> and things can not be done in a common >>>>>>>>>> fashion for both IP protocols, hen we prioritize IPv6. >>>>>>>>>> =20 >>>>>>>>>>> Unfortunately, I can not make it to Vancouver, but I do feel=20 >>>>>>>>>>> that the work is really needed so >>>>>>>>>>> =20 >>>>>>>>>> please count my vote in for the adoption of the WG. >>>>>>>>>> =20 >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Pascal >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Jean Philippe Vasseur (jvasseur) >>>>>>>>>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>>>>>>>>> To: rsn@ietf.org >>>>>>>>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>>>>>>>>> >>>>>>>>>>> Dear all, >>>>>>>>>>> >>>>>>>>>>> As promised, here is the new proposed Working Group, which=20 >>>>>>>>>>> reflects the >>>>>>>>>>> number of comments/suggestions that we received, the pre-WG=20 >>>>>>>>>>> consensus, ... >>>>>>>>>>> >>>>>>>>>>> Thanks to Dave Ward (RTD AD) for his input. >>>>>>>>>>> >>>>>>>>>>> Proposed RL2N WG Charter >>>>>>>>>>> >>>>>>>>>>> Description of Working Group >>>>>>>>>>> >>>>>>>>>>> L2Ns (Low power and Lossy networks) are typically composed of= =20 >>>>>>>>>>> many embedded >>>>>>>>>>> devices with limited power, memory, and processing resources=20 >>>>>>>>>>> interconnected >>>>>>>>>>> by a variety of wireless links, such as IEEE 802.15.4,=20 >>>>>>>>>>> Bluetooth, Low Power >>>>>>>>>>> WiFi. >>>>>>>>>>> >>>>>>>>>>> L2Ns are transitioning to an end-to-end IP-based solution to=20 >>>>>>>>>>> avoid the >>>>>>>>>>> problems of non-interoperable networks interconnected by=20 >>>>>>>>>>> protocol >>>>>>>>>>> translation gateways and proxies. In addition, L2Ns have=20 >>>>>>>>>>> specific routing >>>>>>>>>>> requirements that are not currently met by existing routing=20 >>>>>>>>>>> protocols, such >>>>>>>>>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be=20 >>>>>>>>>>> designed to take >>>>>>>>>>> into consideration the specific power, capabilities,=20 >>>>>>>>>>> attributes and >>>>>>>>>>> functional characteristics of the links and nodes in the=20 >>>>>>>>>>> network. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> There is a wide scope of application areas for L2Ns,=20 >>>>>>>>>>> including industrial >>>>>>>>>>> monitoring, building automation (HVAC, lighting/access=20 >>>>>>>>>>> control), connected >>>>>>>>>>> home, healthcare, environmental monitoring, agricultural,=20 >>>>>>>>>>> smart cities, >>>>>>>>>>> logistics, assets tracking, and refrigeration. The L2N WG=20 >>>>>>>>>>> will focus on >>>>>>>>>>> routing solutions for a subset of these deployment scenarios,= =20 >>>>>>>>>>> namely >>>>>>>>>>> industrial, connected home/building and urban applications.=20 >>>>>>>>>>> The Working >>>>>>>>>>> Group will determine the routing requirements for these=20 >>>>>>>>>>> scenarios. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The Working Group will provide a routing framework for these=20 >>>>>>>>>>> application >>>>>>>>>>> scenarios that provides high reliability in the presence of=20 >>>>>>>>>>> time varying >>>>>>>>>>> loss characteristics and connectivity while permitting=20 >>>>>>>>>>> low-power operation >>>>>>>>>>> with very modest memory and CPU pressure. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The Working Group will pay a particular attention to routing=20 >>>>>>>>>>> security and >>>>>>>>>>> manageability (e.g self managing/configuration) issues, which= =20 >>>>>>>>>>> are >>>>>>>>>>> particularly critical for L2Ns. >>>>>>>>>>> >>>>>>>>>>> Work Items: >>>>>>>>>>> >>>>>>>>>>> - Produce use cases documents for Industrial, Connected Home,= =20 >>>>>>>>>>> Building and >>>>>>>>>>> urban application networks. Each document will describe the=20 >>>>>>>>>>> use case and the >>>>>>>>>>> associated routing protocol requirements. The documents will=20 >>>>>>>>>>> progress in >>>>>>>>>>> collaboration with the 6lowpan Working Group (INT area). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - Survey the applicability of existing protocols to L2Ns. The= =20 >>>>>>>>>>> aim of this >>>>>>>>>>> document will be to analyze the scaling and characteristics=20 >>>>>>>>>>> of existing >>>>>>>>>>> protocols and identify whether or not they meet the routing=20 >>>>>>>>>>> requirements of >>>>>>>>>>> the L2Ns applications identified above. Existing IGPs, MANET,= =20 >>>>>>>>>>> NEMO, DTN >>>>>>>>>>> routing protocols will be part of evaluation. >>>>>>>>>>> >>>>>>>>>>> - Specification of routing metrics used in path calculation.=20 >>>>>>>>>>> This includes >>>>>>>>>>> static and dynamic link/nodes attributes required for routing= =20 >>>>>>>>>>> in L2Ns. >>>>>>>>>>> >>>>>>>>>>> - Provide an architectural framework for routing and path=20 >>>>>>>>>>> selection at Layer >>>>>>>>>>> 3 (Routing for L2N Architecture) >>>>>>>>>>> * Decide whether the L2Ns routing protocol require a=20 >>>>>>>>>>> distributed, >>>>>>>>>>> centralized path computation models or both. >>>>>>>>>>> * Decide whether the L2N routing protocol requires a=20 >>>>>>>>>>> hierarchical routing >>>>>>>>>>> approach. >>>>>>>>>>> >>>>>>>>>>> - Produce a security framework for routing in L2Ns. >>>>>>>>>>> >>>>>>>>>>> Goals And Milestones: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> April 2008 Submit Use case/Routing requirements for=20 >>>>>>>>>>> Industrial, Connected >>>>>>>>>>> Home, Building and Urban networks applications to the IESG to= =20 >>>>>>>>>>> be considered >>>>>>>>>>> as an Informational RFC. >>>>>>>>>>> >>>>>>>>>>> August 2008: Submit Routing metrics for L2Ns document to the=20 >>>>>>>>>>> IESG to be >>>>>>>>>>> considered as an Informational RFC. >>>>>>>>>>> >>>>>>>>>>> September 2008: Submit first draft of the Routing for L2Ns=20 >>>>>>>>>>> Architecture >>>>>>>>>>> document (summary of requirements, path computation model, >>>>>>>>>>> flat/hierarchy,=C5=A0). >>>>>>>>>>> >>>>>>>>>>> November 2008: Submit Protocol Survey to the IESG to be=20 >>>>>>>>>>> considered as an >>>>>>>>>>> Informational RFC. >>>>>>>>>>> >>>>>>>>>>> January 2009 Submit Security Framework for L2Ns to the IESG=20 >>>>>>>>>>> to be considered >>>>>>>>>>> as an Informational RFC >>>>>>>>>>> >>>>>>>>>>> February 2009: Submit the Routing for L2Ns Architecture=20 >>>>>>>>>>> document (summary >>>>>>>>>>> of requirements, metrics and attributes, path selection=20 >>>>>>>>>>> model) to the IESG >>>>>>>>>>> as an Informational RFC. >>>>>>>>>>> >>>>>>>>>>> March 2009: Recharter. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please comment/suggest/... >>>>>>>>>>> >>>>>>>>>>> See you in Vancouver. >>>>>>>>>>> >>>>>>>>>>> JP and David. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> RSN mailing list >>>>>>>>>>> RSN@ietf.org >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> RSN mailing list >>>>>>>>>>> RSN@ietf.org >>>>>>>>>>> https://www1.ietf.org/mailman/listinfo/rsn >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> =20 >>>>>>>>> _______________________________________________ >>>>>>>>> 6lowpan mailing list >>>>>>>>> 6lowpan@ietf.org >>>>>>>>> https://www1.ietf.org/mailman/listinfo/6lowpan >>>>>>>>> =20 >>>>>>>> >>>>>>>> =20 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 Tue Dec 04 12:54: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 1Izby5-0003m5-FD; Tue, 04 Dec 2007 12:54:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izby4-0003lb-T1 for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 12:54:00 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izby2-0003aw-Gc for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 12:54:00 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lB4HrhDk002590; Tue, 4 Dec 2007 18:53:44 +0100 (CET) Received: from [130.129.85.253] (unknown [130.129.85.253]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 05AA96137; Tue, 4 Dec 2007 18:53:42 +0100 (CET) Message-Id: <1CD19A8B-C834-41D7-A772-977883F4D950@tzi.org> From: Carsten Bormann To: Kris Pister In-Reply-To: <47558C8C.8050403@eecs.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Tue, 4 Dec 2007 09:52:26 -0800 References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> <47558C8C.8050403@eecs.berkeley.edu> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Dec 04 2007, at 09:21, Kris Pister wrote: > does option B scare you It sure scares me. http://portal.acm.org/citation.cfm?doid=347059.347561 "This dataset shows the Internet has a wide variety of error sources which can not be detected by link-level checks." RFC 3819 therefore says: Packet corruption may be, and is, also caused by bugs in host and router hardware and software. Even if every subnetwork implemented strong error detection, it is still essential that end-to-end checksums are used at the receiving end host [SP2000]. Whether this class of observations is relevant to LoWPANs can be (and needs to be) discussed. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 04 15:50:24 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 1Izeij-0005q9-0C; Tue, 04 Dec 2007 15:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izeih-0005pa-DL for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 15:50:19 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izeic-0001NW-Li for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 15:50:19 -0500 Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id lB4KoAj8029022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Dec 2007 12:50:12 -0800 (PST) Message-ID: <4755BD7E.6020706@eecs.berkeley.edu> Date: Tue, 04 Dec 2007 12:50:06 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> <47558C8C.8050403@eecs.berkeley.edu> <1CD19A8B-C834-41D7-A772-977883F4D950@tzi.org> In-Reply-To: <1CD19A8B-C834-41D7-A772-977883F4D950@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 6lowpan <6lowpan@lists.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 Touche'! It's an ugly internet out there. :) I agree with their conclusion that "if the consequences of data corruption are large [...] the application should add a stronger application-level checksum." So the truth is that I only trust networks that have 4 byte MICs at both L2 and L4/5. Given that I know that I'm going to have that in any networks that I build myself, 2 bytes of UDP checksum just doesn't seem very attractive to me, and I'd like to be able to have the option to elide them. ksjp Carsten Bormann wrote: > On Dec 04 2007, at 09:21, Kris Pister wrote: > >> does option B scare you > > It sure scares me. > > http://portal.acm.org/citation.cfm?doid=347059.347561 > "This dataset shows the Internet has a wide variety of error sources > which can not be detected by link-level checks." > > RFC 3819 therefore says: > Packet corruption may be, and is, also caused by bugs in host and > router hardware and software. Even if every subnetwork implemented > strong error detection, it is still essential that end-to-end > checksums are used at the receiving end host [SP2000]. > > Whether this class of observations is relevant to LoWPANs can be (and > needs to be) discussed. > > Gruesse, Carsten > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 04 16:08:47 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 1Izf0Z-0004dR-CL; Tue, 04 Dec 2007 16:08:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izf0Y-0004dF-6z for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 16:08:46 -0500 Received: from letter.sics.se ([193.10.64.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izf0X-0002yf-S3 for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 16:08:46 -0500 Received: from [127.0.0.1] (pptp-8.sics.se [193.10.64.168]) by letter.sics.se (Postfix) with ESMTP id 0E8144025F; Tue, 4 Dec 2007 22:08:43 +0100 (CET) Message-ID: <4755C1B2.9010207@sics.se> Date: Tue, 04 Dec 2007 22:08:02 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> <47558C8C.8050403@eecs.berkeley.edu> <1CD19A8B-C834-41D7-A772-977883F4D950@tzi.org> <4755BD7E.6020706@eecs.berkeley.edu> In-Reply-To: <4755BD7E.6020706@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Kris Pister wrote: > Touche'! It's an ugly internet out there. :) > I agree with their conclusion that "if the consequences of data > corruption are large [...] the application should add a stronger > application-level checksum." > > So the truth is that I only trust networks that have 4 byte MICs at both > L2 and L4/5. Given that I know that I'm going to have that in any > networks that I build myself, 2 bytes of UDP checksum just doesn't seem > very attractive to me, and I'd like to be able to have the option to > elide them. It is always possible disable the UDP checksum on a per-datagram basis by setting the checksum field of the UDP header to all zeros. All IP end hosts interpret this as a disabled checksum and do not try to compute the UDP checksum for incoming UDP datagrams. Valid UDP checksums are explicitly never all zeros - a zero checksum is sent as all ones instead. A header compression scheme can safely compress away the entire checksum field for datagrams without a UDP checksum (but leaving a bit to indicate that the checksum is disabled). /adam -- Adam Dunkels http://www.sics.se/~adam/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 04 16:27: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 1IzfIE-0001CO-Jy; Tue, 04 Dec 2007 16:27:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfID-0001C8-VJ for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 16:27:01 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzfIC-0004ef-AM for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 16:27:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 071FAA9651; Tue, 4 Dec 2007 13:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-10 required=6.6 tests=[BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xJMv9gTzooY; Tue, 4 Dec 2007 13:26:54 -0800 (PST) Received: from [192.168.249.177] (unknown [216.18.3.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D2FC1A962B; Tue, 4 Dec 2007 13:26:53 -0800 (PST) Message-ID: <4755C606.3060309@archrock.com> Date: Tue, 04 Dec 2007 13:26:30 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> <47558C8C.8050403@eecs.berkeley.edu> <1CD19A8B-C834-41D7-A772-977883F4D950@tzi.org> <4755BD7E.6020706@eecs.berkeley.edu> In-Reply-To: <4755BD7E.6020706@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Kris Pister wrote: > So the truth is that I only trust networks that have 4 byte MICs at both > L2 and L4/5. Given that I know that I'm going to have that in any > networks that I build myself, 2 bytes of UDP checksum just doesn't seem > very attractive to me, and I'd like to be able to have the option to > elide them. In a previous email, you stated that you weren't arguing for a different transport layer. But now it sounds like you want to change L4 to include a 4 byte MIC. I guess I don't understand why you want to use UDP if you want stronger message integrity checks at L4. -- Jonathan Hui > > ksjp > > Carsten Bormann wrote: >> On Dec 04 2007, at 09:21, Kris Pister wrote: >> >>> does option B scare you >> >> It sure scares me. >> >> http://portal.acm.org/citation.cfm?doid=347059.347561 >> "This dataset shows the Internet has a wide variety of error sources >> which can not be detected by link-level checks." >> >> RFC 3819 therefore says: >> Packet corruption may be, and is, also caused by bugs in host and >> router hardware and software. Even if every subnetwork implemented >> strong error detection, it is still essential that end-to-end >> checksums are used at the receiving end host [SP2000]. >> >> Whether this class of observations is relevant to LoWPANs can be (and >> needs to be) discussed. >> >> Gruesse, Carsten >> > > _______________________________________________ > 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 Tue Dec 04 16:30:07 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 1IzfLD-0007Ja-HO; Tue, 04 Dec 2007 16:30:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfLC-0007JR-KP for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 16:30:06 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzfLC-0004tZ-C0 for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 16:30:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 5A6B5A964D; Tue, 4 Dec 2007 13:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-10 required=6.6 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmQkTGEBKp-Y; Tue, 4 Dec 2007 13:30:00 -0800 (PST) Received: from [192.168.249.177] (unknown [216.18.3.1]) by mail.sf.archrock.com (Postfix) with ESMTP id EB941A9641; Tue, 4 Dec 2007 13:29:58 -0800 (PST) Message-ID: <4755C6BE.9050603@archrock.com> Date: Tue, 04 Dec 2007 13:29:34 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Adam Dunkels Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> <47558C8C.8050403@eecs.berkeley.edu> <1CD19A8B-C834-41D7-A772-977883F4D950@tzi.org> <4755BD7E.6020706@eecs.berkeley.edu> <4755C1B2.9010207@sics.se> In-Reply-To: <4755C1B2.9010207@sics.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Adam Dunkels wrote: > It is always possible disable the UDP checksum on a per-datagram basis > by setting the checksum field of the UDP header to all zeros. All IP end > hosts interpret this as a disabled checksum and do not try to compute > the UDP checksum for incoming UDP datagrams. Valid UDP checksums are > explicitly never all zeros - a zero checksum is sent as all ones instead. > > A header compression scheme can safely compress away the entire checksum > field for datagrams without a UDP checksum (but leaving a bit to > indicate that the checksum is disabled). True for IPv4, but not in IPv6. From RFC 2460: o Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 04 16:33:08 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 1IzfO6-0004oZ-4z; Tue, 04 Dec 2007 16:33:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfO5-0004lT-23 for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 16:33:05 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzfO4-000589-Jf for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 16:33:05 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from localhost (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lB4LWqxx010480; Tue, 4 Dec 2007 22:32:53 +0100 (CET) Message-Id: <69644147-68A9-4CCB-9717-23ACCF747961@tzi.org> From: Carsten Bormann To: Adam Dunkels In-Reply-To: <4755C1B2.9010207@sics.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Tue, 4 Dec 2007 13:32:52 -0800 References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> <47558C8C.8050403@eecs.berkeley.edu> <1CD19A8B-C834-41D7-A772-977883F4D950@tzi.org> <4755BD7E.6020706@eecs.berkeley.edu> <4755C1B2.9010207@sics.se> X-Mailer: Apple Mail (2.915) X-Spam-Score: 4.5 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Dec 04 2007, at 13:08, Adam Dunkels wrote: > Kris Pister wrote: >> Touche'! It's an ugly internet out there. :) >> I agree with their conclusion that "if the consequences of data >> corruption are large [...] the application should add a stronger >> application-level checksum." >> So the truth is that I only trust networks that have 4 byte MICs at >> both L2 and L4/5. Given that I know that I'm going to have that in >> any networks that I build myself, 2 bytes of UDP checksum just >> doesn't seem very attractive to me, and I'd like to be able to have >> the option to elide them. > > It is always possible disable the UDP checksum on a per-datagram > basis by setting the checksum field of the UDP header to all zeros. Not in IPv6. > A header compression scheme can safely compress away the entire > checksum field for datagrams without a UDP checksum (but leaving a > bit to indicate that the checksum is disabled). (You wouldn't leave a bit in the packet, you would leave state in the context.) Yes. This works great for IPv4. See RFC 3095. But not for IPv6. See RFC 2460 (you may want to jump to the 61205th character). Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 04 17:33:24 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 1IzgKQ-0005z3-4g; Tue, 04 Dec 2007 17:33:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgKO-0005yr-Ko for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 17:33:20 -0500 Received: from letter.sics.se ([193.10.64.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzgKM-0001kH-54 for 6lowpan@lists.ietf.org; Tue, 04 Dec 2007 17:33:20 -0500 Received: from [127.0.0.1] (pptp-8.sics.se [193.10.64.168]) by letter.sics.se (Postfix) with ESMTP id BB7364025F; Tue, 4 Dec 2007 23:33:16 +0100 (CET) Message-ID: <4755D582.30508@sics.se> Date: Tue, 04 Dec 2007 23:32:34 +0100 From: Adam Dunkels User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> <474F0DB8.6080706@archrock.com> <4751F0F9.6000402@eecs.berkeley.edu> <4751F662.1080907@archrock.com> <47545B05.2060202@eecs.berkeley.edu> <4754733C.2050001@archrock.com> <47558AC4.9060802@eecs.berkeley.edu> <47558C8C.8050403@eecs.berkeley.edu> <1CD19A8B-C834-41D7-A772-977883F4D950@tzi.org> <4755BD7E.6020706@eecs.berkeley.edu> <4755C1B2.9010207@sics.se> <69644147-68A9-4CCB-9717-23ACCF747961@tzi.org> In-Reply-To: <69644147-68A9-4CCB-9717-23ACCF747961@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: 6lowpan <6lowpan@lists.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 Carsten Bormann wrote: > On Dec 04 2007, at 13:08, Adam Dunkels wrote: > >> Kris Pister wrote: >>> Touche'! It's an ugly internet out there. :) >>> I agree with their conclusion that "if the consequences of data >>> corruption are large [...] the application should add a stronger >>> application-level checksum." >>> So the truth is that I only trust networks that have 4 byte MICs at >>> both L2 and L4/5. Given that I know that I'm going to have that in >>> any networks that I build myself, 2 bytes of UDP checksum just >>> doesn't seem very attractive to me, and I'd like to be able to have >>> the option to elide them. >> >> It is always possible disable the UDP checksum on a per-datagram basis >> by setting the checksum field of the UDP header to all zeros. > > Not in IPv6. > >> A header compression scheme can safely compress away the entire >> checksum field for datagrams without a UDP checksum (but leaving a bit >> to indicate that the checksum is disabled). > > (You wouldn't leave a bit in the packet, you would leave state in the > context.) > Yes. This works great for IPv4. See RFC 3095. > But not for IPv6. See RFC 2460 (you may want to jump to the 61205th > character). Ah, of course. I was obviously thinking about IPv4. /adam -- Adam Dunkels http://www.sics.se/~adam/ _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 06 02:57:32 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 1J0Bbo-0007SS-Gt; Thu, 06 Dec 2007 02:57:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Bbn-0007OV-AB for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 02:57:23 -0500 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Bbi-0000M4-N7 for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 02:57:23 -0500 Received: by an-out-0708.google.com with SMTP id d31so32384and for <6lowpan@lists.ietf.org>; Wed, 05 Dec 2007 23:57:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=WL+ePck/dIVvKdElI7a2LCpx6/kwmsDHlvg0XnCz2z4=; b=dzhoDKaj9os8g8+tJ9NDbhjzOz89Nn8JasiFujOsiq2MiCKSCsH+UbM3sHJoffLbheavzwFkBzp2vMmPP0sLEOKrObOihPSKu6LEVKnSHGqe7yBmzcbm840zMqqLljH5ltvuNfsDIDwZNkz8bCWKbOkRgFyA3ooNtIrxcQ18hHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=fOMye/Gb/XjFizQwMkDJNhl5sUepyUarDjgXbc38CD8TanpdHt7wWumCUbPsuUiHgbJduOq4+9uimcUMxtkeEpkIG7/Wrw++V7Ps5fzZ9F937E9dlWn3zZYZGmvocwEgUZ1MSduyGLoGh2d82Ld6QD0XITJa1v1pnmzisezOgSc= Received: by 10.100.239.11 with SMTP id m11mr5602624anh.1196927838391; Wed, 05 Dec 2007 23:57:18 -0800 (PST) Received: by 10.90.75.9 with HTTP; Wed, 5 Dec 2007 23:57:18 -0800 (PST) Message-ID: Date: Thu, 6 Dec 2007 16:57:18 +0900 From: "Daniel Park" To: 6lowpan <6lowpan@lists.ietf.org> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Subject: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) 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="===============0573040233==" Errors-To: 6lowpan-bounces@ietf.org --===============0573040233== Content-Type: multipart/alternative; boundary="----=_Part_3305_478849.1196927838387" ------=_Part_3305_478849.1196927838387 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This is a tip for understanding and referring how we can fat down NDP for 6lowpan networks. In 16ng working group, we tried to live up with IEEE 802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA optimization results... Hope those efforts help... Daniel Park Co-chair, 16ng working group. *8.2**. Router Advertisement* The AR SHOULD send a number (configurable value) of router advertisements as soon as the IPv6 link is established, to the MS. The AR sends unsolicited router advertisements periodically as per [RFC4861 ]. The interval between periodic router advertisements is however greater than the specification in Neighbor discovery for IPv6, and is discussed in the following section. *8.3**. Router lifetime and periodic router advertisements* The router lifetime SHOULD be set to a large value, preferably in hours. This document over-rides the specification for the value of the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) [RFC4861 ]. The AdvDefaultLifetime in the router advertisement MUST be either zero or between MaxRtrAdvInterval and 43200 seconds. The default value is 2 * MaxRtrAdvInterval. 802.16 hosts have the capability to transition to an idle mode in which case the radio link between the BS and MS is torn down. Paging is required in case the network needs to deliver packets to the MS. In order to avoid waking a mobile which is in idle mode and consuming resources on the air interface, the interval between periodic router advertisements SHOULD be set quite high. The MaxRtrAdvInterval value specified in this document over-rides the recommendation in Neighbor Discovery for IP Version 6 (IPv6) [RFC4861]. The MaxRtrAdvInterval MUST be no less than 4 seconds and no greater than 21600 seconds. The default value for MaxRtrAdvInterval is 10800 seconds. ------=_Part_3305_478849.1196927838387 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
This is a tip for understanding and referring how we can fat down NDP for 6lowpan networks. In 16ng working group, we tried to live up with IEEE 802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA optimization results...
 
Hope those efforts help...
 
Daniel Park
Co-chair, 16ng working group.
 
 
8.2.  Router Advertisement

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

8.3.  Router lifetime and periodic router advertisements

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

   802.16 hosts have the capability to transition to an idle mode in
   which case the radio link between the BS and MS is torn down.  Paging
   is required in case the network needs to deliver packets to the MS.
   In order to avoid waking a mobile which is in idle mode and consuming
   resources on the air interface, the interval between periodic router
   advertisements SHOULD be set quite high.  The MaxRtrAdvInterval value
   specified in this document over-rides the recommendation in Neighbor
   Discovery for IP Version 6 (IPv6) [ RFC4861].  The MaxRtrAdvInterval
   MUST be no less than 4 seconds and no greater than 21600 seconds.
   The default value for MaxRtrAdvInterval is 10800 seconds.
 
------=_Part_3305_478849.1196927838387-- --===============0573040233== 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 --===============0573040233==-- From 6lowpan-bounces@ietf.org Thu Dec 06 03:17:49 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 1J0BvY-0008EZ-LI; Thu, 06 Dec 2007 03:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0BvX-0008ER-DV for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 03:17:47 -0500 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0BvS-0001Hn-Nd for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 03:17:47 -0500 Received: by mu-out-0910.google.com with SMTP id w1so602184mue for <6lowpan@lists.ietf.org>; Thu, 06 Dec 2007 00:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Wq6OgaIYeHcgZtgMz2oF59wkRLhm/Ei8Z5GMx+B7f74=; b=AEf61M72o5fMkvnq0pwXf4bZUz3hwC+uGH2+vVhmvDLKtIcD30Mxyf2lV/DursoYvS2Y+SIiVWkzwiVvJWu/4dyVtiBSjAdkFxZgwPrnFTwxCUkbIUWPU1VW4CsT9NxjpTpTrpVZv1r0Clmzd5mE45lUHYkXLWyLrrVx7Cf5FYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F1xaMX91rM7moMee+eCFxKu0LLz30u9Ob8qYt4YH57EH9CTqaGveQL7iroE5MWL4UoPkdhxxaHRMrUqY32WE6x/vAsIi0zEJ7cPUKMvl5u26epJ43lJHycrVkpP00OAELj1asrS4OImAX24d4Wm72SXGOpluI740Lq+1menuypI= Received: by 10.86.87.5 with SMTP id k5mr797296fgb.1196929060826; Thu, 06 Dec 2007 00:17:40 -0800 (PST) Received: by 10.86.93.20 with HTTP; Thu, 6 Dec 2007 00:17:40 -0800 (PST) Message-ID: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> Date: Thu, 6 Dec 2007 00:17:40 -0800 From: "Samita Chakrabarti" To: "Daniel Park" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 6lowpan <6lowpan@lists.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 Daniel, Thanks for the 16ng ND optimization excerpts. The 16ng IPv6-ND and 6lowpan ND draft share the same idea in this respect. In addition to increasing the router advertisement interval, it also proposes a choice to avoid periodic RA alltogether by using periodic soliciation technique. That way, periodic RA will not wake up all the nodes in the 6lowpan. I see the default value for 802.16 network is about 18min for periodic RAs. -Samita On 12/5/07, Daniel Park wrote: > This is a tip for understanding and referring how we can fat down NDP for > 6lowpan networks. In 16ng working group, we tried to live up with IEEE > 802.16 Idle/Sleep mode in conjunction with IPv6 NDP. Here is a RA > optimization results... > > Hope those efforts help... > > Daniel Park > Co-chair, 16ng working group. > > > 8.2. Router Advertisement > > The AR SHOULD send a number (configurable value) of router > advertisements as soon as the IPv6 link is established, to the MS. > The AR sends unsolicited router advertisements periodically as per > [RFC4861]. The interval between periodic router advertisements is > however greater than the specification in Neighbor discovery for > IPv6, and is discussed in the following section. > > 8.3. Router lifetime and periodic router advertisements > > The router lifetime SHOULD be set to a large value, preferably in > hours. This document over-rides the specification for the value of > the router lifetime in Neighbor Discovery for IP Version 6 (IPv6) > [RFC4861]. The AdvDefaultLifetime in the router advertisement MUST > be either zero or between MaxRtrAdvInterval and 43200 seconds. The > default value is 2 * MaxRtrAdvInterval. > > 802.16 hosts have the capability to transition to an idle mode in > which case the radio link between the BS and MS is torn down. Paging > is required in case the network needs to deliver packets to the MS. > In order to avoid waking a mobile which is in idle mode and consuming > resources on the air interface, the interval between periodic router > advertisements SHOULD be set quite high. The MaxRtrAdvInterval value > specified in this document over-rides the recommendation in Neighbor > Discovery for IP Version 6 (IPv6) [ RFC4861]. The MaxRtrAdvInterval > MUST be no less than 4 seconds and no greater than 21600 seconds. > The default value for MaxRtrAdvInterval is 10800 seconds. > > _______________________________________________ > 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 Thu Dec 06 14:08: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 1J0M5L-0002r6-Pi; Thu, 06 Dec 2007 14:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0M5K-0002qw-PR for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 14:08:34 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0M5I-0000ID-Ct for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 14:08:34 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from localhost (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lB6J8NFl027825; Thu, 6 Dec 2007 20:08:23 +0100 (CET) Message-Id: From: Carsten Bormann To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: multipart/mixed; boundary=Apple-Mail-8--382429215 Mime-Version: 1.0 (Apple Message framework v915) Date: Thu, 6 Dec 2007 11:08:22 -0800 X-Mailer: Apple Mail (2.915) X-Spam-Score: 4.5 (++++) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: Carsten Bormann Subject: [6lowpan] Charter proposal 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 --Apple-Mail-8--382429215 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Lowpanners, Geoff and I have updated the charter proposal based on Marks input and yesterday's discussion. Now would be a good time for comments, in particular also on the timelines we are promising. Separately, we would like to know which of the items you are interested in contributing to -- please volunteer now. Gruesse, Carsten --Apple-Mail-8--382429215 Content-Disposition: attachment; filename="New Charter.txt" Content-Type: text/plain; x-unix-mode=0444; name="New Charter.txt" Content-Transfer-Encoding: 7bit Background/Introduction: Note: Given that there is not much precedent for this type of activity at the IETF, the text that follows is of an introductory nature. Hence, its objective is to give a general idea of the application area and motivations for the work. In particular, this section is not to be construed as detailing work items for the working group. That is done in the following section entitled "Scope of the Working Group." Well-established fields such as control networks, and burgeoning ones such as "sensor" (or transducer) networks, are increasingly being based on wireless technologies. Most (but certainly not all) of these nodes are amongst the most constrained that have ever been networked wirelessly. Extreme low power (such that they will run potentially for years on batteries) and extreme low cost (total device cost in single digit dollars, and riding Moore's law to continuously reduce that price point) are seen as essential enablers towards their deployment in networks with the following characteristics: * Significantly more devices than current local area networks * Severely limited code and ram space (e.g., highly desirable to fit the required code--MAC, IP and anything else needed to execute the embedded application--in, for example, 32K of flash memory, using 8-bit microprocessors) * Unobtrusive but very different user interface for configuration (e.g., using gestures or interactions involving the physical world) A chief component of these devices is wireless communication technology. In particular, the IEEE 802.15.4 standard is very promising for the lower (physical and link) layers. As for higher layer functions, there is considerable interest from non-IETF groups in using IP technology. The IEEE 1451.5 standard for wireless transducers has a chapter for 6LoWPAN and the ISA SP100 standard for wireless industrial networks has adopted 6LoWPAN for their network layer. This working group is expected to coordinate and interact with such groups. Description of Working Group: The working group has completed two RFCs: "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" (RFC4919) that documents and discusses the problem space and "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (RFC4944) which defines the format for the adaptation between IPv6 and 802.15.4. The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. Work Items: 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. 2. Produce "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 describe where the problems are. This document will be informational. 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. As a spin-off from that document, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. Both documents will be informational. 4. Produce "Use Cases for 6LoWPAN" to define, for a small set of applications with sufficiently unique requirements, how 6LoWPANs can solve those requirements, and which protocols and configuration variants can be used for these scenarios. The use cases will cover protocols for transport, application layer, discovery, configuration and commissioning. This document will be informational. 5. Produce "6LoWPAN Security Analysis" to define the threat model of 6LoWPANs, to document suitability of existing key management schemes and to discuss bootstrapping/installation/commissioning/setup issues. This document will be referenced from the "security considerations" of the other 6LoWPAN documents. This document will be informational. The working group will continue to reuse existing protocols and mechanisms whenever reasonable and possible. Non-milestone work items: The Working Group will keep two running, often-respun documents: -- implementers guide, collecting clarifying information based on input from implementers, in particular as it becomes available from interoperability events. -- interoperability guide, providing information for interoperability events, such as temporary interoperability testing strategies or information about test harnesses used for interoperability testing. Both documents will be WG documents, but their disposition is not decided at this point (one example for such a document became RFC 4815 after five years of maintenance and 22 revisions). Goals and Milestones: - Apr 2008 - Submit Stateful Header Compression document to IESG to be considered as an Informational RFC - Jul 2008 - Submit Use Cases document to IESG for consideration as an Informational RFC - Aug 2008 - Submit Security Analysis document to IESG for consideration as an Informational RFC. - Sep 2008 - Submit Architecture documents to IESG for consideration as an Informational RFCs - Dec 2008 - Submit Bootstrapping and ND Optimizations document to IESG to be considered as a Proposed Standard --Apple-Mail-8--382429215 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit --Apple-Mail-8--382429215 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 --Apple-Mail-8--382429215-- From 6lowpan-bounces@ietf.org Thu Dec 06 16:39: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 1J0OQv-0008WD-2z; Thu, 06 Dec 2007 16:39:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0OQt-0008W4-UW for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 16:38:59 -0500 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0OQt-0003fl-Ja for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 16:38:59 -0500 Received: by nz-out-0506.google.com with SMTP id i28so169050nzi for <6lowpan@lists.ietf.org>; Thu, 06 Dec 2007 13:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=zoVeXro9+rg9qT8oPsDPi+hicGgZe8/ppM6/NHDfq6k=; b=JPqGQmsV7sNQ5Km+BEUHRmCdPMs1ip2itk36+fB0chHpHDFjRUO3uP6EpglJpZ3m5jo//baEEGUt28ZzbRfFYAW/Q5HiSxoConlOUjHwOZRFrYTlX6812UMU3OenO/dq0AxEtrW6+iqe3VSz3p2h3PIhOmE/idAEU26l7bruOqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UIpzIAWuM17lwEAVZ4lhDgawTh431Lh1o9WqukXQ4613tGqhYM2H/AGiCTxhASQNZDuVHkOjCFqWjzM053eGzX8S1qsoteIuLqMcG9fs+Wqbu4dB9AAvxaRc0SUL17PzJtZcymy/3L+omTSPond8PRkLAKv9FChIDL9Uniecr6Y= Received: by 10.142.221.19 with SMTP id t19mr1973687wfg.1196977138565; Thu, 06 Dec 2007 13:38:58 -0800 (PST) Received: by 10.142.105.17 with HTTP; Thu, 6 Dec 2007 13:38:58 -0800 (PST) Message-ID: <77f1dba80712061338n68ca8921x5a224670296a839b@mail.gmail.com> Date: Fri, 7 Dec 2007 06:38:58 +0900 From: "Eunsook \"Eunah\" Kim" To: "Carsten Bormann" Subject: Re: [6lowpan] Charter proposal In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 6lowpan <6lowpan@lists.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 Geoff and Garsten, Thanks for the nice work. I'm happy to see the well-described new charter. I just have one question on item number 3. [ 3. Produce "6LoWPAN Architecture" to describe the design and implementation of 6LoWPAN networks. This document will cover the concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such as operation with sleeping nodes, network components (both battery- and line-powered), addressing, and IPv4/IPv6 network connections. As a spin-off from that document, "6LoWPAN Routing Requirements" will describe 6LoWPAN-specific requirements on routing protocols used in 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. Both documents will be informational. ] This phrase says two documents on this item, but I cannot see any milestone for "6LoWPAN Routing Requirements". Please let me know if I misunderstand something here. Thanks, -eunah On 12/7/07, Carsten Bormann wrote: > Lowpanners, > > Geoff and I have updated the charter proposal based on Marks input and > yesterday's discussion. > Now would be a good time for comments, in particular also on the > timelines we are promising. > Separately, we would like to know which of the items you are > interested in contributing to -- please volunteer now. > > Gruesse, Carsten > > > > > _______________________________________________ > 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 Thu Dec 06 17:11:11 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 1J0Ow3-00026k-7y; Thu, 06 Dec 2007 17:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0Ow2-00026Z-BU for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 17:11:10 -0500 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0Ow0-0006Mp-MZ for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 17:11:10 -0500 Received: from [127.0.0.1] (dhcp-34f9.ietf70.org [130.129.52.249]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id lB6MAskD016566 for <6lowpan@lists.ietf.org>; Thu, 6 Dec 2007 16:11:05 -0600 (CST) (envelope-from salo@saloits.com) Message-ID: <47587368.5040305@saloits.com> Date: Thu, 06 Dec 2007 16:10:48 -0600 From: "Timothy J. Salo" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> In-Reply-To: <43b91d370712060017m2d128893g9c57cd2d06628d46@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: 52e1467c2184c31006318542db5614d5 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 Samita Chakrabarti wrote: > ... That way, periodic RA will not wake up > all the nodes in the 6lowpan. ... To the best of my knowledge, 802.15.4 implementations power-down the radio when the system sleeps. As such, a broadcast packet does not wake a sleeping 802.15.4 node. Rather, the packet is simply never received by the sleeping node. If my understanding about this behavior is incorrect, someone please correct me. I have been meaning to check and see what the spec says about this, but haven't yet... Given that the response to broadcast packets differs in 802.16 networks (where an idle node wakes to process the packet) and 802.15.4 networks (where a sleeping node is never even aware of the packet), different solutions are probably required. To reiterate what I have said before, I believe that we must explicitly specify the behavior we expect of multicast in 6lowpan networks that contain sleeping nodes. In particular, does multicast mean "received by the potentially very small percentage of the nodes that aren't currently sleeping" or might it mean "received by every node after they wake up [whenever day that might be]"? After we specify the behavior of multicast, then we can then try to figure out whether we can actually implement that behavior in a useful way. In the interim, I suggest a moratorium on simply assuming that multicast is a potential solution to any of the challenges we face (e.g., duplicate address detection, router announcements, neighbor discovery, ...) -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 06 17:40:38 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 1J0POT-0008P9-TE; Thu, 06 Dec 2007 17:40:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0POT-0008Gu-5c for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 17:40:33 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0POS-0000gz-K9 for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 17:40:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id B0E0AA964F; Thu, 6 Dec 2007 14:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-10 required=6.6 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xphhV1GY7Xx7; Thu, 6 Dec 2007 14:40:27 -0800 (PST) Received: from [130.129.20.160] (dhcp-14a0.ietf70.org [130.129.20.160]) by mail.sf.archrock.com (Postfix) with ESMTP id F1A10A9649; Thu, 6 Dec 2007 14:40:26 -0800 (PST) Message-ID: <47587A55.506@archrock.com> Date: Thu, 06 Dec 2007 14:40:21 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Timothy J. Salo" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> In-Reply-To: <47587368.5040305@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: 6lowpan <6lowpan@lists.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 Tim, comments in line. Timothy J. Salo wrote: > To the best of my knowledge, 802.15.4 implementations power-down > the radio when the system sleeps. As such, a broadcast packet > does not wake a sleeping 802.15.4 node. Rather, the packet > is simply never received by the sleeping node. Depends on the link-layer energy management protocol. It is possible to heavily duty-cycle radio while supporting a broadcast communication. > If my understanding about this behavior is incorrect, someone > please correct me. I have been meaning to check and see what > the spec says about this, but haven't yet... This gets back to the question raised in the WG meeting, regarding how much of the MAC we should assume. The 802.15.4 specification only defines a limited set of power management mechanisms. As a result, many commercial implementations and industrial standards built on 802.15.4 forego the defined power management mechanisms. We've been careful so far to rely only on the frame format and nothing else. > Given that the response to broadcast packets differs in 802.16 > networks (where an idle node wakes to process the packet) and > 802.15.4 networks (where a sleeping node is never even aware > of the packet), different solutions are probably required. > > To reiterate what I have said before, I believe that we must > explicitly specify the behavior we expect of multicast in > 6lowpan networks that contain sleeping nodes. In particular, > does multicast mean "received by the potentially very small > percentage of the nodes that aren't currently sleeping" or might > it mean "received by every node after they wake up [whenever > day that might be]"? After we specify the behavior of multicast, > then we can then try to figure out whether we can actually > implement that behavior in a useful way. > > In the interim, I suggest a moratorium on simply assuming that > multicast is a potential solution to any of the challenges > we face (e.g., duplicate address detection, router announcements, > neighbor discovery, ...) Why not simply let the particular protocol specification state its assumptions about the underlying link? The challenge is that 6lowpan links may be configured very differently and solutions may differ greatly depending on the operational framework. I'd rather not limit the WG to a specific one. -- Jonathan Hui > > -tjs > > > > _______________________________________________ > 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 Thu Dec 06 17:45:24 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 1J0PTA-0004dI-Ah; Thu, 06 Dec 2007 17:45:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0PT9-0004dC-Iz for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 17:45:23 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0PT9-00013p-3O for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 17:45:23 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from localhost (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lB6MjEIg015245; Thu, 6 Dec 2007 23:45:14 +0100 (CET) Message-Id: From: Carsten Bormann To: "Eunsook \"Eunah\" Kim" In-Reply-To: <77f1dba80712061338n68ca8921x5a224670296a839b@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [6lowpan] Charter proposal Date: Thu, 6 Dec 2007 14:45:13 -0800 References: <77f1dba80712061338n68ca8921x5a224670296a839b@mail.gmail.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 4.5 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Dec 06 2007, at 13:38, Eunsook Eunah Kim wrote: > This phrase says two documents on this item, but I cannot see any > milestone for "6LoWPAN Routing Requirements". We may have phrased that too opaquely. The Sep 2008 milestone says: > - Sep 2008 - Submit Architecture documents to IESG for consideration > as an > Informational RFCs > which was meant to include both documents (architecture proper and routing requirements). We should separate that out. Thanks for the comment. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 06 19:40:34 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 1J0RGb-0005Au-MI; Thu, 06 Dec 2007 19:40:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0RGZ-000576-W8 for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 19:40:31 -0500 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0RGY-00013x-1C for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 19:40:31 -0500 Received: from [127.0.0.1] (dhcp-34f9.ietf70.org [130.129.52.249]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id lB70eBjs017117 for <6lowpan@lists.ietf.org>; Thu, 6 Dec 2007 18:40:25 -0600 (CST) (envelope-from salo@saloits.com) Message-ID: <4758965E.4050307@saloits.com> Date: Thu, 06 Dec 2007 18:39:58 -0600 From: "Timothy J. Salo" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <47587A55.506@archrock.com> In-Reply-To: <47587A55.506@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Jonathan Hui wrote: > Timothy J. Salo wrote: >> To the best of my knowledge, 802.15.4 implementations power-down >> the radio when the system sleeps. As such, a broadcast packet >> does not wake a sleeping 802.15.4 node. Rather, the packet >> is simply never received by the sleeping node. > > Depends on the link-layer energy management protocol. It is possible to > heavily duty-cycle radio while supporting a broadcast communication. Should I interpret your first sentence to mean: "It depends on whether the node sleeps?" If it means more than that, please explain. I assume that "heavily duty-cycle [the] radio" is an obscure way of saying "power down the radio". [I like simple, direct language, evidence to the contrary notwithstanding.] Do any of the 802.15.4 chips support a "wake on receive" capability? Does this capability (assuming it exists) require that the radio be powered on continuously? That is, does this capability power-down _only_ the processor, but not the radio? Does this capability really save enough power to meet the needs of many battery-powered, hopefully long-lived wireless sensor networks? If this capability actually exists, then we can talk about whether it is actually useful. Please provide an outline of how you think broadcast might work in networks where most of the nodes sleep (really sleep, as in powering down the radio and most of the microprocessor) most of the time. This is an important discussion to start soon. > This gets back to the question raised in the WG meeting, regarding how > much of the MAC we should assume. The 802.15.4 specification only > defines a limited set of power management mechanisms. As a result, many > commercial implementations and industrial standards built on 802.15.4 > forego the defined power management mechanisms. We've been careful so > far to rely only on the frame format and nothing else. Well, I also don't believe that we have yet specified a complete solution, much less one that works and is useful in common environments. Personally, I doubt that we can develop a complete, working, useful solution without giving more thought to what 802.15.4 capabilities we require or use if they are available. (Wasn't that the general conclusion of the working group meeting? Or, is that still an open question?) >> [...] >> In the interim, I suggest a moratorium on simply assuming that >> multicast is a potential solution to any of the challenges >> we face (e.g., duplicate address detection, router announcements, >> neighbor discovery, ...) > > Why not simply let the particular protocol specification state its > assumptions about the underlying link? The challenge is that 6lowpan > links may be configured very differently and solutions may differ > greatly depending on the operational framework. I'd rather not limit the > WG to a specific one. Well, perhaps for a couple of reasons. First, we have split the functionality necessary to run IPv6 over 802.15.4 networks across a large number of documents. If each of these documents use or require different sets of 802.15.4 capabilities, it will be difficult to figure out whether we have actually specified a complete solution for a particular environment (or perhaps even for any environment). Second, it depends on what our interoperability objective is. There are a range of opinions about what "interoperability" actually means. For some, interoperability means "if you implement a particular feature, here is how it should be implemented". The other view of interoperability focuses on system-level interoperability. Under this view, the objective is "If a system implements the relevant [broad] standards, this it is assured to interoperate with all other systems that implement these standards". A major problem with the first approach is that it doesn't assure system-level interoperability. This is particularly true when lots of fine-grained standards exist (which is the direction that the 6lowpan working group seems to be headed at the moment). That is, when a vendor can pick one standard from column 1, one from column 2, etc. for more than a trivially small number of columns, the chance of systems from different vendors will interoperate become very small. Personally, I prefer system-level (rather than a feature-level) interoperability. It is possible that we will find that there are several very different environments that we want to support (e.g., networks in which nodes sleep versus networks in which nodes can always receive packets). And, we may find that these different environments require different solutions. If this the case, I think that we should specify a small number of solutions that target specific environments, rather than specify a large number of component technologies that vendors can combine in various ways to create solutions (which are likely to be functionally proprietary, in the sense that they don't interoperate with other vendors' products). -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 06 21:49: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 1J0THX-0006ZM-N3; Thu, 06 Dec 2007 21:49:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0THW-0006WP-SZ for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 21:49:38 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0THW-0000ro-9f for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 21:49:38 -0500 Received: from [66.103.196.221] by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1J0THV-0007Yj-Aa; Thu, 06 Dec 2007 18:49:37 -0800 In-Reply-To: <4758965E.4050307@saloits.com> References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <47587A55.506@archrock.com> <4758965E.4050307@saloits.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34F053E9-E5F7-49B8-B9B5-A70131CC35C3@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) Date: Thu, 6 Dec 2007 18:49:38 -0800 To: Timothy J. Salo X-Mailer: Apple Mail (2.752.3) 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: 323acaff36744e8473855e70acc36bcb X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 6lowpan <6lowpan@lists.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 Dec 6, 2007, at 4:39 PM, Timothy J. Salo wrote: > >> Depends on the link-layer energy management protocol. It is >> possible to >> heavily duty-cycle radio while supporting a broadcast communication. > > Should I interpret your first sentence to mean: "It depends on > whether the node sleeps?" If it means more than that, please explain. The general point is that the notion of "I send a packet when the node is off" assumes a particular energy approach. For example, it could be that the sender transmits a long PHY-layer preamble *before* the packet, and receivers periodically wake up for a few ms to listen for such a preamble. From the transmitter's perspective, this is just "sending a packet" but the receiver's radio is asleep, nevertheless the packet can arrive successfully. The assumption is that the link layer provides a broadcast primitive that reaches nearby nodes, taking into consideration the power management policy. More specifically, the number of nodes reached by a broadcast should be independent of the radio duty cycle. > > Do any of the 802.15.4 chips support a "wake on receive" > capability? Does this capability (assuming it exists) > require that the radio be powered on continuously? That is, > does this capability power-down _only_ the processor, but > not the radio? Does this capability really save enough > power to meet the needs of many battery-powered, hopefully > long-lived wireless sensor networks? > This doesn't work like you think it does. To hear a signal, your radio has to be on. The energy cost of demodulation is not the principal issue. > If this capability actually exists, then we can talk > about whether it is actually useful. > > Please provide an outline of how you think broadcast might > work in networks where most of the nodes sleep (really sleep, > as in powering down the radio and most of the microprocessor) > most of the time. This is an important discussion to start > soon. Node transmits long preamble. Node transmits packet many times. Here's a paper in submission that quantifies two approaches on a particular 802.15.4 chip. Note that it actually references two other approaches (BMAC and XMAC) which are themselves extensions of earlier schemes. The author of this paper develops wireless sensor networks for various branches of the U.S. government. http://csl.stanford.edu/~pal/share/spots08.pdf > > Well, I also don't believe that we have yet specified a complete > solution, much less one that works and is useful in common > environments. You could argue that layer 2 interoperability is outside the scope of 6lowpan. For example, not all 15.4 devices work on 2.4GHz; I assume we aren't trying to get 868MHz and 2.4GHz nodes to interoperate? Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 06 21:52: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 1J0TK0-0007XR-Ly; Thu, 06 Dec 2007 21:52:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0TJz-0007XL-Uo for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 21:52:11 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0TJy-00012A-AE for 6lowpan@lists.ietf.org; Thu, 06 Dec 2007 21:52:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 6AC3CA966B; Thu, 6 Dec 2007 18:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-10 required=6.6 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDMvXfTRrsfC; Thu, 6 Dec 2007 18:52:08 -0800 (PST) Received: from [130.129.20.160] (dhcp-14a0.ietf70.org [130.129.20.160]) by mail.sf.archrock.com (Postfix) with ESMTP id 37BC6A9669; Thu, 6 Dec 2007 18:52:08 -0800 (PST) Message-ID: <4758B554.5070306@archrock.com> Date: Thu, 06 Dec 2007 18:52:04 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Timothy J. Salo" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <47587A55.506@archrock.com> <4758965E.4050307@saloits.com> In-Reply-To: <4758965E.4050307@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 6lowpan <6lowpan@lists.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 Tim, see comments below: Timothy J. Salo wrote: > Should I interpret your first sentence to mean: "It depends on > whether the node sleeps?" If it means more than that, please explain. No, you should interpret it as: "with what schedule does the radio enable or disable its receiver". > I assume that "heavily duty-cycle [the] radio" is an obscure > way of saying "power down the radio". [I like simple, > direct language, evidence to the contrary notwithstanding.] Duty-cycle is a generally accepted term to refer to the proportion of time a device is on or off: http://en.wikipedia.org/wiki/Duty_cycle > Do any of the 802.15.4 chips support a "wake on receive" > capability? Does this capability (assuming it exists) > require that the radio be powered on continuously? That is, > does this capability power-down _only_ the processor, but > not the radio? Does this capability really save enough > power to meet the needs of many battery-powered, hopefully > long-lived wireless sensor networks? Low power listening and time-synchronization are two generally accepted mechanisms for duty-cycling a radio. Both mechanisms have been shown to significantly reduce average power consumption (fractions of a percent) in a variety of applications. > If this capability actually exists, then we can talk > about whether it is actually useful. The capability does exist and is being deployed today. > Please provide an outline of how you think broadcast might > work in networks where most of the nodes sleep (really sleep, > as in powering down the radio and most of the microprocessor) > most of the time. This is an important discussion to start > soon. Use low power listening, schedule broadcast slots in a synchronized protocol, buffer packets at a router. There's a bunch of literature on this already. [...] > different environments require different solutions. If this > the case, I think that we should specify a small number of > solutions that target specific environments, rather than specify > a large number of component technologies that vendors can > combine in various ways to create solutions (which are likely > to be functionally proprietary, in the sense that they don't > interoperate with other vendors' products). And we do this by first outlining the small number of configurations. This is what the architecture ID is trying to do. It outlines a number of scenarios and states that different mechanisms may be required depending on the operational scenario you're assuming. Sure, the architecture ID still needs work, but its a starting point. I believe we are in agreement here? -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Dec 07 05:17: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 1J0aHF-0004fa-Hn; Fri, 07 Dec 2007 05:17:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0aHE-0004eK-BW for 6lowpan@lists.ietf.org; Fri, 07 Dec 2007 05:17:48 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0aHD-0004TQ-La for 6lowpan@lists.ietf.org; Fri, 07 Dec 2007 05:17:48 -0500 X-IronPort-AV: E=Sophos;i="4.23,265,1194217200"; d="scan'208";a="264736" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 07 Dec 2007 11:17:46 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lB7AHkKJ007092; Fri, 7 Dec 2007 11:17:46 +0100 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 lB7AHk6q025926; Fri, 7 Dec 2007 10:17:46 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 11:17:46 +0100 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] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Date: Fri, 7 Dec 2007 11:17:41 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04E3FA27@xmb-ams-337.emea.cisco.com> In-Reply-To: <47587368.5040305@saloits.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Thread-Index: Acg4VSF+SuFAbh9nTs2fljoMV4kfBwAXtltw References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> From: "Pascal Thubert (pthubert)" To: "Timothy J. Salo" , "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 07 Dec 2007 10:17:46.0334 (UTC) FILETIME=[6964B7E0:01C838BA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3625; t=1197022666; x=1197886666; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20ND=20optimization=20for=20s ensor=20nodes=20(power=20saving/=09Idle/Sleep=20mode) |Sender:=20; bh=hSg88xcM9yX1LwzXB0O/s98JZvpAo216kqWXDmqDn/k=; b=ryeOt5H+mq/Lj4xCEAEPhJj9GcxW/WTLvKt6MWz6N0xaYqh7VTPq/e9ZO4 gl36Hhs+A58pyJBMw8NfJBKTi1LSVRcXhmWl6ampOvqGeMm7xh/f13+I9M9l wMaq+GKWlo; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Hi I tend to agree with Tim here; multicast is a complex issue in the low power / sleepy space. It's even unclear which WG should be responsible to define it. =20 Back to basics, there are basically 2 extreme models to locate somebody; cry out loud or white board. ND on Ethernet uses the first model based on multicast. Mobile IP uses the second. When you look up a mobile node on the Home Link, the Home Agent is the reference that responds the ND requests on behalf of the mobile nodes. So my question is: Should we take as granted that ND on the LoWPAN requires multicast? Maybe the white board model based on unicast is enough, in which case we get rid of a very difficult dependency. Considering that there is a need for a router that understands 6LowPAN to connect the LoWPAN to the Internet, that router is the natural location for a white board. So the concept of backbone router is this: cry out loud on the high speed backbone that federates LoWPANs, and white board on the LoWPAN, and ND proxying to federate the whole thing. The backbone router implements ND proxying in a fashion that is compatible with mobile IP so one day, sensors with a global address can move away and stay virtually there.=20 In the meantime, a link local address is enough to connect to any node in the network federated by backbone routers, and a mote can move from a backbone router to another within the federated network without renumbering. The story begins in http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router -00.txt :) Pascal =20 >-----Original Message----- >From: Timothy J. Salo [mailto:salo@saloits.com]=20 >Sent: Thursday, December 06, 2007 11:11 PM >To: 6lowpan >Subject: Re: [6lowpan] ND optimization for sensor nodes (power=20 >saving/ Idle/Sleep mode) > >Samita Chakrabarti wrote: >> ... That way, periodic RA will not wake up all the nodes in the=20 >> 6lowpan. ... > >To the best of my knowledge, 802.15.4 implementations=20 >power-down the radio when the system sleeps. As such, a=20 >broadcast packet does not wake a sleeping 802.15.4 node. =20 >Rather, the packet is simply never received by the sleeping node. > >If my understanding about this behavior is incorrect, someone=20 >please correct me. I have been meaning to check and see what=20 >the spec says about this, but haven't yet... > >Given that the response to broadcast packets differs in 802.16=20 >networks (where an idle node wakes to process the packet) and >802.15.4 networks (where a sleeping node is never even aware=20 >of the packet), different solutions are probably required. > >To reiterate what I have said before, I believe that we must=20 >explicitly specify the behavior we expect of multicast in=20 >6lowpan networks that contain sleeping nodes. In particular,=20 >does multicast mean "received by the potentially very small=20 >percentage of the nodes that aren't currently sleeping" or=20 >might it mean "received by every node after they wake up=20 >[whenever day that might be]"? After we specify the behavior=20 >of multicast, then we can then try to figure out whether we=20 >can actually implement that behavior in a useful way. > >In the interim, I suggest a moratorium on simply assuming that=20 >multicast is a potential solution to any of the challenges we=20 >face (e.g., duplicate address detection, router announcements,=20 >neighbor discovery, ...) > >-tjs > > > >_______________________________________________ >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 Dec 07 13:06:38 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 1J0hav-00038d-5h; Fri, 07 Dec 2007 13:06:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0hat-00037r-JW for 6lowpan@lists.ietf.org; Fri, 07 Dec 2007 13:06:35 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0hat-0006p2-1W for 6lowpan@lists.ietf.org; Fri, 07 Dec 2007 13:06:35 -0500 Received: from dnab423241.stanford.edu ([171.66.50.65]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1J0has-0006RJ-6I; Fri, 07 Dec 2007 10:06:34 -0800 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04E3FA27@xmb-ams-337.emea.cisco.com> References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <7892795E1A87F04CADFCCF41FADD00FC04E3FA27@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0CBB6939-45FC-4354-9120-445D538461BE@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Date: Fri, 7 Dec 2007 10:06:36 -0800 To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 3fe17504c5843e76b9e439a63759b02e X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 6lowpan <6lowpan@lists.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 Dec 7, 2007, at 2:17 AM, Pascal Thubert (pthubert) wrote: > Hi > > I tend to agree with Tim here; multicast is a complex issue in the low > power / sleepy space. It's even unclear which WG should be responsible > to define it. > > Back to basics, there are basically 2 extreme models to locate > somebody; > cry out loud or white board. ND on Ethernet uses the first model based > on multicast. Mobile IP uses the second. When you look up a mobile > node > on the Home Link, the Home Agent is the reference that responds the ND > requests on behalf of the mobile nodes. > > So my question is: Should we take as granted that ND on the LoWPAN > requires multicast? Maybe the white board model based on unicast is > enough, in which case we get rid of a very difficult dependency. > Considering that there is a need for a router that understands 6LowPAN > to connect the LoWPAN to the Internet, that router is the natural > location for a white board. The issue here is whether sleep schedules are visible to the network layer, or whether it observes longer latency. MACs which do not support a "cry out" approach, e.g., TDMA with no broadcast slot, typically emulate broadcast through unicast to each neighbor for which a slot exists. The network layer is not made aware of this, as the TDMA schedule will by necessity constrain the set of neighbors that you have a "link" to. Or are you assuming mesh under? > So the concept of backbone router is this: cry out loud on the high > speed backbone that federates LoWPANs, and white board on the LoWPAN, > and ND proxying to federate the whole thing. The backbone router > implements ND proxying in a fashion that is compatible with mobile > IP so > one day, sensors with a global address can move away and stay > virtually > there. I guess I don't quite understand why you think the whiteboard approach is necessary. Can you describe a use case where "cry out" doesn't work? The "nodes are off" case seems very suspect to me: if nodes are *really* off, e.g., for long, application-level periods, you would not expect multicast to reach them. Instead, you would depend on higher-layer protocols (e.g., SRM) for improving reliability. If nodes are off for very short, link-layer periods, the MAC should take care of this. Networks in deployment today tend to solely use the latter approach, as it's quite sufficient. It might be the best approach for performance reasons, but it may not be. The fact that such a tradeoff might depend on the actual media access approach used suggests to me that this is something e > > In the meantime, a link local address is enough to connect to any node > in the network federated by backbone routers, So this assumes mesh under? > and a mote can move from a > backbone router to another within the federated network without > renumbering. This is definitely a desirable property. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Dec 07 17:19: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 1J0lY0-0005sL-SN; Fri, 07 Dec 2007 17:19:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0lY0-0005sG-6J for 6lowpan@lists.ietf.org; Fri, 07 Dec 2007 17:19:52 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0lXy-0008HF-BZ for 6lowpan@lists.ietf.org; Fri, 07 Dec 2007 17:19:52 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 01E32A968D; Fri, 7 Dec 2007 14:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-10 required=6.6 tests=[BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2kR5QX3mBeN; Fri, 7 Dec 2007 14:19:47 -0800 (PST) Received: from [10.10.10.103] (unknown [216.57.213.220]) by mail.sf.archrock.com (Postfix) with ESMTP id 023CDA968B; Fri, 7 Dec 2007 14:19:46 -0800 (PST) Message-ID: <4759C700.6090701@archrock.com> Date: Fri, 07 Dec 2007 14:19:44 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <7892795E1A87F04CADFCCF41FADD00FC04E3FA27@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04E3FA27@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: 6lowpan <6lowpan@lists.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 Pascal, The backbone solution proposed in your draft targets a particular configuration and we should definitely consider it. Though I strongly believe that we are going to see different 6LoWPAN/802.15.4 network configurations. There may be some that do not connect to the Internet and do not require or cannot afford a router. There may be others that choose a route-over approach vs. mesh-under. I just want to reiterate my wish that we don't force the WG into a solution space that only covers a particular 6LoWPAN/802.15.4 configuration. Instead, we should consider a few representative configurations as Tim suggested. While it'd be great to see a single solution satisfy all of them, we should be open to having different ones if needed. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi > > I tend to agree with Tim here; multicast is a complex issue in the low > power / sleepy space. It's even unclear which WG should be responsible > to define it. > > Back to basics, there are basically 2 extreme models to locate somebody; > cry out loud or white board. ND on Ethernet uses the first model based > on multicast. Mobile IP uses the second. When you look up a mobile node > on the Home Link, the Home Agent is the reference that responds the ND > requests on behalf of the mobile nodes. > > So my question is: Should we take as granted that ND on the LoWPAN > requires multicast? Maybe the white board model based on unicast is > enough, in which case we get rid of a very difficult dependency. > Considering that there is a need for a router that understands 6LowPAN > to connect the LoWPAN to the Internet, that router is the natural > location for a white board. > > So the concept of backbone router is this: cry out loud on the high > speed backbone that federates LoWPANs, and white board on the LoWPAN, > and ND proxying to federate the whole thing. The backbone router > implements ND proxying in a fashion that is compatible with mobile IP so > one day, sensors with a global address can move away and stay virtually > there. > > In the meantime, a link local address is enough to connect to any node > in the network federated by backbone routers, and a mote can move from a > backbone router to another within the federated network without > renumbering. > > The story begins in > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router > -00.txt :) > > Pascal > > >> -----Original Message----- >> From: Timothy J. Salo [mailto:salo@saloits.com] >> Sent: Thursday, December 06, 2007 11:11 PM >> To: 6lowpan >> Subject: Re: [6lowpan] ND optimization for sensor nodes (power >> saving/ Idle/Sleep mode) >> >> Samita Chakrabarti wrote: >>> ... That way, periodic RA will not wake up all the nodes in the >>> 6lowpan. ... >> To the best of my knowledge, 802.15.4 implementations >> power-down the radio when the system sleeps. As such, a >> broadcast packet does not wake a sleeping 802.15.4 node. >> Rather, the packet is simply never received by the sleeping node. >> >> If my understanding about this behavior is incorrect, someone >> please correct me. I have been meaning to check and see what >> the spec says about this, but haven't yet... >> >> Given that the response to broadcast packets differs in 802.16 >> networks (where an idle node wakes to process the packet) and >> 802.15.4 networks (where a sleeping node is never even aware >> of the packet), different solutions are probably required. >> >> To reiterate what I have said before, I believe that we must >> explicitly specify the behavior we expect of multicast in >> 6lowpan networks that contain sleeping nodes. In particular, >> does multicast mean "received by the potentially very small >> percentage of the nodes that aren't currently sleeping" or >> might it mean "received by every node after they wake up >> [whenever day that might be]"? After we specify the behavior >> of multicast, then we can then try to figure out whether we >> can actually implement that behavior in a useful way. >> >> In the interim, I suggest a moratorium on simply assuming that >> multicast is a potential solution to any of the challenges we >> face (e.g., duplicate address detection, router announcements, >> neighbor discovery, ...) >> >> -tjs >> >> >> >> _______________________________________________ >> 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 Dec 07 17:54: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 1J0m5J-0001xN-Te; Fri, 07 Dec 2007 17:54:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0m5I-0001xE-Fl for 6lowpan@lists.ietf.org; Fri, 07 Dec 2007 17:54:16 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0m5H-0003P5-LP for 6lowpan@lists.ietf.org; Fri, 07 Dec 2007 17:54:16 -0500 Received: by py-out-1112.google.com with SMTP id u77so1879793pyb for <6lowpan@lists.ietf.org>; Fri, 07 Dec 2007 14:54:15 -0800 (PST) Received: by 10.35.78.9 with SMTP id f9mr3988625pyl.1197068054896; Fri, 07 Dec 2007 14:54:14 -0800 (PST) Received: by 10.35.18.7 with HTTP; Fri, 7 Dec 2007 14:54:14 -0800 (PST) Message-ID: <8f5144140712071454v44822a04s8d943cbaf2ba23b8@mail.gmail.com> Date: Fri, 7 Dec 2007 23:54:14 +0100 From: "Muneeb Ali" To: "Philip Levis" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) In-Reply-To: <34F053E9-E5F7-49B8-B9B5-A70131CC35C3@cs.stanford.edu> MIME-Version: 1.0 References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <47587A55.506@archrock.com> <4758965E.4050307@saloits.com> <34F053E9-E5F7-49B8-B9B5-A70131CC35C3@cs.stanford.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: 6lowpan <6lowpan@lists.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="===============1456593054==" Errors-To: 6lowpan-bounces@ietf.org --===============1456593054== Content-Type: multipart/alternative; boundary="----=_Part_6682_23741341.1197068054887" ------=_Part_6682_23741341.1197068054887 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/7/07, Philip Levis wrote: > > On Dec 6, 2007, at 4:39 PM, Timothy J. Salo wrote: > > > > > > Do any of the 802.15.4 chips support a "wake on receive" > > capability? Does this capability (assuming it exists) > > require that the radio be powered on continuously? That is, > > does this capability power-down _only_ the processor, but > > not the radio? Does this capability really save enough > > power to meet the needs of many battery-powered, hopefully > > long-lived wireless sensor networks? > > > > This doesn't work like you think it does. To hear a signal, your > radio has to be on. The energy cost of demodulation is not the > principal issue. > > Phil Yes, to hear a signal the radio needs to be on. So "wake on receive" is hard unless you consider dual radios. The concept of "dual radios" has existed in theory. A second, always-on, radio can wake up the "main" radio to give you wake on receive functionality. However, the power consumption of the always-on second radio will cost you a lot more (in terms of energy) compared to duty-cycling the "main" radio. Thats why dual radios with wake-on-receive have largely remained a theoretical concept. See this work http://www.st.ewi.tudelft.nl/~koen/papers/wakeup-radio.pdf for a working prototype of a dual radio (EUR 5 per radio) that has acceptable energy costs in always-on mode. The current problem, however, is that the range of the wake-up radio is fairly small. Second problem is that to keep the energy costs low, you will end up with a "bare-bones" radio that is not even sophisticated enough to do addressing. You end up waking up a lot of neighbors if you don't know how to address a particular one (don't know if they have already solved this). Increasing the range while keeping energy costs acceptable is an on-going work at the startup from where one of the authors is from. _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > -- Cheers, Muneeb Ali | http://muneeb.org ------=_Part_6682_23741341.1197068054887 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/7/07, Philip Levis <pal@cs.stanford.edu> wrote:
On Dec 6, 2007, at 4:39 PM, Timothy J. Salo wrote:


>
> Do any of the 802.15.4 chips support a "wake on receive"
> capability?  Does this capability (assuming it exists)
> require that the radio be powered on continuously? That is,
> does this capability power-down _only_ the processor, but
> not the radio?  Does this capability really save enough
> power to meet the needs of many battery-powered, hopefully
> long-lived wireless sensor networks?
>

This doesn't work like you think it does. To hear a signal, your
radio has to be on. The energy cost of demodulation is not the
principal issue.

Phil


Yes, to hear a signal the radio needs to be on. So "wake on receive" is hard unless you consider dual radios. The concept of "dual radios" has existed in theory. A second, always-on, radio can wake up the "main" radio to give you wake on receive functionality. However, the power consumption of the always-on second radio will cost you a lot more (in terms of energy) compared to duty-cycling the "main" radio. Thats why dual radios with wake-on-receive have largely remained a theoretical concept. See this work
http://www.st.ewi.tudelft.nl/~koen/papers/wakeup-radio.pdf

for a working prototype of a dual radio (EUR 5 per radio) that has acceptable energy costs in always-on mode. The current problem, however, is that the range of the wake-up radio is fairly small. Second problem is that to keep the energy costs low, you will end up with a "bare-bones" radio that is not even sophisticated enough to do addressing. You end up waking up a lot of neighbors if you don't know how to address a particular one (don't know if they have already solved this). Increasing the range while keeping energy costs acceptable is an on-going work at the startup from where one of the authors is from. 

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



--
Cheers,

Muneeb Ali | http://muneeb.org ------=_Part_6682_23741341.1197068054887-- --===============1456593054== 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 --===============1456593054==-- From 6lowpan-bounces@ietf.org Sat Dec 08 03:17:45 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 1J0usY-0002Bs-Pr; Sat, 08 Dec 2007 03:17:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0usW-0002Bk-QC for 6lowpan@lists.ietf.org; Sat, 08 Dec 2007 03:17:40 -0500 Received: from m13-3.163.com ([220.181.13.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J0usQ-0006UV-E8 for 6lowpan@lists.ietf.org; Sat, 08 Dec 2007 03:17:40 -0500 Received: from 192.168.208.59(211.144.102.58) ( 192.168.208.59(211.144.102.58) [192.168.208.59(211.144.102.58)] ) by webmail-app3 (Coremail) ; Sat, 8 Dec 2007 16:17:21 +0800 (CST) MIME-Version: 1.0 Message-ID: <475A5311.0000C5.27764@bj163app3.163.com> Date: Sat, 8 Dec 2007 16:17:21 +0800 (CST) From: "yanzexuan" To: "muneeb ali" , "philip levis" Subject: Re: Re: [6lowpan] ND optimization for sen sor nodes (power saving / Idle/Sleep mode ) X-Priority: 3 X-Originating-IP: [192.168.208.59(211.144.102.58)] X-Mailer: 163com References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <47587A55.506@archrock.com> <4758965E.4050307@saloits.com> <34F053E9-E5F7-49B8-B9B5-A70131CC35C3@cs.stanford.edu> <8f5144140712071454v44822a04s8d943cbaf2ba23b8@mail.gmail.com> In-Reply-To: <8f5144140712071454v44822a04s8d943cbaf2ba23b8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: 6lowpan <6lowpan@lists.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="===============2114866480==" Errors-To: 6lowpan-bounces@ietf.org --===============2114866480== Content-Type: Multipart/Alternative; boundary="Boundary-=_LJfXiFAsFTicxPYvKVNtfzAFSCLb" --Boundary-=_LJfXiFAsFTicxPYvKVNtfzAFSCLb Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi all, I learned much from u all in the passed one year, it's my hounor to be a member of 6lowpan group, It's a promissing team. I am leaving school soon, and will no longer work on 6lowpan, so, do any body know how to quit from 6Lowpan group? or, would the admin be kindly to remove me from the member list? thanks, yan From: "Muneeb Ali" To: "Philip Levis" Date: Sat, 8 Dec 2007 06:54:14 +0800 (CST) Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) On 12/7/07, Philip Levis wrote: On Dec 6, 2007, at 4:39 PM, Timothy J. Salo wrote: > > Do any of the 802.15.4 chips support a "wake on receive" > capability? Does this capability (assuming it exists) > require that the radio be powered on continuously? That is, > does this capability power-down _only_ the processor, but > not the radio? Does this capability really save enough > power to meet the needs of many battery-powered, hopefully > long-lived wireless sensor networks? > This doesn't work like you think it does. To hear a signal, your radio has to be on. The energy cost of demodulation is not the principal issue. Phil Yes, to hear a signal the radio needs to be on. So "wake on receive" is hard unless you consider dual radios. The concept of "dual radios" has existed in theory. A second, always-on, radio can wake up the "main" radio to give you wake on receive functionality. However, the power consumption of the always-on second radio will cost you a lot more (in terms of energy) compared to duty-cycling the "main" radio. Thats why dual radios with wake-on-receive have largely remained a theoretical concept. See this work http://www.st.ewi.tudelft.nl/~koen/papers/wakeup-radio.pdf for a working prototype of a dual radio (EUR 5 per radio) that has acceptable energy costs in always-on mode. The current problem, however, is that the range of the wake-up radio is fairly small. Second problem is that to keep the energy costs low, you will end up with a "bare-bones" radio that is not even sophisticated enough to do addressing. You end up waking up a lot of neighbors if you don't know how to address a particular one (don't know if they have already solved this). Increasing the range while keeping energy costs acceptable is an on-going work at the startup from where one of the authors is from. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan -- Cheers, Muneeb Ali | http://muneeb.org --Boundary-=_LJfXiFAsFTicxPYvKVNtfzAFSCLb Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit


Hi all,

I learned much from u all in the passed one year, it's my hounor to be a member of 6lowpan group, It's a promissing team.

I am leaving school soon, and will no longer work on 6lowpan, so, do any body know how to quit from 6Lowpan group? or, would the admin be kindly to remove me from the member list?

thanks,

yan





From: "Muneeb Ali" <ali@muneeb.org>
To: "Philip Levis" <pal@cs.stanford.edu>
Date: Sat, 8 Dec 2007 06:54:14 +0800 (CST)
Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode)

On 12/7/07, Philip Levis <pal@cs.stanford.edu> wrote:

On Dec 6, 2007, at 4:39 PM, Timothy J. Salo wrote:


>
> Do any of the 802.15.4 chips support a "wake on receive"
> capability?  Does this capability (assuming it exists)
> require that the radio be powered on continuously? That is,
> does this capability power-down _only_ the processor, but
> not the radio?  Does this capability really save enough
> power to meet the needs of many battery-powered, hopefully
> long-lived wireless sensor networks?
>

This doesn't work like you think it does. To hear a signal, your
radio has to be on. The energy cost of demodulation is not the
principal issue.

Phil


Yes, to hear a signal the radio needs to be on. So "wake on receive" is hard unless you consider dual radios. The concept of "dual radios" has existed in theory. A second, always-on, radio can wake up the "main" radio to give you wake on receive functionality. However, the power consumption of the always-on second radio will cost you a lot more (in terms of energy) compared to duty-cycling the "main" radio. Thats why dual radios with wake-on-receive have largely remained a theoretical concept. See this work
http://www.st.ewi.tudelft.nl/~koen/papers/wakeup-radio.pdf

for a working prototype of a dual radio (EUR 5 per radio) that has acceptable energy costs in always-on mode. The current problem, however, is that the range of the wake-up radio is fairly small. Second problem is that to keep the energy costs low, you will end up with a "bare-bones" radio that is not even sophisticated enough to do addressing. You end up waking up a lot of neighbors if you don't know how to address a particular one (don't know if they have already solved this). Increasing the range while keeping energy costs acceptable is an on-going work at the startup from where one of the authors is from. 

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



--
Cheers,

Muneeb Ali | http://muneeb.org

--Boundary-=_LJfXiFAsFTicxPYvKVNtfzAFSCLb-- --===============2114866480== 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 --===============2114866480==-- From 6lowpan-bounces@ietf.org Sat Dec 08 04:10:11 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 1J0vhL-0003Vt-9e; Sat, 08 Dec 2007 04:10:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0vhK-0003Qv-JE for 6lowpan@lists.ietf.org; Sat, 08 Dec 2007 04:10:10 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0vhI-0000QM-4M for 6lowpan@lists.ietf.org; Sat, 08 Dec 2007 04:10:10 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lB89A5uN012220; Sat, 8 Dec 2007 02:10:05 -0700 (MST) Subject: RE: [6lowpan] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04E3FA27@xmb-ams-337.emea.cisco.com> References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <7892795E1A87F04CADFCCF41FADD00FC04E3FA27@xmb-ams-337.emea.cisco.com> Content-Type: text/plain Date: Fri, 07 Dec 2007 14:49:03 -0700 Message-Id: <1197064143.6356.22.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 6lowpan <6lowpan@lists.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 Since I'm working with Pascal on the Backbone Router (BbR) draft/concept, I agree and like the idea that if the lowpan is connected to the internet there will be something like a BbR and it would be a natural place to have the "white board". I don't necessarily agree that multicast for sleepy nodes is really any more complex than it is for non-sleepy nodes when the underlying network doesn't support multicast. My other concern about relying on the BbR for ND type service is if the network is installed without an Internet connection (or BbR). geoff On Fri, 2007-12-07 at 11:17 +0100, Pascal Thubert (pthubert) wrote: > Hi > > I tend to agree with Tim here; multicast is a complex issue in the low > power / sleepy space. It's even unclear which WG should be responsible > to define it. > > Back to basics, there are basically 2 extreme models to locate somebody; > cry out loud or white board. ND on Ethernet uses the first model based > on multicast. Mobile IP uses the second. When you look up a mobile node > on the Home Link, the Home Agent is the reference that responds the ND > requests on behalf of the mobile nodes. > > So my question is: Should we take as granted that ND on the LoWPAN > requires multicast? Maybe the white board model based on unicast is > enough, in which case we get rid of a very difficult dependency. > Considering that there is a need for a router that understands 6LowPAN > to connect the LoWPAN to the Internet, that router is the natural > location for a white board. > > So the concept of backbone router is this: cry out loud on the high > speed backbone that federates LoWPANs, and white board on the LoWPAN, > and ND proxying to federate the whole thing. The backbone router > implements ND proxying in a fashion that is compatible with mobile IP so > one day, sensors with a global address can move away and stay virtually > there. > > In the meantime, a link local address is enough to connect to any node > in the network federated by backbone routers, and a mote can move from a > backbone router to another within the federated network without > renumbering. > > The story begins in > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router > -00.txt :) > > Pascal > > > >-----Original Message----- > >From: Timothy J. Salo [mailto:salo@saloits.com] > >Sent: Thursday, December 06, 2007 11:11 PM > >To: 6lowpan > >Subject: Re: [6lowpan] ND optimization for sensor nodes (power > >saving/ Idle/Sleep mode) > > > >Samita Chakrabarti wrote: > >> ... That way, periodic RA will not wake up all the nodes in the > >> 6lowpan. ... > > > >To the best of my knowledge, 802.15.4 implementations > >power-down the radio when the system sleeps. As such, a > >broadcast packet does not wake a sleeping 802.15.4 node. > >Rather, the packet is simply never received by the sleeping node. > > > >If my understanding about this behavior is incorrect, someone > >please correct me. I have been meaning to check and see what > >the spec says about this, but haven't yet... > > > >Given that the response to broadcast packets differs in 802.16 > >networks (where an idle node wakes to process the packet) and > >802.15.4 networks (where a sleeping node is never even aware > >of the packet), different solutions are probably required. > > > >To reiterate what I have said before, I believe that we must > >explicitly specify the behavior we expect of multicast in > >6lowpan networks that contain sleeping nodes. In particular, > >does multicast mean "received by the potentially very small > >percentage of the nodes that aren't currently sleeping" or > >might it mean "received by every node after they wake up > >[whenever day that might be]"? After we specify the behavior > >of multicast, then we can then try to figure out whether we > >can actually implement that behavior in a useful way. > > > >In the interim, I suggest a moratorium on simply assuming that > >multicast is a potential solution to any of the challenges we > >face (e.g., duplicate address detection, router announcements, > >neighbor discovery, ...) > > > >-tjs > > > > > > > >_______________________________________________ > >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 Dec 08 04:10:32 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 1J0vhg-0003tN-OC; Sat, 08 Dec 2007 04:10:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0vhg-0003tI-2H for 6lowpan@lists.ietf.org; Sat, 08 Dec 2007 04:10:32 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0vhd-0000RH-ME for 6lowpan@lists.ietf.org; Sat, 08 Dec 2007 04:10:32 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lB89ASa1012237; Sat, 8 Dec 2007 02:10:28 -0700 (MST) Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) From: Geoff Mulligan To: "Timothy J. Salo" In-Reply-To: <47587368.5040305@saloits.com> References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> Content-Type: text/plain Date: Fri, 07 Dec 2007 15:07:14 -0700 Message-Id: <1197065234.6356.42.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.9 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 6lowpan <6lowpan@lists.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 Tim, I think that you have some misunderstandings. On Thu, 2007-12-06 at 16:10 -0600, Timothy J. Salo wrote: > Samita Chakrabarti wrote: > > ... That way, periodic RA will not wake up > > all the nodes in the 6lowpan. ... > > To the best of my knowledge, 802.15.4 implementations power-down > the radio when the system sleeps. As such, a broadcast packet > does not wake a sleeping 802.15.4 node. Rather, the packet > is simply never received by the sleeping node. > This is not true. A node that sleeps can receive broadcast packets. - If the broadcast packet is transmitted on some schedule then the sleeping node can wake up on that schedule and receive the packet. - If the broadcast packet is transmitted with some sort of long preamble then the sleeping node can wake up on it's own schedule, over hear the preamble and stay awake to receive the packet. - If the broadcast packet is transmitted multiple times the sleeping node can wake up during one of these transmissions and receive the packet. This is much like receiving any packet, not just broadcast packets. > If my understanding about this behavior is incorrect, someone > please correct me. I have been meaning to check and see what > the spec says about this, but haven't yet... There is nothing in the spec on this. As far as I know, there are no 15.4 radios that wake on some sort of reception. > > Given that the response to broadcast packets differs in 802.16 > networks (where an idle node wakes to process the packet) and > 802.15.4 networks (where a sleeping node is never even aware > of the packet), different solutions are probably required. > > To reiterate what I have said before, I believe that we must > explicitly specify the behavior we expect of multicast in > 6lowpan networks that contain sleeping nodes. No we don't. > In particular, > does multicast mean "received by the potentially very small > percentage of the nodes that aren't currently sleeping" or might > it mean "received by every node after they wake up [whenever > day that might be]"? > After we specify the behavior of multicast, > then we can then try to figure out whether we can actually > implement that behavior in a useful way. > > In the interim, I suggest a moratorium on simply assuming that > multicast is a potential solution to any of the challenges > we face (e.g., duplicate address detection, router announcements, > neighbor discovery, ...) NO. > > -tjs > > > > _______________________________________________ > 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 Dec 08 09:09:08 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 1J10Mc-0005uU-2P; Sat, 08 Dec 2007 09:09:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J10Mb-0005q1-5Q for 6lowpan@lists.ietf.org; Sat, 08 Dec 2007 09:09:05 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J10Ma-00059Y-Qk for 6lowpan@lists.ietf.org; Sat, 08 Dec 2007 09:09:05 -0500 Received: by an-out-0708.google.com with SMTP id d31so267294and for <6lowpan@lists.ietf.org>; Sat, 08 Dec 2007 06:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=YyQmQGBUX4xUxkTO9chpTz1OoFhEs8fJciwnXEoCP9Y=; b=tjmILWJU4SZ/xmP/KiU9J5RN3gMMkfoh2/M0UxV+IswDZDvqhawRV0iUQsFYiPnWPPQ1jUwhLnrOXazIAMz5CwGWq1pw//2s1PIUvKiQ0UZ3nHD6J7RHGSLcZXtRHfGW8skwZbYk2MfXQNl2yTShGs8roHUC084AtHh60bRCPhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MeonwoEPi5LOSo3W1A5onww+SV8T71KTi50RCGgFzRKEE+hKv1061kw2OlIv9my3UfoMm4YuCIZ2bnyEQko9RYe4U99ROlkHNp+RjrGkCHvqBiXiMnfcjuu6UEBbCQG1vN5nlc+WZAz2QdCCKtfgob37G+HPJElZTDYbIaoPdsg= Received: by 10.100.241.17 with SMTP id o17mr11195037anh.1197122944508; Sat, 08 Dec 2007 06:09:04 -0800 (PST) Received: by 10.100.215.8 with HTTP; Sat, 8 Dec 2007 06:09:04 -0800 (PST) Message-ID: Date: Sat, 8 Dec 2007 23:09:04 +0900 From: "Daniel Park" To: "Carsten Bormann" Subject: Re: [6lowpan] Charter proposal In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: 6lowpan <6lowpan@lists.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 Overall looks good to me. Here is several comments at this stage. COMMENT 1: [cut and paste] The Working Group will generate the necessary documents to ensure interoperable implementations of 6LoWPAN networks and will define the necessary security and management protocols and constructs for building 6LoWPAN networks, paying particular attention to protocols already available. [snip] Given the description above, WG should produce "6LoWPAN management protocols or method" a.k.a. MIB for 6LoWPAN management. I had seen Mark's positive opinion on this work during our session meeting. COMMENT 2: [cut and paste] 1. Produce "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations" to define limited extensions to IPv6 Neighbor Discovery [RFC4861] for use specifically in low-power networks. This document (or documents) will define how to bootstrap a 6LoWPAN network and explore ND optimizations such as reusing the structure of the 802.15.4 network (e.g., by using the coordinators), and reduce the need for multicast by having devices talk to coordinators (without creating a single point-of-failure, or changing the semantics of the IPv6 ND multicasts). This document or documents will be a proposed standard. [snip] Given the sentence above, both bootstrapping and ND optimization will be merged into one deliverable if I am correct. But, I don't think it is a reasonable way. So, my suggestion is to have both deliverables for each subject. COMMENT 3: I don't have a strong opinion on this matter, but I guess we should consider how to improve the quality of RFC 4944, especially Global Address HC, TCP operation, ICMPv6 operation and etc. RFC 4944-bis is one of options. COMMENT 4: Just curious how to dig out *mobility issue* from the proposed charter. I guess some of requirements of mobility for 6lowpan networks is doable for the initial activity at this stage except spcific mobility solutions. Thanks, Daniel Park [at] SAMSUNG Electronics. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sun Dec 09 05:33: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 1J1JT0-0002t5-Kv; Sun, 09 Dec 2007 05:32:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1JSz-0002sk-UP for 6lowpan@lists.ietf.org; Sun, 09 Dec 2007 05:32:57 -0500 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1JSx-0001wO-JS for 6lowpan@lists.ietf.org; Sun, 09 Dec 2007 05:32:57 -0500 Received: from [10.0.1.3] (213-216-242-195-Tuira-TR1.suomi.net [213.216.242.195]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id lB9AWpjr026326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Dec 2007 12:32:52 +0200 Message-ID: <475BC452.3090309@sensinode.com> Date: Sun, 09 Dec 2007 12:32:50 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Carsten Bormann Subject: Re: [6lowpan] Charter proposal References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: 6lowpan <6lowpan@lists.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, In my opinion the new charter is good, although I would of course liked to have seen the bootstrapping/ND optimization timeline to be quite a bit faster. But I guess the process is slow as it is going as a proposed standard? One clarification: Is 4. "Use Cases for 6LoWPAN" the place where such a minimal 6lowpan/IPv6 profile, for example use cases, be defined? Pascal and I were talking about this on the list last week. Or is the "implementor's guide" ID the correct place for describing the minimal profile? In my opinion either place could do.. We just need something to show other groups in a reasonable time (an RFC), so for that reason 4. would be a better place as the implementor's guide may go through 22 revisions over 5 years ;-) Contributions: Personally I'd like to contribute to the implementor's guide and interop IDs, along with the "Use Cases for 6lowpan". - Zach Carsten Bormann wrote: > Lowpanners, > > Geoff and I have updated the charter proposal based on Marks input and > yesterday's discussion. > Now would be a good time for comments, in particular also on the > timelines we are promising. > Separately, we would like to know which of the items you are interested > in contributing to -- please volunteer now. > > Gruesse, Carsten > > > ------------------------------------------------------------------------ > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan -- Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 10 12:34:37 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 1J1mWV-0003jA-4k; Mon, 10 Dec 2007 12:34:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1mWT-0003Mc-5O for 6lowpan@lists.ietf.org; Mon, 10 Dec 2007 12:34:29 -0500 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1mWS-0006k9-JE for 6lowpan@lists.ietf.org; Mon, 10 Dec 2007 12:34:29 -0500 Received: by wr-out-0506.google.com with SMTP id 68so1310668wra for <6lowpan@lists.ietf.org>; Mon, 10 Dec 2007 09:34:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=l05DUhdtRYpevTGPJl/thyoS1/OIbN14tbgEAGfxrIQ=; b=Z66lswSKdvlnyCf0fNBhZKjal8zKrK2C5DYObEx3Q0qm4Vq+MEdQUeUBob4i45LzdJN3mWMvvn4vCQkNZtugrVr4y//S7+H5xkyLUC1tOc6tfShUen4kBYm1Xxd3Ch6ym/B0n11yy1YOYrolTdHVpDNfFZi4Uxbq5Ds97WUO5+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rGyzGKc3ozBti/y5o4AS1+wARBNg5uxF7+sAga4ZkImy7omD05PbkVhmcv0uW2iYGFLJn5dgRdYTD4WNnkQf5JXb+HXeV4z1+sRS0r5E4+MLSXaXaCOoV18OMaIeF4uuku56aDqnvt71tMIfIUvBBgwooPpDRf55ELbF4ClYMQw= Received: by 10.78.83.15 with SMTP id g15mr858977hub.1197308066575; Mon, 10 Dec 2007 09:34:26 -0800 (PST) Received: by 10.78.23.14 with HTTP; Mon, 10 Dec 2007 09:34:26 -0800 (PST) Message-ID: <374005f30712100934s622e40a0i36ec27030e64fd01@mail.gmail.com> Date: Mon, 10 Dec 2007 23:04:26 +0530 From: "Ian Chakeres" To: "Geoff Mulligan" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) In-Reply-To: <1197065234.6356.42.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <1197065234.6356.42.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 6lowpan <6lowpan@lists.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 I tend to agree with Tim that sleeping can potentially be a big issue for both 6lowpan and more general routing in sensor networks. I do not think it should be dismissed. I also think that if 6lowpan does not choose one architectures (e.g. host-host, router-host, or router-router), it will be difficult to specify some of the optimizations. For example, ND optimization. Ian On Dec 8, 2007 3:37 AM, Geoff Mulligan wrote: > Tim, > I think that you have some misunderstandings. > > On Thu, 2007-12-06 at 16:10 -0600, Timothy J. Salo wrote: > > Samita Chakrabarti wrote: > > > ... That way, periodic RA will not wake up > > > all the nodes in the 6lowpan. ... > > > > To the best of my knowledge, 802.15.4 implementations power-down > > the radio when the system sleeps. As such, a broadcast packet > > does not wake a sleeping 802.15.4 node. Rather, the packet > > is simply never received by the sleeping node. > > > This is not true. A node that sleeps can receive broadcast packets. > > - If the broadcast packet is transmitted on some schedule then the > sleeping node can wake up on that schedule and receive the packet. > - If the broadcast packet is transmitted with some sort of long > preamble then the sleeping node can wake up on it's own schedule, over > hear the preamble and stay awake to receive the packet. > - If the broadcast packet is transmitted multiple times the sleeping > node can wake up during one of these transmissions and receive the > packet. > > This is much like receiving any packet, not just broadcast packets. > > > If my understanding about this behavior is incorrect, someone > > please correct me. I have been meaning to check and see what > > the spec says about this, but haven't yet... > > There is nothing in the spec on this. As far as I know, there are no > 15.4 radios that wake on some sort of reception. > > > > > Given that the response to broadcast packets differs in 802.16 > > networks (where an idle node wakes to process the packet) and > > 802.15.4 networks (where a sleeping node is never even aware > > of the packet), different solutions are probably required. > > > > To reiterate what I have said before, I believe that we must > > explicitly specify the behavior we expect of multicast in > > 6lowpan networks that contain sleeping nodes. > > No we don't. > > > In particular, > > does multicast mean "received by the potentially very small > > percentage of the nodes that aren't currently sleeping" or might > > it mean "received by every node after they wake up [whenever > > day that might be]"? > > After we specify the behavior of multicast, > > then we can then try to figure out whether we can actually > > implement that behavior in a useful way. > > > > In the interim, I suggest a moratorium on simply assuming that > > multicast is a potential solution to any of the challenges > > we face (e.g., duplicate address detection, router announcements, > > neighbor discovery, ...) > > NO. > > > > > > -tjs > > > > > > > > _______________________________________________ > > 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 Mon Dec 10 15:07:24 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 1J1ouQ-00065o-IN; Mon, 10 Dec 2007 15:07:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1oZ5-0006JY-3Z for 6lowpan@lists.ietf.org; Mon, 10 Dec 2007 14:45:19 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1oZ4-0002BA-8k for 6lowpan@lists.ietf.org; Mon, 10 Dec 2007 14:45:19 -0500 Received: by nf-out-0910.google.com with SMTP id 4so1171738nfv for <6lowpan@lists.ietf.org>; Mon, 10 Dec 2007 11:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; bh=QZZ6+Ewq3lNzWZWgkjj3oZ0hi2gZk42ppM5P75n/Hv8=; b=GIU5AyiS3HedjWbVKmqGDgHF2Sk1hgXX+KhJhluHhSt4an8pE+0hNCOI0wxYi/816MDFRFqdJdtctGWInyo5PNSBB7vc4v3ibruq9sq3esZrziDKmVPlojuf63fRbRupfy09kYXg8V2+EquVdUbrm+GlWGUtRNnr2s8I4/eMpPE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer; b=Q5yJC87JqedRwA4eqxIwMf1UoVFBRLARHRxZgmup0VCHXmjFuID6bmgLd9CgJxzEoWRplruzAUw4yUtrQqoo+1c80qEMrpkDAGCKd/PUOHvAmuo5SLgad7VzF7OcXK8VxzsVgIjQCYgl2uoAbPfZSiXbdGQWJ3ScUNJOG+7IKtc= Received: by 10.82.150.20 with SMTP id x20mr6066348bud.1197315917111; Mon, 10 Dec 2007 11:45:17 -0800 (PST) Received: from ?10.137.139.194? ( [80.187.219.35]) by mx.google.com with ESMTPS id e8sm1688479muf.2007.12.10.11.45.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Dec 2007 11:45:16 -0800 (PST) Message-Id: From: Carsten Bormann To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Mon, 10 Dec 2007 20:45:10 +0100 References: X-Mailer: Apple Mail (2.915) X-Spam-Score: 1.2 (+) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-Mailman-Approved-At: Mon, 10 Dec 2007 15:07:19 -0500 Cc: Carsten Bormann Subject: [6lowpan] Issue of the week: Charter finalization 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 (Sending from my gmail account, as lists.ietf.org seems to have some issues:) Lowpanners, we have had some recent discussion on issues related to network structure, in particular the use of multicast and the issue of sleeping nodes. I don't want to interrupt this discussion, but I would like to remind everyone that we also have one short term objective: Getting rechartered. The *theme of the week* for the working group is the finalization of the charter. In particular, the following questions have been raised: A) is the timeline, which was too tight, now too relaxed? (Obviously, the chairs don't think so, but what do you think?) B) should there be work on a "minimal 6lowpan/IPv6 profile"? (I had envisioned each of the use cases to explain what protocols are used in implementing that particular use case, not the generation of a unified minimal profile that would apply to all use cases.) C) Daniel has reminded us that there needs to be a management solution at some point. I'm not sure that simply defining a MIB is the right way to provide this (SNMPv3 on sensor nodes?). Instead, we could add "management method" to the subjects of the architecture document before actually creating the solution. Is that the right place? D) The discussions about multicast have reminded us that 4944 alone does not provide a solution beyond a single radio range. MANET's SMF provides one, but presupposes some support from the routing protocol. The BbR approach reminds me of 802.11, where all multicast is unicast to the AP which then sends it back into the wireless network (which might allow a simplified flooding based on something like RPF). E) There were some comments during the meeting that we already were taking on a sizable amount of work. I'm not sure we want to take on all of the other points Daniel raised: [...] I guess we should consider how to improve the quality of RFC 4944, especially Global Address HC, TCP operation, ICMPv6 operation and etc. RFC 4944-bis is one of options. [...] how to dig out *mobility issue* from the proposed charter. I guess some of requirements of mobility for 6lowpan networks is doable for the initial activity at this stage except specific mobility solutions. F) Going through each of the documents, the following contributions have been promised recently: 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have longstanding contributions from Samita Chakrabarti and Erik Nordmark. Anybody else? Daniel has also proposed to split 1 into bootstrapping and ND optimization. There is also the subject of commissioning. What is the right set of documents, and which ones do (each of) you want to work on? 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": During the meeting, Kris Pister indicated that he was interested in contributing, and Carsten Bormann (that would be me) might be contributing a bit of ROHC background. 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff Mulligan, and JP Vasseur. Any other takers? In particular, somebody with a network management slant? 3a "Routing requirements" (which needs its own milestone entry) has a draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During the RL2N BOF, a similar document was proposed as a result of the RL2N-followup WG to be formed. We need to understand whether the two documents (the 6lowpan one and the rl2n++ one) are sufficiently different or whether we simply need to cooperate on one document, which would then have to include the 6lowpan-specific aspects including mesh-under. 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" might provide a basis, but we need more input, in particular from implementors of each of these scenarios that we actually want to use as use cases. 5 "6LoWPAN Security Analysis". Nobody? (I might provide some input, but can't do this on my own.) 6 Implementers' guide: Zach Shelby is interested 7 Interop guide: Zach Shelby is interested In order to accelerate rechartering, we should have answers to these questions/credibles sets of contributors to these documents at the end of this week, so please don't hesitate providing your input. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 10 15:07:24 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 1J1ouQ-00064f-Ak; Mon, 10 Dec 2007 15:07:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxuRm-0007z2-If for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 20:13:38 -0500 Received: from web81904.mail.mud.yahoo.com ([68.142.207.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxuRk-0005sr-8i for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 20:13:38 -0500 Received: (qmail 34082 invoked by uid 60001); 30 Nov 2007 01:13:35 -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:Cc:MIME-Version:Content-Type:Message-ID; b=kq9+39mMAaNMOhHJ0OCS/yb1YQRf2xQix4QjZoPp629ndJdNK4K+NyIaD+j32J4DnKg2wGge8VI7NFj/I7rQ4/e7SRpSeOj52Z7cYYe8Isoe6naqJ0WU4AHE2e7Q2AaQ6bMs3mIqEnV5Bg3yOuojihKBujZOw3tRxksRTCymZuM=; X-YMail-OSG: AmQPsLAVM1nMDB.v9UfdT2APUOoZ2orVTDyUeni27MRipxtlEz8OcxH2XboMPUQdsQdiVivuifFuJ1sYvqxYBOR7UwYb2rXgzR_C8aX5LtZPb4U- Received: from [131.107.0.71] by web81904.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 17:13:35 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.152 Date: Thu, 29 Nov 2007 17:13:35 -0800 (PST) From: gabriel montenegro Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter To: Geoff Mulligan , Kris Pister MIME-Version: 1.0 Message-ID: <750929.34078.qm@web81904.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e X-Mailman-Approved-At: Mon, 10 Dec 2007 15:07:19 -0500 Cc: 6lowpan <6lowpan@lists.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="===============0644530130==" Errors-To: 6lowpan-bounces@ietf.org --===============0644530130== Content-Type: multipart/alternative; boundary="0-382288667-1196385215=:34078" --0-382288667-1196385215=:34078 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Geoff, =0A=0ACould you please provide a pointer to the message or document = with that exception? =0AThis is an important item and it should be added to= the group's Wiki page.=0A=0AMy recollection is different, but I may have j= ust forgotten. What I recollect is that back when we =0Awere starting the w= orking group and initiating work on the problem statement draft, was that t= he recommendation=0Awas to stay away from issuing our own IPv6 profile, pre= cisely because saying things like ("IPsec is not recommended in lowpan=0Aen= vironments") was a sure-fire way to invite controversy at the IESG. E.g., I= Pv6 mandates IPsec, so how could=0Awe ever claim to support IPv6.... This d= ebate probably is better had in 6man in terms of a revision of the hosts=0A= requirements, rather than in any particular WG.=0A=0A-gabriel=0A=0A----- Or= iginal Message ----=0AFrom: Geoff Mulligan =0ATo: Kris = Pister =0ACc: 6lowpan <6lowpan@lists.ietf.org>=0A= Sent: Thursday, November 29, 2007 11:09:02 AM=0ASubject: Re: [6lowpan] RE: = [RSN] Here is the new RL2N Proposed Working Charter=0A=0AWe did not try to = get an exception to UDP checksums.=0A=0A geoff=0A=0AOn Thu, 2007-11-29 a= t 10:59 -0800, Kris Pister wrote:=0A> Geoff - ooh, I like exceptions.=0A> D= id we try to get an exception on the UDP checksum? It's painful to =0A> le= ave that in the compressed header if we have L2 message integrity.=0A> =0A>= ksjp=0A> =0A> Geoff Mulligan wrote:=0A> > We have already received an exce= ption from the IESG to IPsec on=0A 6lowpan=0A> > devices.=0A> >=0A> > g= eoff=0A> >=0A> > On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthuber= t) wrote:=0A> > =0A> >> Hum... =0A> >>=0A> >> I had missed that; Seems th= at we have to make an exception :) If=0A you consider ISA100.11a, they alre= ady have security at L2 and L5, it=0A makes little sense to MUST IPSec on t= op of that.=0A> >>=0A> >> Pascal=0A> >>=0A> >> =0A> >>> -----Original M= essage-----=0A> >>> From: Kris Pister [mailto:pister@eecs.berkeley.edu]=0A>= >>> Sent: Wednesday, November 28, 2007 8:03 PM=0A> >>> To: Pascal Thubert = (pthubert)=0A> >>> Cc: 6lowpan=0A> >>> Subject: Re: [RSN] Here is the new R= L2N Proposed Working Charter=0A> >>>=0A> >>> Hmm. From 4294:=0A> >>>=0A> >= >> "However, while authentication and encryption can each be NULL,=0A they= =0A> >>> MUST NOT both be NULL."=0A> >>>=0A> >>> ksjp=0A> >>>=0A> >>> Pasca= l Thubert (pthubert) wrote:=0A> >>> =0A> >>>> Hi Kris:=0A> >>>>=0A> >= >>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL=0A encrypt= ion and authentication for=0A> >>>> =0A> >>> interoperability reaso= ns.=0A> >>> =0A> >>>> On the general question of RFC 4294 itself: I'm= not sure the=0A work was ever done. I hope someone=0A> >>>> =0A> >= > >from the list can help?=0A> >> =0A> >>>> If the answer is unclear, a= nd considering that we are=0A re-chartering the group, maybe we could have= =0A> >>>> =0A> >>> a work item to specify the instantiation of RFC = 4294 for LoWPAN=0A nodes?=0A> >>> =0A> >>>> Pascal=0A> >>>> _________= _______________________________=0A> >>>> From: Kris Pister [mailto:pister@e= ecs.berkeley.edu]=0A> >>>> Sent: Wednesday, November 28, 2007 5:42 PM=0A> >= >>> To: Pascal Thubert (pthubert)=0A> >>>> Cc: 6lowpan=0A> >>>> Subject: Re= : [RSN] Here is the new RL2N Proposed Working Charter=0A> >>>>=0A> >>>> Is = there an email thread somewhere that discusses the impact on=0A 6LoWPAN of = the security=0A> >>>> =0A> >>> requirements of 4294 and 4303?=0A> >= >> =0A> >>>> My first quick readthrough makes me very uncomfortable t= hat some=0A of the mandates are going to be=0A> >>>> =0A> >>> ugly = from a header standpoint.=0A> >>> =0A> >>>> ksjp=0A> >>>>=0A> >>>> Pa= scal Thubert (pthubert) wrote:=0A> >>>> Hi JP:=0A> >>>>=0A> >>>> Thanks a b= unch for this charter. I'll try not to rephrase what=0A was already discuss= ed with Christian,=0A> >>>> =0A> >>> Anders, Philip and Misha.=0A> = >>> =0A> >>>> There's an additional item I'd wish to see either in RO= LL or=0A 6LoWPAN and I do not know exactly=0A> >>>> =0A> >>> where = it belongs, maybe both. The question is whether we need to=0A and can docum= ent how RFC 4294=0A> >>> applies for sensors, and M2M devices in general, w= hether they act=0A as hosts or as routers.=0A> >>> =0A> >>>> I've see= n IPv6 presented as a Pandora box that drags just too=0A much stuff to be i= ncorporated in a=0A> >>>> =0A> >>> sensory device. For instance, at= the moment, SP100.11a endorses=0A 6LoWPAN formats but it's not so clear=0A= > >>> at all that IPv6 itself is mandated. A clear spec with=0A well-docume= nted implementation could be a=0A> >>> formidable tool to despond to Fear, = Uncertainty and Defiance.=0A> >>> =0A> >>>> So maybe we do not need D= HCP (a MAY in RFC 4294) and maybe can=0A do without multicast at all if ND = is=0A> >>>> =0A> >>> supported some other way (such as suggested in= :=0A http://www.ietf.org/internet-drafts/draft-thubert-=0A> >>> lowpan-back= bone-router-00.txt). Maybe NULL encryption and=0A authentication is enough = etc, etc...=0A> >>> =0A> >>>> Being able to define one minimum set an= d maybe a few other=0A profiles for the use cases that we=0A> >>>> = =0A> >>> selected could help tremendously.=0A> >>> =0A> >>>> Otherwis= e I find the charter real well written and easy to=0A digest. >>From the MA= NEMO experience, I=0A> >>>> =0A> >>> expect that some arguments abo= ut the relative applicability of=0A existing MANET protocols will be=0A> >>= > difficult to prove without some good simulation work running=0A agreed-up= on scenarios.=0A> >>> =0A> >>>> Finally, I'm a bit confused that it s= eems that both IPv4 and=0A IPv6 seem supported. Ipv4 comes with a=0A> >>>> = =0A> >>> lot of overhead like DHCP. I suggest that when trouble com= es and=0A things can not be done in a common=0A> >>> fashion for both IP pr= otocols, hen we prioritize IPv6.=0A> >>> =0A> >>>> Unfortunately, I c= an not make it to Vancouver, but I do feel=0A that the work is really neede= d so=0A> >>>> =0A> >>> please count my vote in for the adoption of = the WG.=0A> >>> =0A> >>>> Cheers,=0A> >>>>=0A> >>>> Pascal=0A> >>>>= =0A> >>>>=0A> >>>> -----Original Message-----=0A> >>>> From: Jean Philippe = Vasseur (jvasseur)=0A> >>>> Sent: Wednesday, November 21, 2007 9:19 PM=0A> = >>>> To: rsn@ietf.org=0A> >>>> Subject: [RSN] Here is the new RL2N Proposed= Working Charter=0A> >>>>=0A> >>>> Dear all,=0A> >>>>=0A> >>>> As promised,= here is the new proposed Working Group, which=0A reflects the=0A> >>>> num= ber of comments/suggestions that we received, the pre-WG=0A consensus, ...= =0A> >>>>=0A> >>>> Thanks to Dave Ward (RTD AD) for his input.=0A> >>>>=0A>= >>>> Proposed RL2N WG Charter=0A> >>>>=0A> >>>> Description of Working Gro= up=0A> >>>>=0A> >>>> L2Ns (Low power and Lossy networks) are typically comp= osed of=0A many embedded=0A> >>>> devices with limited power, memory, and p= rocessing resources=0A interconnected=0A> >>>> by a variety of wireless lin= ks, such as IEEE 802.15.4,=0A Bluetooth, Low Power=0A> >>>> WiFi.=0A> >>>>= =0A> >>>> L2Ns are transitioning to an end-to-end IP-based solution to=0A a= void the=0A> >>>> problems of non-interoperable networks interconnected by= =0A protocol=0A> >>>> translation gateways and proxies. In addition, L2Ns h= ave=0A specific routing=0A> >>>> requirements that are not currently met by= existing routing=0A protocols, such=0A> >>>> as OSPF, IS-IS, AODV, and OLS= R. L2N path selection must be=0A designed to take=0A> >>>> into considerati= on the specific power, capabilities, attributes=0A and=0A> >>>> functional = characteristics of the links and nodes in the=0A network.=0A> >>>>=0A> >>>>= =0A> >>>> There is a wide scope of application areas for L2Ns, including=0A= industrial=0A> >>>> monitoring, building automation (HVAC, lighting/access= control),=0A connected=0A> >>>> home, healthcare, environmental monitoring= , agricultural, smart=0A cities,=0A> >>>> logistics, assets tracking, and r= efrigeration. The L2N WG will=0A focus on=0A> >>>> routing solutions for a = subset of these deployment scenarios,=0A namely=0A> >>>> industrial, connec= ted home/building and urban applications. The=0A Working=0A> >>>> Group wil= l determine the routing requirements for these=0A scenarios.=0A> >>>>=0A> >= >>>=0A> >>>> The Working Group will provide a routing framework for these= =0A application=0A> >>>> scenarios that provides high reliability in the pr= esence of time=0A varying=0A> >>>> loss characteristics and connectivity wh= ile permitting low-power=0A operation=0A> >>>> with very modest memory and = CPU pressure.=0A> >>>>=0A> >>>>=0A> >>>> The Working Group will pay a parti= cular attention to routing=0A security and=0A> >>>> manageability (e.g self= managing/configuration) issues, which=0A are=0A> >>>> particularly critica= l for L2Ns.=0A> >>>>=0A> >>>> Work Items:=0A> >>>>=0A> >>>> - Produce use c= ases documents for Industrial, Connected Home,=0A Building and=0A> >>>> urb= an application networks. Each document will describe the use=0A case and th= e=0A> >>>> associated routing protocol requirements. The documents will=0A = progress in=0A> >>>> collaboration with the 6lowpan Working Group (INT area= ).=0A> >>>>=0A> >>>>=0A> >>>> - Survey the applicability of existing protoc= ols to L2Ns. The=0A aim of this=0A> >>>> document will be to analyze the sc= aling and characteristics of=0A existing=0A> >>>> protocols and identify wh= ether or not they meet the routing=0A requirements of=0A> >>>> the L2Ns app= lications identified above. Existing IGPs, MANET,=0A NEMO, DTN=0A> >>>> rou= ting protocols will be part of evaluation.=0A> >>>>=0A> >>>> - Specificatio= n of routing metrics used in path calculation.=0A This includes=0A> >>>> st= atic and dynamic link/nodes attributes required for routing in=0A L2Ns.=0A>= >>>>=0A> >>>> - Provide an architectural framework for routing and path=0A= selection at Layer=0A> >>>> 3 (Routing for L2N Architecture)=0A> >>>> * De= cide whether the L2Ns routing protocol require a=0A distributed,=0A> >>>> c= entralized path computation models or both.=0A> >>>> * Decide whether the L= 2N routing protocol requires a=0A hierarchical routing=0A> >>>> approach.= =0A> >>>>=0A> >>>> - Produce a security framework for routing in L2Ns.=0A> = >>>>=0A> >>>> Goals And Milestones:=0A> >>>>=0A> >>>>=0A> >>>> April 2008 S= ubmit Use case/Routing requirements for Industrial,=0A Connected=0A> >>>> H= ome, Building and Urban networks applications to the IESG to be=0A consider= ed=0A> >>>> as an Informational RFC.=0A> >>>>=0A> >>>> August 2008: Submit = Routing metrics for L2Ns document to the=0A IESG to be=0A> >>>> considered = as an Informational RFC.=0A> >>>>=0A> >>>> September 2008: Submit first dra= ft of the Routing for L2Ns=0A Architecture=0A> >>>> document (summary of r= equirements, path computation model,=0A> >>>> flat/hierarchy,=A9).=0A> >>>>= =0A> >>>> November 2008: Submit Protocol Survey to the IESG to be=0A consid= ered as an=0A> >>>> Informational RFC.=0A> >>>>=0A> >>>> January 2009 Submi= t Security Framework for L2Ns to the IESG to=0A be considered=0A> >>>> as a= n Informational RFC=0A> >>>>=0A> >>>> February 2009: Submit the Routing for= L2Ns Architecture document=0A (summary=0A> >>>> of requirements, metrics = and attributes, path selection model)=0A to the IESG=0A> >>>> as an Informa= tional RFC.=0A> >>>>=0A> >>>> March 2009: Recharter.=0A> >>>>=0A> >>>>=0A> = >>>> Please comment/suggest/...=0A> >>>>=0A> >>>> See you in Vancouver.=0A>= >>>>=0A> >>>> JP and David.=0A> >>>>=0A> >>>>=0A> >>>> ___________________= ____________________________=0A> >>>> RSN mailing list=0A> >>>> RSN@ietf.or= g=0A> >>>> https://www1.ietf.org/mailman/listinfo/rsn=0A> >>>>=0A> >>>>=0A>= >>>>=0A> >>>> _______________________________________________=0A> >>>> RSN= mailing list=0A> >>>> RSN@ietf.org=0A> >>>> https://www1.ietf.org/mailman/= listinfo/rsn=0A> >>>>=0A> >>>>=0A> >>>> =0A> >> ___________________= ____________________________=0A> >> 6lowpan mailing list=0A> >> 6lowpan@iet= f.org=0A> >> https://www1.ietf.org/mailman/listinfo/6lowpan=0A> >> =0A>= >=0A> > =0A=0A=0A_______________________________________________=0A6lowp= an mailing list=0A6lowpan@ietf.org=0Ahttps://www1.ietf.org/mailman/listinfo= /6lowpan=0A=0A=0A=0A --0-382288667-1196385215=:34078 Content-Type: text/html; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable
Geoff,

Could you please provide a pointer to t= he message or document with that exception?
This is an important item a= nd it should be added to the group's Wiki page.

My recollection is d= ifferent, but I may have just forgotten. What I recollect is that back when= we
were starting the working group and initiating work on the problem = statement draft, was that the recommendation
was to stay away from issui= ng our own IPv6 profile, precisely because saying things like ("IPsec is no= t recommended in lowpan
environments") was a sure-fire way to invite con= troversy at the IESG. E.g., IPv6 mandates IPsec, so how could
we ever cl= aim to support IPv6.... This debate probably is better had in 6man in terms of a revision of the hosts
requirements, rather than in any parti= cular WG.

-gabriel

----- Original Message ----
Fro= m: Geoff Mulligan <geoff@mulligan.com>
To: Kris Pister <pister@= eecs.berkeley.edu>
Cc: 6lowpan <6lowpan@lists.ietf.org>
Sent= : Thursday, November 29, 2007 11:09:02 AM
Subject: Re: [6lowpan] RE: [RS= N] Here is the new RL2N Proposed Working Charter

We did not try to g= et an exception to UDP checksums.

    geoff

On= Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote:
> Geoff - ooh, I = like exceptions.
> Did we try to get an exception on the UDP checksum= ?  It's painful to
> leave that in the compressed header if we = have L2 message integrity.
>
> ksjp
>
> Geoff Mul= ligan wrote:
> > We have already received an exception from the IESG to IPsec on=0A 6lowpan
> > devices.
> >
>= >     geoff
> >
> > On Thu, 2007-11-29= at 16:09 +0100, Pascal Thubert (pthubert) wrote:
> > 
&= gt; >> Hum...
> >>
> >> I had missed that; S= eems that we have to make an exception :) If=0A you consider ISA100.11a, th= ey already have security at L2 and L5, it=0A makes little sense to MUST IPS= ec on top of that.
> >>
> >> Pascal
> >>= ;
> >>   
> >>> -----Original Messag= e-----
> >>> From: Kris Pister [mailto:pister@e= ecs.berkeley.edu]
> >>> Sent: Wednesday, November 28, 20= 07 8:03 PM
> >>> To: Pascal Thubert (pthubert)
> >&= gt;> Cc: 6lowpan
> >>> Subject: Re: [RSN] Here is the new= RL2N Proposed Working Charter
> >>>
> >>> Hm= m.  From 4294:
> >>>
> >>> "However, whi= le authentication and encryption can each be NULL,=0A they
> >>= > MUST NOT both be NULL."
> >>>
> >>> ksjp=
> >>>
> >>> Pascal Thubert (pthubert) wrote:=
> >>>     
> >>>> Hi Kri= s:
> >>>>
> >>>> For your question on E= SP, AFAIK, RFC 4294 only mandates NULL=0A encryption and authentication for=
> >>>>       
> >>>= interoperability reasons.
> >>>     
&g= t; >>>> On the general question of RFC 4294 itself: I'm not sur= e the=0A work was ever done. I hope someone
> >>>>  =      
> >> >from the list can help?
>= >>   
> >>>> If the answer is unclear,= and considering that we are=0A re-chartering the group, maybe we could hav= e
> >>>>       
> >>>= ; a work item to specify the instantiation of RFC 4294 for LoWPAN=0A nodes?=
> >>>     
> >>>> Pascal=
> >>>> ________________________________________
> = >>>> From: Kris Pister [mailto:pister@eecs.berkele= y.edu]
> >>>> Sent: Wednesday, November 28, 2007 5:42= PM
> >>>> To: Pascal Thubert (pthubert)
> >>= >> Cc: 6lowpan
> >>>> Subject: Re: [RSN] Here is th= e new RL2N Proposed Working Charter
> >>>>
> >&g= t;>> Is there an email thread somewhere that discusses the impact on= =0A 6LoWPAN of the security
> >>>>      &n= bsp;
> >>> requirements of 4294 and 4303?
> >>= >     
> >>>> My first quick readthro= ugh makes me very uncomfortable that some=0A of the mandates are going to b= e
> >>>>       
> >>>= ; ugly from a header standpoint.
> >>>      =
> >>>> ksjp
> >>>>
> >>>= ;> Pascal Thubert (pthubert) wrote:
> >>>> Hi JP:
&= gt; >>>>
> >>>> Thanks a bunch for this chart= er. I'll try not to rephrase what=0A was already discussed with Christian,<= br>> >>>>       
> >>> = Anders, Philip and Misha.
> >>>     
>= ; >>>> There's an additional item I'd wish to see either in ROL= L or=0A 6LoWPAN and I do not know exactly
> >>>>  &n= bsp;    
> >>> where it belongs, maybe both. The= question is whether we need to=0A and can document how RFC 4294
> &g= t;>> applies for sensors, and M2M devices in general, whether they ac= t=0A as hosts or as routers.
> >>>     
= > >>>> I've seen IPv6 presented as a Pandora box that drags = just too=0A much stuff to be incorporated in a
> >>>>&nbs= p;      
> >>> sensory device. For instance= , at the moment, SP100.11a endorses=0A 6LoWPAN formats but it's not so clea= r
> >>> at all that IPv6 itself is mandated. A clear spec wi= th=0A well-documented implementation could be a
> >>> formid= able tool to despond to Fear, Uncertainty and Defiance.
> >>>= ;     
> >>>> So maybe we do not need DH= CP (a MAY in RFC 4294) and maybe can=0A do without multicast at all if ND i= s
> >>>>       
> >>>= ; supported some other way (such as suggested in:=0A http://www.ietf.= org/internet-drafts/draft-thubert-
> >>> lowpan-backbone= -router-00.txt). Maybe NULL encryption and=0A authentication is enough etc,= etc...
> >>>     
> >>>>= Being able to define one minimum set and maybe a few other=0A profiles for= the use cases that we
> >>>>        =
> >>> selected could help tremendously.
> >>&g= t;     
> >>>> Otherwise I find the char= ter real well written and easy to=0A digest. >>From the MANEMO experi= ence, I
> >>>>       
> >&= gt;> expect that some arguments about the relative applicability of=0A e= xisting MANET protocols will be
> >>> difficult to prove wit= hout some good simulation work running=0A agreed-upon scenarios.
> &g= t;>>     
> >>>> Finally, I'm a bi= t confused that it seems that both IPv4 and=0A IPv6 seem supported. Ipv4 co= mes with a
> >>>>       
> &g= t;>> lot of overhead like DHCP. I suggest that when trouble comes and= =0A things can not be done in a common
> >>> fashion for bot= h IP protocols, hen we prioritize IPv6.
> >>>    &= nbsp;
> >>>> Unfortunately, I can not make it to Vancou= ver, but I do feel=0A that the work is really needed so
> >>>= ;>       
> >>> please count my vot= e in for the adoption of the WG.
> >>>      =
> >>>> Cheers,
> >>>>
> >>= >> Pascal
> >>>>
> >>>>
> &= gt;>>> -----Original Message-----
> >>>> From: J= ean Philippe Vasseur (jvasseur)
> >>>> Sent: Wednesday, N= ovember 21, 2007 9:19 PM
> >>>> To: rsn@ietf.org
> >>= ;>> Subject: [RSN] Here is the new RL2N Proposed Working Charter
&= gt; >>>>
> >>>> Dear all,
> >>>= ;>
> >>>> As promised, here is the new proposed Workin= g Group, which=0A reflects the
> >>>> number of comments/= suggestions that we received, the pre-WG=0A consensus, ...
> >>= >>
> >>>> Thanks to Dave Ward (RTD AD) for his inpu= t.
> >>>>
> >>>> Proposed RL2N WG Chart= er
> >>>>
> >>>> Description of Working= Group
> >>>>
> >>>> L2Ns (Low power an= d Lossy networks) are typically composed of=0A many embedded
> >&g= t;>> devices with limited power, memory, and processing resources=0A = interconnected
> >>>> by a variety of wireless links, suc= h as IEEE 802.15.4,=0A Bluetooth, Low Power
> >>>> WiFi.<= br>> >>>>
> >>>> L2Ns are transitioning to= an end-to-end IP-based solution to=0A avoid the
> >>>> p= roblems of non-interoperable networks interconnected by=0A protocol
>= >>>> translation gateways and proxies. In addition, L2Ns have= =0A specific routing
> >>>> requirements that are not cur= rently met by existing routing=0A protocols, such
> >>>> = as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be=0A designed to t= ake
> >>>> into consideration the specific power, capabil= ities, attributes=0A and
> >>>> functional characteristic= s of the links and nodes in the=0A network.
> >>>>
>= ; >>>>
> >>>> There is a wide scope of applic= ation areas for L2Ns, including=0A industrial
> >>>> moni= toring, building automation (HVAC, lighting/access control),=0A connected> >>>> home, healthcare, environmental monitoring, agricul= tural, smart=0A cities,
> >>>> logistics, assets tracking= , and refrigeration. The L2N WG will=0A focus on
> >>>> r= outing solutions for a subset of these deployment scenarios,=0A namely
&= gt; >>>> industrial, connected home/building and urban applicat= ions. The=0A Working
> >>>> Group will determine the rout= ing requirements for these=0A scenarios.
> >>>>
> &= gt;>>>
> >>>> The Working Group will provide a r= outing framework for these=0A application
> >>>> scenario= s that provides high reliability in the presence of time=0A varying
>= >>>> loss characteristics and connectivity while permitting lo= w-power=0A operation
> >>>> with very modest memory and C= PU pressure.
> >>>>
> >>>>
> >= >>> The Working Group will pay a particular attention to routing= =0A security and
> >>>> manageability (e.g self managing/= configuration) issues, which=0A are
> >>>> particularly c= ritical for L2Ns.
> >>>>
> >>>> Work It= ems:
> >>>>
> >>>> - Produce use cases = documents for Industrial, Connected Home,=0A Building and
> >>&= gt;> urban application networks. Each document will describe the use=0A = case and the
> >>>> associated routing protocol requireme= nts. The documents will=0A progress in
> >>>> collaborati= on with the 6lowpan Working Group (INT area).
> >>>>
&= gt; >>>>
> >>>> - Survey the applicability of= existing protocols to L2Ns. The=0A aim of this
> >>>> do= cument will be to analyze the scaling and characteristics of=0A existing> >>>> protocols and identify whether or not they meet the = routing=0A requirements of
> >>>> the L2Ns applications i= dentified above. Existing IGPs, MANET,=0A NEMO, DTN
> >>>>= ; routing protocols will be part of evaluation.
> >>>>> >>>> - Specification of routing metrics used in path calc= ulation.=0A This includes
> >>>> static and dynamic link/= nodes attributes required for routing in=0A L2Ns.
> >>>><= br>> >>>> - Provide an architectural framework for routing a= nd path=0A selection at Layer
> >>>> 3 (Routing for L2N A= rchitecture)
> >>>> * Decide whether the L2Ns routing pro= tocol require a=0A distributed,
> >>>> centralized path c= omputation models or both.
> >>>> * Decide whether the L2= N routing protocol requires a=0A hierarchical routing
> >>>&= gt; approach.
> >>>>
> >>>> - Produce a= security framework for routing in L2Ns.
> >>>>
> &= gt;>>> Goals And Milestones:
> >>>>
> >= >>>
> >>>> April 2008 Submit Use case/Routing re= quirements for Industrial,=0A Connected
> >>>> Home, Buil= ding and Urban networks applications to the IESG to be=0A considered
>= ; >>>> as an Informational RFC.
> >>>>
>= ; >>>> August 2008: Submit Routing metrics for L2Ns document to= the=0A IESG to be
> >>>> considered as an Informational = RFC.
> >>>>
> >>>> September 2008: Subm= it first draft of the Routing for L2Ns=0A Architecture
> >>>= > document  (summary of requirements, path computation model,
&g= t; >>>> flat/hierarchy,=A9).
> >>>>
> &= gt;>>> November 2008: Submit Protocol Survey to the IESG to be=0A = considered as an
> >>>> Informational RFC.
> >&g= t;>>
> >>>> January 2009 Submit Security Framework = for L2Ns to the IESG to=0A be considered
> >>>> as an Inf= ormational RFC
> >>>>
> >>>> February 2= 009: Submit the Routing for L2Ns Architecture document=0A  (summary> >>>> of requirements, metrics and attributes, path select= ion model)=0A to the IESG
> >>>> as an Informational RFC.=
> >>>>
> >>>> March 2009: Recharter.> >>>>
> >>>>
> >>>> P= lease comment/suggest/...
> >>>>
> >>>>= See you in Vancouver.
> >>>>
> >>>> JP= and David.
> >>>>
> >>>>
> >&= gt;>> _______________________________________________
> >>= ;>> RSN mailing list
> >>>> RSN@ietf.org
> >>&= gt;> https://www1.ietf.org/mailman/listinfo/rsn
> >>>&g= t;
> >>>>
> >>>>
> >>>&g= t; _______________________________________________
> >>>>= RSN mailing list
> >>>> RSN@ietf.org
> >>>> https://www1.ie= tf.org/mailman/listinfo/rsn
> >>>>
> >>&g= t;>
> >>>>       
> >&g= t; _______________________________________________
> >> 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

--0-382288667-1196385215=:34078-- --===============0644530130== 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 --===============0644530130==-- From 6lowpan-bounces@ietf.org Mon Dec 10 15:47:02 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 1J1pWn-0000Fb-UF; Mon, 10 Dec 2007 15:47:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pWm-0000Ds-Jz for 6lowpan@lists.ietf.org; Mon, 10 Dec 2007 15:47:00 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1pWk-0003m4-Oc for 6lowpan@lists.ietf.org; Mon, 10 Dec 2007 15:47:00 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF01C8A18E; Mon, 10 Dec 2007 21:46:57 +0100 (CET) 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 21953-08; Mon, 10 Dec 2007 21:46:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1B6A8A189; Mon, 10 Dec 2007 21:46:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2925D41F3FA; Mon, 10 Dec 2007 21:46:53 +0100 (CET) Date: Mon, 10 Dec 2007 21:46:53 +0100 From: Juergen Schoenwaelder To: Carsten Bormann Subject: Re: [6lowpan] Issue of the week: Charter finalization Message-ID: <20071210204653.GA17027@elstar.local> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de 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 Mon, Dec 10, 2007 at 08:45:10PM +0100, Carsten Bormann wrote: > C) Daniel has reminded us that there needs to be a management solution > at some point. I'm not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? [...] > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > with a network management slant? [...] Just to let you know that I am still lurking on this list. I am not sure what is needed at this point in time concering management. SNMP can be reasonably byte efficient (and there were proposals in the past to make it even more efficient) but it uses a polling approach which may be questioned on some 6lowpan scenarios where you might want to save the requests and perhaps even do aggregation along the routing path. On the other hand, we might be able to reuse some of the IPv6 MIBs and that might be goodness. During our 6lowpan implementation exercise, we found a few things in the RFC that would be nice to fix and which we have posted to this list (without much feedback I must say). From my perspective, I think there should be continued work on the 6lowpan specifications - either as an implementors guide or simply work towards revised specifications. And it might help to actually have interoperability tests carried out to see how much implementations interoperate in terms of the various compression schemes and fragmentation. Who would participate in some interoperability test at one of the upcoming IETFs? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 10 15:47:16 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 1J1pX2-0000Lm-5C; Mon, 10 Dec 2007 15:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1pX1-0000Lh-5n for 6lowpan@lists.ietf.org; Mon, 10 Dec 2007 15:47:15 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1pWy-0003mn-Pk for 6lowpan@lists.ietf.org; Mon, 10 Dec 2007 15:47:15 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lBAKl1R9028429 for <6lowpan@lists.ietf.org>; Mon, 10 Dec 2007 13:47:11 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Mon, 10 Dec 2007 13:46:56 -0700 Message-Id: <1197319616.5697.45.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [6lowpan] Issue of the Week: Charter Finalization 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 Lowpanners, We have had some recent discussion on issues related to network structure, in particular the use of multicast and the issue of sleeping nodes. Carsten and I don't want to interrupt this discussion, but we would like to remind everyone that we also have one CRITICAL short term objective: Getting rechartered. The *theme of the week* for the working group is the finalization of the charter. In particular, the following questions have been raised: A) is the timeline, which was too tight, now too relaxed? (Obviously, the chairs don't think so, but what do you think?) B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had envisioned each of the use cases to explain what protocols are used in implementing that particular use case, not the generation of a unified minimal profile that would apply to all use cases.) C) Daniel has reminded us that there needs to be a management solution at some point. We're not sure that simply defining a MIB is the right way to provide this (SNMPv3 on sensor nodes?). Instead, we could add "management method" to the subjects of the architecture document before actually creating the solution. Is that the right place? D) The discussions about multicast have reminded us that 4944 alone does not provide a solution beyond a single radio range. MANET's SMF provides one, but presupposes some support from the routing protocol. The BbR approach reminds me of 802.11, where all multicast is unicast to the AP which then sends it back into the wireless network (which might allow a simplified flooding based on something like RPF). E) There were some comments during the meeting that we already were taking on a sizable amount of work. I'm not sure we want to take on all of the other points Daniel raised: [...] I guess we should consider how to improve the quality of RFC 4944, especially Global Address HC, TCP operation, ICMPv6 operation and etc. RFC 4944-bis is one of options. [...] how to dig out *mobility issue* from the proposed charter. I guess some of requirements of mobility for 6lowpan networks is doable for the initial activity at this stage except specific mobility solutions. F) Going through each of the documents, the following contributions have been promised recently: 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have longstanding contributions from Samita Chakrabarti and Erik Nordmark. Anybody else? Daniel has also proposed to split 1 into bootstrapping and ND optimization. There is also the subject of commissioning. What is the right set of documents, and which ones do (each of) you want to work on? 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": During the meeting, Kris Pister indicated that he was interested in contributing, and Carsten Bormann might be contributing a bit of ROHC background. 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff Mulligan, and JP Vasseur. Any other takers? In particular, somebody with a network management slant? 3a "Routing requirements" (which needs its own milestone entry) has a draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During the RL2N BOF, a similar document was proposed as a result of the RL2N-followup WG to be formed. We need to understand whether the two documents (the 6lowpan one and the rl2n++ one) are sufficiently different or whether we simply need to cooperate on one document, which would then have to include the 6lowpan-specific aspects including mesh-under. 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" might provide a basis, but we need more input, in particular from implementors of each of these scenarios that we actually want to use as use cases. 5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten and Geoff might provide some input, but can't do this on their own.) 6 Implementers' guide: Zach Shelby and Jonathan Hui are interested. What about the other folks that have built or are building 6LoWPAN implementations. 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about the other folks that have built or are building 6LoWPAN implementations. In order to accelerate rechartering, we should have answers to these questions/credible sets of contributors to these documents by the end of this week, so please don't hesitate providing your input. Gruesse, Carsten and Geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 11 00:52:11 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 1J1y2M-0001eV-1r; Tue, 11 Dec 2007 00:52:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1y2L-0001eQ-5p for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 00:52:09 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1y2J-0007Ch-3x for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 00:52:09 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lBB5pTO6000844; Mon, 10 Dec 2007 22:51:34 -0700 (MST) Subject: Re: [6lowpan] Issue of the week: Charter finalization From: Geoff Mulligan To: j.schoenwaelder@jacobs-university.de In-Reply-To: <20071210204653.GA17027@elstar.local> References: <20071210204653.GA17027@elstar.local> Content-Type: text/plain Date: Mon, 10 Dec 2007 22:51:26 -0700 Message-Id: <1197352286.5697.64.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Juergen, I guess that I missed your suggestions on fixes to the RFC? Perhaps after we get this rechartering done we can take up the fixes. I like the idea of finding a way to more efficiently transfer SNMP messages as well as a simpler way to implement SNMP (not a full ASN.1) geoff On Mon, 2007-12-10 at 21:46 +0100, Juergen Schoenwaelder wrote: > On Mon, Dec 10, 2007 at 08:45:10PM +0100, Carsten Bormann wrote: > > > C) Daniel has reminded us that there needs to be a management solution > > at some point. I'm not sure that simply defining a MIB is the > > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > > could add "management method" to the subjects of the architecture > > document before actually creating the solution. Is that the right > > place? > > [...] > > > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > > with a network management slant? > > [...] > > Just to let you know that I am still lurking on this list. I am not > sure what is needed at this point in time concering management. SNMP > can be reasonably byte efficient (and there were proposals in the past > to make it even more efficient) but it uses a polling approach which > may be questioned on some 6lowpan scenarios where you might want to > save the requests and perhaps even do aggregation along the routing > path. On the other hand, we might be able to reuse some of the IPv6 > MIBs and that might be goodness. > > During our 6lowpan implementation exercise, we found a few things in > the RFC that would be nice to fix and which we have posted to this > list (without much feedback I must say). From my perspective, I think > there should be continued work on the 6lowpan specifications - either > as an implementors guide or simply work towards revised specifications. > > And it might help to actually have interoperability tests carried out > to see how much implementations interoperate in terms of the various > compression schemes and fragmentation. Who would participate in some > interoperability test at one of the upcoming IETFs? > > /js > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 11 01:01:10 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 1J1yB4-0008W8-6m; Tue, 11 Dec 2007 01:01:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1yB2-0008W3-Li for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 01:01:08 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1yB2-0007MP-8B for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 01:01:08 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lBB617Vr000892 for <6lowpan@lists.ietf.org>; Mon, 10 Dec 2007 23:01:07 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Mon, 10 Dec 2007 23:01:04 -0700 Message-Id: <1197352864.5697.74.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [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 Lowpanners, As Mark Townsley (our Area Director) mentioned at the IETF meeting last week, he would like to see some discussion and/or acknowledgment that the current charter text is acceptable to the working group. We have had a couple of folks send some input with some minor issues surrounding splitting some of the docs, but we need more input. Mark doesn't want us to move forward with something as important as the new charter and work items unless we have positive feedback, not just silence. If you agree with the direction of the working group based on the Charter, please drop a note to the list and let us know this! geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 11 01:02:27 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 1J1yCI-0002bm-Oa; Tue, 11 Dec 2007 01:02:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1yCH-0002bY-9H for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 01:02:25 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1yCF-0007OP-JT for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 01:02:25 -0500 Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id lBB62DGg000900; Mon, 10 Dec 2007 23:02:13 -0700 (MST) Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) From: Geoff Mulligan To: Ian Chakeres In-Reply-To: <374005f30712100934s622e40a0i36ec27030e64fd01@mail.gmail.com> References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <1197065234.6356.42.camel@dellx1> <374005f30712100934s622e40a0i36ec27030e64fd01@mail.gmail.com> Content-Type: text/plain Date: Mon, 10 Dec 2007 23:02:11 -0700 Message-Id: <1197352931.5697.76.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: 6lowpan <6lowpan@lists.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, I'm not sure what you mean by choosing one architecture? geoff On Mon, 2007-12-10 at 23:04 +0530, Ian Chakeres wrote: > I tend to agree with Tim that sleeping can potentially be a big issue > for both 6lowpan and more general routing in sensor networks. I do not > think it should be dismissed. > > I also think that if 6lowpan does not choose one architectures (e.g. > host-host, router-host, or router-router), it will be difficult to > specify some of the optimizations. For example, ND optimization. > > Ian > > On Dec 8, 2007 3:37 AM, Geoff Mulligan wrote: > > Tim, > > I think that you have some misunderstandings. > > > > On Thu, 2007-12-06 at 16:10 -0600, Timothy J. Salo wrote: > > > Samita Chakrabarti wrote: > > > > ... That way, periodic RA will not wake up > > > > all the nodes in the 6lowpan. ... > > > > > > To the best of my knowledge, 802.15.4 implementations power-down > > > the radio when the system sleeps. As such, a broadcast packet > > > does not wake a sleeping 802.15.4 node. Rather, the packet > > > is simply never received by the sleeping node. > > > > > This is not true. A node that sleeps can receive broadcast packets. > > > > - If the broadcast packet is transmitted on some schedule then the > > sleeping node can wake up on that schedule and receive the packet. > > - If the broadcast packet is transmitted with some sort of long > > preamble then the sleeping node can wake up on it's own schedule, over > > hear the preamble and stay awake to receive the packet. > > - If the broadcast packet is transmitted multiple times the sleeping > > node can wake up during one of these transmissions and receive the > > packet. > > > > This is much like receiving any packet, not just broadcast packets. > > > > > If my understanding about this behavior is incorrect, someone > > > please correct me. I have been meaning to check and see what > > > the spec says about this, but haven't yet... > > > > There is nothing in the spec on this. As far as I know, there are no > > 15.4 radios that wake on some sort of reception. > > > > > > > > Given that the response to broadcast packets differs in 802.16 > > > networks (where an idle node wakes to process the packet) and > > > 802.15.4 networks (where a sleeping node is never even aware > > > of the packet), different solutions are probably required. > > > > > > To reiterate what I have said before, I believe that we must > > > explicitly specify the behavior we expect of multicast in > > > 6lowpan networks that contain sleeping nodes. > > > > No we don't. > > > > > In particular, > > > does multicast mean "received by the potentially very small > > > percentage of the nodes that aren't currently sleeping" or might > > > it mean "received by every node after they wake up [whenever > > > day that might be]"? > > > After we specify the behavior of multicast, > > > then we can then try to figure out whether we can actually > > > implement that behavior in a useful way. > > > > > > In the interim, I suggest a moratorium on simply assuming that > > > multicast is a potential solution to any of the challenges > > > we face (e.g., duplicate address detection, router announcements, > > > neighbor discovery, ...) > > > > NO. > > > > > > > > > > -tjs > > > > > > > > > > > > _______________________________________________ > > > 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 Tue Dec 11 03:04: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 1J206O-00013B-NP; Tue, 11 Dec 2007 03:04:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J206O-000134-1d for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 03:04:28 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J206N-0001W1-1M for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 03:04:28 -0500 X-IronPort-AV: E=Sophos;i="4.24,150,1196636400"; d="scan'208";a="528675" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2007 09:04:22 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBB84OdJ024017; Tue, 11 Dec 2007 09:04:24 +0100 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 lBB84Imc014884; Tue, 11 Dec 2007 08:04:22 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 09:04:18 +0100 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] Issue of the Week: Charter Finalization Date: Tue, 11 Dec 2007 09:04:10 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04E403DD@xmb-ams-337.emea.cisco.com> In-Reply-To: <1197319616.5697.45.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Issue of the Week: Charter Finalization Thread-Index: Acg7be/Jap6ZBuJ+QEWtZl2N11PWbAAWl07Q From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "6lowpan" <6lowpan@lists.ietf.org>, "Julien Abeille (jabeille)" , "Zach Shelby" X-OriginalArrivalTime: 11 Dec 2007 08:04:18.0375 (UTC) FILETIME=[6DEE2570:01C83BCC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6824; t=1197360264; x=1198224264; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Issue=20of=20the=20Week=3A= 20Charter=20Finalization |Sender:=20; bh=qxOhvaGYI1SKKT9IJKvVrEehW0lCoYvBiR4pV04E9fc=; b=AJvPIeV5bGpewmt3pvHOe6NpLxuA5vL36tHuXrrts/lNYz/9mFeJqMJzNr xeDvB9lgIFCz/2sS7POzoB//vVILnyHicyCMLkbRQR74jxaatro/IDGko016 +NwiaqsxuS; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -2.8 (--) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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 Hi Geoff: My answer is 2 fold: organizational and functional. 1) moving forward: What I see in the charter is a lot of good work ahead, and maybe not = enough people for doing it! There's nothing I would drop from your long = list. There's even some stuff I'd wish to add. But then we need to hire = on this list! Long as we have enough people committed on contributing to a given task, = go for it. Seems that a cross ref between prioritized work items and = volunteers could help sort manning out. Are the tasks in the charter = already ordered by priority? 2) items:=20 I can commit to participate to the ND work, in particular WRT BrB. I = agree with your image of an AP up to the point that with BrB, ND is done = with recoverable unicast over a multihop mesh under, whereas in the WIFI = AP case, we have direct sight and the AP actually rebroadcasts things = that were passed unicast, with no recovery. So please count me in for = the ND related work. I'm also interested on a work item that is not mentioned on the charter, = fragment flow control and recovery. Considering that a 1500 bytes packet = will be sliced in about 25 pieces, and that the loss of a single = fragment causes the resending of the 25 of them, it might be appropriate = to propose a minimalist fragment recovery to start with, wouldn't you = think? Finally, I'm all for the 6LoWPAN profile and I know enough people who = wish to contribute. The question is whether that one should be done at = 6MAN or 6LoWPAN. Maybe we could get some wisdom from the ADs on this? I hope this helps Pascal =20 >-----Original Message----- >From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org]=20 >Sent: lundi 10 d=E9cembre 2007 21:47 >To: 6lowpan >Subject: [6lowpan] Issue of the Week: Charter Finalization > >Lowpanners, > >We have had some recent discussion on issues related to=20 >network structure, in particular the use of multicast and the=20 >issue of sleeping nodes. =20 > >Carsten and I don't want to interrupt this discussion, but we=20 >would like to remind everyone that we also have one CRITICAL=20 >short term objective: >Getting rechartered. > >The *theme of the week* for the working group is the=20 >finalization of the charter. In particular, the following=20 >questions have been raised: > >A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) > >B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) > >C) Daniel has reminded us that there needs to be a management solution > at some point. We're not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? > >D) The discussions about multicast have reminded us that 4944 alone > does not provide a solution beyond a single radio range. MANET's > SMF provides one, but presupposes some support from the routing > protocol. The BbR approach reminds me of 802.11, where all > multicast is unicast to the AP which then sends it back into the > wireless network (which might allow a simplified flooding based on > something like RPF). > >E) There were some comments during the meeting that we already were > taking on a sizable amount of work. I'm not sure we want to take > on all of the other points Daniel raised: > > [...] I guess we should consider how to improve the quality of RFC > 4944, especially Global Address HC, TCP operation, ICMPv6 operation > and etc. RFC 4944-bis is one of options. > > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. > >F) Going through each of the documents, the following contributions > have been promised recently: > >1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations":=20 >We have longstanding contributions from Samita Chakrabarti and=20 >Erik Nordmark. >Anybody else? Daniel has also proposed to split 1 into=20 >bootstrapping and ND optimization. There is also the subject=20 >of commissioning. >What is the right set of documents, and which ones do (each=20 >of) you want to work on? > >2 "Problem Statement for Stateful Header Compression in 6LoWPANs": >During the meeting, Kris Pister indicated that he was=20 >interested in contributing, and Carsten Bormann might be=20 >contributing a bit of ROHC background. > >3 "6LoWPAN Architecture" already has a draft from Dave Culler,=20 >Geoff Mulligan, and JP Vasseur. Any other takers? In=20 >particular, somebody with a network management slant? > >3a "Routing requirements" (which needs its own milestone=20 >entry) has a draft from Dominik Kaspar, Eunsook Kim, and=20 >Carsten Bormann. During the RL2N BOF, a similar document was=20 >proposed as a result of the RL2N-followup WG to be formed. We=20 >need to understand whether the two documents (the 6lowpan one=20 >and the rl2n++ one) are sufficiently different or whether we=20 >simply need to cooperate on one document, which would then=20 >have to include the 6lowpan-specific aspects including mesh-under. > >4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. >Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" >might provide a basis, but we need more input, in particular=20 >from implementors of each of these scenarios that we actually=20 >want to use as use cases. > >5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten=20 >and Geoff might provide some input, but can't do this on their own.) > >6 Implementers' guide: Zach Shelby and Jonathan Hui are interested. >What about the other folks that have built or are building=20 >6LoWPAN implementations. > >7 Interop guide: Zach Shelby and Jonathan Hui are interested.=20 >What about the other folks that have built or are building=20 >6LoWPAN implementations. > >In order to accelerate rechartering, we should have answers to=20 >these questions/credible sets of contributors to these=20 >documents by the end of this week, so please don't hesitate=20 >providing your input. > >Gruesse, Carsten and Geoff > > > > >_______________________________________________ >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 Tue Dec 11 07:47: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 1J24WQ-00064Y-Rg; Tue, 11 Dec 2007 07:47:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J24WP-00064R-L9 for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 07:47:37 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J24WO-0007VN-EX for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 07:47:37 -0500 X-IronPort-AV: E=Sophos;i="4.24,152,1196636400"; d="scan'208";a="568309" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2007 13:47:35 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBBClZ9E024626; Tue, 11 Dec 2007 13:47:35 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBBClZmc021629; Tue, 11 Dec 2007 12:47:35 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 13:47:34 +0100 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] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Date: Tue, 11 Dec 2007 13:47:29 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04E9B2CB@xmb-ams-337.emea.cisco.com> In-Reply-To: <4759C700.6090701@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Thread-Index: Acg5H02pLMBjsVtmQqCHAvdg7P3jgwCwme2Q From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Geoff Mulligan" X-OriginalArrivalTime: 11 Dec 2007 12:47:34.0977 (UTC) FILETIME=[00B1CB10:01C83BF4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7055; t=1197377255; x=1198241255; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20ND=20optimization=20for=20s ensor=20nodes=20(power=09saving/=09Idle/Sleep=20mode) |Sender:=20; bh=gEYLVkgVFqz+6kMLtBAESPJh+iSkuvR2uQUDeYZm60s=; b=jORANbwCXyTMf4WBqt7Wwbp5i94gWyw4FxgqSVrgEV8nkinpFgLM9hbd95 cYCcgzPW/5mQli1V5w8ZFMZ3X1+OQqAsElBobd1WT2UfSyVUKWJ83vNW2RJf RvCqy8RkKc; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: 6lowpan <6lowpan@lists.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 Jonathan and Geoff: This makes sense to me. Now; The BrB draft is 2 fold; part of it is routing from to the backbone and = the Internet; and part of it is white board concept applied to 6LoWPAN. = We could separate the features in 2 drafts, but it seems simpler to = specify that the implementation of the proxy part towards the backbone = be required only when there is a backbone in the first place.=20 It also seems that the white board is a good approach regardless of = whether we have a backbone or not, considering the very nature of the = LoWPAN. We can do a very refined multicast support and try to approach = the energy cost and latency that we get with the white board model; but = it seems to me that the nearest to that grail we could get, the more = states we'd add in nodes all around, and still we'd never get as good as = white board. I've no handy proof of this assertion, but I'd be surprised = and quite interested to be proven wrong. Also, it makes sense that the behavior of the motes be the same whether = there's a backbone or not; if we recognize the need for the backbone = router for a number of supported situations, and if we agree that the = white board approach enables the registration for the proxy function = transparently, then isn't it the fair approach overall? In all of the architectures and deployments I've seen, there is always a = special box, called a sink, a router, a manager or a gateway, that plays = a central role for the LoWPAN. The case when that special box does not = exist seems really remote, so we can quite safely assume that the = special box exists and is a good candidate for the white board. Does that make sense? Pascal =20 >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com]=20 >Sent: vendredi 7 d=E9cembre 2007 23:20 >To: Pascal Thubert (pthubert) >Cc: Timothy J. Salo; 6lowpan >Subject: Re: [6lowpan] ND optimization for sensor nodes (power=20 >saving/ Idle/Sleep mode) > > >Hi Pascal, > >The backbone solution proposed in your draft targets a=20 >particular configuration and we should definitely consider it.=20 >Though I strongly believe that we are going to see different=20 >6LoWPAN/802.15.4 network configurations. There may be some=20 >that do not connect to the Internet and do not require or=20 >cannot afford a router. There may be others that choose a=20 >route-over approach vs. mesh-under. I just want to reiterate=20 >my wish that we don't force the WG into a solution space that=20 >only covers a particular 6LoWPAN/802.15.4 configuration.=20 >Instead, we should consider a few representative=20 >configurations as Tim suggested. While it'd be great to see a=20 >single solution satisfy all of them, we should be open to=20 >having different ones if needed. > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi >>=20 >> I tend to agree with Tim here; multicast is a complex issue=20 >in the low=20 >> power / sleepy space. It's even unclear which WG should be=20 >responsible=20 >> to define it. >> =20 >> Back to basics, there are basically 2 extreme models to locate=20 >> somebody; cry out loud or white board. ND on Ethernet uses the first=20 >> model based on multicast. Mobile IP uses the second. When=20 >you look up=20 >> a mobile node on the Home Link, the Home Agent is the reference that=20 >> responds the ND requests on behalf of the mobile nodes. >>=20 >> So my question is: Should we take as granted that ND on the LoWPAN=20 >> requires multicast? Maybe the white board model based on unicast is=20 >> enough, in which case we get rid of a very difficult dependency. >> Considering that there is a need for a router that=20 >understands 6LowPAN=20 >> to connect the LoWPAN to the Internet, that router is the natural=20 >> location for a white board. >>=20 >> So the concept of backbone router is this: cry out loud on the high=20 >> speed backbone that federates LoWPANs, and white board on=20 >the LoWPAN,=20 >> and ND proxying to federate the whole thing. The backbone router=20 >> implements ND proxying in a fashion that is compatible with=20 >mobile IP=20 >> so one day, sensors with a global address can move away and stay=20 >> virtually there. >>=20 >> In the meantime, a link local address is enough to connect=20 >to any node=20 >> in the network federated by backbone routers, and a mote can=20 >move from=20 >> a backbone router to another within the federated network without=20 >> renumbering. >>=20 >> The story begins in >>=20 >http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-rout >> er >> -00.txt :) >>=20 >> Pascal >> =20 >>=20 >>> -----Original Message----- >>> From: Timothy J. Salo [mailto:salo@saloits.com] >>> Sent: Thursday, December 06, 2007 11:11 PM >>> To: 6lowpan >>> Subject: Re: [6lowpan] ND optimization for sensor nodes (power=20 >>> saving/ Idle/Sleep mode) >>> >>> Samita Chakrabarti wrote: >>>> ... That way, periodic RA will not wake up all the nodes in the=20 >>>> 6lowpan. ... >>> To the best of my knowledge, 802.15.4 implementations=20 >power-down the=20 >>> radio when the system sleeps. As such, a broadcast packet does not=20 >>> wake a sleeping 802.15.4 node. >>> Rather, the packet is simply never received by the sleeping node. >>> >>> If my understanding about this behavior is incorrect,=20 >someone please=20 >>> correct me. I have been meaning to check and see what the=20 >spec says=20 >>> about this, but haven't yet... >>> >>> Given that the response to broadcast packets differs in 802.16=20 >>> networks (where an idle node wakes to process the packet) and >>> 802.15.4 networks (where a sleeping node is never even aware of the=20 >>> packet), different solutions are probably required. >>> >>> To reiterate what I have said before, I believe that we must=20 >>> explicitly specify the behavior we expect of multicast in 6lowpan=20 >>> networks that contain sleeping nodes. In particular, does=20 >multicast=20 >>> mean "received by the potentially very small percentage of=20 >the nodes=20 >>> that aren't currently sleeping" or might it mean "received by every=20 >>> node after they wake up [whenever day that might be]"? After we=20 >>> specify the behavior of multicast, then we can then try to=20 >figure out=20 >>> whether we can actually implement that behavior in a useful way. >>> >>> In the interim, I suggest a moratorium on simply assuming that=20 >>> multicast is a potential solution to any of the challenges we face=20 >>> (e.g., duplicate address detection, router announcements, neighbor=20 >>> discovery, ...) >>> >>> -tjs >>> >>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www1.ietf.org/mailman/listinfo/6lowpan >>> >>=20 >> _______________________________________________ >> 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 Tue Dec 11 13:00: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 1J29Od-0006L5-3M; Tue, 11 Dec 2007 12:59:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J29Oc-0006Ky-HH for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 12:59:54 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J29Ob-00066S-Ot for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 12:59:54 -0500 X-IronPort-AV: E=Sophos;i="4.24,153,1196636400"; d="scan'208";a="611901" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 11 Dec 2007 18:59:53 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBBHxrpR002532; Tue, 11 Dec 2007 18:59:53 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBBHxemc016726; Tue, 11 Dec 2007 17:59:40 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 18:59:40 +0100 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] Charter proposal Date: Tue, 11 Dec 2007 18:59:31 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04E9B502@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Charter proposal Thread-Index: Acg4O5W/gVhSW9d4SDGRnUG62H8gCAD4fQIg From: "Pascal Thubert (pthubert)" To: "Carsten Bormann" , "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 11 Dec 2007 17:59:40.0700 (UTC) FILETIME=[9A185DC0:01C83C1F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1559; t=1197395993; x=1198259993; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Charter=20proposal |Sender:=20; bh=tBc9TBBmKzXZ6tXeUfJlAQXsxCqKJCXXw0ARZz1K0qM=; b=WAUZeIfGxKUWI3VMGH4+/ZNS40ZbwC2vJkQJ83RrXm9t5eLbqfwKp9ULXI DNXkU9dcgukhVQ3lksVati0oH0I3EGeb3QiiziptFDvGPH6Bl1hAzHhdheaI kpvPqTScwV; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Hi Carsten: I do believe that the charter is quite good at this point. It is open to = architecture with mesh under and routing over, and does not seem limited = to 802.15.4 (at least item 3, 4 and 5 are not, right?). I would appreciate a sentence to enable maintenance work on existing = RFCs (e.g.. RFC 4944 for LP WIFI), and some capability to handle = requirements from other parties (e.g.. new 6LoWPAN headers required = other parties such as ISA100.11a).=20 We also need to understand which group is in charge of the LoWPAN node = requirements for IPv6. If that's 6LoWPAN, then I do believe we should = have a charter item for it. To answer Carsten's question, I'm willing to help on work item 1 = "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations". I believe it = can be stable by end of '08 if a number of choices are made to the = simpler. I'm also willing to start some work on fragment recovery if = that can be added to the charter.=20 Pascal =20 >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org]=20 >Sent: jeudi 6 d=E9cembre 2007 20:08 >To: 6lowpan >Cc: Carsten Bormann >Subject: [6lowpan] Charter proposal > >Lowpanners, > >Geoff and I have updated the charter proposal based on Marks=20 >input and yesterday's discussion. >Now would be a good time for comments, in particular also on=20 >the timelines we are promising. >Separately, we would like to know which of the items you are=20 >interested in contributing to -- please volunteer now. > >Gruesse, Carsten > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 11 14:23: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 1J2Ahv-0000Hy-Hd; Tue, 11 Dec 2007 14:23:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ahu-0000Ht-OP for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 14:23:54 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Ahs-00083T-DW for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 14:23:54 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Dec 2007 14:23:50 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBBJNoHu024543; Tue, 11 Dec 2007 14:23:50 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBBJNiZc021052; Tue, 11 Dec 2007 19:23:50 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 14:23:48 -0500 Received: from 10.86.104.181 ([10.86.104.181]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 11 Dec 2007 19:23:48 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 11 Dec 2007 14:23:42 -0500 Subject: Re: [6lowpan] Issue of the Week: Charter Finalization From: JP Vasseur To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> Message-ID: Thread-Topic: [6lowpan] Issue of the Week: Charter Finalization Thread-Index: Acg8K1bxlbU0xKgeEdyPqAANk8WjQA== In-Reply-To: <1197319616.5697.45.camel@dellx1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 19:23:48.0658 (UTC) FILETIME=[5AE9A120:01C83C2B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6891; t=1197401030; x=1198265030; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20Issue=20of=20the=20Week=3A= 20Charter=20Finalization |Sender:=20 |To:=20Geoff=20Mulligan=20,=206low pan=20<6lowpan@lists.ietf.org>; bh=1psDz711Rte//JVbVGHDPMKiCH5raCGoYwtOR2F3O2w=; b=mo+OFincq3hgkagXM6ZClmIuMDYYEv0eO0woiro5yxA4TOdo+dInQ9BoFi dUjw7gh7U08OVWGyUQ5K/XqJkxZhrSA40Zk3lN5IP06hZVp+WktyZfmaW0Tw zVT+SWf1lf; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -2.8 (--) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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 Hi Geoff, The proposed charter captures very well the discussions that we've been having for some time, thanks. Minor comments in line, > From: Geoff Mulligan > Date: Mon, 10 Dec 2007 13:46:56 -0700 > To: 6lowpan <6lowpan@lists.ietf.org> > Subject: [6lowpan] Issue of the Week: Charter Finalization > > Lowpanners, > > We have had some recent discussion on issues related to network > structure, in particular the use of multicast and the issue of sleeping > nodes. > > Carsten and I don't want to interrupt this discussion, but we would like > to remind everyone that we also have one CRITICAL short term objective: > Getting rechartered. > > The *theme of the week* for the working group is the finalization of the > charter. OK so I won't comment on this aspect for the time being ;-) In particular, the following questions have been raised: > > A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) > Are you planning to share the proposed Milestones? > B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) Can't agree more ... We had an informational discussion on this topic last Thursday and this was also my input: if we want to work on a minimal 6lowpan/IPv6 profile (and I think that we should), it will have to be on a per-case basis. > > C) Daniel has reminded us that there needs to be a management solution > at some point. We're not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? I think so, at least to start with. Should there be a need to define a SSNMP (Super Simple ....), would it be done here ?? I'm not against this idea, but it is by itself a fairly heavy work item. > > D) The discussions about multicast have reminded us that 4944 alone > does not provide a solution beyond a single radio range. MANET's > SMF provides one, but presupposes some support from the routing > protocol. The BbR approach reminds me of 802.11, where all > multicast is unicast to the AP which then sends it back into the > wireless network (which might allow a simplified flooding based on > something like RPF). *If* a ROLL WG is formed that is certainly an area that we'll be working on. Hopefully the solution should be applicable to 6lowpan. > > E) There were some comments during the meeting that we already were > taking on a sizable amount of work. I'm not sure we want to take > on all of the other points Daniel raised: > > [...] I guess we should consider how to improve the quality of RFC > 4944, especially Global Address HC, TCP operation, ICMPv6 operation > and etc. RFC 4944-bis is one of options. > > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. I would certainly not add anything to what is already quite loaded. > > F) Going through each of the documents, the following contributions > have been promised recently: > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > Anybody else? Daniel has also proposed to split 1 into bootstrapping > and ND optimization. I second that. There is also the subject of commissioning. > What is the right set of documents, and which ones do (each of) you > want to work on? Count me in (for comments). > > 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": > During the meeting, Kris Pister indicated that he was interested in > contributing, and Carsten Bormann might be contributing a bit of ROHC > background. > > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > with a network management slant? > > 3a "Routing requirements" (which needs its own milestone entry) has a > draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During > the RL2N BOF, a similar document was proposed as a result of the > RL2N-followup WG to be formed. We need to understand whether the two > documents (the 6lowpan one and the rl2n++ one) are sufficiently > different or whether we simply need to cooperate on one document, > which would then have to include the 6lowpan-specific aspects > including mesh-under. > If a ROLL WG is formed, the situation will be much clearer in a few months. I can see two options here: 1) Leave this out of the new charter for the moment, 2) Include the mesh-under routing requirement as the WG item, in which case it would be preferable to have one document with the mesh under routing requirements specifics being worked out in 6lowpan, feeding ROLL (if formed). The challenge here is that this document will most likely look quite similar to the first routing requirement David and I had started with before moving to a use case approach ... > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" > might provide a basis, but we need more input, in particular from > implementors of each of these scenarios that we actually want to use > as use cases. > > 5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten and Geoff > might provide some input, but can't do this on their own.) > > 6 Implementers' guide: Zach Shelby and Jonathan Hui are interested. > What about the other folks that have built or are building 6LoWPAN > implementations. Could you shed some light on what you mean by "Implementers' guide" especially in an IETF context? > > 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about > the other folks that have built or are building 6LoWPAN implementations. Certainly useful. > > In order to accelerate rechartering, we should have answers to these > questions/credible sets of contributors to these documents by the end > of this week, so please don't hesitate providing your input. Thanks. JP. > > Gruesse, Carsten and Geoff > > > > > _______________________________________________ > 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 Tue Dec 11 15:11:11 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 1J2BRe-0002R1-EF; Tue, 11 Dec 2007 15:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BRd-0002Qu-8L for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 15:11:09 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2BRb-0000kf-Ag for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 15:11:09 -0500 Received: by rv-out-0910.google.com with SMTP id k20so2154822rvb for <6lowpan@lists.ietf.org>; Tue, 11 Dec 2007 12:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=YQ3zDLKKkT1c5jyH+OJVO34KpqPf9bJ/se13kK97sn0=; b=vLwyR81dMbg7MXpC8l5Lwj94sy85BE0pQcPwkaiQsOypgd+YVsCMKD+kakHtW0zsIolTXMsbHfLHRVsJ39F8vkih1In2hkofI14s+fvHIkAwQXh3e/TSJuaz0uJ3zP7ZoEOaigmsyI9BphmMS21+1Y5NCka6MLtLIPhFR0C6eTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fA7vmryQ5muzw4Z902PaGkaSCrLkx0/0xVRr16Jb8d4pbESch02x5i3xm/QnA3OwvcjzdbHwFm2zyC6dKKOijzdzYJ6Nuqz6ScRRfwPyCR52EvYPhjI2jQgbWqxN4t9QvAVAX4dgGq9r1TD0ssk+nhT7BuBCipZC4SUD4I7uBHI= Received: by 10.141.161.6 with SMTP id n6mr2768288rvo.1197403862481; Tue, 11 Dec 2007 12:11:02 -0800 (PST) Received: by 10.140.164.8 with HTTP; Tue, 11 Dec 2007 12:11:02 -0800 (PST) Message-ID: Date: Wed, 12 Dec 2007 05:11:02 +0900 From: "Ki-Hyung Kim" To: "Geoff Mulligan" , Carsten Subject: Re: [6lowpan] Issue of the Week: Charter Finalization In-Reply-To: <1197319616.5697.45.camel@dellx1> MIME-Version: 1.0 References: <1197319616.5697.45.camel@dellx1> X-Spam-Score: 1.2 (+) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 6lowpan <6lowpan@lists.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="===============0410176459==" Errors-To: 6lowpan-bounces@ietf.org --===============0410176459== Content-Type: multipart/alternative; boundary="----=_Part_20942_6849960.1197403862476" ------=_Part_20942_6849960.1197403862476 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Geoff and Carsten, The proposed charter looks quite nice and appropriate to move forward. The comments are in line. On 12/11/07, Geoff Mulligan wrote: > Lowpanners, > > We have had some recent discussion on issues related to network > structure, in particular the use of multicast and the issue of sleeping > nodes. > > Carsten and I don't want to interrupt this discussion, but we would like > to remind everyone that we also have one CRITICAL short term objective: > Getting rechartered. > > The *theme of the week* for the working group is the finalization of the > charter. In particular, the following questions have been raised: > > A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) The timeline looks OK and to be safe to keep. > > B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) > I think this issue could be raised later case by case. > C) Daniel has reminded us that there needs to be a management solution > at some point. We're not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? > Very simple NMP could be described in terms of architecture of 6lowpan. > D) The discussions about multicast have reminded us that 4944 alone > does not provide a solution beyond a single radio range. MANET's > SMF provides one, but presupposes some support from the routing > protocol. The BbR approach reminds me of 802.11, where all > multicast is unicast to the AP which then sends it back into the > wireless network (which might allow a simplified flooding based on > something like RPF). > > E) There were some comments during the meeting that we already were > taking on a sizable amount of work. I'm not sure we want to take > on all of the other points Daniel raised: > > [...] I guess we should consider how to improve the quality of RFC > 4944, especially Global Address HC, TCP operation, ICMPv6 operation > and etc. RFC 4944-bis is one of options. > > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. I think we could consider them if we have volunteers anytime. > > F) Going through each of the documents, the following contributions > have been promised recently: > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > Anybody else? Daniel has also proposed to split 1 into bootstrapping > and ND optimization. There is also the subject of commissioning. > What is the right set of documents, and which ones do (each of) you > want to work on? I would like to contribute the bootstrapping and commissioning ID. > > 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": > During the meeting, Kris Pister indicated that he was interested in > contributing, and Carsten Bormann might be contributing a bit of ROHC > background. > > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > with a network management slant? I would like to contribute on the part of the architecture, including mesh under vs route over, scalability issue (scalable 6lowpan architecture), management mechanism for 6lowpan (very simple NMP), service discovery issue. > > 3a "Routing requirements" (which needs its own milestone entry) has a > draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During > the RL2N BOF, a similar document was proposed as a result of the > RL2N-followup WG to be formed. We need to understand whether the two > documents (the 6lowpan one and the rl2n++ one) are sufficiently > different or whether we simply need to cooperate on one document, > which would then have to include the 6lowpan-specific aspects > including mesh-under. > > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" > might provide a basis, but we need more input, in particular from > implementors of each of these scenarios that we actually want to use > as use cases. I might contribute some use cases of 6lowpan, including the testbed of meteorological sensor networks which integrates 6lowpan with wireless mesh networks, use cases of building management. for instance, we have more than 200 sensor nodes installed on one floor in our office building. It could be extended to the entire building for multi-purposes of building management such as security, energy saving, etc. > > 5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten and Geoff > might provide some input, but can't do this on their own.) > > 6 Implementers' guide: Zach Shelby and Jonathan Hui are interested. > What about the other folks that have built or are building 6LoWPAN > implementations. > > 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about > the other folks that have built or are building 6LoWPAN implementations. > For both implementer's guide and interop guide, I could contribute some part of them, as we have an implementation of 6lowpan and more than 10 reference sites of 6lowpan in Korea. > In order to accelerate rechartering, we should have answers to these > questions/credible sets of contributors to these documents by the end > of this week, so please don't hesitate providing your input. > > Gruesse, Carsten and Geoff > I hope this helps the WG to accelerate the rechartering and move forward. -- Ki-Hyung Kim Founder and CTO of picosNet, Inc. (http://www.picosnet.com) Tel: +82-31-219-2433, Cel: +82-10-4760-2551 ------=_Part_20942_6849960.1197403862476 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Geoff and Carsten,

The proposed charter looks quite nice and appropriate to move forward.
The comments are in line.

On 12/11/07, Geoff Mulligan < geoff-ietf@mulligan.org> wrote:
> Lowpanners,
>
> We have had some recent discussion on issues related to network
> structure, in particular the use of multicast and the issue of sleeping
> nodes.
>
> Carsten and I don't want to interrupt this discussion, but we would like
> to remind everyone that we also have one CRITICAL short term objective:
> Getting rechartered.
>
> The *theme of the week* for the working group is the finalization of the
> charter.  In particular, the following questions have been raised:
>
> A) is the timeline, which was too tight, now too relaxed?  (Obviously,
>   the chairs don't think so, but what do you think?)
 
The timeline looks OK and to be safe to keep.

>
> B) should there be work on a "minimal 6lowpan/IPv6 profile"?  (We had
>   envisioned each of the use cases to explain what protocols are used
>   in implementing that particular use case, not the generation of a
>   unified minimal profile that would apply to all use cases.)
>
 
I think this issue could be raised later case by case. 

> C) Daniel has reminded us that there needs to be a management solution
>   at some point.  We're not sure that simply defining a MIB is the
>   right way to provide this (SNMPv3 on sensor nodes?).  Instead, we
>   could add "management method" to the subjects of the architecture
>   document before actually creating the solution.  Is that the right
>   place?
>
Very simple NMP could be described in terms of architecture of 6lowpan.
 

> D) The discussions about multicast have reminded us that 4944 alone
>   does not provide a solution beyond a single radio range.  MANET's
>   SMF provides one, but presupposes some support from the routing
>   protocol.  The BbR approach reminds me of 802.11, where all
>   multicast is unicast to the AP which then sends it back into the
>   wireless network (which might allow a simplified flooding based on
>   something like RPF).
>
> E) There were some comments during the meeting that we already were
>   taking on a sizable amount of work.  I'm not sure we want to take
>   on all of the other points Daniel raised:
>
>   [...] I guess we should consider how to improve the quality of RFC
>   4944, especially Global Address HC, TCP operation, ICMPv6 operation
>   and etc. RFC 4944-bis is one of options.
>
>   [...] how to dig out *mobility issue* from the proposed charter. I
>   guess some of requirements of mobility for 6lowpan networks is
>   doable for the initial activity at this stage except specific
>   mobility solutions.
I think we could consider them if we have volunteers anytime.
 
>
> F) Going through each of the documents, the following contributions
>   have been promised recently:
>
> 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have
> longstanding contributions from Samita Chakrabarti and Erik Nordmark.
> Anybody else?  Daniel has also proposed to split 1 into bootstrapping
> and ND optimization.  There is also the subject of commissioning.
> What is the right set of documents, and which ones do (each of) you
> want to work on?
I would like to contribute the bootstrapping and commissioning ID.

>
> 2 "Problem Statement for Stateful Header Compression in 6LoWPANs":
> During the meeting, Kris Pister indicated that he was interested in
> contributing, and Carsten Bormann might be contributing a bit of ROHC
> background.
>
> 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff
> Mulligan, and JP Vasseur.  Any other takers?  In particular, somebody
> with a network management slant?
I would like to contribute on the part of the architecture, including mesh under vs route over, scalability issue (scalable 6lowpan architecture), management mechanism for 6lowpan (very simple NMP), service discovery issue.

>
> 3a "Routing requirements" (which needs its own milestone entry) has a
> draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann.  During
> the RL2N BOF, a similar document was proposed as a result of the
> RL2N-followup WG to be formed.  We need to understand whether the two
> documents (the 6lowpan one and the rl2n++ one) are sufficiently
> different or whether we simply need to cooperate on one document,
> which would then have to include the 6lowpan-specific aspects
> including mesh-under.
>
> 4 "Use Cases for 6LoWPAN".  Zach Shelby has indicated his interest.
> Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs"
> might provide a basis, but we need more input, in particular from
> implementors of each of these scenarios that we actually want to use
> as use cases.
I might contribute some use cases of 6lowpan, including the testbed of meteorological sensor networks which integrates 6lowpan with wireless mesh networks, use cases of building management. for instance, we have more than 200 sensor nodes installed on one floor in our office building. It could be extended to the entire building for multi-purposes of building management such as security, energy saving, etc.
 
>
> 5 "6LoWPAN Security Analysis".  Daniel / Anybody?  (Carsten and Geoff
> might provide some input, but can't do this on their own.)
>
> 6 Implementers' guide: Zach Shelby and Jonathan Hui are interested.
> What about the other folks that have built or are building 6LoWPAN
> implementations.
>
> 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about
> the other folks that have built or are building 6LoWPAN implementations.
>
For both implementer's guide and interop guide, I could contribute some part of them, as we have an implementation of 6lowpan and more than 10 reference sites of 6lowpan in Korea.
 
> In order to accelerate rechartering, we should have answers to these
> questions/credible sets of contributors to these documents by the end
> of this week, so please don't hesitate providing your input.
>
> Gruesse, Carsten and Geoff
>
 
 
I hope this helps the WG to accelerate the rechartering and move forward.

--
Ki-Hyung Kim
Founder and CTO of picosNet, Inc. (http://www.picosnet.com)
Tel: +82-31-219-2433, Cel: +82-10-4760-2551
------=_Part_20942_6849960.1197403862476-- --===============0410176459== 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 --===============0410176459==-- From 6lowpan-bounces@ietf.org Tue Dec 11 15:17: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 1J2BYA-0001tb-V9; Tue, 11 Dec 2007 15:17:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2BY9-0001rX-DK for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 15:17:53 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2BY8-0000tq-KE for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 15:17:53 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 89F20A9617; Tue, 11 Dec 2007 12:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-10 required=6.6 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+LrpAwJTAh6; Tue, 11 Dec 2007 12:17:48 -0800 (PST) Received: from [192.168.7.194] (69-12-164-135.sfo.archedrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 271CDA9643; Tue, 11 Dec 2007 12:17:48 -0800 (PST) Message-ID: <475EF06A.20709@archrock.com> Date: Tue, 11 Dec 2007 12:17:46 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Geoff Mulligan Subject: Re: [6lowpan] Issue of the Week: Charter Finalization References: <1197319616.5697.45.camel@dellx1> In-Reply-To: <1197319616.5697.45.camel@dellx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: 6lowpan <6lowpan@lists.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 Overall, the charter looks good to me. Though I do think that some of the items must be more use case driven, as I think that we'll probably see different requirements based on the use cases. So maybe the wording on the charter items should change to reflect that? See comments below: Geoff Mulligan wrote: [...] > The *theme of the week* for the working group is the finalization of the > charter. In particular, the following questions have been raised: > > A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) While we'd all like to see 6LoWPAN move faster, I think the current timeline is realistic and achievable. > B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) Yes. But I do believe that it should be specified case-by-case driven by the application, network architecture, or both. Maybe this should be a part of the use case documents? > C) Daniel has reminded us that there needs to be a management solution > at some point. We're not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? Manageability is important, but it's not clear whether SNMP or something SNMP-like is the right approach. Maybe we should have some work that surveys existing management mechanisms/methodology? [...] > F) Going through each of the documents, the following contributions > have been promised recently: > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > Anybody else? Daniel has also proposed to split 1 into bootstrapping > and ND optimization. There is also the subject of commissioning. > What is the right set of documents, and which ones do (each of) you > want to work on? I'm interested in specifying ND/autoconf for route-over. I know this overlaps with the AUTOCONF WG and I should probably start there. But I do believe that 802.15.4 places some more stringent requirements on the autoconf solution (e.g. 6LoWPAN's mapping of L3 to L2 addresses, extreme resource constraints, etc.) and that we can make 802.15.4 specific optimizations. Do the chairs have any thoughts on this? > 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": > During the meeting, Kris Pister indicated that he was interested in > contributing, and Carsten Bormann might be contributing a bit of ROHC > background. I'm interested in continuing my effort on HC1g and defining 6LoWPAN header compression for route-over configurations. I do believe this may be separate from the solution for mesh-under. > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > with a network management slant? I can help out on the overall doc if help is needed. > 3a "Routing requirements" (which needs its own milestone entry) has a > draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During > the RL2N BOF, a similar document was proposed as a result of the > RL2N-followup WG to be formed. We need to understand whether the two > documents (the 6lowpan one and the rl2n++ one) are sufficiently > different or whether we simply need to cooperate on one document, > which would then have to include the 6lowpan-specific aspects > including mesh-under. Yes, it's unclear to me how the 6LoWPAN and ROLL documents are related and if they will be sufficiently different. I also believe that routing requirements must be use-case driven, so it's unclear to me whether this should be done in a single document, or as part of documents that describe use cases. > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" > might provide a basis, but we need more input, in particular from > implementors of each of these scenarios that we actually want to use > as use cases. Not sure if the intention here is to generate a single Use Case document. I'm seeing a pattern here where decisions may and probably will be largely driven by the use case. This applies to minimal node requirements, routing requirements, etc. Maybe we should generate separate docs for individual use cases that the WG is interested in that lay out each of the requirements? -- Jonathan Hui > 5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten and Geoff > might provide some input, but can't do this on their own.) > > 6 Implementers' guide: Zach Shelby and Jonathan Hui are interested. > What about the other folks that have built or are building 6LoWPAN > implementations. > > 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about > the other folks that have built or are building 6LoWPAN implementations. > > In order to accelerate rechartering, we should have answers to these > questions/credible sets of contributors to these documents by the end > of this week, so please don't hesitate providing your input. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 11 15:47: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 1J2C0K-0004X7-Uv; Tue, 11 Dec 2007 15:47:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2C0J-0004Wy-SA for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 15:46:59 -0500 Received: from xsmtp0.ethz.ch ([82.130.70.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2C0I-0001UV-4x for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 15:46:59 -0500 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 21:46:56 +0100 Received: from styx ([129.132.74.245]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 21:46:56 +0100 Received: by styx (Postfix, from userid 1000) id 56CDE674013; Tue, 11 Dec 2007 21:46:56 +0100 (CET) Date: Tue, 11 Dec 2007 21:46:56 +0100 From: m.harvan@jacobs-university.de To: Geoff Mulligan Subject: Re: [6lowpan] Issue of the week: Charter finalization Message-ID: <20071211204656.GC7071@styx.inf.ethz.ch> References: <20071210204653.GA17027@elstar.local> <1197352286.5697.64.camel@dellx1> MIME-Version: 1.0 In-Reply-To: <1197352286.5697.64.camel@dellx1> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-OriginalArrivalTime: 11 Dec 2007 20:46:56.0514 (UTC) FILETIME=[F7E80E20:01C83C36] X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 6lowpan <6lowpan@lists.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="===============0332078439==" Errors-To: 6lowpan-bounces@ietf.org --===============0332078439== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6zdv2QT/q3FMhpsV" Content-Disposition: inline --6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Dec 10, 2007 at 10:51:26PM -0700, Geoff Mulligan wrote: > Juergen, > I guess that I missed your suggestions on fixes to the RFC? http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00669.html http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00670.html http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00671.html http://www1.ietf.org/mail-archive/web/6lowpan/current/msg00672.html Matus --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHXvdA43LQWDWf0QIRAgByAJ474LnPWckYZ5fpcDiMjZCnLh7xagCghoVG nKRLqIO3auvjPi7OBtAF3j4= =mNr6 -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV-- --===============0332078439== 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 --===============0332078439==-- From 6lowpan-bounces@ietf.org Tue Dec 11 17:18: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 1J2DQe-0001bf-F6; Tue, 11 Dec 2007 17:18:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2DQd-0001bT-8V for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 17:18:15 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2DQb-0003dF-9w for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 17:18:15 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C24A8A186; Tue, 11 Dec 2007 23:18:12 +0100 (CET) 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 29001-06; Tue, 11 Dec 2007 23:18:07 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8BFED865CE; Tue, 11 Dec 2007 23:18:07 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E522E420672; Tue, 11 Dec 2007 23:18:07 +0100 (CET) Date: Tue, 11 Dec 2007 23:18:07 +0100 From: Juergen Schoenwaelder To: Geoff Mulligan Subject: Re: [6lowpan] Issue of the week: Charter finalization Message-ID: <20071211221807.GB18861@elstar.local> References: <20071210204653.GA17027@elstar.local> <1197352286.5697.64.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1197352286.5697.64.camel@dellx1> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Carsten Bormann , 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de 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 Mon, Dec 10, 2007 at 10:51:26PM -0700, Geoff Mulligan wrote: > Juergen, > I guess that I missed your suggestions on fixes to the RFC? The relevant messages were posted in June: Message-ID: <46770339.1070303@jacobs-university.de> Date: Tue, 19 Jun 2007 00:12:09 +0200 From: Matus Harvan Subject: [6lowpan] compressed UDP Length field Message-ID: <46772081.6040207@jacobs-university.de> Date: Tue, 19 Jun 2007 02:17:05 +0200 From: Matus Harvan Subject: [6lowpan] ICMP error messages - ICMP payload Message-ID: <467718A5.8040501@jacobs-university.de> Date: Tue, 19 Jun 2007 01:43:33 +0200 From: Matus Harvan Subject: [6lowpan] fragment reassembly Message-ID: <46771E16.1000502@jacobs-university.de> Date: Tue, 19 Jun 2007 02:06:46 +0200 From: Matus Harvan Subject: [6lowpan] alignment of HC-compressed/inline-carried fields > I like the idea of finding a way to more efficiently transfer SNMP > messages as well as a simpler way to implement SNMP (not a full ASN.1) SNMP never used full ASN.1 - and I am not sure BER encoding is actually a problem. There are implementation techniques to deal with BER data reasonably fast and with a small memory footprint. Most of the overhead in SNMP messages comes from the OIDs if an SNMP message carries multiple varbinds; there have been proposals in the past to perform OID compression - not sure whether some of this would be applicable here. The other probably more important thing is of course again security; SNMPv1 is historic and SNMPv3 with security is much more verbose and computationally expensive (if you enable security). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 11 17:33:04 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 1J2Dey-0001IS-K0; Tue, 11 Dec 2007 17:33:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Dew-0001Gg-Qc for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 17:33:02 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Dev-0004FT-27 for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 17:33:02 -0500 Received: from dnab4222ca.stanford.edu ([171.66.34.202]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1J2Des-0002gf-Np; Tue, 11 Dec 2007 14:33:00 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <154138D0-695D-4FDE-B6CD-CE64501B05A8@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] Issue of the Week: Charter Finalization Date: Tue, 11 Dec 2007 14:32:58 -0800 To: JP Vasseur X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 6bee508a35d8245455fa42c2dd36c733 X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Geoff Mulligan , 6lowpan <6lowpan@lists.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 Dec 11, 2007, at 11:23 AM, JP Vasseur wrote: > Hi Geoff, > > The proposed charter captures very well the discussions that we've > been > having for some time, thanks. > > Minor comments in line, I agree with JP. The routing requirements work item will have some interesting collaborations with ROLL if it forms. But that does not mean 6lowpan should not do it. If anything, ROLL can take an approach from above while 6lowpan can take an approach from below. Overall, I think the charter is in good shape and I support it. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 11 21:14:05 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 1J2H6n-0004Tb-Jl; Tue, 11 Dec 2007 21:14:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2H6m-0004TW-OI for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 21:14:00 -0500 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2H6k-0001J7-Hb for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 21:14:00 -0500 Received: by wa-out-1112.google.com with SMTP id j4so79756wah.1 for <6lowpan@lists.ietf.org>; Tue, 11 Dec 2007 18:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=RdFD9D87hXvBRc3vNH5TKW0OqHxj/0PmGG8l/kkEG28=; b=u3wWr7To4Bl4Lke0Nv0yPWuUq7Btk0ZwnUiAQ1Q3Ts3QXntWV52Se0R9ZpWrvuL70S5SIWtB+ns+QSjOnwoPTmTEIHr1m6Vk1x2KF2oR0fGpyyPfbEzxzuWXMxd/tUaXREvW687XSorf8Tgrzs/NJZXy2On16SrafHsrE0BlG+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E4LGLP1HBss+WgyN6ejysPeVKf6VJYGkzv/jZ5vrMFsYH5465o09q2EM7n21QAN9lRKOcPYu2Y6Z5LHYq2W+cEldqgeljC3m2F8QQ8oTV1IYNVQTQPN1nhtfMuBhBG5fps03IuD3ZEkFuQbYmqXjM5FQuQwKi3f0BPV/OTLbsd0= Received: by 10.142.109.16 with SMTP id h16mr19159wfc.38.1197425637595; Tue, 11 Dec 2007 18:13:57 -0800 (PST) Received: by 10.143.125.6 with HTTP; Tue, 11 Dec 2007 18:13:57 -0800 (PST) Message-ID: <77f1dba80712111813x514be322h113bd0f605439e35@mail.gmail.com> Date: Wed, 12 Dec 2007 11:13:57 +0900 From: "Eunsook \"Eunah\" Kim" To: "Jonathan Hui" Subject: Re: [6lowpan] Issue of the Week: Charter Finalization In-Reply-To: <475EF06A.20709@archrock.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1197319616.5697.45.camel@dellx1> <475EF06A.20709@archrock.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: Geoff Mulligan , 6lowpan <6lowpan@lists.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 Geoff & Carsten, The current proposed rechartering items are well-shaped, but I feel that somehow we restart some old discussion in some part. My comments are inline. On 12/12/07, Jonathan Hui wrote: > > Overall, the charter looks good to me. Though I do think that some of > the items must be more use case driven, as I think that we'll probably > see different requirements based on the use cases. So maybe the wording > on the charter items should change to reflect that? See comments below: > > Geoff Mulligan wrote: > > [...] > > > The *theme of the week* for the working group is the finalization of the > > charter. In particular, the following questions have been raised: > > > > A) is the timeline, which was too tight, now too relaxed? (Obviously, > > the chairs don't think so, but what do you think?) > > While we'd all like to see 6LoWPAN move faster, I think the current > timeline is realistic and achievable. [E] I agreed on it, but when I see the recharter discussion, it kinda push us back to the previous meeting. We had a long discussion on rechartering items until we see the current proposal. I think we have good base documents for current recharter item, so the way we can achieve the timeline is not to restart if we include something or not, but to gather opinion what's our expectation on each items. Then, the current authors and future contributors gather the idea to progress the work. > > > B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had > > envisioned each of the use cases to explain what protocols are used > > in implementing that particular use case, not the generation of a > > unified minimal profile that would apply to all use cases.) > > Yes. But I do believe that it should be specified case-by-case driven by > the application, network architecture, or both. Maybe this should be a > part of the use case documents? > [E] Yes. We had an informal meeting in Vancouver, including JP, Jonathan, Mikko, Dominik and Eunsook to discuss this topic. We discussed how to approach this work by our experience to implement 6lowpan. What we discussed was it's necessary work for implementors, it will be an informational guide to 6lowpan implementors, and will be described case by case (based on configuration, networking, architecture) But, I think in somehow, we mix the current 'use case' in the charter with 'implementation guide'. It surely would be discribed case-by-case, but it's different from the current 'use case' approach, I think. In the current 'use case(scenario)', it shows applicability of 6lowpan with a bit more general view, and more scenario base, which could have similar configuration cases, different data gathering pattern, etc. I totally agree that the current document needs to be touched more implementation information, but I disagree to combine 'profiling cases for implemetation' with 'use case(scenario)' of 6lowpan. It will delay the current work, and we need to spend some time to match the different view on it. > > > [...] > > > F) Going through each of the documents, the following contributions > > have been promised recently: > > > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > > Anybody else? Daniel has also proposed to split 1 into bootstrapping > > and ND optimization. There is also the subject of commissioning. > > What is the right set of documents, and which ones do (each of) you > > want to work on? > > I'm interested in specifying ND/autoconf for route-over. I know this > overlaps with the AUTOCONF WG and I should probably start there. But I > do believe that 802.15.4 places some more stringent requirements on the > autoconf solution (e.g. 6LoWPAN's mapping of L3 to L2 addresses, extreme > resource constraints, etc.) and that we can make 802.15.4 specific > optimizations. Do the chairs have any thoughts on this? [E] I'm also interested in ND, and I also think we can look at autoconf wg work first. > > > 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": > > During the meeting, Kris Pister indicated that he was interested in > > contributing, and Carsten Bormann might be contributing a bit of ROHC > > background. > > I'm interested in continuing my effort on HC1g and defining 6LoWPAN > header compression for route-over configurations. I do believe this may > be separate from the solution for mesh-under. no arguement at all. :) > > > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > > with a network management slant? > > I can help out on the overall doc if help is needed. > > > 3a "Routing requirements" (which needs its own milestone entry) has a > > draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During > > the RL2N BOF, a similar document was proposed as a result of the > > RL2N-followup WG to be formed. We need to understand whether the two > > documents (the 6lowpan one and the rl2n++ one) are sufficiently > > different or whether we simply need to cooperate on one document, > > which would then have to include the 6lowpan-specific aspects > > including mesh-under. > > Yes, it's unclear to me how the 6LoWPAN and ROLL documents are related > and if they will be sufficiently different. I also believe that routing > requirements must be use-case driven, so it's unclear to me whether this > should be done in a single document, or as part of documents that > describe use cases. > [E] If ROLL is in clear status, we can discuss how we will progress this work together. But, I don't think we should take out this work from our charter now. I clearly see we have both common and different parts together. It doesn't mean that we don't need to do the work due to the common part. We, 6lowpaners should make our requirements and give the input to ROLL. Actually, I partially agree that we need to describe the requirements in use-case driven. Due to 6lowpan node characteristics, we have very general 6lowpan requirements, and some part of requirements can be different by use-case (not scenario, but more likely networking case). We can enhance the current documents to specify more 6lowpan general req, and put chapter to point out req. for different neworking cases. > > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. > > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" > > might provide a basis, but we need more input, in particular from > > implementors of each of these scenarios that we actually want to use > > as use cases. > > Not sure if the intention here is to generate a single Use Case > document. I'm seeing a pattern here where decisions may and probably > will be largely driven by the use case. This applies to minimal node > requirements, routing requirements, etc. Maybe we should generate > separate docs for individual use cases that the WG is interested in that > lay out each of the requirements? > [E] In my view, here 'use case' is a guideline to show 6lowpan's applicability. Based on each application scenario, it should contain deployment cases, topology, high-level technical characteristics for each scenario, implementation perspective guide to deploy, etc. As I mentioned in the above, I think we need to enhace the current doc to collect more industries' input. But, again, this is not an specific profiling or so. It should be more general picture for 6lowpan applicatability, IMO. > > 5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten and Geoff > > might provide some input, but can't do this on their own.) > > > > 6 Implementers' guide: Zach Shelby and Jonathan Hui are interested. > > What about the other folks that have built or are building 6LoWPAN > > implementations. > > [E] If you mention profiling here. I already said my opinion in the above that we, some 6lowpaners already volunteered, and I'm one of them. Although you say different thing, I think implementer's guide is always useful. > > 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about > > the other folks that have built or are building 6LoWPAN implementations. > > [E] In the informal profiling meeting, we exchanged our thought on having an event of interoperability test. :) It would be good to have a doc for it. :) Thanks chairs for the new charter, and I hope we have discussion to progress the works in the new charter item now. - Eunsook > > In order to accelerate rechartering, we should have answers to these > > questions/credible sets of contributors to these documents by the end > > of this week, so please don't hesitate providing your input. > > _______________________________________________ > 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 Tue Dec 11 21:22: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 1J2HFJ-0007AO-SF; Tue, 11 Dec 2007 21:22:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2HFI-0007AJ-VY for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 21:22:48 -0500 Received: from hs-out-0708.google.com ([64.233.178.245] helo=hs-out-2122.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2HFI-0001UF-K7 for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 21:22:48 -0500 Received: by hs-out-2122.google.com with SMTP id n78so52191hsc.9 for <6lowpan@lists.ietf.org>; Tue, 11 Dec 2007 18:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=t/dK6iClgY02zAr/wLqtGkDQpl79LXst5gMyoui1thg=; b=BwzXHPLUJ4ARHkjRHkstE3um+l/AAuWtctwmnRINrDQBrU9r0jBF6OW71Fa5/Jw1y72qW+WZVLMmzvoxq87Hdwi2CVceX98/EKPMzTpa/ag7TxbX5qbIQtQhTH/ECuv31tfqb6w1kWRcURve4I+QOruGuUC6cwTSusse7sNmzqg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sKnYZsdQQZcku2KySsfIDs5IgqRc0RJfBHtxebLUXXj9aItSw7+9X1dQ1FO4Xx4athUp296Vr+eKgL9Y9hKOL6DVRov2FXrEkCQRmAezYibI2gXap0zl7UzuL11mRZrL2mcPmXxUW67FU5YkhX0Lf4wqm8aY/7jYW7EE5pmnKkg= Received: by 10.142.49.4 with SMTP id w4mr16654wfw.167.1197426167101; Tue, 11 Dec 2007 18:22:47 -0800 (PST) Received: by 10.143.125.6 with HTTP; Tue, 11 Dec 2007 18:22:47 -0800 (PST) Message-ID: <77f1dba80712111822o6eda0bfo57527ad5c1084c2@mail.gmail.com> Date: Wed, 12 Dec 2007 11:22:47 +0900 From: "Eunsook \"Eunah\" Kim" To: "Pascal Thubert (pthubert)" Subject: Re: [6lowpan] Charter proposal In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04E9B502@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7892795E1A87F04CADFCCF41FADD00FC04E9B502@xmb-ams-337.emea.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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, Carsten and Pascal, I also think the current proposed charter is in good shape. > [..] > We also need to understand which group is in charge of the LoWPAN node re= quirements for IPv6. If that's 6LoWPAN, then I do believe we should have a = charter item for it. > Pascal, we had a good informal meeting with a few volunteer, from your initiation. I think we can work on it, ask 6lowpaners' feedback and comments, and if it's the right way to bring to other WG, we can do it after 6lowpaners' feedback. The important thing is that many 6lowpan implementors share the necessary of the work. Of course, it would be more than great if we can officially charter on the item. -eunsook > To answer Carsten's question, I'm willing to help on work item 1 "6LoWPAN= Bootstrapping and 6LoWPAN IPv6 ND Optimizations". I believe it can be stab= le by end of '08 if a number of choices are made to the simpler. I'm also w= illing to start some work on fragment recovery if that can be added to the = charter. > > Pascal > > > >-----Original Message----- > >From: Carsten Bormann [mailto:cabo@tzi.org] > >Sent: jeudi 6 d=E9cembre 2007 20:08 > >To: 6lowpan > >Cc: Carsten Bormann > >Subject: [6lowpan] Charter proposal > > > >Lowpanners, > > > >Geoff and I have updated the charter proposal based on Marks > >input and yesterday's discussion. > >Now would be a good time for comments, in particular also on > >the timelines we are promising. > >Separately, we would like to know which of the items you are > >interested in contributing to -- please volunteer now. > > > >Gruesse, Carsten > > > > > > _______________________________________________ > 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 Tue Dec 11 21:45:07 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 1J2Hat-0005ux-H0; Tue, 11 Dec 2007 21:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Has-0005mo-9Y for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 21:45:06 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Haq-0001yN-3J for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 21:45:06 -0500 Received: by nz-out-0506.google.com with SMTP id i28so43106nzi.31 for <6lowpan@lists.ietf.org>; Tue, 11 Dec 2007 18:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xxygmyIKTQueKHRO/bqvRBb3hs+Pw7ZZQ3C36vYZpFM=; b=q8xFx1ub/+PYPWuK57f3t0/26S04x1RGOLm6jAlHujTp1PW0oQ/AxydfYrd7N4zearVeCZHOYxOcxessEFZ9xPnkBx88qvDsrb98HQQXqmeq8ZB/ux0iggbH7Gwl6pC/3CklhTIjJbREgu1qqQbLcclXlV/kbVQjS87W0z0QQu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uozvcCDxlp2GIhydSd0MtQCsmQAAxEW23oqedsI/nLMRIk85pbgwV+EAPkb68CBJgZWqfIeWtn7ZSU8Fd4KPW12/mu8CpshVS8Th/Rk41mcHoEeOVewcxYhZnZgYUUeRwdR3tPn1/G6Iyfc4avEzVsOuCSEb2wTLg/krIUJhP+I= Received: by 10.142.143.7 with SMTP id q7mr24331wfd.3.1197427503176; Tue, 11 Dec 2007 18:45:03 -0800 (PST) Received: by 10.142.147.18 with HTTP; Tue, 11 Dec 2007 18:45:03 -0800 (PST) Message-ID: <2a3692de0712111845p6bd99ef9teac3b6c11e53c06f@mail.gmail.com> Date: Wed, 12 Dec 2007 11:45:03 +0900 From: "Dominik Kaspar" To: "Carsten Bormann" Subject: Re: [6lowpan] Charter proposal In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 6lowpan <6lowpan@lists.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 Hello, [Routing Requirements] As far as I remember, at the IETF-69 we have made the decision to formulate the 6lowpan-specific routing requirements and feed them into a hopefully soon existing ROLL working group. Also in IETF-70, everyone seemed to agree that this is the way to go, so I don't know why suddenly scepsis is raised again. Having 6lowpan based on IEEE 802.15.4, which differentiates between different device types/roles, or the assumption that 6lowpans are not transit networks, are only two examples of what creates sufficient difference to the routing requirement drafts in ROLL. [6lowpan/IPv6 Profiling] It has been suggested to merge a minimal 6lowpan/IPv6 profile into the "Use Cases for 6lowpan" item. In my opinion, the timeline for the "Use Cases" document is already set quite generously, while I estimate the work needed for defining such a minimal profile to be rather extensive... Also, topicwise the two items are not well matched. The "Use Cases" documents is aimed to provide a high-level application overview, while a profile document would give very low-level information and would fit much better into a "LoWPAN node requirements for IPv6" document that Pascal has suggested (please correct me if I misunderstood). Best regards, Dominik On 12/7/07, Carsten Bormann wrote: > Lowpanners, > > Geoff and I have updated the charter proposal based on Marks input and > yesterday's discussion. > Now would be a good time for comments, in particular also on the > timelines we are promising. > Separately, we would like to know which of the items you are > interested in contributing to -- please volunteer now. > > Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Dec 11 21:53: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 1J2HjC-0007N9-LD; Tue, 11 Dec 2007 21:53:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2HjB-0007Aq-LW for 6lowpan@ietf.org; Tue, 11 Dec 2007 21:53:41 -0500 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 1J2Hj8-0002Cq-NR for 6lowpan@ietf.org; Tue, 11 Dec 2007 21:53:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [6lowpan] Issue of the week: Charter finalization Date: Tue, 11 Dec 2007 18:53:40 -0800 Message-ID: <3D8BC6C339A9894C9955EF58D3722D65015E56FD@dust-exch-02.dusthq.dust-inc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [6lowpan] Issue of the week: Charter finalization Thread-Index: Acg8ajMUZU8l+XWURJ2gWGJ+no9yjw== From: "Chol Kang" To: , X-Spam-Score: 3.0 (+++) X-Scan-Signature: 9b2e2cf232e9b58e6b44296eedf75198 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: , Content-Type: multipart/mixed; boundary="===============1286819787==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1286819787== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83C6A.31D8C44F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83C6A.31D8C44F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Geoff and Carsten, I am also interested in contributing to: 7. Interop Guide. =20 Regards, =20 Chol Su Kang =20 =20 >-----Original Message----- >From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org] >Sent: lundi 10 d=E9cembre 2007 21:47 >To: 6lowpan >Subject: [6lowpan] Issue of the Week: Charter Finalization >=20 >Lowpanners, >=20 >We have had some recent discussion on issues related to network=20 >structure, in particular the use of multicast and the issue of sleeping = >nodes. >=20 >Carsten and I don't want to interrupt this discussion, but we would=20 >like to remind everyone that we also have one CRITICAL short term=20 >objective: >Getting rechartered. >=20 >The *theme of the week* for the working group is the finalization of=20 >the charter. In particular, the following questions have been raised: >=20 >A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) >=20 >B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) >=20 >C) Daniel has reminded us that there needs to be a management solution > at some point. We're not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? >=20 >D) The discussions about multicast have reminded us that 4944 alone > does not provide a solution beyond a single radio range. MANET's > SMF provides one, but presupposes some support from the routing > protocol. The BbR approach reminds me of 802.11, where all > multicast is unicast to the AP which then sends it back into the > wireless network (which might allow a simplified flooding based on > something like RPF). >=20 >E) There were some comments during the meeting that we already were > taking on a sizable amount of work. I'm not sure we want to take > on all of the other points Daniel raised: >=20 > [...] I guess we should consider how to improve the quality of RFC > 4944, especially Global Address HC, TCP operation, ICMPv6 operation > and etc. RFC 4944-bis is one of options. >=20 > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. >=20 >F) Going through each of the documents, the following contributions > have been promised recently: >=20 >1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations":=20 >We have longstanding contributions from Samita Chakrabarti and Erik=20 >Nordmark. >Anybody else? Daniel has also proposed to split 1 into bootstrapping=20 >and ND optimization. There is also the subject of commissioning. >What is the right set of documents, and which ones do (each >of) you want to work on? >=20 >2 "Problem Statement for Stateful Header Compression in 6LoWPANs": >During the meeting, Kris Pister indicated that he was interested in=20 >contributing, and Carsten Bormann might be contributing a bit of ROHC=20 >background. >=20 >3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff=20 >Mulligan, and JP Vasseur. Any other takers? In particular, somebody=20 >with a network management slant? >=20 >3a "Routing requirements" (which needs its own milestone >entry) has a draft from Dominik Kaspar, Eunsook Kim, and Carsten=20 >Bormann. During the RL2N BOF, a similar document was proposed as a=20 >result of the RL2N-followup WG to be formed. We need to understand=20 >whether the two documents (the 6lowpan one and the rl2n++ one) are=20 >sufficiently different or whether we simply need to cooperate on one=20 >document, which would then have to include the 6lowpan-specific aspects = >including mesh-under. >=20 >4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. >Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" >might provide a basis, but we need more input, in particular from=20 >implementors of each of these scenarios that we actually want to use as = >use cases. >=20 >5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten and Geoff=20 >might provide some input, but can't do this on their own.) >=20 >6 Implementers' guide: Zach Shelby and Jonathan Hui are interested. >What about the other folks that have built or are building 6LoWPAN=20 >implementations. >=20 >7 Interop guide: Zach Shelby and Jonathan Hui are interested.=20 >What about the other folks that have built or are building 6LoWPAN=20 >implementations. >=20 >In order to accelerate rechartering, we should have answers to these=20 >questions/credible sets of contributors to these documents by the end=20 >of this week, so please don't hesitate providing your input. >=20 >Gruesse, Carsten and Geoff >=20 >=20 >=20 >=20 >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www1.ietf.org/mailman/listinfo/6lowpan >=20 =20 =20 =20 ------_=_NextPart_001_01C83C6A.31D8C44F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Geoff and = Carsten,

I am also = interested in contributing to:

=A0=A0=A0=A0=A0 7. = Interop Guide.

 

Regards,

 

Chol Su = Kang

 

 

>-----Original Message-----

>From: Geoff = Mulligan [mailto:geoff-ietf@mulligan.org]

>Sent: lundi 10 = d=E9cembre 2007 21:47

>To: = 6lowpan

>Subject: = [6lowpan] Issue of the Week: Charter Finalization

> 

>Lowpanners,

> 

>We have had = some recent discussion on issues related to network

>structure, in = particular the use of multicast and the issue of sleeping =

>nodes.

> 

>Carsten and I = don't want to interrupt this discussion, but we would

>like to remind = everyone that we also have one CRITICAL short term

>objective:

>Getting = rechartered.

> 

>The *theme of = the week* for the working group is the finalization of =

>the charter.=A0 = In particular, the following questions have been = raised:

> 

>A) is the = timeline, which was too tight, now too relaxed?=A0 = (Obviously,

>=A0=A0 the = chairs don't think so, but what do you think?)

> 

>B) should there = be work on a "minimal 6lowpan/IPv6 profile"?=A0 (We = had

>=A0=A0 = envisioned each of the use cases to explain what protocols are = used

>=A0=A0 in = implementing that particular use case, not the generation of = a

>=A0=A0 unified = minimal profile that would apply to all use cases.)

> 

>C) Daniel has = reminded us that there needs to be a management = solution

>=A0=A0 at some = point.=A0 We're not sure that simply defining a MIB is the

>=A0=A0 right = way to provide this (SNMPv3 on sensor nodes?).=A0 Instead, = we

>=A0=A0 could = add "management method" to the subjects of the = architecture

>=A0=A0 document = before actually creating the solution.=A0 Is that the = right

>=A0=A0 = place?

> 

>D) The = discussions about multicast have reminded us that 4944 alone

>=A0=A0 does not = provide a solution beyond a single radio range.=A0 = MANET's

>=A0=A0 SMF = provides one, but presupposes some support from the routing

>=A0=A0 = protocol.=A0 The BbR approach reminds me of 802.11, where all

>=A0=A0 = multicast is unicast to the AP which then sends it back into the

>=A0=A0 wireless = network (which might allow a simplified flooding based on

>=A0=A0 = something like RPF).

> 

>E) There were = some comments during the meeting that we already = were

>=A0=A0 taking = on a sizable amount of work.=A0 I'm not sure we want to = take

>=A0=A0 on all = of the other points Daniel raised:

> 

>=A0=A0 [...] I = guess we should consider how to improve the quality of = RFC

>=A0=A0 4944, = especially Global Address HC, TCP operation, ICMPv6 = operation

>=A0=A0 and etc. = RFC 4944-bis is one of options.

> 

>=A0=A0 [...] = how to dig out *mobility issue* from the proposed charter. = I

>=A0=A0 guess = some of requirements of mobility for 6lowpan networks = is

>=A0=A0 doable = for the initial activity at this stage except = specific

>=A0=A0 mobility = solutions.

> 

>F) Going = through each of the documents, the following contributions

>=A0=A0 have = been promised recently:

> 

>1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": =

>We have = longstanding contributions from Samita Chakrabarti and Erik =

>Nordmark.

>Anybody = else?=A0 Daniel has also proposed to split 1 into bootstrapping =

>and ND = optimization.=A0 There is also the subject of commissioning.

>What is the = right set of documents, and which ones do (each

>of) you want to = work on?

> 

>2 "Problem Statement for Stateful Header Compression in = 6LoWPANs":

>During the = meeting, Kris Pister indicated that he was interested in

>contributing, = and Carsten Bormann might be contributing a bit of ROHC =

>background.

> 

>3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff =

>Mulligan, and = JP Vasseur.=A0 Any other takers?=A0 In particular, somebody =

>with a network management slant?

> 

>3a = "Routing requirements" (which needs its own = milestone

>entry) has a = draft from Dominik Kaspar, Eunsook Kim, and Carsten

>Bormann.=A0 = During the RL2N BOF, a similar document was proposed as a =

>result of the RL2N-followup WG to be formed.=A0 We need to understand =

>whether the two documents (the 6lowpan one and the rl2n++ one) are =

>sufficiently = different or whether we simply need to cooperate on one =

>document, which = would then have to include the 6lowpan-specific aspects =

>including = mesh-under.

> 

>4 "Use = Cases for 6LoWPAN".=A0 Zach Shelby has indicated his = interest.

>Eunsook Kim et = al.'s "Design and Application Spaces for = 6LoWPANs"

>might provide a = basis, but we need more input, in particular from

>implementors of = each of these scenarios that we actually want to use as =

>use = cases.

> 

>5 "6LoWPAN = Security Analysis".=A0 Daniel / Anybody?=A0 (Carsten and Geoff =

>might provide = some input, but can't do this on their own.)

> 

>6 Implementers' = guide: Zach Shelby and Jonathan Hui are = interested.

>What about the = other folks that have built or are building 6LoWPAN =

>implementations.

> 

>7 Interop = guide: Zach Shelby and Jonathan Hui are interested.

>What about the = other folks that have built or are building 6LoWPAN =

>implementations.

> 

>In order to = accelerate rechartering, we should have answers to these =

>questions/credible sets of contributors to these documents by the end =

>of this week, = so please don't hesitate providing your input.

> 

>Gruesse, = Carsten and Geoff

> 

> 

> 

> 

>_______________________________________________

>6lowpan mailing = list

>6lowpan@ietf.org

>https://www1.ietf= .org/mailman/listinfo/6lowpan

> 

 

 

 

------_=_NextPart_001_01C83C6A.31D8C44F-- --===============1286819787== 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 --===============1286819787==-- From 6lowpan-bounces@ietf.org Tue Dec 11 23:21:14 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 1J2J5t-0001vo-Nt; Tue, 11 Dec 2007 23:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2J5s-0001vb-Oj for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 23:21:12 -0500 Received: from nlpi029.sbcis.sbc.com ([207.115.36.58] helo=nlpi029.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2J5r-0003oy-4t for 6lowpan@lists.ietf.org; Tue, 11 Dec 2007 23:21:12 -0500 X-ORBL: [71.131.220.243] Received: from [192.168.1.50] (adsl-71-131-220-243.dsl.sntc01.pacbell.net [71.131.220.243]) by nlpi029.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id lBC4L6Ka031069; Tue, 11 Dec 2007 22:21:06 -0600 Message-Id: <34C76911-8769-4D4F-8E1A-F006019211BC@Sun.COM> From: "Pete St. Pierre" To: Carsten Bormann , Geoff Mulligan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [6lowpan] Issue of the week: Charter finalization Date: Tue, 11 Dec 2007 20:21:06 -0800 References: X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 6lowpan <6lowpan@lists.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 Carsten, Geoff, et. al., Thanks for all your hard work in getting the draft charter finalized for WG discussion last week in Vancouver. I think it did a very good job of incorporating the many opinions discussed on the list in the last few months. While there were always be room to massage details, I'm definitely in favor of adopting the work items as described and look forward to contributing to some of the deliverables. Additional comments below. On Dec 10, 2007, at 11:45 AM, Carsten Bormann wrote: > A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) I think the timelines are reasonable. I believe some of the items depend on more empirical data which can only be gained from deployment experience. The scenario descriptions help here, but I think we need much more depth in the descriptions. > B) should there be work on a "minimal 6lowpan/IPv6 profile"? (I had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) I think there is value (if a useful unified set can be found) to a single profile. We're pushing for interoperability and there's nothing more frustrating that saying, "yes, it's 6lowpan, but not that profile". > C) Daniel has reminded us that there needs to be a management solution > at some point. I'm not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? > > D) The discussions about multicast have reminded us that 4944 alone > does not provide a solution beyond a single radio range. MANET's > SMF provides one, but presupposes some support from the routing > protocol. The BbR approach reminds me of 802.11, where all > multicast is unicast to the AP which then sends it back into the > wireless network (which might allow a simplified flooding based on > something like RPF). > > E) There were some comments during the meeting that we already were > taking on a sizable amount of work. I'm not sure we want to take > on all of the other points Daniel raised: For the current charter, I think we've set a good course. I think there is merit to Daniel's comments, but I think we need to focus on the initial items. If the priority changes or we find ourselves incredibly efficient, we can always propose amending the charter. > > > [...] I guess we should consider how to improve the quality of RFC > 4944, especially Global Address HC, TCP operation, ICMPv6 operation > and etc. RFC 4944-bis is one of options. > > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. > > F) Going through each of the documents, the following contributions > have been promised recently: > < -- document list clipped to save electrons -- > Given that I'm in the midst of a Java implementation of IPv6/6lowpan I'm really looking forward to contributing to the Implementer's guide and interoperability drafts. I cut my networking teeth in the SNMP space and wouldn't refreshing my cranial cache and pitching in on the architecture spec if my time allows. Implementation and interoperability are definitely my main concerns at this time. ...Pete -- Pete St. Pierre Sun Microsystems, Inc http://www.sunspotworld.com > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Dec 12 03:04: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 1J2MZe-0003re-Re; Wed, 12 Dec 2007 03:04:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2MZc-0003rY-Ue for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 03:04:08 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2MZb-0008Ny-Mr for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 03:04:08 -0500 X-IronPort-AV: E=Sophos;i="4.24,155,1196636400"; d="scan'208";a="650269" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2007 09:04:02 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBC846Pd015229; Wed, 12 Dec 2007 09:04:06 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBC846mc013913; Wed, 12 Dec 2007 08:04:06 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 09:04:06 +0100 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] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Date: Wed, 12 Dec 2007 09:03:50 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04E9B616@xmb-ams-337.emea.cisco.com> In-Reply-To: <0CBB6939-45FC-4354-9120-445D538461BE@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Thread-Index: Acg4+/tNRVrHNBfZQ3yLPa5L+wv7kQDkgaSA From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 12 Dec 2007 08:04:06.0156 (UTC) FILETIME=[910F6CC0:01C83C95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5712; t=1197446646; x=1198310646; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20ND=20optimization=20for=20s ensor=20nodes=20(power=20saving/=09Idle/Sleep=20mode) |Sender:=20; bh=zHQ2b6MNkcyn+RSkNgsQv8Xzh2JsYaDZTkhUhnGIbBs=; b=bf+CJP/WMK1YwATgth89k7gSITQGjAchZqPydVvexUe/lI5IQdEFESoqpc TyT1EGAwHT08JVs/67gUSg7FcrcO2o8WRUlAs6OYaapoO2VlcPEKAewVuEq1 /eTSOg6R1E; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: 6lowpan <6lowpan@lists.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 Philip Thanks a bunch for your answers, and sorry for being delayed; please see inline. >> So my question is: Should we take as granted that ND on the LoWPAN=20 >> requires multicast? Maybe the white board model based on unicast is=20 >> enough, in which case we get rid of a very difficult dependency. >> Considering that there is a need for a router that=20 >understands 6LowPAN=20 >> to connect the LoWPAN to the Internet, that router is the natural=20 >> location for a white board. > >The issue here is whether sleep schedules are visible to the=20 >network layer, or whether it observes longer latency. MACs=20 >which do not support a "cry out" approach, e.g., TDMA with no=20 >broadcast slot, typically emulate broadcast through unicast to=20 >each neighbor for which a slot exists. The network layer is=20 >not made aware of this, as the TDMA schedule will by necessity=20 >constrain the set of neighbors that you have a "link" to. Or=20 >are you assuming mesh under? Yes; I have in mind the following requirements: - One link throughout (same subnet) - potentially multiple radio hops (mesh-under) - potentially a high speed federating backbone (proxy ND) - one fits-it-all ND solution for motes (no "profile" for ND) And the multiple radio hops are mesh under in this case. If we used ROLL all the time then we could assume a model close to the 802.11 infrastructure mode and simplify the problem quite a bit. But there are already mesh-under approaches that are well-advanced and using 6LoWPAN so we have to support them as well. The white board is a clean way to decouple ND from the multicast problem. Note: I'm not 100% sure that we need to solve the multicast problem at network level in the mesh-under LoWPAN anyway. For the specific needs such as upload trigger or software image upgrade, application level support could be good enough, for instance using RFC 2090 to optimize a download. Remember that we have this minimum LoWPAN node IPv6 support to define. If we can avoid multicast stuff like MLD snooping we simplify that support quite a bit.=20 > >> So the concept of backbone router is this: cry out loud on the high=20 >> speed backbone that federates LoWPANs, and white board on=20 >the LoWPAN,=20 >> and ND proxying to federate the whole thing. The backbone router=20 >> implements ND proxying in a fashion that is compatible with=20 >mobile IP=20 >> so one day, sensors with a global address can move away and stay=20 >> virtually there. > >I guess I don't quite understand why you think the whiteboard=20 >approach is necessary. Can you describe a use case where "cry out" =20 >doesn't work? The "nodes are off" case seems very suspect to=20 >me: if nodes are *really* off, e.g., for long,=20 >application-level periods, you would not expect multicast to=20 >reach them. Instead, you would depend on higher-layer=20 >protocols (e.g., SRM) for improving reliability. If nodes are=20 >off for very short, link-layer periods, the MAC should take=20 >care of this. Networks in deployment today tend to solely use=20 >the latter approach, as it's quite sufficient. > I'm arguing that we do not need multicast for the specific mission of ND over LoWPAN and that the white board model saves energy and time even if we had mesh level multicast support. You need to go through Samita's draft to see how ND uses multicast and the issues and costs that are associated to that. I'm not arguing that multicast can not be done. I'm not convinced it should be done because I've not seen the requirement docs that prove that a generic network service is required in the mesh-under space at least for the applications that are currently envisioned.=20 Finally I'm making a difference between multicast and broadcast. If multicast is actually implemented over a mac level broadcast, that makes it completely inefficient for the mission at hand (NS, DAD, etc...). OTOH, if we have mesh-under multicast routing, we save a lot of bandwidth and latency, and the flows start to compare with white board, but we add states everywhere for mcast routing we're still not as good anyway.=20 Neither way achieves ND flows faster than white board. White board enables instant response to DAD within a LoWPAN. Backbone router enables instant response over the transit even if the node is sleeping. The only trouble with white board is that it's not fully distributed P2P. Maybe that's acceptable WRT the benefits in the LoWPAN case. > It might be the best approach for performance reasons, but=20 >it may not be. The fact that such a tradeoff might depend on=20 >the actual media access approach used suggests to me that this=20 >is something e > >> >> In the meantime, a link local address is enough to connect=20 >to any node=20 >> in the network federated by backbone routers, > >So this assumes mesh under? Does. That's the model for WiHART and ISA 100.11a. That model is here to stay, even if the brighter future is ROLL. I'd concentrate the multicast routing effort in ROLL, reusing well known techniques, and keep mesh-under simple enough for the missions that it is currently designed for. > >> and a mote can move from a >> backbone router to another within the federated network without=20 >> renumbering. > >This is definitely a desirable property. > Yes, the requirement comes from ISA. They want 10K nodes in a single network. They want a link local address to be valid throughout, and transparent mobility: the network is thus a single link, and the BbR is designed with a mobility support that inherits from RFC 3775 - with slight differences. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Dec 12 12:07:58 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 1J2V3t-0008Jd-Se; Wed, 12 Dec 2007 12:07:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2V3s-0008J2-0v for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 12:07:56 -0500 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2V3p-0002X1-LL for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 12:07:55 -0500 Received: from [127.0.0.1] (thinkpad.saloits.com [192.168.255.98]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id lBCH7Q3H047851 for <6lowpan@lists.ietf.org>; Wed, 12 Dec 2007 11:07:42 -0600 (CST) (envelope-from salo@saloits.com) Message-ID: <47601545.7090402@saloits.com> Date: Wed, 12 Dec 2007 11:07:17 -0600 From: "Timothy J. Salo" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <1197065234.6356.42.camel@dellx1> In-Reply-To: <1197065234.6356.42.camel@dellx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 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 Geoff Mulligan wrote: > Tim, > I think that you have some misunderstandings. Undoubtedly. However, this broad claim about my lack of omniscience doesn't appear to be applicable to the issue that my e-mail raises. > On Thu, 2007-12-06 at 16:10 -0600, Timothy J. Salo wrote: >> Samita Chakrabarti wrote: >>> ... That way, periodic RA will not wake up >>> all the nodes in the 6lowpan. ... >> To the best of my knowledge, 802.15.4 implementations power-down >> the radio when the system sleeps. As such, a broadcast packet >> does not wake a sleeping 802.15.4 node. Rather, the packet >> is simply never received by the sleeping node. >> > This is not true. A node that sleeps can receive broadcast packets. > > - If the broadcast packet is transmitted on some schedule then the > sleeping node can wake up on that schedule and receive the packet. > - If the broadcast packet is transmitted with some sort of long > preamble then the sleeping node can wake up on it's own schedule, over > hear the preamble and stay awake to receive the packet. > - If the broadcast packet is transmitted multiple times the sleeping > node can wake up during one of these transmissions and receive the > packet. All you have said is that a sleeping node can receive if it isn't sleeping. I don't think that this sort of "Black is white, (as long as it changes color)" answer does much to advance the discussion at hand. By the way, you missed the most interesting solution to this problem, namely the "indirect transmission" mechanism specified in the 802.15.4 specification. See, for example, section 7.5.6.3 of the 802.15.4-2006 specification. Note that 802.15.4 also defines "macTransactionPersistenceTime", a parameter which specifies the maximum time that a coordinator must hold onto a packet waiting for an RFD to wake. (Also, I think 802.15.4 specifies a minimum queue length of one!) These schemes have several problems, some of them serious: o They don't interoperate. Again, is system-level interoperability one of our objectives? If it isn't, I suggest we simply say so. o They all require a fair amount of energy. In particular, the second approach burns a lot of energy on the transmit side (as well as burns channel bandwidth) waiting for all of the receive nodes to wake. Plus, the unlucky receive nodes that wake early have to stay awake to receive the whole preamble. And, this scheme pretty much requires that all nodes wake pretty regularly. For most processors, simply waking is a time- and energy-consuming task. Yes, some newer microprocessors require less time and energy to wake. But, do we want to hardwire that assumption into 6lowpan? o All of these schemes cause multicast to exhibit a latency that is nontrivial and not necessarily bounded. Again, it seems to me that we need to say _something_ about the expected behavior of multicast in 6lowpan environments. Is there a bound on latency (which of course puts an upper bound on how long nodes can sleep, and therefore how long they can live)? > This is much like receiving any packet, not just broadcast packets. > >> If my understanding about this behavior is incorrect, someone >> please correct me. I have been meaning to check and see what >> the spec says about this, but haven't yet... > > There is nothing in the spec on this. As far as I know, there are no > 15.4 radios that wake on some sort of reception. Precisely. My point is that multicast is different in 802.16 networks (which I understand have a wake-from-idle capability) and 802.15.4 networks (which don't). I don't think that we should simply assume that the 16ng approach to using multicast is necessarily directly applicable to 6lowpan. I am suggesting that we actually think about the issue. >> Given that the response to broadcast packets differs in 802.16 >> networks (where an idle node wakes to process the packet) and >> 802.15.4 networks (where a sleeping node is never even aware >> of the packet), different solutions are probably required. >> >> To reiterate what I have said before, I believe that we must >> explicitly specify the behavior we expect of multicast in >> 6lowpan networks that contain sleeping nodes. > > No we don't. I continue to disagree. For example, is there no bound on how long multicast may take? Is there an expectation of some level of reliably reaching every node in the network? The behavior of multicast in 6lowpan networks _will_ be different than with traditional media (e.g., latency, reliability, cost). It would seem prudent to at least warn application and protocol developers about this. >> In particular, >> does multicast mean "received by the potentially very small >> percentage of the nodes that aren't currently sleeping" or might >> it mean "received by every node after they wake up [whenever >> day that might be]"? >> After we specify the behavior of multicast, >> then we can then try to figure out whether we can actually >> implement that behavior in a useful way. >> >> In the interim, I suggest a moratorium on simply assuming that >> multicast is a potential solution to any of the challenges >> we face (e.g., duplicate address detection, router announcements, >> neighbor discovery, ...) > > NO. Battery-powered nodes have a fixed amount of energy. They can spend that energy on infrastructure or overhead activities (like waking up to listen for repetitive RA multicasts) or they can spend that energy transmitting useful application information. I think 6lowpan should minimize the energy cost of simply belonging to a 6lowpan network. I think that this means eliminating multicasts that provide no more information than simply "I'm not dead yet". For that matter, I suggest that we try to eliminate the need for the basic 6lowpan infrastructure protocols to use any multicast. Having said all that, I understand that "perfect" is often the enemy of "good enough". However, I think it would be beneficial to at least think about what "perfect" might look before declaring "good enough". -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Dec 12 13:01:51 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 1J2Vu2-0001jK-6w; Wed, 12 Dec 2007 13:01:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Vu0-0001j6-Mh for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 13:01:48 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2Vtz-0005Fi-L9 for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 13:01:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 04D2DA9633; Wed, 12 Dec 2007 10:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-10 required=6.6 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0HDBoMD6jtH; Wed, 12 Dec 2007 10:01:44 -0800 (PST) Received: from [192.168.7.194] (69-12-164-135.sfo.archedrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 89D46A9630; Wed, 12 Dec 2007 10:01:44 -0800 (PST) Message-ID: <47602207.7060903@archrock.com> Date: Wed, 12 Dec 2007 10:01:43 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) References: <7892795E1A87F04CADFCCF41FADD00FC04E9B2CB@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04E9B2CB@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: 6lowpan <6lowpan@lists.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 Pascal, Yes, I do see a bunch of cases where BrB and "white-board" may make a=20 lot of sense. But, we're drifting a bit from the genesis of this=20 discussion. The proposed statement from Tim was to place a moratorium on=20 the use of multicast in proposed solutions. My suggestion is that this=20 statement is over constraining. One such example where multicast may be=20 useful is in route-over networks. Link-local multicast only has a scope=20 of a single radio transmission hop and is often done by either=20 implementing or emulating broadcast at L2, which most energy-management=20 protocols for 802.15.4 support. -- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan and Geoff: >=20 > This makes sense to me. Now; >=20 > The BrB draft is 2 fold; part of it is routing from to the backbone and= the Internet; and part of it is white board concept applied to 6LoWPAN. = We could separate the features in 2 drafts, but it seems simpler to speci= fy that the implementation of the proxy part towards the backbone be requ= ired only when there is a backbone in the first place.=20 >=20 > It also seems that the white board is a good approach regardless of whe= ther we have a backbone or not, considering the very nature of the LoWPAN= . We can do a very refined multicast support and try to approach the ener= gy cost and latency that we get with the white board model; but it seems = to me that the nearest to that grail we could get, the more states we'd a= dd in nodes all around, and still we'd never get as good as white board. = I've no handy proof of this assertion, but I'd be surprised and quite int= erested to be proven wrong. >=20 > Also, it makes sense that the behavior of the motes be the same whether= there's a backbone or not; if we recognize the need for the backbone rou= ter for a number of supported situations, and if we agree that the white = board approach enables the registration for the proxy function transparen= tly, then isn't it the fair approach overall? >=20 > In all of the architectures and deployments I've seen, there is always = a special box, called a sink, a router, a manager or a gateway, that play= s a central role for the LoWPAN. The case when that special box does not = exist seems really remote, so we can quite safely assume that the special= box exists and is a good candidate for the white board. >=20 > Does that make sense? >=20 > Pascal > =20 >=20 >> -----Original Message----- >> From: Jonathan Hui [mailto:jhui@archrock.com]=20 >> Sent: vendredi 7 d=E9cembre 2007 23:20 >> To: Pascal Thubert (pthubert) >> Cc: Timothy J. Salo; 6lowpan >> Subject: Re: [6lowpan] ND optimization for sensor nodes (power=20 >> saving/ Idle/Sleep mode) >> >> >> Hi Pascal, >> >> The backbone solution proposed in your draft targets a=20 >> particular configuration and we should definitely consider it.=20 >> Though I strongly believe that we are going to see different=20 >> 6LoWPAN/802.15.4 network configurations. There may be some=20 >> that do not connect to the Internet and do not require or=20 >> cannot afford a router. There may be others that choose a=20 >> route-over approach vs. mesh-under. I just want to reiterate=20 >> my wish that we don't force the WG into a solution space that=20 >> only covers a particular 6LoWPAN/802.15.4 configuration.=20 >> Instead, we should consider a few representative=20 >> configurations as Tim suggested. While it'd be great to see a=20 >> single solution satisfy all of them, we should be open to=20 >> having different ones if needed. >> >> -- >> Jonathan Hui >> >> >> Pascal Thubert (pthubert) wrote: >>> Hi >>> >>> I tend to agree with Tim here; multicast is a complex issue=20 >> in the low=20 >>> power / sleepy space. It's even unclear which WG should be=20 >> responsible=20 >>> to define it. >>> =20 >>> Back to basics, there are basically 2 extreme models to locate=20 >>> somebody; cry out loud or white board. ND on Ethernet uses the first=20 >>> model based on multicast. Mobile IP uses the second. When=20 >> you look up=20 >>> a mobile node on the Home Link, the Home Agent is the reference that=20 >>> responds the ND requests on behalf of the mobile nodes. >>> >>> So my question is: Should we take as granted that ND on the LoWPAN=20 >>> requires multicast? Maybe the white board model based on unicast is=20 >>> enough, in which case we get rid of a very difficult dependency. >>> Considering that there is a need for a router that=20 >> understands 6LowPAN=20 >>> to connect the LoWPAN to the Internet, that router is the natural=20 >>> location for a white board. >>> >>> So the concept of backbone router is this: cry out loud on the high=20 >>> speed backbone that federates LoWPANs, and white board on=20 >> the LoWPAN,=20 >>> and ND proxying to federate the whole thing. The backbone router=20 >>> implements ND proxying in a fashion that is compatible with=20 >> mobile IP=20 >>> so one day, sensors with a global address can move away and stay=20 >>> virtually there. >>> >>> In the meantime, a link local address is enough to connect=20 >> to any node=20 >>> in the network federated by backbone routers, and a mote can=20 >> move from=20 >>> a backbone router to another within the federated network without=20 >>> renumbering. >>> >>> The story begins in >>> >> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-rout >>> er >>> -00.txt :) >>> >>> Pascal >>> =20 >>> >>>> -----Original Message----- >>>> From: Timothy J. Salo [mailto:salo@saloits.com] >>>> Sent: Thursday, December 06, 2007 11:11 PM >>>> To: 6lowpan >>>> Subject: Re: [6lowpan] ND optimization for sensor nodes (power=20 >>>> saving/ Idle/Sleep mode) >>>> >>>> Samita Chakrabarti wrote: >>>>> ... That way, periodic RA will not wake up all the nodes in the=20 >>>>> 6lowpan. ... >>>> To the best of my knowledge, 802.15.4 implementations=20 >> power-down the=20 >>>> radio when the system sleeps. As such, a broadcast packet does not=20 >>>> wake a sleeping 802.15.4 node. >>>> Rather, the packet is simply never received by the sleeping node. >>>> >>>> If my understanding about this behavior is incorrect,=20 >> someone please=20 >>>> correct me. I have been meaning to check and see what the=20 >> spec says=20 >>>> about this, but haven't yet... >>>> >>>> Given that the response to broadcast packets differs in 802.16=20 >>>> networks (where an idle node wakes to process the packet) and >>>> 802.15.4 networks (where a sleeping node is never even aware of the=20 >>>> packet), different solutions are probably required. >>>> >>>> To reiterate what I have said before, I believe that we must=20 >>>> explicitly specify the behavior we expect of multicast in 6lowpan=20 >>>> networks that contain sleeping nodes. In particular, does=20 >> multicast=20 >>>> mean "received by the potentially very small percentage of=20 >> the nodes=20 >>>> that aren't currently sleeping" or might it mean "received by every=20 >>>> node after they wake up [whenever day that might be]"? After we=20 >>>> specify the behavior of multicast, then we can then try to=20 >> figure out=20 >>>> whether we can actually implement that behavior in a useful way. >>>> >>>> In the interim, I suggest a moratorium on simply assuming that=20 >>>> multicast is a potential solution to any of the challenges we face=20 >>>> (e.g., duplicate address detection, router announcements, neighbor=20 >>>> discovery, ...) >>>> >>>> -tjs >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Wed Dec 12 13:16:34 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 1J2W8H-00054Q-P1; Wed, 12 Dec 2007 13:16:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2W8G-00054L-7y for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 13:16:32 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2W8D-0005bd-V4 for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 13:16:32 -0500 X-IronPort-AV: E=Sophos;i="4.24,157,1196636400"; d="scan'208";a="728517" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Dec 2007 19:16:29 +0100 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 lBCIGTFA017609; Wed, 12 Dec 2007 19:16:29 +0100 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 lBCIG6me014463; Wed, 12 Dec 2007 18:16:18 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 19:16:07 +0100 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] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Date: Wed, 12 Dec 2007 19:15:58 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04E9BA3D@xmb-ams-337.emea.cisco.com> In-Reply-To: <47602207.7060903@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] ND optimization for sensor nodes (power saving/ Idle/Sleep mode) Thread-Index: Acg86Rwgr9Fb/B2kQ12NRho9/oWY+wAAKZ1A From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" X-OriginalArrivalTime: 12 Dec 2007 18:16:07.0191 (UTC) FILETIME=[1080B270:01C83CEB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8983; t=1197483389; x=1198347389; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20ND=20optimization=20for=20s ensor=20nodes=20(power=09saving/=09Idle/Sleep=20mode) |Sender:=20; bh=VuHo9pvHzf1JoMBYjJvnhgWzcmddzedwj34eO/yjPdY=; b=B2eV2V5Pp3oVV5xWlRcdH3Db/Qov6aUJhKIu50RzxPlbIaJt0UAWb1fhYj 5ojqB7xhu3WSlQPoRKRMaS6ma3XBj65xjrT8SCVlfTf3SpZt6Wzk/TuOZ6QZ Xnn7auDDny; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: 6lowpan <6lowpan@lists.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 Jonathan, I think we're on sync. All I claim is that for the specific purpose of = ND over LoWPAN, the white board model is more efficient then multicast; = and that the different is most apparent when we're doing multihop (mesh = under). I do not want to ban work on multicast. But if we have a = preferred solution that do not depend on specific mesh under / mac = variation for broadcast/multicast support, it's all the better. If that = solution enables scaling with a BbR for no additional control, well, = fine. Pascal =20 >-----Original Message----- >From: Jonathan Hui [mailto:jhui@archrock.com]=20 >Sent: mercredi 12 d=E9cembre 2007 19:02 >To: Pascal Thubert (pthubert) >Cc: Geoff Mulligan; Timothy J. Salo; 6lowpan >Subject: Re: [6lowpan] ND optimization for sensor nodes (power=20 >saving/ Idle/Sleep mode) > > >Hi Pascal, > >Yes, I do see a bunch of cases where BrB and "white-board" may=20 >make a lot of sense. But, we're drifting a bit from the=20 >genesis of this discussion. The proposed statement from Tim=20 >was to place a moratorium on the use of multicast in proposed=20 >solutions. My suggestion is that this statement is over=20 >constraining. One such example where multicast may be useful=20 >is in route-over networks. Link-local multicast only has a=20 >scope of a single radio transmission hop and is often done by=20 >either implementing or emulating broadcast at L2, which most=20 >energy-management protocols for 802.15.4 support. > >-- >Jonathan Hui > > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan and Geoff: >>=20 >> This makes sense to me. Now; >>=20 >> The BrB draft is 2 fold; part of it is routing from to the=20 >backbone and the Internet; and part of it is white board=20 >concept applied to 6LoWPAN. We could separate the features in=20 >2 drafts, but it seems simpler to specify that the=20 >implementation of the proxy part towards the backbone be=20 >required only when there is a backbone in the first place.=20 >>=20 >> It also seems that the white board is a good approach=20 >regardless of whether we have a backbone or not, considering=20 >the very nature of the LoWPAN. We can do a very refined=20 >multicast support and try to approach the energy cost and=20 >latency that we get with the white board model; but it seems=20 >to me that the nearest to that grail we could get, the more=20 >states we'd add in nodes all around, and still we'd never get=20 >as good as white board. I've no handy proof of this assertion,=20 >but I'd be surprised and quite interested to be proven wrong. >>=20 >> Also, it makes sense that the behavior of the motes be the=20 >same whether there's a backbone or not; if we recognize the=20 >need for the backbone router for a number of supported=20 >situations, and if we agree that the white board approach=20 >enables the registration for the proxy function transparently,=20 >then isn't it the fair approach overall? >>=20 >> In all of the architectures and deployments I've seen, there=20 >is always a special box, called a sink, a router, a manager or=20 >a gateway, that plays a central role for the LoWPAN. The case=20 >when that special box does not exist seems really remote, so=20 >we can quite safely assume that the special box exists and is=20 >a good candidate for the white board. >>=20 >> Does that make sense? >>=20 >> Pascal >> =20 >>=20 >>> -----Original Message----- >>> From: Jonathan Hui [mailto:jhui@archrock.com] >>> Sent: vendredi 7 d=E9cembre 2007 23:20 >>> To: Pascal Thubert (pthubert) >>> Cc: Timothy J. Salo; 6lowpan >>> Subject: Re: [6lowpan] ND optimization for sensor nodes (power=20 >>> saving/ Idle/Sleep mode) >>> >>> >>> Hi Pascal, >>> >>> The backbone solution proposed in your draft targets a particular=20 >>> configuration and we should definitely consider it. >>> Though I strongly believe that we are going to see different >>> 6LoWPAN/802.15.4 network configurations. There may be some that do=20 >>> not connect to the Internet and do not require or cannot afford a=20 >>> router. There may be others that choose a route-over approach vs.=20 >>> mesh-under. I just want to reiterate my wish that we don't=20 >force the=20 >>> WG into a solution space that only covers a particular=20 >>> 6LoWPAN/802.15.4 configuration. >>> Instead, we should consider a few representative configurations as=20 >>> Tim suggested. While it'd be great to see a single solution satisfy=20 >>> all of them, we should be open to having different ones if needed. >>> >>> -- >>> Jonathan Hui >>> >>> >>> Pascal Thubert (pthubert) wrote: >>>> Hi >>>> >>>> I tend to agree with Tim here; multicast is a complex issue >>> in the low >>>> power / sleepy space. It's even unclear which WG should be >>> responsible >>>> to define it. >>>> =20 >>>> Back to basics, there are basically 2 extreme models to locate=20 >>>> somebody; cry out loud or white board. ND on Ethernet uses=20 >the first=20 >>>> model based on multicast. Mobile IP uses the second. When >>> you look up >>>> a mobile node on the Home Link, the Home Agent is the=20 >reference that=20 >>>> responds the ND requests on behalf of the mobile nodes. >>>> >>>> So my question is: Should we take as granted that ND on the LoWPAN=20 >>>> requires multicast? Maybe the white board model based on=20 >unicast is=20 >>>> enough, in which case we get rid of a very difficult dependency. >>>> Considering that there is a need for a router that >>> understands 6LowPAN >>>> to connect the LoWPAN to the Internet, that router is the natural=20 >>>> location for a white board. >>>> >>>> So the concept of backbone router is this: cry out loud on=20 >the high=20 >>>> speed backbone that federates LoWPANs, and white board on >>> the LoWPAN, >>>> and ND proxying to federate the whole thing. The backbone router=20 >>>> implements ND proxying in a fashion that is compatible with >>> mobile IP >>>> so one day, sensors with a global address can move away and stay=20 >>>> virtually there. >>>> >>>> In the meantime, a link local address is enough to connect >>> to any node >>>> in the network federated by backbone routers, and a mote can >>> move from >>>> a backbone router to another within the federated network without=20 >>>> renumbering. >>>> >>>> The story begins in >>>> >>>=20 >http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-rou >>> t >>>> er >>>> -00.txt :) >>>> >>>> Pascal >>>> =20 >>>> >>>>> -----Original Message----- >>>>> From: Timothy J. Salo [mailto:salo@saloits.com] >>>>> Sent: Thursday, December 06, 2007 11:11 PM >>>>> To: 6lowpan >>>>> Subject: Re: [6lowpan] ND optimization for sensor nodes (power=20 >>>>> saving/ Idle/Sleep mode) >>>>> >>>>> Samita Chakrabarti wrote: >>>>>> ... That way, periodic RA will not wake up all the nodes in the=20 >>>>>> 6lowpan. ... >>>>> To the best of my knowledge, 802.15.4 implementations >>> power-down the >>>>> radio when the system sleeps. As such, a broadcast=20 >packet does not=20 >>>>> wake a sleeping 802.15.4 node. >>>>> Rather, the packet is simply never received by the sleeping node. >>>>> >>>>> If my understanding about this behavior is incorrect, >>> someone please >>>>> correct me. I have been meaning to check and see what the >>> spec says >>>>> about this, but haven't yet... >>>>> >>>>> Given that the response to broadcast packets differs in 802.16=20 >>>>> networks (where an idle node wakes to process the packet) and >>>>> 802.15.4 networks (where a sleeping node is never even=20 >aware of the=20 >>>>> packet), different solutions are probably required. >>>>> >>>>> To reiterate what I have said before, I believe that we must=20 >>>>> explicitly specify the behavior we expect of multicast in 6lowpan=20 >>>>> networks that contain sleeping nodes. In particular, does >>> multicast >>>>> mean "received by the potentially very small percentage of >>> the nodes >>>>> that aren't currently sleeping" or might it mean=20 >"received by every=20 >>>>> node after they wake up [whenever day that might be]"? After we=20 >>>>> specify the behavior of multicast, then we can then try to >>> figure out >>>>> whether we can actually implement that behavior in a useful way. >>>>> >>>>> In the interim, I suggest a moratorium on simply assuming that=20 >>>>> multicast is a potential solution to any of the=20 >challenges we face=20 >>>>> (e.g., duplicate address detection, router announcements,=20 >neighbor=20 >>>>> discovery, ...) >>>>> >>>>> -tjs >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Wed Dec 12 13:35: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 1J2WR1-0001kV-42; Wed, 12 Dec 2007 13:35:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2WR0-0001Zu-5I for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 13:35:54 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2WQy-00069k-PW for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 13:35:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9C018A95FE; Wed, 12 Dec 2007 10:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-10 required=6.6 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PpfmwLRsRHO; Wed, 12 Dec 2007 10:35:49 -0800 (PST) Received: from [192.168.7.194] (69-12-164-135.sfo.archedrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id DAB38A95F6; Wed, 12 Dec 2007 10:35:49 -0800 (PST) Message-ID: <47602A04.9040101@archrock.com> Date: Wed, 12 Dec 2007 10:35:48 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Timothy J. Salo" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <1197065234.6356.42.camel@dellx1> <47601545.7090402@saloits.com> In-Reply-To: <47601545.7090402@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: 6lowpan <6lowpan@lists.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 Timothy J. Salo wrote: > o They don't interoperate. Again, is system-level > interoperability one of our objectives? If it isn't, I > suggest we simply say so. Hasn't the IETF traditionally concerned itself with interoperability at L3 and above? 802.15.4 links with different configurations are logically different links as stated in the architecture ID. I don't think this WG should be worried about interoperability between arbitrary link layers simply because they utilize a radio with 'IEEE 802.15.4' in its datasheet. Note that just because a radio may be IEEE 802.15.4 compliant, doesn't mean it can communicate with any arbitrary IEEE 802.15.4 radio. There may be differences in frequency (2.4 GHz, 916 MHz, 868 MHz), modulation (BPSK, ASK, O-QPSK), baudrate (20, 100, 250 kbps). Then there's IEEE 802.15.4-2006 vs. 802.15.4a vs. the currently-in-progress 802.15.4e. I'd be surprised if the energy-management mechanisms in 802.15.4-2006 are at all compatible with 802.15.4e. Note that there are commonalities in all of this (addressing, frame format, etc). I don't think it is in the best interest of this WG to pick a single slice and say we will develop solutions that address only that one slice. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Dec 12 14:36: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 1J2XNf-0008S8-VA; Wed, 12 Dec 2007 14:36:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2XNe-0008RA-AP for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 14:36:30 -0500 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2XNd-0007vc-Fp for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 14:36:30 -0500 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 lBCJa2QQ048466 for <6lowpan@lists.ietf.org>; Wed, 12 Dec 2007 13:36:18 -0600 (CST) (envelope-from salo@saloits.com) Message-ID: <47603817.5030705@saloits.com> Date: Wed, 12 Dec 2007 13:35:51 -0600 From: "Timothy J. Salo" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <1197065234.6356.42.camel@dellx1> <47601545.7090402@saloits.com> <47602A04.9040101@archrock.com> In-Reply-To: <47602A04.9040101@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Jonathan Hui wrote: > > Timothy J. Salo wrote: >> o They don't interoperate. Again, is system-level >> interoperability one of our objectives? If it isn't, I >> suggest we simply say so. > > Hasn't the IETF traditionally concerned itself with > interoperability at L3 and above? I think there is no question that 6lowpan is breaking new ground within the IETF. As far as I know, this is the first IETF Working Group that intends to specify a layer-two routing solution. (Yes, yes, I know. We could claim that it is actually "mesh under routing" or layer 2.5 routing, or layer 2.3457 routing. But nonetheless, 6lowpan intends to specify a routing solution that operates on link-layer addresses. And, I think this is unique within the IETF.) Given that 6lowpan is already working on a layer-two routing solution (no matter what you call it) it seems to me that we have created a strong argument that, at least in some environments, it is important to think about how things should be done below layer three. This should permit us to think about layer-two issues that we think may be important. > I don't think this WG > should be worried about interoperability between arbitrary link layers > simply because they utilize a radio with 'IEEE 802.15.4' in its > datasheet. Note that just because a radio may be IEEE 802.15.4 > compliant, doesn't mean it can communicate with any arbitrary IEEE > 802.15.4 radio. There may be differences in frequency (2.4 GHz, 916 MHz, > 868 MHz), modulation (BPSK, ASK, O-QPSK), baudrate (20, 100, 250 kbps). > Then there's IEEE 802.15.4-2006 vs. 802.15.4a vs. the > currently-in-progress 802.15.4e. I'd be surprised if the > energy-management mechanisms in 802.15.4-2006 are at all compatible with > 802.15.4e. Note that there are commonalities in all of this (addressing, > frame format, etc). I don't think it is in the best interest of this WG > to pick a single slice and say we will develop solutions that address > only that one slice. Well, dramatic as you try to make it sound, these parameters can't be selected independently. Customers in ITU Region 2 have about two choices: o 2.450 GHz / 250 kbps / O-QPSK o 915 MHz / 40 kbps / DSSS with BKSK I think 868 MHz operation is only permitted in Europe (but I think 915 MHz ISM operation is restricted to ITU Region 2, which doesn't include Europe). Interestingly, I believe that devices operating in the 868 MHz ISM band [in Europe] are permitted to operate at only a 1% duty cycle. So yes, customers may, depending where they are, have as many as _two_ (not the 36 you seemed to be trying to lead us to believe) incompatible physical layer choices. (Although which two choices customers have varies by geographic, or more precisely ITU, region). Correct me if I am wrong, but you appear to be arguing that because the 802.15.4 spec offers customers two choices, then the IETF should make no effort to ensure system-level interoperability. I am not convinced that this is the right answer (or the right reasoning). By the way, I am glad to see your support for the notion that 6lowpan is targeting 802.14.4 _networks_, rather than 802.15.4 _radios_. This permits us to at least consider making use of 802.15.4 functionality that might not be implemented in 802.15.4-compatible chips. -tjs _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Dec 12 15:50: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 1J2YX6-0006vz-QE; Wed, 12 Dec 2007 15:50:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2YX5-0006k4-OW for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 15:50:19 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2YX3-0001Nc-GQ for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 15:50:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id E22DAA9647; Wed, 12 Dec 2007 12:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-10 required=6.6 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mt+yyW1bNMP; Wed, 12 Dec 2007 12:50:14 -0800 (PST) Received: from [192.168.7.194] (69-12-164-135.sfo.archedrock.com [69.12.164.135]) by mail.sf.archrock.com (Postfix) with ESMTP id 0F286A963E; Wed, 12 Dec 2007 12:50:14 -0800 (PST) Message-ID: <47604984.6020009@archrock.com> Date: Wed, 12 Dec 2007 12:50:12 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Timothy J. Salo" Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <1197065234.6356.42.camel@dellx1> <47601545.7090402@saloits.com> <47602A04.9040101@archrock.com> <47603817.5030705@saloits.com> In-Reply-To: <47603817.5030705@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 6lowpan <6lowpan@lists.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 Timothy J. Salo wrote: > I think there is no question that 6lowpan is breaking new > ground within the IETF. As far as I know, this is the first > IETF Working Group that intends to specify a layer-two > routing solution. (Yes, yes, I know. We could claim that > it is actually "mesh under routing" or layer 2.5 routing, or > layer 2.3457 routing. But nonetheless, 6lowpan intends to > specify a routing solution that operates on link-layer > addresses. And, I think this is unique within the IETF.) Really? There is nothing in the proposed charter that suggests we will develop a mesh under routing solution. If you remember at the 69th IETF, we did come to an agreement that we would not develop a mesh-under solution at this time. The only related proposal is to develop *requirements* for such a mesh under solution which could be defined outside the IETF. [...] > So yes, customers may, depending where they are, have as many as > _two_ (not the 36 you seemed to be trying to lead us to believe) > incompatible physical layer choices. (Although which two choices > customers have varies by geographic, or more precisely ITU, region). You haven't addressed my concerns about the variants of IEEE 802.15.4 (a, e, 2006). I also forgot to include ISA, which is developing their own 802.15.4 configuration, utilizing frequency agility and time synchronization. Should we ignore them too? The issue is that 802.15.4-2006 specifies only a limited set of energy-management mechanisms, which are often not satisfactory in a large number of applications. For example, there is no provision for energy-constrained FFDs. This is precisely the reason why there are new energy-management protocols being defined for 802.15.4. Furthermore, what about support for route-over which would be useful for ROLL (if it forms)? Are you ready to say that link-local multicast should never be used? How do you plan on discovering your neighbors at L3? The WG currently does not assume a particular configuration and I believe there is support to keep it that way. > Correct me if I am wrong, but you appear to be arguing that because > the 802.15.4 spec offers customers two choices, then the IETF should > make no effort to ensure system-level interoperability. I am not > convinced that this is the right answer (or the right reasoning). It all depends on what's included in your 'system'. If you expect 802.15.4-2006, ISA100.11a, 802.15.4e to all interoperate using the exact same network-layer mechanisms, then good luck. You might get 2 of the 3, but I highly doubt you'd get all three. > By the way, I am glad to see your support for the notion that > 6lowpan is targeting 802.14.4 _networks_, rather than 802.15.4 > _radios_. This permits us to at least consider making use > of 802.15.4 functionality that might not be implemented in > 802.15.4-compatible chips. Yes, I am promoting networks. The issue is that just saying 802.15.4 does not define the network. -- Jonathan Hui _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Dec 12 15:58:47 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 1J2YfG-0001Bx-F6; Wed, 12 Dec 2007 15:58:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2YfF-00018D-E8 for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 15:58:45 -0500 Received: from web84113.mail.mud.yahoo.com ([68.142.206.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J2YfE-0001aQ-RV for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 15:58:45 -0500 Received: (qmail 58753 invoked by uid 60001); 12 Dec 2007 20:58:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=I5C8+xITCmLQtKk1Ex/fhcABfzmsTXqHlKbAKcs9AqAd+qIyL3/HQ3apDfIC3RPjy7MDxn39YfyYF31k/jMkK25599fKDbg9xguxxCWuAGhtTmvSIwNCYq5H+0NzTFazoHU8cLx+eL6hpqe/TZg/xLy8OQu0QnD9eJet5Ke76xU=; X-YMail-OSG: DCmGxdcVM1kocCSiz8pHwDaOj9M9_gVER0s5vejNec5m1qBwWdrn_DJoAUmLLZyfxvRaduv8ewJ4oXFPUgcOvLsjLo3VuOraoRmk7WPxWOzIsAs- Received: from [71.123.247.57] by web84113.mail.mud.yahoo.com via HTTP; Wed, 12 Dec 2007 12:58:44 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.158.1 Date: Wed, 12 Dec 2007 12:58:44 -0800 (PST) From: Behcet Sarikaya Subject: Re: [6lowpan] rechartering To: Geoff Mulligan MIME-Version: 1.0 Message-ID: <394987.58298.qm@web84113.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154946326==" Errors-To: 6lowpan-bounces@ietf.org --===============0154946326== Content-Type: multipart/alternative; boundary="0-2068847395-1197493124=:58298" --0-2068847395-1197493124=:58298 Content-Type: text/plain; charset=us-ascii Hi all, I read the charter I support it moving forward. I had some more things to do in mind but maybe the next rechartering can address those issues. I will try to involve myself in the work to do as much as my cycles permit me to do. Regards, Behcet ----- Original Message ---- From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Sent: Tuesday, December 11, 2007 12:01:04 AM Subject: [6lowpan] rechartering Lowpanners, As Mark Townsley (our Area Director) mentioned at the IETF meeting last week, he would like to see some discussion and/or acknowledgment that the current charter text is acceptable to the working group. We have had a couple of folks send some input with some minor issues surrounding splitting some of the docs, but we need more input. Mark doesn't want us to move forward with something as important as the new charter and work items unless we have positive feedback, not just silence. If you agree with the direction of the working group based on the Charter, please drop a note to the list and let us know this! geoff _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --0-2068847395-1197493124=:58298 Content-Type: text/html; charset=us-ascii
Hi all,
  I read the charter I support it moving forward. I had some more things to do in mind but maybe the next rechartering can address those issues.
  I will try to involve myself in the work to do as much as my cycles permit me to do.

Regards,

Behcet

----- Original Message ----
From: Geoff Mulligan <geoff-ietf@mulligan.org>
To: 6lowpan <6lowpan@lists.ietf.org>
Sent: Tuesday, December 11, 2007 12:01:04 AM
Subject: [6lowpan] rechartering

Lowpanners,
  As Mark Townsley (our Area Director) mentioned at the IETF meeting
last week, he would like to see some discussion and/or acknowledgment
that the current charter text is acceptable to the working group.

We have had a couple of folks send some input with some minor issues
surrounding splitting some of the docs, but we need more input.

Mark doesn't want us to move forward with something as important as the
new charter and work items unless we have positive feedback, not just
silence.

If you agree with the direction of the working group based on the
Charter, please drop a note to the list and let us know this!

    geoff



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

--0-2068847395-1197493124=:58298-- --===============0154946326== 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 --===============0154946326==-- From 6lowpan-bounces@ietf.org Wed Dec 12 22:51: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 1J2f6w-0001jZ-LH; Wed, 12 Dec 2007 22:51:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2f6u-0001jR-Gn for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 22:51:44 -0500 Received: from violet.upc.es ([147.83.2.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2f6s-0004u1-AW for 6lowpan@lists.ietf.org; Wed, 12 Dec 2007 22:51:44 -0500 Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id lBD3pdiM015986; Thu, 13 Dec 2007 04:51:40 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 509A42CBCF0; Thu, 13 Dec 2007 04:51:34 +0100 (CET) Received: from 211.217.113.217 by webmail.entel.upc.edu with HTTP; Thu, 13 Dec 2007 05:51:41 +0100 (CET) Message-ID: <62290.211.217.113.217.1197521501.squirrel@webmail.entel.upc.edu> In-Reply-To: <1934.211.229.239.247.1197509356.squirrel@webmail.entel.upc.edu> References: <1934.211.229.239.247.1197509356.squirrel@webmail.entel.upc.edu> Date: Thu, 13 Dec 2007 05:51:41 +0100 (CET) Subject: Re: [6lowpan] Issue of the week: Charter finalization From: "Carles Gomez Montenegro" To: "Carsten Bormann" , "6lowpan" <6lowpan@lists.ietf.org> User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Thu, 13 Dec 2007 04:51:40 +0100 (CET) X-Spam-Score: 1.7 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Hi Geoff, Carsten, all, Some comments in line: > The *theme of the week* for the working group is the finalization of the > charter. In particular, the following questions have been raised: > > A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) > B) should there be work on a "minimal 6lowpan/IPv6 profile"? (I had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) We believe there could be a minimal 6lowpan/Ipv6 profile derived from the analysis of the different uses cases. If the profile is not reduced we can define a set of profiles, suitable for different uses cases. A profile-based solution could address the diversity of requirements that arise from different use cases. > C) Daniel has reminded us that there needs to be a management solution > at some point. I'm not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? Yes, we believe management should be considered in the architecture > D) The discussions about multicast have reminded us that 4944 alone > does not provide a solution beyond a single radio range. MANET's > SMF provides one, but presupposes some support from the routing > protocol. The BbR approach reminds me of 802.11, where all > multicast is unicast to the AP which then sends it back into the > wireless network (which might allow a simplified flooding based on > something like RPF). We believe some multicast solution should be supported, but it should be considered possibly by RL2N, where unicast and multicast routing protocols can be matched if necessary. > E) There were some comments during the meeting that we already were > taking on a sizable amount of work. I'm not sure we want to take > on all of the other points Daniel raised: > > [...] I guess we should consider how to improve the quality of RFC > 4944, especially Global Address HC, TCP operation, ICMPv6 operation > and etc. RFC 4944-bis is one of options. Transport protocols should be considered. See our comment below (regarding the architecture topic). > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. According to our vision, mobility is not a strict requirement at this stage. In most cases, it can be solved through a quick network reconfiguration. > F) Going through each of the documents, the following contributions > have been promised recently: > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > Anybody else? Daniel has also proposed to split 1 into bootstrapping > and ND optimization. There is also the subject of commissioning. > What is the right set of documents, and which ones do (each of) you > want to work on? > > 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": > During the meeting, Kris Pister indicated that he was interested in > contributing, and Carsten Bormann (that would be me) might be > contributing a bit of ROHC background. > > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > with a network management slant? We believe transport protocols should be considered. In a reduced resource network, crosslayer issues should be considered. Architecture should consider this fact providing mechanisms to exchange relevant information (reliability, link quality,..) through layers > 3a "Routing requirements" (which needs its own milestone entry) has a > draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During > the RL2N BOF, a similar document was proposed as a result of the > RL2N-followup WG to be formed. We need to understand whether the two > documents (the 6lowpan one and the rl2n++ one) are sufficiently > different or whether we simply need to cooperate on one document, > which would then have to include the 6lowpan-specific aspects > including mesh-under. We believe, at least at this time, it might not be necessary having two different routing requirements documents (one from RL2N and one from 6LoWPAN). Since LoWPAN scenarios are a subset of those considered by RL2N, at least there should be an RL2N requirements document, which should address the requirements for 6LoWPAN. If RL2N requirements were too broad for 6LoWPAN, then a routing requirements document for 6LoWPAN would make sense. > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" > might provide a basis, but we need more input, in particular from > implementors of each of these scenarios that we actually want to use > as use cases. We can contribute. We have developed applications for home automation, healthcare and city management environments. > 5 "6LoWPAN Security Analysis". Nobody? (I might provide some input, > but can't do this on my own.) > > 6 Implementers' guide: Zach Shelby is interested We may contribute. > 7 Interop guide: Zach Shelby is interested > Best regards, Carles Gomez Technical University of Catalonia _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 13 03:15:33 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 1J2jE7-0006YU-LF; Thu, 13 Dec 2007 03:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jE6-0006YN-IF for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 03:15:26 -0500 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2jE5-0001gX-Ht for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 03:15:25 -0500 Received: by wa-out-1112.google.com with SMTP id j4so952075wah.1 for <6lowpan@lists.ietf.org>; Thu, 13 Dec 2007 00:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5O0HmqhS9yba/gd8irM3L5jgInAMVyu6h6LhS94wDF4=; b=CaFOzZklNoAf7YRAp+YnvQTnM9zU2TjBvGsdkORWE6KvXSMxitRkzzkzQdjBbAtG61o3VEov0b5gSvKNCXLa98zHmuitfkZUYGzfbV72f9naMmYz/FusfC5BC+Z8tFpjQV7TbBBvAkIR1rpIMsXdT2j1PjIJKzl3XOGUplIEmRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V6s51hAiOCx9+q3+HmcgaaHMZTfFWc/jKD10AnGw+Wkn0GnuI/Bg7dxZau/BkzKD9SRfQ69JMmrZFJVPdFBk9qEI1PrwjlDg1Uua7NtHP0tnB+z9Gmv+2yDclyA+Na3fEPjRUCP3BDH7S1ek505dSdQRUmGMTDreCnvj4Ts8Bek= Received: by 10.114.12.9 with SMTP id 9mr1965503wal.23.1197533724838; Thu, 13 Dec 2007 00:15:24 -0800 (PST) Received: by 10.115.19.15 with HTTP; Thu, 13 Dec 2007 00:15:24 -0800 (PST) Message-ID: <77f1dba80712130015m7e517cdek593e89d930c6c8d5@mail.gmail.com> Date: Thu, 13 Dec 2007 17:15:24 +0900 From: "Eunsook \"Eunah\" Kim" To: "Carles Gomez Montenegro" Subject: Re: [6lowpan] Issue of the week: Charter finalization In-Reply-To: <62290.211.217.113.217.1197521501.squirrel@webmail.entel.upc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1934.211.229.239.247.1197509356.squirrel@webmail.entel.upc.edu> <62290.211.217.113.217.1197521501.squirrel@webmail.entel.upc.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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 Carles, My thought is inline; >[....] > > 3a "Routing requirements" (which needs its own milestone entry) has a > > draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During > > the RL2N BOF, a similar document was proposed as a result of the > > RL2N-followup WG to be formed. We need to understand whether the two > > documents (the 6lowpan one and the rl2n++ one) are sufficiently > > different or whether we simply need to cooperate on one document, > > which would then have to include the 6lowpan-specific aspects > > including mesh-under. > > We believe, at least at this time, it might not be necessary having two > different routing requirements documents (one from RL2N and one from > 6LoWPAN). Since LoWPAN scenarios are a subset of those considered by RL2N, > at least there should be an RL2N requirements document, which should > address the requirements for 6LoWPAN. If RL2N requirements were too broad > for 6LoWPAN, then a routing requirements document for 6LoWPAN would make > sense. > [E] Carles, as you already know, RL2N focuses on 3 scenarios at this moment based on multiple PHY/MAC condition. I believe that 6LoWPAN needs its own routing requirement narrowing down the scope of the document as 6LoWPAN specific, including its very unique node characteristics. I think that RL2N can use the input as one of the area where RL2N solution will be used. > > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. > > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" > > might provide a basis, but we need more input, in particular from > > implementors of each of these scenarios that we actually want to use > > as use cases. > > We can contribute. We have developed applications for home automation, > healthcare and city management environments. > [E] I think the current "application space" documents contains home automation and healthcare. I think the doc need to have deeper depth by collecting experiences like you did. It must be great to work together. -eunah _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 13 03:25: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 1J2jNu-00025j-Nm; Thu, 13 Dec 2007 03:25:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2jNt-00023d-0c for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 03:25:33 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2jNq-00022J-Nh for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 03:25:32 -0500 X-IronPort-AV: E=Sophos;i="4.24,161,1196636400"; d="scan'208";a="761698" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 13 Dec 2007 09:25:28 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBD8PSCR024721; Thu, 13 Dec 2007 09:25:28 +0100 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 lBD8P5mg001766; Thu, 13 Dec 2007 08:25:17 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 09:25:10 +0100 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] Issue of the week: Charter finalization Date: Thu, 13 Dec 2007 09:25:03 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04E9BB4D@xmb-ams-337.emea.cisco.com> In-Reply-To: <77f1dba80712130015m7e517cdek593e89d930c6c8d5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Issue of the week: Charter finalization Thread-Index: Acg9YGXS4zHafZ/qQFmh0Sy1k1Z1eAAAHyGg From: "Pascal Thubert (pthubert)" To: "Eunsook \"Eunah\" Kim" , "Carles Gomez Montenegro" X-OriginalArrivalTime: 13 Dec 2007 08:25:10.0681 (UTC) FILETIME=[AD306090:01C83D61] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3044; t=1197534328; x=1198398328; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Issue=20of=20the=20week=3A= 20Charter=20finalization |Sender:=20; bh=4foAfYx4G12+DpFBSFgKUh8D6VLC2q3Qgig2bdadF0s=; b=LlVMKNJHX4N8N9abj5nykX6OjlZhUDUXmcGvYO1kr9h5TW7tSFHovk0xk5 mc/y/duTGIPK0gzVTXeBXFY19qeadJ0xK99nOyEoItgNqTkpHsjtdXE+Pj9X fHLUfwrhV+; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Carsten Bormann , 6lowpan <6lowpan@lists.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: Maybe we should be more explicit on what we assume from the mesh-under = when there is a mesh-under.=20 In particular what we expect as multicast routing from that L2 = mesh-under service.=20 If we make no assumption then we implicitly accept that plain = flooding/pruning is also a supported option to carry L3 multicast. And I would not base ND support on that. Pascal =20 >-----Original Message----- >From: Eunsook "Eunah" Kim [mailto:eunah.ietf@gmail.com]=20 >Sent: jeudi 13 d=E9cembre 2007 09:15 >To: Carles Gomez Montenegro >Cc: Carsten Bormann; 6lowpan >Subject: Re: [6lowpan] Issue of the week: Charter finalization > >Hi Carles, > >My thought is inline; > >>[....] >> > 3a "Routing requirements" (which needs its own milestone=20 >entry) has=20 >> > a draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. =20 >> > During the RL2N BOF, a similar document was proposed as a=20 >result of=20 >> > the RL2N-followup WG to be formed. We need to understand whether=20 >> > the two documents (the 6lowpan one and the rl2n++ one) are=20 >> > sufficiently different or whether we simply need to=20 >cooperate on one=20 >> > document, which would then have to include the 6lowpan-specific=20 >> > aspects including mesh-under. >> >> We believe, at least at this time, it might not be necessary having=20 >> two different routing requirements documents (one from RL2N and one=20 >> from 6LoWPAN). Since LoWPAN scenarios are a subset of those=20 >considered=20 >> by RL2N, at least there should be an RL2N requirements=20 >document, which=20 >> should address the requirements for 6LoWPAN. If RL2N=20 >requirements were=20 >> too broad for 6LoWPAN, then a routing requirements document for=20 >> 6LoWPAN would make sense. >> > >[E] Carles, as you already know, RL2N focuses on 3 scenarios=20 >at this moment based on multiple PHY/MAC condition. I believe=20 >that 6LoWPAN needs its own routing requirement narrowing down=20 >the scope of the document as 6LoWPAN specific, including its=20 >very unique node characteristics. I think that RL2N can use=20 >the input as one of the area where RL2N solution will be used. > >> > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. >> > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" >> > might provide a basis, but we need more input, in particular from=20 >> > implementors of each of these scenarios that we actually=20 >want to use=20 >> > as use cases. >> >> We can contribute. We have developed applications for home=20 >automation,=20 >> healthcare and city management environments. >> > >[E] I think the current "application space" documents contains=20 >home automation and healthcare. I think the doc need to have=20 >deeper depth by collecting experiences like you did. It must=20 >be great to work together. > >-eunah > >_______________________________________________ >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 Thu Dec 13 14:53:09 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 1J2u7B-0005Lx-NV; Thu, 13 Dec 2007 14:53:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2u79-0005Lo-OV for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 14:52:59 -0500 Received: from ees1s0.engr.ccny.cuny.edu ([134.74.16.1]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J2u78-0007SD-3K for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 14:52:59 -0500 Received: (qmail 20573 invoked from network); 13 Dec 2007 19:56:58 -0000 Received: from unknown (HELO leenotebook) (134.74.17.56) by ees1s0.engr.ccny.cuny.edu with SMTP; 13 Dec 2007 19:56:58 -0000 From: "Myung J. Lee" To: "'6lowpan'" <6lowpan@lists.ietf.org> References: <1197319616.5697.45.camel@dellx1> In-Reply-To: <1197319616.5697.45.camel@dellx1> Subject: RE: [6lowpan] Issue of the Week: Charter Finalization Date: Thu, 13 Dec 2007 14:52:26 -0500 Organization: CUNY Message-ID: <004a01c83dc1$bfaf0540$3f0d0fc0$@cuny.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7bue2kJ49PVDNRfWS89Xd71AQIgCPGSqg Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lee@ccny.cuny.edu 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 Dear Carsten and Geoff, You and the group members did a great job in preparing all the works necessary for rechartering. Although I have been working quite sometime for "mesh under" within IEEE 802.15.5, 6lowpan is relatively new to me. Nevertheless, I find that the categories of the work items are well done, which would develop into a set of RFCs useful for the services envisioned in the charter. Few comments are added inline below. Thank you, Myung Lee lee@ccny.cuny.edu ------------------------------------------------------- A) is the timeline, which was too tight, now too relaxed? (Obviously, the chairs don't think so, but what do you think?) ==> I think the timeline is reasonable. B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had envisioned each of the use cases to explain what protocols are used in implementing that particular use case, not the generation of a unified minimal profile that would apply to all use cases.) ==> A unified profile would necessarily be fat and the other extreme would pose interoperability problem. Thus, we may need to narrow down the use cases into a few MAJOR categories according to some measures, for instance, with/without line power, mobility, number of nodes, etc. Also, if there is a urgent and strong market need, it should be taken care of first. C) Daniel has reminded us that there needs to be a management solution at some point. We're not sure that simply defining a MIB is the right way to provide this (SNMPv3 on sensor nodes?). Instead, we could add "management method" to the subjects of the architecture document before actually creating the solution. Is that the right place? ==> Yes, we need management solution. Currently, 15.5 solution permits MAC and Mesh MIB access via primitives in management plane. D) The discussions about multicast have reminded us that 4944 alone does not provide a solution beyond a single radio range. MANET's SMF provides one, but presupposes some support from the routing protocol. The BbR approach reminds me of 802.11, where all multicast is unicast to the AP which then sends it back into the wireless network (which might allow a simplified flooding based on something like RPF). ==> In view of performance, I believe any functions and services slanted towards applications, they are to be placed at higher layers, but simple common services to all layers may be placed lower. E) There were some comments during the meeting that we already were taking on a sizable amount of work. I'm not sure we want to take on all of the other points Daniel raised: [...] I guess we should consider how to improve the quality of RFC 4944, especially Global Address HC, TCP operation, ICMPv6 operation and etc. RFC 4944-bis is one of options. ===> We may work on specific requirements for reliable e2e protocol for WSN, since TCP doesn't fit for error prone and band stricken 6lowpan environment. [...] how to dig out *mobility issue* from the proposed charter. I guess some of requirements of mobility for 6lowpan networks is doable for the initial activity at this stage except specific mobility solutions. ==> The mobility issue may be undertaken in conjunction with the profiles above, considering use cases that need mobility. I am interested in this area. F) Going through each of the documents, the following contributions have been promised recently: 3a "Routing requirements" (which needs its own milestone entry) has a draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During the RL2N BOF, a similar document was proposed as a result of the RL2N-followup WG to be formed. We need to understand whether the two documents (the 6lowpan one and the rl2n++ one) are sufficiently different or whether we simply need to cooperate on one document, which would then have to include the 6lowpan-specific aspects including mesh-under. ==> I am interested in this area. 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" might provide a basis, but we need more input, in particular from implementors of each of these scenarios that we actually want to use as use cases. ==> I am interested in contributing some in this area. Gruesse, Carsten and Geoff _______________________________________________ 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 Thu Dec 13 15:23:57 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 1J2ub6-0000hT-VJ; Thu, 13 Dec 2007 15:23:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ub5-0000hK-PS for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 15:23:55 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2ub4-0008Fm-TJ for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 15:23:55 -0500 Received: from soda-wlan-226.airbears.berkeley.edu ([136.152.170.229]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1J2ub4-0005Hv-33; Thu, 13 Dec 2007 12:23:54 -0800 In-Reply-To: <47601545.7090402@saloits.com> References: <43b91d370712060017m2d128893g9c57cd2d06628d46@mail.gmail.com> <47587368.5040305@saloits.com> <1197065234.6356.42.camel@dellx1> <47601545.7090402@saloits.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [6lowpan] ND optimization for sensor nodes (power saving / Idle/Sleep mode) Date: Thu, 13 Dec 2007 12:23:56 -0800 To: Timothy J. Salo X-Mailer: Apple Mail (2.752.3) 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: 5e15904e367bf57319d290d73554c551 X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 6lowpan <6lowpan@lists.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 Dec 12, 2007, at 9:07 AM, Timothy J. Salo wrote: >>> >> This is not true. A node that sleeps can receive broadcast >> packets. - If the broadcast packet is transmitted on some >> schedule then the >> sleeping node can wake up on that schedule and receive the packet. >> - If the broadcast packet is transmitted with some sort of long >> preamble then the sleeping node can wake up on it's own schedule, >> over >> hear the preamble and stay awake to receive the packet. >> - If the broadcast packet is transmitted multiple times the >> sleeping >> node can wake up during one of these transmissions and receive the >> packet. > > All you have said is that a sleeping node can receive if > it isn't sleeping. I don't think that this sort of "Black is > white, (as long as it changes color)" answer does much to advance > the discussion at hand. Geoff's point is that while the nodes sleep, you schedule and structure communication such that this does not prevent receiving packets. Numerous products, protocols, and systems have shown you can achieve very low duty cycles while still maintaining connectivity. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 13 22:36:06 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 1J31LC-0006a2-QB; Thu, 13 Dec 2007 22:35:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J31LB-0006Zw-NY for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 22:35:57 -0500 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J31LB-0001fy-DV for 6lowpan@lists.ietf.org; Thu, 13 Dec 2007 22:35:57 -0500 Received: by an-out-0708.google.com with SMTP id d31so255413and.103 for <6lowpan@lists.ietf.org>; Thu, 13 Dec 2007 19:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=igsuy1s16PYXRbM2XkfMe3K9Jak9CqSKehE7/JuarJw=; b=NAtgg68vOfDC/RUlAeW1VhnBkZsMlRltim02Q/bqO2Y8iOluhU3UJSy3czqpn0CUVjwueNQelS3T4x/hFN+iXzvFao6kfJEbwu4fx6FN2PzzmzJo85wNvu1zqdfg8jmC0ReQuGLDCeSOjyYT+JjMxnhAbLyebCdQi0bM3whQZUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=czDPbIvRWqSQYn6abVjcRCVXebE2TMIDrfaDJ9d2v4FNNJjbUrvnNMC9NqQPPHKbaXYwFlXOkPe+ZMR3tQ6W9ECo78j0rhEsm9QNEQWBvl+ayiqtMryalQUgw1zsJHK9wSu5ubldJBBDrfixfHGtKeQaeqwTY+7AHpHFUNrnfbI= Received: by 10.101.68.19 with SMTP id v19mr5824075ank.4.1197603356815; Thu, 13 Dec 2007 19:35:56 -0800 (PST) Received: by 10.100.215.8 with HTTP; Thu, 13 Dec 2007 19:35:56 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 12:35:56 +0900 From: "Daniel Park" To: "Geoff Mulligan" Subject: Re: [6lowpan] Issue of the Week: Charter Finalization In-Reply-To: <1197319616.5697.45.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1197319616.5697.45.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 6lowpan <6lowpan@lists.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 > C) Daniel has reminded us that there needs to be a management solution > at some point. We're not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? Agreed. > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. "draft-chakrabarti-mobopts-lowpan-req-01" is doable and I don't see any harmful to this work at this stage. As a part of manemo (manet mobility) use cases, we had a 6lowpan mobility discussion before within IETF. 6lowpan WG is a base camp and works with others WGs (nemo folks, manet folks, etc) together..By doing this work, we will be able to deploy 6lowpan networks larger than today. I guess Pascal can help out with his namo expertise in this space. Right ? > F) Going through each of the documents, the following contributions > have been promised recently: > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > Anybody else? Daniel has also proposed to split 1 into bootstrapping > and ND optimization. There is also the subject of commissioning. > What is the right set of documents, and which ones do (each of) you > want to work on? I am interesting in ND optimization (based on 16ng ND extension background) and commissioning part. > 5 "6LoWPAN Security Analysis". Daniel / Anybody? (Carsten and Geoff > might provide some input, but can't do this on their own.) If other guys are help me with their security expertise, that would be great. I will go for the revision to be ready for WG adoption soon. Thanks, Daniel Park _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Dec 14 05:14:04 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 1J37YM-0000i9-Lz; Fri, 14 Dec 2007 05:13:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J37YL-0000i4-RJ for 6lowpan@lists.ietf.org; Fri, 14 Dec 2007 05:13:57 -0500 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J37YK-0000vy-Vh for 6lowpan@lists.ietf.org; Fri, 14 Dec 2007 05:13:57 -0500 Received: from [192.168.0.12] (addr-213-139-165-97.baananet.fi [213.139.165.97]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id lBEADkgT004818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2007 12:13:52 +0200 Message-ID: <4762575C.1090507@sensinode.com> Date: Fri, 14 Dec 2007 12:13:48 +0200 From: Mikko Saarnivala User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Geoff Mulligan , 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] Issue of the Week: Charter Finalization References: <1197319616.5697.45.camel@dellx1> In-Reply-To: <1197319616.5697.45.camel@dellx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Hello, Geoff and all - comments inline. Geoff Mulligan wrote: > Carsten and I don't want to interrupt this discussion, but we would like > to remind everyone that we also have one CRITICAL short term objective: > Getting rechartered. I feel that the proposed charter is nicely structured with well defined scope and support it with minimal changes. > The *theme of the week* for the working group is the finalization of the > charter. In particular, the following questions have been raised: > > A) is the timeline, which was too tight, now too relaxed? (Obviously, > the chairs don't think so, but what do you think?) From my standpoint of view the timeline _could_ be even more aggressive on some items but maybe it's best to keep it as it is in order to remain realistic. > B) should there be work on a "minimal 6lowpan/IPv6 profile"? (We had > envisioned each of the use cases to explain what protocols are used > in implementing that particular use case, not the generation of a > unified minimal profile that would apply to all use cases.) I think this would be recommendable as there seems to be several issues that need to be defined in order to guarantee system level interoperability. I would also be willing to contribute to this item. Eunah has already mentioned on the list about the informal meeting that some of us (Eunah, JP, Dominik, Jonathan and I) had in Vancouver on the possible minimal 6lowpan profile item. I took some notes on the meeting and will probably post them later on the list. > F) Going through each of the documents, the following contributions > have been promised recently: > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > Anybody else? Daniel has also proposed to split 1 into bootstrapping > and ND optimization. There is also the subject of commissioning. > What is the right set of documents, and which ones do (each of) you > want to work on? I would be willing to contribute to this item. > 7 Interop guide: Zach Shelby and Jonathan Hui are interested. What about > the other folks that have built or are building 6LoWPAN implementations. Best regards, -- Mr. Mikko Saarnivala | Software systems | +358 50 5696287 Sensinode Ltd. | _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Dec 17 06:17:43 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 1J4Dye-0004a4-6V; Mon, 17 Dec 2007 06:17:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Dyc-0004Zs-Ns for 6lowpan@lists.ietf.org; Mon, 17 Dec 2007 06:17:38 -0500 Received: from violet.upc.es ([147.83.2.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4Dyb-0007Yu-2n for 6lowpan@lists.ietf.org; Mon, 17 Dec 2007 06:17:38 -0500 Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id lBHBHYwc028978; Mon, 17 Dec 2007 12:17:34 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id C5D252CBCF0; Mon, 17 Dec 2007 12:17:28 +0100 (CET) Received: from 217.216.17.251 by webmail.entel.upc.edu with HTTP; Mon, 17 Dec 2007 13:17:34 +0100 (CET) Message-ID: <3538.217.216.17.251.1197893854.squirrel@webmail.entel.upc.edu> In-Reply-To: <62290.211.217.113.217.1197521501.squirrel@webmail.entel.upc.edu> References: <1934.211.229.239.247.1197509356.squirrel@webmail.entel.upc.edu> <62290.211.217.113.217.1197521501.squirrel@webmail.entel.upc.edu> Date: Mon, 17 Dec 2007 13:17:34 +0100 (CET) Subject: Re: [6lowpan] Issue of the week: Charter finalization From: "Carles Gomez Montenegro" To: "Carsten Bormann" , "6lowpan" <6lowpan@lists.ietf.org> User-Agent: SquirrelMail/1.4.10a-1.fc6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Mon, 17 Dec 2007 12:17:35 +0100 (CET) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Hi all, Regarding our comment on routing requirements in our last e-mail, we would like to clarify our point of view. We believe RL2N/ROLL should have a set of routing requirements which should satisfy the ones provided by 6LoWPAN. We would like to emphasize that we strongly support the need for 6LoWPAN own routing requirements draft, according to the specificities of 6LoWPAN environments. Best regards, Carles _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Dec 27 10:19:07 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 1J7uVh-0006ly-JA; Thu, 27 Dec 2007 10:19:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J7uVg-0006lt-J1 for 6lowpan@lists.ietf.org; Thu, 27 Dec 2007 10:19:00 -0500 Received: from cypress.ugent.be ([157.193.71.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J7uVf-00028D-QI for 6lowpan@lists.ietf.org; Thu, 27 Dec 2007 10:19:00 -0500 Received: from gorilla.ugent.be (HELO localhost) ([157.193.49.20]) by cypress.ugent.be with ESMTP; 27 Dec 2007 16:18:58 +0100 Received: from cypress.ugent.be ([157.193.71.48]) by localhost (gorilla.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 09003-08-3; Thu, 27 Dec 2007 16:18:58 +0100 (CET) Received: from mail4.intec.ugent.be ([157.193.214.4]) by cypress.ugent.be with ESMTP; 27 Dec 2007 16:18:51 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKhRc0edwdYE/2dsb2JhbACRYJo4 Received: from localhost (localhost [127.0.0.1]) by mail4.intec.ugent.be (Postfix) with ESMTP id B887640B2BA; Thu, 27 Dec 2007 16:18:46 +0100 (CET) Received: from mail4.intec.ugent.be ([127.0.0.1]) by localhost (mail4.intec.ugent.be [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD1CIkzSLRF1; Thu, 27 Dec 2007 16:18:46 +0100 (CET) Received: from webserver6.intec.ugent.be (webserver6.intec.ugent.be [157.193.214.11]) by mail4.intec.ugent.be (Postfix) with ESMTP id 89B7940B2B9; Thu, 27 Dec 2007 16:18:46 +0100 (CET) Received: from 192.168.1.67 (SquirrelMail authenticated user pdemil) by webserver6.intec.ugent.be with HTTP; Thu, 27 Dec 2007 16:18:50 +0100 (CET) Message-ID: <2036.192.168.1.67.1198768730.squirrel@webserver6.intec.ugent.be> Date: Thu, 27 Dec 2007 16:18:50 +0100 (CET) Subject: Re: [6lowpan] Issue of the week: Charter finalization From: "Pieter De Mil" To: "Carsten Bormann" User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by UGent DICT X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: 6lowpan <6lowpan@lists.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 Carsten, All, I've attended the Vancouver-meeting (my first IETF meeting) and I support the new charter. Some comments inline... > Lowpanners, > > C) Daniel has reminded us that there needs to be a management solution > at some point. I'm not sure that simply defining a MIB is the > right way to provide this (SNMPv3 on sensor nodes?). Instead, we > could add "management method" to the subjects of the architecture > document before actually creating the solution. Is that the right > place? Network monitoring is a crucial component of a wireless network, in order to detect node and link failures, to detect interference, to monitor remaining life time of devices, to monitor achieved QoS, etc. Monitoring leads to network management actions. I'm convinced it's important to add a management framework in the architecture document and I would like to contribute to this. > > E) There were some comments during the meeting that we already were > taking on a sizable amount of work. I'm not sure we want to take > on all of the other points Daniel raised: > > [...] I guess we should consider how to improve the quality of RFC > 4944, especially Global Address HC, TCP operation, ICMPv6 operation > and etc. RFC 4944-bis is one of options. What is the impact of TCP in wireless sensor networks? I believe a new (adaptive) transport layer will be of great benefit to some scenarios (but I guess that is out of scope of this WG). > > [...] how to dig out *mobility issue* from the proposed charter. I > guess some of requirements of mobility for 6lowpan networks is > doable for the initial activity at this stage except specific > mobility solutions. > > F) Going through each of the documents, the following contributions > have been promised recently: > > 1 "6LoWPAN Bootstrapping and 6LoWPAN IPv6 ND Optimizations": We have > longstanding contributions from Samita Chakrabarti and Erik Nordmark. > Anybody else? Daniel has also proposed to split 1 into bootstrapping > and ND optimization. There is also the subject of commissioning. > What is the right set of documents, and which ones do (each of) you > want to work on? > Commissioning and bootstrapping are very interesting topics, count me in. Security will be an important aspect of this. > 2 "Problem Statement for Stateful Header Compression in 6LoWPANs": > During the meeting, Kris Pister indicated that he was interested in > contributing, and Carsten Bormann (that would be me) might be > contributing a bit of ROHC background. > > 3 "6LoWPAN Architecture" already has a draft from Dave Culler, Geoff > Mulligan, and JP Vasseur. Any other takers? In particular, somebody > with a network management slant? I'm willing to help on this (Architecture + network management). > > 3a "Routing requirements" (which needs its own milestone entry) has a > draft from Dominik Kaspar, Eunsook Kim, and Carsten Bormann. During > the RL2N BOF, a similar document was proposed as a result of the > RL2N-followup WG to be formed. We need to understand whether the two > documents (the 6lowpan one and the rl2n++ one) are sufficiently > different or whether we simply need to cooperate on one document, > which would then have to include the 6lowpan-specific aspects > including mesh-under. The routing requirements are different for each use case. Even for a specific use case, vendors may want to emphasize different aspects (e.g. maximum network lifetime vs. low latency). > > 4 "Use Cases for 6LoWPAN". Zach Shelby has indicated his interest. > Eunsook Kim et al.'s "Design and Application Spaces for 6LoWPANs" > might provide a basis, but we need more input, in particular from > implementors of each of these scenarios that we actually want to use > as use cases. We have developed network solutions for Wireless Building Automation. We'll be happy to give some input. > > 5 "6LoWPAN Security Analysis". Nobody? (I might provide some input, > but can't do this on my own.) > > 6 Implementers' guide: Zach Shelby is interested > > 7 Interop guide: Zach Shelby is interested > > In order to accelerate rechartering, we should have answers to these > questions/credibles sets of contributors to these documents at the end > of this week, so please don't hesitate providing your input. > > Gruesse, Carsten Thanks for all your hard work, your efforts are appreciated! Happy holidays, Pieter _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan