From rsn-bounces@ietf.org Thu Nov 01 02:58:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0G-0002H1-LE; Thu, 01 Nov 2007 02:58:08 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1InU0F-0002Fb-It for rsn-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 02:58:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0A-0002BY-Nb for rsn@ietf.org; Thu, 01 Nov 2007 02:58:02 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InU04-0002sS-EM for rsn@ietf.org; Thu, 01 Nov 2007 02:57:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D7328A962F; Wed, 31 Oct 2007 23:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-10 required=6.6 tests=[AWL=-0.012, 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 qQ69iId2TNk3; Wed, 31 Oct 2007 23:57:52 -0700 (PDT) Received: from [192.168.1.143] (adsl-71-142-67-12.dsl.pltn13.pacbell.net [71.142.67.12]) by mail.sf.archrock.com (Postfix) with ESMTP id 2DADCA962E; Wed, 31 Oct 2007 23:57:52 -0700 (PDT) Message-ID: <472978EF.80102@archrock.com> Date: Wed, 31 Oct 2007 23:57:51 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kris Pister References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> In-Reply-To: <4728FC22.1030500@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: 926f893f9bbbfa169f045f85f0cdb955 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Kris Pister wrote: > Hmm. I guess you're right after all - I am confused. I completely > agree with your statements below, but then I re-read RFC4944 and it says: > "Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes > should include a byte matching this pattern immediately following the > 802.15.4. header." > And I read the Arch Rock 6LoWPAN tutorial (which is really well done, by > the way), and it says "dispatch: coexistence with other protocols over > the same link". These statements do not appear to be aligned with what > you wrote below. I don't see where the statements conflict. There are two kinds of coexistence: (i) two sets of nodes operating in isolation but in the same physical vicinity and (ii) a single set of nodes operating together using multiple protocols above the link. A crypto-based solution only addresses the former efficiently. > As I see it, there are only three options: > 1) we assume that MAC-layer MICs are always used for 6LoWPAN, perhaps > with a well-known 6LoWPAN key, and then there is never any question > about coexistence. If you're parsing the dispatch byte, you already > know that this is a 6LoWPAN frame. > 2) we assume 1, but plan to share MAC-layer crypto with other non-LoWPAN > protocols. This sounds like a bad idea from a crypto standpoint. Why? Do we really expect networks to operate with a single protocol? LLC/SNAP encapsulation allows multiple protocols to operate along side IP. ARP, RARP, MPLS, bridging, just to name a few. Some link-specific protocols have nothing to do with IP (e.g. link management), but operate in networks that support IP. -- Jonathan Hui > 3) we believe that non-6LoWPAN frames may get through to the network > layer, talk about "coexsistence", and cross our fingers that 15.4 toy > designers are all familiar with and abide by the IETF recommendations. > Down this path lies mysteriously failed networks, broken deployments, > and more of the same semi-functionality that has held WSN > commercialization back for the last 5 years. > > So which is it? My vote is #1. > > ksjp > > Jonathan Hui wrote: >> >> Kris, I think you're a bit confused on the purpose of the 6lowpan >> header type. The header type is completely orthogonal to whether >> people choose to utilize strong integrity checks. The dispatch type is >> analogous to the Next Header field in IP packets. It gives flexibility >> in constructing different header stacks, yet is easy to parse. Its >> what enables IPv6 to support extension headers. >> >> Robust networks always need strong integrity checks, but integrity >> checks don't replace dispatch types. >> >> -- >> Jonathan Hui >> >> >> Kris Pister wrote: >>> Here's a thread from ISA that may be of interest. 6lowpan had some >>> email a few months ago on the topic of coexistence, and the level of >>> safety afforded by the dispatch byte. If you read Gerry's email >>> below, you'll see that once again this approach has proven hazardous >>> in a public forum. I'd say at least half of the WSN companies that >>> I've talked to have fallen victim to this (Dust included - back in >>> 2003!). >>> >>> ksjp >>> >>> Kris Pister wrote: >>>> This is an example of a very common problem seen in the early stages >>>> of software development in sensor networks. Wireless HART does not, >>>> and SP100.11a should not, suffer from it. >>>> The general problem is that those unfamiliar with working in a >>>> regulated but unlicensed band are not used to the idea that there is >>>> a lot of traffic flying around at 2.4GHz, employing a wide range of >>>> MAC protocols. More subtly, even well-formed packets in your own >>>> network can be corrupted in flight in such a way that the frame >>>> check sequence (FCS) does not catch the errors. In both cases, the >>>> naive system will try to execute the instructions in a packet that >>>> is essentially random, with disastrous results. >>>> In TSMP (the basis of Wireless HART and SP100.11a data link layers), >>>> the solution to this problem is to use a message integrity code >>>> (MIC) on every packet. This 32 bit number is a cryptographic hash >>>> of the entire packet, and prevents corrupted or foreign packets from >>>> being accepted at the lowest layer of the communication stack, with >>>> a probability of 99.99999998% (fewer than one in 4 billion get >>>> through on average). For a reliable network, even this is not >>>> enough, since undetected errors might occur on the order of once per >>>> year per network. >>>> Another 32 bit MIC is used at the application layer to verify the >>>> authenticity of the sender of the message. Combined with the DLL >>>> MIC, this reduces the probability of executing random packets to >>>> something like once per age-of-the-universe per network. Even with >>>> energy scavenging, that's a long time! :) >>>> >>>> The lesson here is simple: never *ever* turn off crypto in your >>>> networks. Use well-known published keys if you want to, but keep >>>> the integrity codes in place. >>>> >>>> ksjp >>>> -- >>>> Prof. EECS, UC Berkeley >>>> Founder & CTO, Dust Networks >>>> >>>> >>>> ________________________________ >>>> >>>> From: Gerry Nadler [mailto:gnadler@machinetalker.com] >>>> Sent: Mon 10/29/2007 10:31 AM >>>> To: ISA100 >>>> Subject: [sp100] interoperability problems at ISA Houston >>>> >>>> >>>> Everyone: >>>> >>>> >>>> >>>> On the evening before the ISA exhibition (Monday night) I visited >>>> the show floor to see the ISA-100 booth. Most all the booths were >>>> unmanned and all was quiet except for a small group in one booth >>>> that was having problems. They were using Zigbee. Their Zigbee >>>> system was not functioning due to some type of interference. (The >>>> name of the company is not mentioned here because for the purpose of >>>> this note it is not necessary). I walked by the booth and the >>>> people were very frustrated as to the cause of their problem. I >>>> tried to help. We set up a 15.4 packet sniffer to look at the >>>> packets to see what was the cause of the problem. The vendor was >>>> using Ember chips and software stack. We got the sniffer running >>>> and looked at the packets and we saw the problem. There was nothing >>>> we could do because the 15.4 stack was being corrupted by an illegal >>>> packet(or so I thought at the time). The packets were sent to the >>>> Ember software team for analysis and they made modification to their >>>> stack and the vendor was up and running by the time the show opened >>>> on Tuesday. >>>> >>>> >>>> >>>> I walked around the show floor at about 11 PM at night and looked to >>>> see who might be transmitting 15.4 packets. I checked the ISA-100 >>>> booth and the surrounding area and everything seemed to be shut >>>> down. I walked up and down every aisle looking for a possible >>>> transmission site. I didn't see anything except for the wireless >>>> HART booth where there was "flashing LEDs", a possible sign of RF >>>> transmissions. It could have been another Zigbee/SP-100 >>>> transmission site as well. >>>> >>>> >>>> >>>> On Tuesday I stopped by the booth and Bob LeFort the president of >>>> Ember was at the booth. We had a nice chat and when I got back home >>>> I asked him if he could have his software people write up what they >>>> found. Below is a short analysis of the problem written by the VP >>>> of engineering at Ember. They did a great job and had the problem >>>> diagnosed and fixed before Houston show opened the next day. >>>> >>>> >>>> >>>> I have included this because depending on your point of view this >>>> may be harbinger of things to come or it can be dismissed.. I >>>> thought the group should know what we may or may not expect in the >>>> future. >>>> >>>> >>>> >>>> Gerry >>>> >>>> >>>> >>>> Ember report by Skip Ashton, Ember VP Engineering. >>>> >>>> >>>> The cause of the problem was an Ember device receiving a coordinator >>>> realignment packet. Under the 15.4 specification, this packet is >>>> intended to be unicast to an orphan device, or broadcast to a >>>> network that is changing its parameters. Receipt of this packet was >>>> causing the Ember device to change channels and PAN ID. The 15.4 >>>> specification requires this packet be sent with a 64 bit extended >>>> address for the source. However, in this case the 16 bit >>>> coordinator address for the source was being used making this an >>>> illegal packet. This illegal packet to change PAN ID was being >>>> generated by another network device at a regular interval. >>>> >>>> >>>> >>>> Reception and processing of the coordinator realignment command is >>>> mandatory within 802.15.4. However, it should be ignored by devices >>>> that are using higher levels of control over items such as channel >>>> change. A ZigBee network device is not expecting a coordinator >>>> realignment. This command is not used to change channels within >>>> ZigBee, because a higher layer network command is used instead. As >>>> such, these type of MAC commands should be ignored. >>>> >>>> >>>> >>>> A change was made to our stack to ignore such MAC command frames >>>> once the ZigBee stack is operational. >>>> --- You are currently subscribed to sp100 as: >>>> kpister@dustnetworks.com To unsubscribe send a blank email to >>>> leave-sp100-100144H@isa-online.org >>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Nov 01 02:58:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0S-0002Vh-2Z; Thu, 01 Nov 2007 02:58:20 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1InU0R-0002Vb-OJ for rsn-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 02:58:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0R-0002VT-DU for rsn@ietf.org; Thu, 01 Nov 2007 02:58:19 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InU0R-0002t9-2n for rsn@ietf.org; Thu, 01 Nov 2007 02:58:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id CF7FAA963A; Wed, 31 Oct 2007 23:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -0.564 X-Spam-Level: X-Spam-Status: No, score=-0.564 tagged_above=-10 required=6.6 tests=[AWL=-0.011, 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 39llXN1okSyN; Wed, 31 Oct 2007 23:58:15 -0700 (PDT) Received: from [192.168.1.143] (adsl-71-142-67-12.dsl.pltn13.pacbell.net [71.142.67.12]) by mail.sf.archrock.com (Postfix) with ESMTP id 2A760A962E; Wed, 31 Oct 2007 23:58:15 -0700 (PDT) Message-ID: <47297907.6060300@archrock.com> Date: Wed, 31 Oct 2007 23:58:15 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis Subject: Re: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> <1193883110.8654.40.camel@dellx1> 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: cf4fa59384e76e63313391b70cd0dd25 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org, Geoff Mulligan X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Philip Levis wrote: > I don't understand; NALP is the set of all dispatch bytes whose first > two bits are zero. If IANA isn't responsible for the NALP values, then > I assume no-one is and it's a free-for-all of collision? I agree with Geoff, IANA should not be concerned with NALP and how it is structured. NALP allows protocols that may have nothing to do with IP. Typically, the IEEE Registration Authority is responsible for maintaining their own namespace with ethertypes. Back in 2005, it seems that the WG did consider using LLC/SNAP encapsulation, but that adds another 8 octets and was thought to be too heavy weight. -- Jonathan Hui jhui@archrock.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Nov 01 16:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ingva-0001AM-68; Thu, 01 Nov 2007 16:46:10 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1InPXa-0005RK-WA for rsn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 22:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPXa-0005RA-Lr for rsn@ietf.org; Wed, 31 Oct 2007 22:12:14 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InPXT-0008MK-LD for rsn@ietf.org; Wed, 31 Oct 2007 22:12:14 -0400 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 lA12Bl8t018131; Wed, 31 Oct 2007 20:11:47 -0600 (MDT) Subject: Re: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston From: Geoff Mulligan To: Philip Levis In-Reply-To: <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> Content-Type: text/plain Date: Wed, 31 Oct 2007 20:11:50 -0600 Message-Id: <1193883110.8654.40.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Thu, 01 Nov 2007 16:46:08 -0400 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Phil, If the TinyOS research protocol would be possibly using 6lowpan designated other headers, such as HC1 or HC1g or the Frag header, then I would think that rather than using NALP, they could request a non-NALP dispatch value. I would like to see devices that not attempting to utilize any IP and 6lowpan headers/functions assign the first 2 bits after the 15.4 header to Zero. What they do with the other 6 bits then are up to them. I would recommend that IANA stay out of that fray. geoff On Wed, 2007-10-31 at 15:18 -0700, Philip Levis wrote: > On Oct 31, 2007, at 3:05 PM, Kris Pister wrote: > > > Hmm. I guess you're right after all - I am confused. I completely > > agree with your statements below, but then I re-read RFC4944 and it > > says: > > "Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes > > should include a byte matching this pattern immediately following > > the 802.15.4. header." > > And I read the Arch Rock 6LoWPAN tutorial (which is really well > > done, by the way), and it says "dispatch: coexistence with other > > protocols over the same link". These statements do not appear to > > be aligned with what you wrote below. > > > > As I see it, there are only three options: > > 1) we assume that MAC-layer MICs are always used for 6LoWPAN, > > perhaps with a well-known 6LoWPAN key, and then there is never any > > question about coexistence. If you're parsing the dispatch byte, > > you already know that this is a 6LoWPAN frame. > > 2) we assume 1, but plan to share MAC-layer crypto with other non- > > LoWPAN protocols. This sounds like a bad idea from a crypto > > standpoint. > > 3) we believe that non-6LoWPAN frames may get through to thFrom rsn-bounces@ietf.org Thu Nov 01 16:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ingva-0001AM-68; Thu, 01 Nov 2007 16:46:10 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1InPXa-0005RK-WA for rsn-confirm+ok@megatron.ietf.org; Wed, 31 Oct 2007 22:12:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InPXa-0005RA-Lr for rsn@ietf.org; Wed, 31 Oct 2007 22:12:14 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InPXT-0008MK-LD for rsn@ietf.org; Wed, 31 Oct 2007 22:12:14 -0400 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 lA12Bl8t018131; Wed, 31 Oct 2007 20:11:47 -0600 (MDT) Subject: Re: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston From: Geoff Mulligan To: Philip Levis In-Reply-To: <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> Content-Type: text/plain Date: Wed, 31 Oct 2007 20:11:50 -0600 Message-Id: <1193883110.8654.40.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-Mailman-Approved-At: Thu, 01 Nov 2007 16:46:08 -0400 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Phil, If the TinyOS research protocol would be possibly using 6lowpan designated other headers, such as HC1 or HC1g or the Frag header, then I would think that rather than using NALP, they could request a non-NALP dispatch value. I would like to see devices that not attempting to utilize any IP and 6lowpan headers/functions assign the first 2 bits after the 15.4 header to Zero. What they do with the other 6 bits then are up to them. I would recommend that IANA stay out of that fray. geoff On Wed, 2007-10-31 at 15:18 -0700, Philip Levis wrote: > On Oct 31, 2007, at 3:05 PM, Kris Pister wrote: > > > Hmm. I guess you're right after all - I am confused. I completely > > agree with your statements below, but then I re-read RFC4944 and it > > says: > > "Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes > > should include a byte matching this pattern immediately following > > the 802.15.4. header." > > And I read the Arch Rock 6LoWPAN tutorial (which is really well > > done, by the way), and it says "dispatch: coexistence with other > > protocols over the same link". These statements do not appear to > > be aligned with what you wrote below. > > > > As I see it, there are only three options: > > 1) we assume that MAC-layer MICs are always used for 6LoWPAN, > > perhaps with a well-known 6LoWPAN key, and then there is never any > > question about coexistence. If you're parsing the dispatch byte, > > you already know that this is a 6LoWPAN frame. > > 2) we assume 1, but plan to share MAC-layer crypto with other non- > > LoWPAN protocols. This sounds like a bad idea from a crypto > > standpoint. > > 3) we believe that non-6LoWPAN frames may get through to the > > network layer, talk about "coexsistence", and cross our fingers > > that 15.4 toy designers are all familiar with and abide by the IETF > > recommendations. Down this path lies mysteriously failed networks, > > broken deployments, and more of the same semi-functionality that > > has held WSN commercialization back for the last 5 years. > > > > So which is it? My vote is #1. > > I think it's #2. > > The idea is that you can design protocols that safely operate > alongside 6lowpan. If you're concerned about people just grabbing > NALP identifiers willy-nilly, well, that's what IANA is for. To give > an example, chances are TinyOS 2.1 will introduce an NALP byte for > its protocols so TinyOS research protocols can coexist on a node also > running 6lowpan. > > Phil > > > _______________________________________________ > 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 From rsn-bounces@ietf.org Thu Nov 01 16:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ingva-0001Ap-Be; Thu, 01 Nov 2007 16:46:10 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1InZxw-00060I-KB for rsn-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 09:20:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZxv-00060A-Lp for rsn@ietf.org; Thu, 01 Nov 2007 09:20:08 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InZxo-0001Gz-Ot for rsn@ietf.org; Thu, 01 Nov 2007 09:20:07 -0400 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 lA1DJgAI020820; Thu, 1 Nov 2007 07:19:42 -0600 (MDT) Subject: Re: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston From: Geoff Mulligan To: Philip Levis In-Reply-To: References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> <1193883110.8654.40.camel@dellx1> Content-Type: text/plain Date: Thu, 01 Nov 2007 07:19:47 -0600 Message-Id: <1193923187.8654.53.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Thu, 01 Nov 2007 16:46:08 -0400 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org You're right Phil. IANA is probably responsible for those 6 bits also, but my thought was, since there are only 64 values, that it is really probably too small a name space for all of the companies doing proprietary stuff and if they just set their first two bits to 00 then at least they can be determined not to be a 6lowpan packet. Yes it would be a free for all, but after the 64 values are used up, there is no choice for other companies to but to either not use 00 or to overlap with an already used value. I'd prefer to say that those bit are not defined and applice > > network layer, talk about "coexsistence", and cross our fingers > > that 15.4 toy designers are all familiar with and abide by the IETF > > recommendations. Down this path lies mysteriously failed networks, > > broken deployments, and more of the same semi-functionality that > > has held WSN commercialization back for the last 5 years. > > > > So which is it? My vote is #1. > > I think it's #2. > > The idea is that you can design protocols that safely operate > alongside 6lowpan. If you're concerned about people just grabbing > NALP identifiers willy-nilly, well, that's what IANA is for. To give > an example, chances are TinyOS 2.1 will introduce an NALP byte for > its protocols so TinyOS research protocols can coexist on a node also > running 6lowpan. > > Phil > > > _______________________________________________ > 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 From rsn-bounces@ietf.org Thu Nov 01 16:46:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ingva-0001Ap-Be; Thu, 01 Nov 2007 16:46:10 -0400 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1InZxw-00060I-KB for rsn-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 09:20:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZxv-00060A-Lp for rsn@ietf.org; Thu, 01 Nov 2007 09:20:08 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InZxo-0001Gz-Ot for rsn@ietf.org; Thu, 01 Nov 2007 09:20:07 -0400 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 lA1DJgAI020820; Thu, 1 Nov 2007 07:19:42 -0600 (MDT) Subject: Re: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems at ISA Houston From: Geoff Mulligan To: Philip Levis In-Reply-To: References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com> <47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com> <4728FC22.1030500@eecs.berkeley.edu> <59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu> <1193883110.8654.40.camel@dellx1> Content-Type: text/plain Date: Thu, 01 Nov 2007 07:19:47 -0600 Message-Id: <1193923187.8654.53.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Thu, 01 Nov 2007 16:46:08 -0400 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org You're right Phil. IANA is probably responsible for those 6 bits also, but my thought was, since there are only 64 values, that it is really probably too small a name space for all of the companies doing proprietary stuff and if they just set their first two bits to 00 then at least they can be determined not to be a 6lowpan packet. Yes it would be a free for all, but after the 64 values are used up, there is no choice for other companies to but to either not use 00 or to overlap with an already used value. I'd prefer to say that those bit are not defined and application specific rather than try to put some other structure and naming. I thought also by allowing them to be application defined, these NALP protocols would overlap their proprietary protocol and therefore not need to burn an entire byte for the NALP dispatch and we might get more companies to accept using just 2 bits to help deal with packet differentiation. geoff On Wed, 2007-10-31 at 20:44 -0700, Philip Levis wrote: > On Oct 31, 2007, at 7:11 PM, Geoff Mulligan wrote: > > > Phil, > > > > If the TinyOS research protocol would be possibly using 6lowpan > > designated other headers, such as HC1 or HC1g or the Frag header, > > then I > > would think that rather than using NALP, they could request a non-NALP > > dispatch value. > > > > > > I would like to see devices that not attempting to utilize any IP and > > 6lowpan headers/functions assign the first 2 bits after the 15.4 > > header > > to Zero. What they do with the other 6 bits then are up to them. I > > would recommend that IANA stay out of that fray. > > I don't understand; NALP is the set of all dispatch bytes whose first > two bits are zero. If IANA isn't responsible for the NALP values, > then I assume no-one is and it's a free-for-all of collision? > > Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn ation specific rather than try to put some other structure and naming. I thought also by allowing them to be application defined, these NALP protocols would overlap their proprietary protocol and therefore not need to burn an entire byte for the NALP dispatch and we might get more companies to accept using just 2 bits to help deal with packet differentiation. geoff On Wed, 2007-10-31 at 20:44 -0700, Philip Levis wrote: > On Oct 31, 2007, at 7:11 PM, Geoff Mulligan wrote: > > > Phil, > > > > If the TinyOS research protocol would be possibly using 6lowpan > > designated other headers, such as HC1 or HC1g or the Frag header, > > then I > > would think that rather than using NALP, they could request a non-NALP > > dispatch value. > > > > > > I would like to see devices that not attempting to utilize any IP and > > 6lowpan headers/functions assign the first 2 bits after the 15.4 > > header > > to Zero. What they do with the other 6 bits then are up to them. I > > would recommend that IANA stay out of that fray. > > I don't understand; NALP is the set of all dispatch bytes whose first > two bits are zero. If IANA isn't responsible for the NALP values, > then I assume no-one is and it's a free-for-all of collision? > > Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Nov 05 07:31:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip16i-00073w-VJ; Mon, 05 Nov 2007 07:31:08 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Ip16h-00071j-Lv for rsn-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 07:31:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip16h-000706-8J for rsn@ietf.org; Mon, 05 Nov 2007 07:31:07 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip16f-0005P3-SS for rsn@ietf.org; Mon, 05 Nov 2007 07:31:07 -0500 X-IronPort-AV: E=Sophos;i="4.21,372,1188802800"; d="scan'208";a="246815366" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by sj-iport-6.cisco.com with ESMTP; 05 Nov 2007 04:31:04 -0800 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 lA5CV3kR012879; Mon, 5 Nov 2007 13:31:03 +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 lA5CUpqr001012; Mon, 5 Nov 2007 12:31:01 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:30:53 +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: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems atISA Houston Date: Mon, 5 Nov 2007 13:30:48 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04B709BC@xmb-ams-337.emea.cisco.com> In-Reply-To: <1193923187.8654.53.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems atISA Houston Thread-Index: AcgcyN27joctxhnUTTeukLgNSiSzpwC3gpIQ References: <3D8BC6C339A9894C9955EF58D3722D65FBF4AD@dust-exch-02.dusthq.dust-inc.com><47275963.2050001@eecs.berkeley.edu> <47276369.8020603@archrock.com><4728FC22.1030500@eecs.berkeley.edu><59516A93-BA7F-4D6A-B568-C0A39CCB6B7C@cs.stanford.edu><1193883110.8654.40.camel@dellx1> <1193923187.8654.53.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "Philip Levis" X-OriginalArrivalTime: 05 Nov 2007 12:30:53.0325 (UTC) FILETIME=[B4CAD3D0:01C81FA7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--15.929800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3756; t=1194265863; x=1195129863; 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[RSN]=20Re=3A=20[6lowpan]=20Re=3A=20[sp100]=20interop erability=20problems=20atISA=20Houston |Sender:=20; bh=ihEU2cnaD9LixeBnbb49YP+kgTa08RObo2Ev9jiBcvw=; b=Ob5Sw5VRT24/5hZdzNhuWoAHb+ci8xxDolTyQM2pD/GfYaaAQVMEyQ7qzezj4aiaVe6mg04v 5Sip+Md4zVd3bmwYrEykH5Fy3yy92Kt0siHzpeYIqv3UUw0uRhs8DogD; 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: a8a20a483a84f747e56475e290ee868e Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Geoff: It is a common thing to reserve one value for experimentations (see RFC 4064 for MIP4). Maybe we should write a small IETF spec that does this here too. RFC 4064 intro: " Mobile IPv4 message types range from 0 to 255. This document reserves a message type for experimental purposes, to evaluate enhancements to Mobile IPv4 messages before a formal standards proposal is issued. Without experimental message capability, one would have to select a type value from the range defined for IANA assignment, which may result in collisions. Within a message, Mobile IP defines a general extension mechanism allowing optional information to be carried by Mobile IP control messages. Extensions are not skippable if defined in the range [0- 127] and are skippable if defined in the range [128-255]. This document reserves extension types in both the skippable and non- skippable ranges for experimental use. Mobile IPv4 defines error codes for use by the FA [64-127] and HA [128-192]. This document reserves an error code in both of these ranges for experimental use. The definition of experimental numbers in this document is made according to the recommendation of Section 2.2 of BCP 82, RFC 3692. " Also, RFCs like 3115 enable vendor extensions, which is also a pretty good idea that we should keep in mind. What do you think? Pascal >-----Original Message----- >From: Geoff Mulligan [mailto:geoff@mulligan.com] >Sent: Thursday, November 01, 2007 2:20 PM >To: Philip Levis >Cc: 6lowpan; rsn@ietf.org >Subject: Re: [RSN] Re: [6lowpan] Re: [sp100] interoperability problems atISA Houston > >You're right Phil. IANA is probably responsible for those 6 bits also, >but my thought was, since there are only 64 values, that it is really >probably too small a name space for all of the companies doing >proprietary stuff and if they just set their first two bits to 00 then >at least they can be determined not to be a 6lowpan packet. > >Yes it would be a free for all, but after the 64 values are used up, >there is no choice for other companies to but to either not use 00 or to >overlap with an already used value. I'd prefer to say that those bit >are not defined and application specific rather than try to put some >other structure and naming. > >I thought also by allowing them to be application defined, these NALP >protocols would overlap their proprietary protocol and therefore not >need to burn an entire byte for the NALP dispatch and we might get more >companies to accept using just 2 bits to help deal with packet >differentiation. > > geoff > >On Wed, 2007-10-31 at 20:44 -0700, Philip Levis wrote: >> On Oct 31, 2007, at 7:11 PM, Geoff Mulligan wrote: >> >> > Phil, >> > >> > If the TinyOS research protocol would be possibly using 6lowpan >> > designated other headers, such as HC1 or HC1g or the Frag header, >> > then I >> > would think that rather than using NALP, they could request a non-NALP >> > dispatch value. >> >> >> > >> > I would like to see devices that not attempting to utilize any IP and >> > 6lowpan headers/functions assign the first 2 bits after the 15.4 >> > header >> > to Zero. What they do with the other 6 bits then are up to them. I >> > would recommend that IANA stay out of that fray. >> >> I don't understand; NALP is the set of all dispatch bytes whose first >> two bits are zero. If IANA isn't responsible for the NALP values, >> then I assume no-one is and it's a free-for-all of collision? >> >> Phil > > > >_______________________________________________ >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 From rsn-bounces@ietf.org Sat Nov 10 17:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqyse-0001V9-VS; Sat, 10 Nov 2007 17:32:44 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iqyse-0001V4-Bq for rsn-confirm+ok@megatron.ietf.org; Sat, 10 Nov 2007 17:32:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqysZ-0001Sj-D4 for rsn@ietf.org; Sat, 10 Nov 2007 17:32:39 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqysV-00078W-Uz for rsn@ietf.org; Sat, 10 Nov 2007 17:32: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 lAAMWXRu004513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 10 Nov 2007 14:32:35 -0800 (PST) Message-ID: <4736317C.5030809@eecs.berkeley.edu> Date: Sat, 10 Nov 2007 14:32:28 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rsn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [RSN] industrial requirements X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Version 0 of the routing requirements for industrial automation is now available. Comments and questions are eagerly awaited. http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00.txt ksjp _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Nov 12 13:33:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ire61-0002Xh-GJ; Mon, 12 Nov 2007 13:33:17 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Ire5y-0002WW-U4 for rsn-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 13:33:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ire5t-0002SC-T0 for rsn@ietf.org; Mon, 12 Nov 2007 13:33:09 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ire5t-0004VP-IH for rsn@ietf.org; Mon, 12 Nov 2007 13:33:09 -0500 X-IronPort-AV: E=Sophos;i="4.21,406,1188802800"; d="scan'208";a="545685691" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 12 Nov 2007 10:33:09 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lACIX8mY022236 for ; Mon, 12 Nov 2007 10:33:09 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lACIWeQa021868 for ; Mon, 12 Nov 2007 18:33:08 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 13:33:07 -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, 12 Nov 2007 18:33:07 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Mon, 12 Nov 2007 13:33:06 -0500 From: JP Vasseur To: Message-ID: Thread-Topic: BOF Schedule, proposed agenda and WG charter Thread-Index: AcglWndetblNnJFNEdyHogANk8WjQA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Nov 2007 18:33:07.0551 (UTC) FILETIME=[784AC6F0:01C8255A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15540.002 X-TM-AS-Result: No--9.099100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=644; t=1194892389; x=1195756389; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20BOF=20Schedule,=20proposed=20agenda=20and=20WG=20charter |Sender:=20; bh=Z1QMzDaYa8gPSNyRpRvJCAoyvDXlyU8fWj4DXtCGHwg=; b=GBbIK8upB6ic7ZCY47tkmm1ChhS2s9g3Jj2VYVQM0iqQkWAdxSBje5UjvfgqCEehfe7ved7l z2jnZRI6uV25equRwwZM4rUWoS2e5KjHrNLpfyGZug5k6ftb0Gly1JhhMc7OdD/Rr774fsHVrb nzyILdSRGyGJbxKFQS3EHhY+c=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [RSN] BOF Schedule, proposed agenda and WG charter X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear all, So the BOF will be held on Thursday: 1510-1610 Afternoon Session II Oak INT mip4 Mobility for IPv4 WG Salon 2 RAI peppermint Provisioning Extensions in Peering Registries for Multimedia INTerconnection BOF Salon 1 RTG isis IS-IS for IP Internets WG Salon A/B RTG rl2n Routing For Low Power and Lossy Networks BOF Cypress SEC btns Better-Than-Nothing Security WG I uploaded the BOF Agenda: http://www3.ietf.org/proceedings/07dec/agenda/rl2n.txt And we updated the Proposed WG Charter: http://www.employees.org/~jvasseur/ Comments welcome. Thanks. JP and David. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Nov 12 21:44:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irllh-0007Kq-4W; Mon, 12 Nov 2007 21:44:49 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Irllg-0007Kk-76 for rsn-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 21:44:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irllf-0007Kc-RW for rsn@ietf.org; Mon, 12 Nov 2007 21:44:47 -0500 Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irllf-0006yc-Cb for rsn@ietf.org; Mon, 12 Nov 2007 21:44:47 -0500 Received: from soyoungpc ([129.254.72.94]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 11:51:08 +0900 From: "Soyoung Hwang" To: "'Kris Pister'" , References: <4736317C.5030809@eecs.berkeley.edu> Subject: RE: [RSN] industrial requirements Date: Tue, 13 Nov 2007 11:45:23 +0900 Message-ID: <000001c8259f$3d60c900$5e48fe81@soyoungpc> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acgj6pKq8g4RR1KERTmSEwpkzhVs7wBsy2cg In-Reply-To: <4736317C.5030809@eecs.berkeley.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-OriginalArrivalTime: 13 Nov 2007 02:51:08.0162 (UTC) FILETIME=[0A862E20:01C825A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hello! A minor thing... :) >> 2.1. Applications and Traffic Patterns >> The industrial market classifies process applications into three broad categories and six classes. There are only two categories, safety and monitoring. Is there the other one? Soyoung -----Original Message----- From: Kris Pister [mailto:pister@eecs.berkeley.edu] Sent: Sunday, November 11, 2007 7:32 AM To: rsn@ietf.org Subject: [RSN] industrial requirements Version 0 of the routing requirements for industrial automation is now available. Comments and questions are eagerly awaited. http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00. txt ksjp _______________________________________________ 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 From rsn-bounces@ietf.org Tue Nov 13 03:30:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrAU-0006Al-6y; Tue, 13 Nov 2007 03:30:46 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IrrAS-0006AS-Nt for rsn-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 03:30:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrAN-00065Y-Hy for rsn@ietf.org; Tue, 13 Nov 2007 03:30:39 -0500 Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrrAK-0000K7-5M for rsn@ietf.org; Tue, 13 Nov 2007 03:30:39 -0500 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: [RSN] connected home requirements v02 Date: Tue, 13 Nov 2007 09:30:20 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB687B7@zensys17.zensys.local> In-Reply-To: <4736317C.5030809@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] connected home requirements v02 Thread-Index: Acgj6ZrhDFSoecGrTzGViHzdoeuq+gB5U6HA References: <4736317C.5030809@eecs.berkeley.edu> From: "Anders Brandt" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Gentlemen, Version 2 of the routing requirements for the connected home is now available. http://www.ietf.org/internet-drafts/draft-brandt-rl2n-home-routing-reqs- 02.txt Please do not hesitate to comment or post clarifying questions. Best regards, Anders Brandt _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Nov 13 09:35:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrwrS-00049b-45; Tue, 13 Nov 2007 09:35:30 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IrwrR-00049W-LG for rsn-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 09:35:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrwrR-00049O-A8 for rsn@ietf.org; Tue, 13 Nov 2007 09:35:29 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrwrP-0003yx-26 for rsn@ietf.org; Tue, 13 Nov 2007 09:35:29 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1198559nfb for ; Tue, 13 Nov 2007 06:35:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=uBqpy0nV+K+m7Vj8IvdbVWemlacLQSU9WCk90LM04dg=; b=Rfg8JxBljkaZyWQPciaRIKQCLsoTYuNsZUFAeYzum/uw7A8C/EleEaGXi/h7wZYnZikMwtDBh3ygz/mQK74lUSOxUTHc86Z/ae0KTVDCdonxrRJs7VAnpUc461i7GIBnoxLkPOUIqapwPtbS9VcuJvmxovzs41G9h5DMo0itMW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=F7n4zc3clb2syoiLW2atHEyAYuJjnE1ZNd6UE3th3J40lu1fj0LqRWTQ5kW+5sNkzBkFnmXReE0m0d8RibwoNvtwNb/tvHPFu0KbJKJIpyhQ8vm8etGU02RxcTq7xE+4YL2q1LcDBPQ7cVkrkPyfY9Czb7p4PU5NLphBiC45Iw4= Received: by 10.78.185.15 with SMTP id i15mr6705862huf.1194964525640; Tue, 13 Nov 2007 06:35:25 -0800 (PST) Received: by 10.78.19.9 with HTTP; Tue, 13 Nov 2007 06:35:25 -0800 (PST) Message-ID: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.com> Date: Tue, 13 Nov 2007 20:05:25 +0530 From: "Ian Chakeres" To: "JP Vasseur" Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org RSN/RL2N, I think the WG charter is still fuzzy, perhaps it will gel after the pre-BOF meetup. Have you considered using an exploratory group? It would perhaps help create the focus needed. http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt Ian On Nov 13, 2007 12:03 AM, JP Vasseur wrote: > Dear all, > > So the BOF will be held on Thursday: > > 1510-1610 Afternoon Session II > Oak INT mip4 Mobility for IPv4 WG > Salon 2 RAI peppermint Provisioning Extensions in Peering > Registries for Multimedia INTerconnection BOF > Salon 1 RTG isis IS-IS for IP Internets WG > Salon A/B RTG rl2n Routing For Low Power and Lossy Networks BOF > Cypress SEC btns Better-Than-Nothing Security WG > > I uploaded the BOF Agenda: > http://www3.ietf.org/proceedings/07dec/agenda/rl2n.txt > > And we updated the Proposed WG Charter: http://www.employees.org/~jvasseur/ > > Comments welcome. > > Thanks. > > 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 From rsn-bounces@ietf.org Tue Nov 13 13:38:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0eD-00070b-G7; Tue, 13 Nov 2007 13:38:05 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Is0eC-0006yn-KS for rsn-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 13:38:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0eB-0006xL-Qe for rsn@ietf.org; Tue, 13 Nov 2007 13:38:03 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is0eB-0001gV-G9 for rsn@ietf.org; Tue, 13 Nov 2007 13:38:03 -0500 Received: from dnab422094.stanford.edu ([171.66.32.148]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Is0eA-0004In-7m; Tue, 13 Nov 2007 10:38:02 -0800 In-Reply-To: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.com> References: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.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: [RSN] BOF Schedule, proposed agenda and WG charter Date: Tue, 13 Nov 2007 10:37:53 -0800 To: Ian Chakeres X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.4 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: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Nov 13, 2007, at 6:35 AM, Ian Chakeres wrote: > RSN/RL2N, > > I think the WG charter is still fuzzy, perhaps it will gel after the > pre-BOF meetup. > > Have you considered using an exploratory group? It would perhaps help > create the focus needed. > > http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt Ian, Let me try a rewording of the 4th paragraph that does not change the content in any way: The Working Group has two goals. The first is to survey and establish the requirements for the applications described above. The second is to design and develop routing solutions for these applications that meet the key RL2N requirements of being energy efficient, dealing with dynamic link loss rates, and having small routing state. What do you feel is fuzzy here? Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Nov 13 13:55:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0ua-0005TD-K4; Tue, 13 Nov 2007 13:55:00 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Is0uY-0005RP-Hx for rsn-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 13:54:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0uY-0005Qh-5e for rsn@ietf.org; Tue, 13 Nov 2007 13:54:58 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is0uX-0002Fr-AU for rsn@ietf.org; Tue, 13 Nov 2007 13:54:58 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Nov 2007 13:54:55 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lADIsu8L013221; Tue, 13 Nov 2007 13:54:56 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lADIsuV3017150; Tue, 13 Nov 2007 18:54:56 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 13:54:56 -0500 Received: from 161.44.71.191 ([161.44.71.191]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Nov 2007 18:54:56 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 13 Nov 2007 13:54:54 -0500 Subject: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter From: JP Vasseur To: Ian Chakeres Message-ID: Thread-Topic: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter Thread-Index: AcgmJq1o7AvDiJIZEdyAEAANk8WjQA== In-Reply-To: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Nov 2007 18:54:56.0953 (UTC) FILETIME=[AF2B6A90:01C82626] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15542.002 X-TM-AS-Result: No--13.161500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7158; t=1194980096; x=1195844096; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20**=20ALL, =20Please=20read=20and=20comment=20**=20Re=3A=20[RSN ]=20BOF=20Schedule,=0A=20proposed=20agenda=20and=20WG=20charter |Sender:=20 |To:=20Ian=20Chakeres=20; bh=2UKJpoe2dlJW7C3uKZg0gkiQvRXEfB7pEY7s2NMlvts=; b=d+tTbCzNdj7vsXI5EpGO/OX/ZkUPvzqmLV01IcwJ1ZpybeK75Jo2VdRBcZex3JQUfnaHG+K5 kMq6aJE8V9pHHXOY5p6C+n0HQxVb8deBuqW8C7Am0b92SpMeLVVjQr3K; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 2.6 (++) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Ian, You asked several relevant questions in a previous email thread to which we replied and that we took into account in the proposed WG charter. There are still clarifications to be made (IPv4 / v6, ...). We plan to post early next week the minutes of the pre-WG meeting that will take place this coming Thursday in order to get additional feed-back and adjust the proposed charter before the BOF. As matter of fact, we have a good set of people with the required background and level of energy to make relevant contribution that are in clear agreement on what needs to be done. We have received so far lots of positive and constructive feed-backs. That being said, since you pointed to draft-aboba-sg-experiment-04.txt, I'm tempted to provide a concise reply to these questions, which will also allow the people on the list to express their opinion and make sure that we are all on the same page. - Are the issues that the working group plans to address clear and relevant to the Internet community? JP> Based on the number of feed-backs received so far and the comments that we got during the Routing area meeting, it seems quite clear but if there is anything unclear, we will be more happy to clarify. - Are the goals specific and reasonably achievable, and achievable within a reasonable time frame? JP> One of the challenges with L2Ns is that the scope may potentially be wide. We had initially started to collect the requirements in an ID but we decided to adopt an application-specific approach, which has proven to be quite efficient in several other WGs: " There is wide scope of application areas for L2Ns, including industrial monitoring, building HVAC and lighting control, connected home, healthcare, environmental monitoring, agricultural, smart cities, logistics, and refrigeration. The L2N WG will focus on routing solutions for a subset of these deployment scenarios, namely industrial, connected home/building and smart cities." There are already two ID for Industrial and Connected Home driven by authors with a strong expertise in each area and deployment background. Thus the work is SCOPED and WELL UNDERSTOOD. - What are the risks and urgency of the work, to determine the level of effort required? JP> See our presentation during the Routing Area meeting in Chicago. Proprietary solutions are being deployed TODAY. It is thus urgent to specify an IP standard based solution. The problem is well understood and solutions are deployed so the level of risk is minor. - Do the working group's activities overlap with those of another working group? ... JP> There is no overlap but of course RL2N *will* have to work with other WGs for sure such as 6lowpan (see the consensual decision wrt to routing), MANET, ... - Is there sufficient interest within the IETF in the working group's topic with enough people willing to expend the effort to produce the desired result (e.g., a protocol specification)? ... JP> Looking at the number of people involved, it is much look like it is. - Is there enough expertise within the IETF in the working group's topic, and are those people interested in contributing in the working group? ... JP> This is a key question particularly relevant here since L2Ns are quite specific and require a set of areas of expertise. When we first started this initiative we spent time making sure to have experts in L2N (Sensor) and Routing with a different backgrounds (end user, Service Providers, Sensor/L2N/Router Vendors, academic). If you look at the various IDs and active participants, we will see a good representation of each category. - Does a base of interested consumers (end-users) appear to exist for the planned work? ... JP> Yes although I would prefer them to express themselves here. - Does the IETF have a reasonable role to play in the determination of the technology? ... JP> If we want to see IP in L2Ns, it is definitely the case, I do not think that we need to argue here. - Are all known intellectual property rights relevant to the proposed working group's efforts issues understood? JP> The WG may of course have to deal with IPR issues. Nothing specific to the area of L2Ns. - Is the proposed work plan an open IETF effort or is it an attempt to "bless" non-IETF technology where the effect of input from IETF participants may be limited? JP> With no restriction, an open IETF effort. Should a WG be formed, we may want to establish liaison with other SDOs/Alliance (e.g. Zigbee) but the work is an open IETF effort and by no means an attempt to "bless" non IETF technology. - Is there a good understanding of any existing work that is relevant to the topics that the proposed working group is to pursue? This includes work within the IETF and elsewhere. JP> Yes, see the protocol overview draft. Furthermore the participants also have a strong knowledge on what being done elsewhere (SP100, Zigbee, Zwave, ..) - Do the working group's goals overlap with known work in another standards body, and if so is adequate liaison in place? JP> This is the point that I was mentioning before. We're planning to discuss potential liaisons during the pre-WG meeting this week. Thanks. JP. > From: Ian Chakeres > Date: Tue, 13 Nov 2007 20:05:25 +0530 > To: JP Vasseur > Cc: > Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter > > RSN/RL2N, > > I think the WG charter is still fuzzy, perhaps it will gel after the > pre-BOF meetup. > > Have you considered using an exploratory group? It would perhaps help > create the focus needed. > > http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt > > Ian > > On Nov 13, 2007 12:03 AM, JP Vasseur wrote: >> Dear all, >> >> So the BOF will be held on Thursday: >> >> 1510-1610 Afternoon Session II >> Oak INT mip4 Mobility for IPv4 WG >> Salon 2 RAI peppermint Provisioning Extensions in Peering >> Registries for Multimedia INTerconnection BOF >> Salon 1 RTG isis IS-IS for IP Internets WG >> Salon A/B RTG rl2n Routing For Low Power and Lossy Networks BOF >> Cypress SEC btns Better-Than-Nothing Security WG >> >> I uploaded the BOF Agenda: >> http://www3.ietf.org/proceedings/07dec/agenda/rl2n.txt >> >> And we updated the Proposed WG Charter: http://www.employees.org/~jvasseur/ >> >> Comments welcome. >> >> Thanks. >> >> 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 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Nov 13 13:58:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0yM-0004fz-Vi; Tue, 13 Nov 2007 13:58:54 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Is0yL-0004dc-98 for rsn-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 13:58:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0yK-0004ci-Us for rsn@ietf.org; Tue, 13 Nov 2007 13:58:52 -0500 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is0yI-0007pb-33 for rsn@ietf.org; Tue, 13 Nov 2007 13:58:52 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1273703nfb for ; Tue, 13 Nov 2007 10:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hWRYq8xHUAEnNz+NWT2ZO+tE0R+LyqYq0tdYHypLXWY=; b=rIxsHaNarZumLAx2Vt0Byf6XhKcymAVqGK+S8w5Ea/Rx8K2kKDzUQw6X3XYDes4Hs9NYQCxjY+obSW3MFuLHfeRKtjKwZaq3L47nSzkAzXWNirwkCB2DC7xybunSNN72DcUoPfbgGl4gFXICKu9nr33Q2rbXD7zndwynNhBy8wY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=anQCP/JP8lmkMVVPYwVYZkZYvhEABRHgjxHCPPcMjiEfkvf82Qtya3u5IW7A3p3UwV/aato9c6mcjYi36Ov/wZoodw3I2v3R+AJ+Tft578uQJi0K93JCvRf4wLNAFDNwYzX8ujSREHj7y2XbOW8+AYQ+F3dAWcSvL90MQNB1TCA= Received: by 10.78.138.14 with SMTP id l14mr7120571hud.1194980328838; Tue, 13 Nov 2007 10:58:48 -0800 (PST) Received: by 10.78.19.9 with HTTP; Tue, 13 Nov 2007 10:58:48 -0800 (PST) Message-ID: <374005f30711131058g564870c4qeca4728cd448c66c@mail.gmail.com> Date: Wed, 14 Nov 2007 00:28:48 +0530 From: "Ian Chakeres" To: "Philip Levis" Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org I don't think that the group has agreement on the challenges/requirements that will be addressed. Right now, the group is seems to be flushing out a large wish list for requirements in many sensor network areas, but I haven't seen any discussion on which of these requirements MUST be accomplished by a proposed protocol. Also, given the multiple conflicting goals (energy efficient, dynamic loss rates, small routing sate) it would be nice if the group could determine the priority among them. As proposed solutions will probably each tradeoff one goal for another. I think the exploratory group concept seems to match the current state of RSN/RL2N. Ian On Nov 14, 2007 12:07 AM, Philip Levis wrote: > > On Nov 13, 2007, at 6:35 AM, Ian Chakeres wrote: > > > RSN/RL2N, > > > > I think the WG charter is still fuzzy, perhaps it will gel after the > > pre-BOF meetup. > > > > Have you considered using an exploratory group? It would perhaps help > > create the focus needed. > > > > http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt > > Ian, > > Let me try a rewording of the 4th paragraph that does not change the > content in any way: > > The Working Group has two goals. The first is to survey and establish > the requirements for the applications described above. The second is > to design and develop routing solutions for these applications that > meet the key RL2N requirements of being energy efficient, dealing > with dynamic link loss rates, and having small routing state. > > What do you feel is fuzzy here? > > Phil > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Nov 13 14:01:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is10x-0007yB-6X; Tue, 13 Nov 2007 14:01:35 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Is10v-0007wZ-GY for rsn-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 14:01:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is10v-0007v6-3u for rsn@ietf.org; Tue, 13 Nov 2007 14:01:33 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is10u-0002eU-Oh for rsn@ietf.org; Tue, 13 Nov 2007 14:01:33 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Nov 2007 14:01:32 -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 lADJ1WHe015805; Tue, 13 Nov 2007 14:01:32 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lADJ1Hhe008752; Tue, 13 Nov 2007 19:01:32 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 14:01:32 -0500 Received: from 161.44.71.191 ([161.44.71.191]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Tue, 13 Nov 2007 19:01:31 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 13 Nov 2007 14:01:29 -0500 Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter From: JP Vasseur To: Ian Chakeres Message-ID: Thread-Topic: [RSN] BOF Schedule, proposed agenda and WG charter Thread-Index: AcgmJ5jZ14dHkpIaEdyAEAANk8WjQA== In-Reply-To: <374005f30711131058g564870c4qeca4728cd448c66c@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Nov 2007 19:01:32.0023 (UTC) FILETIME=[9AA65070:01C82627] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15542.002 X-TM-AS-Result: No--11.914800-8.000000-4 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2076; t=1194980492; x=1195844492; 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[RSN]=20BOF=20Schedule, =20proposed=20agenda=20and=20W G=20charter |Sender:=20 |To:=20Ian=20Chakeres=20; bh=NPClT1oqvUGl3GTLfLK6/zUreB5tsQBueUkeZfHgkRM=; b=eAi76n4oj31KyQmneV70/4XnVBd49qJZxAFoR57PTKDAaCkm7iF5P45QFas8923EuHTOE8lh BuerbOQTfkrVDGnT24euFrGbyx4Pbmidc/jB0vXRuplBEyOTu2bbfydl; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 2.6 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Ian, > From: Ian Chakeres > Date: Wed, 14 Nov 2007 00:28:48 +0530 > To: Philip Levis > Cc: JP Vasseur , > Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter > > I don't think that the group has agreement on the > challenges/requirements that will be addressed. Right now, the group > is seems to be flushing out a large wish list for requirements in many > sensor network areas, but I haven't seen any discussion on which of > these requirements MUST be accomplished by a proposed protocol. > Did you read the application specific requirement IDs? > Also, given the multiple conflicting goals (energy efficient, dynamic > loss rates, small routing sate) it would be nice if the group could > determine the priority among them. As proposed solutions will probably > each tradeoff one goal for another. Same comment. > > I think the exploratory group concept seems to match the current state > of RSN/RL2N. See my previous email. Thanks. JP. > > Ian > > On Nov 14, 2007 12:07 AM, Philip Levis wrote: >> >> On Nov 13, 2007, at 6:35 AM, Ian Chakeres wrote: >> >>> RSN/RL2N, >>> >>> I think the WG charter is still fuzzy, perhaps it will gel after the >>> pre-BOF meetup. >>> >>> Have you considered using an exploratory group? It would perhaps help >>> create the focus needed. >>> >>> http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt >> >> Ian, >> >> Let me try a rewording of the 4th paragraph that does not change the >> content in any way: >> >> The Working Group has two goals. The first is to survey and establish >> the requirements for the applications described above. The second is >> to design and develop routing solutions for these applications that >> meet the key RL2N requirements of being energy efficient, dealing >> with dynamic link loss rates, and having small routing state. >> >> What do you feel is fuzzy here? >> >> Phil >> _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Nov 13 14:29:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1S4-0006cl-Vn; Tue, 13 Nov 2007 14:29:36 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Is1S4-0006cV-8n for rsn-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 14:29:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1S3-0006cN-VS for rsn@ietf.org; Tue, 13 Nov 2007 14:29:35 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is1S0-0001CB-GH for rsn@ietf.org; Tue, 13 Nov 2007 14:29:35 -0500 Received: from dnab422094.stanford.edu ([171.66.32.148]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Is1Rz-0007jv-ML; Tue, 13 Nov 2007 11:29:31 -0800 In-Reply-To: <374005f30711131058g564870c4qeca4728cd448c66c@mail.gmail.com> References: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.com> <374005f30711131058g564870c4qeca4728cd448c66c@mail.gmail.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: [RSN] BOF Schedule, proposed agenda and WG charter Date: Tue, 13 Nov 2007 11:29:28 -0800 To: Ian Chakeres X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.4 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Nov 13, 2007, at 10:58 AM, Ian Chakeres wrote: > I don't think that the group has agreement on the > challenges/requirements that will be addressed. Right now, the group > is seems to be flushing out a large wish list for requirements in many > sensor network areas, but I haven't seen any discussion on which of > these requirements MUST be accomplished by a proposed protocol. > > Also, given the multiple conflicting goals (energy efficient, dynamic > loss rates, small routing sate) it would be nice if the group could > determine the priority among them. As proposed solutions will probably > each tradeoff one goal for another. > > I think the exploratory group concept seems to match the current state > of RSN/RL2N. Ian, The challenges are: 1) Dealing with dynamic loss rates 2) Being energy efficient 3) Have small routing state Of course, once you start ultra-optimizing any of these three, you will enter a realm of tradeoffs and possibly a suite of protocols to choose from. But experience has shown that something which is good and general is the key step: it's pretty clear that one can design protocols that simultaneously beat existing standardized protocols on all three requirements. Given how many real applications there are out there, how much vendors are clamoring for good open protocols, and how many real protocols have been analyzed, implemented, and evaluated, it seems to me that the period of exploration is over. Today, there are working protocols that meet all three requirements and run on hundreds of thousands of nodes. The goal is to transition and evolve this work into a set of standards that enable IP connectivity to the next 10 billion nodes. I also feel like you're applying a double standard here. What are the requirements that MANETs MUST meet? We have to be careful with MUST statements for normative reasons... Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Nov 13 23:55:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAHK-00016n-SF; Tue, 13 Nov 2007 23:55:06 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IsAHJ-000156-Lf for rsn-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 23:55:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAHJ-00014q-9v for rsn@ietf.org; Tue, 13 Nov 2007 23:55:05 -0500 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsAHG-0004tC-Pk for rsn@ietf.org; Tue, 13 Nov 2007 23:55:05 -0500 Received: by wr-out-0506.google.com with SMTP id 70so51510wra for ; Tue, 13 Nov 2007 20:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ZCJICzQAdm1Uc8RuylF2Qc7J1sAj5ql4ycPNBmuIQjo=; b=s1C3LSmTm8jbq00kiGWykh8+n5swLOT7oBs6m6ATkQyuIsGcUi8g2rnmrMWxTkH51kUlz1bLa6rieHS4+drtZhs6GM/8055XAwfYItE0jr7kR98fyA0I9Zb4hTYEvRxbQvmRPUxQ3G2/UoLeKg6gGSwVVnjjlqwidQ79wbR0XFw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZVWzec7gZYXob/WaRyKBxUB+oIh/SoumWFqnCNiA0fa0nSTiAxLgnRRYWoyqyyfbKVV+mX3AqxadeA614ZZu9+YtE47ci/XgMtCV3gBOMYybb+8Iwj5kxv2ebfTWJCVAcfw5zqRqg6CEXvxmS2NiwqHvQeAhUzlP8YhbKjLurwg= Received: by 10.142.232.20 with SMTP id e20mr1418418wfh.1195016101537; Tue, 13 Nov 2007 20:55:01 -0800 (PST) Received: by 10.142.187.19 with HTTP; Tue, 13 Nov 2007 20:55:01 -0800 (PST) Message-ID: <2a3692de0711132055k1cafc5em68b956b6b6b095c4@mail.gmail.com> Date: Wed, 14 Nov 2007 13:55:01 +0900 From: "Dominik Kaspar" To: "Philip Levis" Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.com> <374005f30711131058g564870c4qeca4728cd448c66c@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Philip, Talking about the three challenges/requirements you listed (are these terms "challenges" and "requirements" interchangeable anyway?) 1) Dealing with dynamic loss rates 2) Being energy efficient 3) Have small routing state Philip: "[...] it's pretty clear that one can design protocols that simultaneously beat existing standardized protocols on all three requirements." Would you mind to clarify why this is so clear? I think it is indeed still a challenge. Are there any studies to support your statement? Philip: "Today, there are working protocols that meet all three requirements and run on hundreds of thousands of nodes. The goal is to transition and evolve this work into a set of standards that enable IP connectivity to the next 10 billion nodes". I am curious about the names of any working protocol or implemented system that meets all three routing requirements on a 100'000 network of low-power nodes. Dominik On 11/14/07, Philip Levis wrote: > > On Nov 13, 2007, at 10:58 AM, Ian Chakeres wrote: > > > I don't think that the group has agreement on the > > challenges/requirements that will be addressed. Right now, the group > > is seems to be flushing out a large wish list for requirements in many > > sensor network areas, but I haven't seen any discussion on which of > > these requirements MUST be accomplished by a proposed protocol. > > > > Also, given the multiple conflicting goals (energy efficient, dynamic > > loss rates, small routing sate) it would be nice if the group could > > determine the priority among them. As proposed solutions will probably > > each tradeoff one goal for another. > > > > I think the exploratory group concept seems to match the current state > > of RSN/RL2N. > > Ian, > > The challenges are: > > 1) Dealing with dynamic loss rates > 2) Being energy efficient > 3) Have small routing state > > Of course, once you start ultra-optimizing any of these three, you > will enter a realm of tradeoffs and possibly a suite of protocols to > choose from. But experience has shown that something which is good > and general is the key step: it's pretty clear that one can design > protocols that simultaneously beat existing standardized protocols on > all three requirements. > > Given how many real applications there are out there, how much > vendors are clamoring for good open protocols, and how many real > protocols have been analyzed, implemented, and evaluated, it seems to > me that the period of exploration is over. Today, there are working > protocols that meet all three requirements and run on hundreds of > thousands of nodes. The goal is to transition and evolve this work > into a set of standards that enable IP connectivity to the next 10 > billion nodes. > > I also feel like you're applying a double standard here. What are the > requirements that MANETs MUST meet? We have to be careful with MUST > statements for normative reasons... > > Phil > > > _______________________________________________ > 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 From rsn-bounces@ietf.org Wed Nov 14 00:55:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsBDq-0005J2-Ga; Wed, 14 Nov 2007 00:55:34 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IsBDn-0005Ew-NJ for rsn-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 00:55:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsBDn-0005E1-60 for rsn@ietf.org; Wed, 14 Nov 2007 00:55:31 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsBDm-0003rT-Mg for rsn@ietf.org; Wed, 14 Nov 2007 00:55:31 -0500 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1IsBDl-0001mX-3R; Tue, 13 Nov 2007 21:55:29 -0800 In-Reply-To: <2a3692de0711132055k1cafc5em68b956b6b6b095c4@mail.gmail.com> References: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.com> <374005f30711131058g564870c4qeca4728cd448c66c@mail.gmail.com> <2a3692de0711132055k1cafc5em68b956b6b6b095c4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E5877B4-24CD-4F2E-8C84-C4C5F494DF50@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter Date: Tue, 13 Nov 2007 21:55:27 -0800 To: Dominik Kaspar 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: 2e2010fe0da008b9f5e122b86dc99621 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Nov 13, 2007, at 8:55 PM, Dominik Kaspar wrote: > Philip, > > Talking about the three challenges/requirements you listed (are these > terms "challenges" and "requirements" interchangeable anyway?) > > 1) Dealing with dynamic loss rates > 2) Being energy efficient > 3) Have small routing state > > Philip: "[...] it's pretty clear that one can design protocols that > simultaneously beat existing standardized protocols on all three > requirements." > > Would you mind to clarify why this is so clear? I think it is indeed > still a challenge. Are there any studies to support your statement? Two easy cases are Arch Rock's routing layer and Wireless HART. > > Philip: "Today, there are working protocols that meet all three > requirements and run on hundreds of thousands of nodes. The goal is to > transition and evolve this work into a set of standards that enable IP > connectivity to the next 10 billion nodes". > > I am curious about the names of any working protocol or implemented > system that meets all three routing requirements on a 100'000 network > of low-power nodes. I apologize for being unclear. I didn't intend to claim that there are protocols running on 100,000 node networks (I don't know of any). Rather, there are hundreds of thousands of nodes running energy efficient, loss-adaptive, limited routing state protocols. I wanted to make it clear that there are real working protocols out there running on a lot of hardware: this isn't a problem of the future, it is a problem of the now. Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Nov 14 03:11:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDL0-0002II-O9; Wed, 14 Nov 2007 03:11:06 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IsDKz-0002FW-7b for rsn-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 03:11:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDKt-00020u-NN for rsn@ietf.org; Wed, 14 Nov 2007 03:10:59 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsDKt-0007jA-0w for rsn@ietf.org; Wed, 14 Nov 2007 03:10:59 -0500 Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 09:10:57 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 09:10:57 +0100 From: "Teco Boot" To: References: <374005f30711130635i6f2a09f2obaef7f7222c81c37@mail.gmail.com> <374005f30711131058g564870c4qeca4728cd448c66c@mail.gmail.com> <2a3692de0711132055k1cafc5em68b956b6b6b095c4@mail.gmail.com> <9E5877B4-24CD-4F2E-8C84-C4C5F494DF50@cs.stanford.edu> In-Reply-To: <9E5877B4-24CD-4F2E-8C84-C4C5F494DF50@cs.stanford.edu> Subject: RE: [RSN] BOF Schedule, proposed agenda and WG charter Date: Wed, 14 Nov 2007 09:10:45 +0100 Message-ID: <006401c82695$dcfd27a0$96f776e0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgmgw4lAgJVV3NHSWO7r4xic+mubwAEI9nA Content-Language: nl X-OriginalArrivalTime: 14 Nov 2007 08:10:57.0286 (UTC) FILETIME=[E28BE260:01C82695] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Can I check the presentation on RL2N at the Routing Area meeting IETF-69? I cannot find it on IETF site or anywhere else. Maybe it was sent on RSN ML, but not stored in archives. Teco. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Nov 14 17:26:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQgO-0002Ie-Rn; Wed, 14 Nov 2007 17:26:04 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IsQgN-0002FY-I8 for rsn-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 17:26:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQgN-0002Cr-59 for rsn@ietf.org; Wed, 14 Nov 2007 17:26:03 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsQgK-0002uY-IN for rsn@ietf.org; Wed, 14 Nov 2007 17:26:03 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 23:25:35 +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: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter Date: Wed, 14 Nov 2007 23:27:14 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter thread-index: AcgmJq1o7AvDiJIZEdyAEAANk8WjQAA2xa9A References: From: "DOHLER Mischa RD-TECH-GRE" To: "JP Vasseur" X-OriginalArrivalTime: 14 Nov 2007 22:25:35.0920 (UTC) FILETIME=[46FE7B00:01C8270D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: rsn@ietf.org, CHEGARAY Gabriel RD-TECH-GRE X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear JP, dear all, Thanks for your efforts in getting all this together. After some FT/Orange internal discussions and having had you on the phone today, we have decided to actively participate in RL2N. I will try hard to call in tomorrow.=20 To aid tomorrow's discussion, we have a few comments/questions, some of which may have been addressed before. Our comments on the formulation of the charter have been sent to you offline a few hours ago. Rather as an input to tomorrow's discussion, some of our general technical comments as well as comments on the excellent drafts can be found below. Many thanks and with kind regards, Mischa, Christian and Gabriel. _______________________________________ Dr Mischa Dohler France Telecom R&D Senior Research Expert Tel: +33 4 76 76 45 14 Fax: +33 4 76 76 44 50 Mob: +33 6 74 70 86 75 http://perso.rd.francetelecom.fr/dohler _______________________________________ ... visit http://www.pimrc2008.org/ ... _______________________________________ General comments: 1) The current technical requirements and also the charter very much focus on wireless solutions. Do you exclude wired solutions, i.e. mixed networks? 2) IETF focuses on routing, but you will agree that multihop is inherently a routing + MAC problem. We have seen the discussion on doing routing at layer 2 (mesh under) or layer 3 (route over); however, we believe that key is 'and' and not 'or'. Energy consumption of a routing protocol will strongly depend on the chosen MAC and vice-versa, where not all MACs go plug-'n-play with all routing protocols. How do you plan to handle this problematic? 3) Albeit touched here and there in the published drafts, we would like to see stronger statements concerning: - the need of energy-optimised network ramp-up protocols (when all nodes are being switched on; nodes are added; etc); - the directed information flow towards gateways (WLAN, cellular); - the availability of a heterogeneous set of nodes (battery, plugged into mains, recharged regularly, recharged irregularly, etc). 4) As an integrated service provider, we would certainly like to see an all-IP solution. However, despite the usual polemic of IP versus non-IP, a key question for us is how the addresses are assigned and when. Does the group also perceive this as an important issue and have solutions already been hinted at? 5) We think that the three chosen categories makes sense: home automation (high node type diversity), industrial control (low latency), smart city (longivity). However, home automation solutions have relatively low hop-counts; we might be wrong but we believe that routing is not really an issue and that proposed solutions (e.g. ZigBee Pro) should do for a commercially viable roll-out. Industrial control roll-outs hamper today, mainly because of the latency problem; however, e.g. the recently proposed IEEE 802.15.4e has the minimisation of latency as a design goal. We agree, however, with the proposed drafts that there is still a lot of scope in optimising the energy consumption of the protocols. In any case, we generally believe that innovative solutions are still missing for the Smart City. We would like to take the lead on this draft which we commenced writing and which we hope to be able to issue shortly via JP for first comments. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comments on "draft-brandt-rl2n-home-routing-reqs-01.txt": 1) Section "4.3. Support of Mobility": Is it typical to give such a loose bound on the convergence time, eg "few hundreds of milli-seconds"? 2) Section "5. Traffic pattern": It is stated that "a tree topology may prove inefficient for nodes in a distributed system." How does this relate to "draft-thubert-tree-discovery-06.txt"? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comments on "draft-culler-rl2n-routing-reqs-01.txt": 1) Section "3. "Route over" versus "Mesh under": We would delete reference to IEEE 802.16. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comments on "draft-pister-rl2n-indus-routing-reqs-00.txt": 1) Section "2. Introduction": Should cabeling costs be part of the draft? 2) Section "2.1. Applications and Traffic Patterns": What does "multi-topology routing" exactly imply? 3) Section "5. Device-Aware Routing Requirements": We would suggest to mention larger lifetimes than 5 years, eg at least 10-15 years. 4) Section "10. Security": In the case of an all-IP solution, we would welcome that solutions MUST support (at least some form of) security.=20 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Nov 16 14:29:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6sg-0003dR-5G; Fri, 16 Nov 2007 14:29:34 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1It6sf-0003dI-2u for rsn-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 14:29:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6se-0003d8-FH for rsn@ietf.org; Fri, 16 Nov 2007 14:29:32 -0500 Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It6sc-0004O0-Ap for rsn@ietf.org; Fri, 16 Nov 2007 14:29:32 -0500 Received: from [129.25.14.14] (n1-14-14.dhcp.drexel.edu [129.25.14.14]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id lAGJZiA2009982; Fri, 16 Nov 2007 14:35:44 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <3AB8A7EF-553C-4882-B173-2AF078FF4685@ece.drexel.edu> From: Jaudelice Cavalcante de Oliveira Subject: Re: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter Date: Fri, 16 Nov 2007 14:29:20 -0500 To: rsn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: (-0.675) AWL,HTML_MESSAGE X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3adba28c47054ea827843deea22a7215 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1689195414==" Errors-To: rsn-bounces@ietf.org --===============1689195414== Content-Type: multipart/alternative; boundary=Apple-Mail-4-38312016 --Apple-Mail-4-38312016 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Somehow my message was not posted, so I am resending it.... Cheers, Jaudelice. --- From: Jaudelice Cavalcante de Oliveira Date: Wed, 14 Nov 2007 19:42:57 -0500 To: Cc: JP Vasseur , Ian Chakeres Subject: Re: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter I have been following the discussions on the list since its creation and have read the excellent documents posted. I am planning to attend tomorrow's meeting and I also attended the Routing area meeting in Chicago, where I saw strong support for this work. I am excited to finally see this work taking place at the IETF. Long ago, I had mentioned to several colleagues that the community needed a WG at the IETF, given the number of proprietary solutions out there, and the need for good open protocols and, moreover, IP based solutions. I think the group has come a long way already, taking the right steps, (I like the application-specific approach -- it makes a lot of sense to me, specially for sensor networks -- and the three selected deployment scenarios) and I look forward to a Working Group being formed to work on the charter. While the recently proposed charter may not be the final one, I noticed that a long time was allocated to discuss it during the Pre- WG meeting tomorrow. Cheers, Jaudelice C. de Oliveira Assistant Professor ECE Dept., Drexel University http://www.ece.drexel.edu/faculty/deoliveira/ On Nov 13, 2007, at 1:54 PM, JP Vasseur wrote: > Ian, > > You asked several relevant questions in a previous email thread to > which we > replied and that we took into account in the proposed WG charter. > There are > still clarifications to be made (IPv4 / v6, ...). We plan to post > early next > week the minutes of the pre-WG meeting that will take place this > coming > Thursday in order to get additional feed-back and adjust the proposed > charter before the BOF. > > As matter of fact, we have a good set of people with the required > background > and level of energy to make relevant contribution that are in clear > agreement on what needs to be done. We have received so far lots of > positive > and constructive feed-backs. That being said, since you pointed to > draft-aboba-sg-experiment-04.txt, I'm tempted to provide a concise > reply to > these questions, which will also allow the people on the list to > express > their opinion and make sure that we are all on the same page. > > - Are the issues that the working group plans to address > clear and relevant to the Internet community? > > JP> Based on the number of feed-backs received so far and the > comments that > we got during the Routing area meeting, it seems quite clear but if > there is > anything unclear, we will be more happy to clarify. > > - Are the goals specific and reasonably achievable, and > achievable within a reasonable time frame? > > JP> One of the challenges with L2Ns is that the scope may > potentially be > wide. We had initially started to collect the requirements in an ID > but we > decided to adopt an application-specific approach, which has proven > to be > quite efficient in several other WGs: > > " There is wide scope of application areas for L2Ns, including > industrial > monitoring, building HVAC and lighting control, connected home, > healthcare, > environmental monitoring, agricultural, smart cities, logistics, and > refrigeration. The L2N WG will focus on routing solutions for a > subset of > these deployment scenarios, namely industrial, connected home/ > building and > smart cities." > > There are already two ID for Industrial and Connected Home driven > by authors > with a strong expertise in each area and deployment background. > > Thus the work is SCOPED and WELL UNDERSTOOD. > > - What are the risks and urgency of the work, to determine > the level of effort required? > > JP> See our presentation during the Routing Area meeting in Chicago. > Proprietary solutions are being deployed TODAY. It is thus urgent > to specify > an IP standard based solution. The problem is well understood and > solutions > are deployed so the level of risk is minor. > > - Do the working group's activities overlap with those of > another working group? > ... > > JP> There is no overlap but of course RL2N *will* have to work with > other > WGs for sure such as 6lowpan (see the consensual decision wrt to > routing), > MANET, ... > > - Is there sufficient interest within the IETF in the working > group's topic with enough people willing to expend the effort > to produce the desired result (e.g., a protocol > specification)? > ... > > JP> Looking at the number of people involved, it is much look like > it is. > > - Is there enough expertise within the IETF in the working > group's topic, and are those people interested in > contributing in the working group? > ... > > JP> This is a key question particularly relevant here since L2Ns > are quite > specific and require a set of areas of expertise. When we first > started this > initiative we spent time making sure to have experts in L2N > (Sensor) and > Routing with a different backgrounds (end user, Service Providers, > Sensor/L2N/Router Vendors, academic). If you look at the various > IDs and > active participants, we will see a good representation of each > category. > > - Does a base of interested consumers (end-users) appear to > exist for the planned work? > ... > > JP> Yes although I would prefer them to express themselves here. > > - Does the IETF have a reasonable role to play in the > determination of the technology? > ... > > JP> If we want to see IP in L2Ns, it is definitely the case, I do > not think > that we need to argue here. > > - Are all known intellectual property rights relevant to > the proposed working group's efforts issues understood? > > JP> The WG may of course have to deal with IPR issues. Nothing > specific to > the area of L2Ns. > > - Is the proposed work plan an open IETF effort or is it an > attempt to "bless" non-IETF technology where the effect of > input from IETF participants may be limited? > > JP> With no restriction, an open IETF effort. Should a WG be > formed, we may > want to establish liaison with other SDOs/Alliance (e.g. Zigbee) > but the > work is an open IETF effort and by no means an attempt to "bless" > non IETF > technology. > > - Is there a good understanding of any existing work that is > relevant to the topics that the proposed working group is to > pursue? This includes work within the IETF and elsewhere. > > JP> Yes, see the protocol overview draft. Furthermore the > participants also > have a strong knowledge on what being done elsewhere (SP100, > Zigbee, Zwave, > ..) > > - Do the working group's goals overlap with known work in > another standards body, and if so is adequate liaison > in place? > > JP> This is the point that I was mentioning before. We're planning to > discuss potential liaisons during the pre-WG meeting this week. > > Thanks. > > JP. > >> From: Ian Chakeres >> Date: Tue, 13 Nov 2007 20:05:25 +0530 >> To: JP Vasseur >> Cc: >> Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter >> >> RSN/RL2N, >> >> I think the WG charter is still fuzzy, perhaps it will gel after the >> pre-BOF meetup. >> >> Have you considered using an exploratory group? It would perhaps help >> create the focus needed. >> >> http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt >> >> Ian >> >> On Nov 13, 2007 12:03 AM, JP Vasseur wrote: >>> Dear all, >>> >>> So the BOF will be held on Thursday: >>> >>> 1510-1610 Afternoon Session II >>> Oak INT mip4 Mobility for IPv4 WG >>> Salon 2 RAI peppermint Provisioning Extensions in Peering >>> Registries for Multimedia INTerconnection BOF >>> Salon 1 RTG isis IS-IS for IP Internets WG >>> Salon A/B RTG rl2n Routing For Low Power and Lossy >>> Networks BOF >>> Cypress SEC btns Better-Than-Nothing Security WG >>> >>> I uploaded the BOF Agenda: >>> http://www3.ietf.org/proceedings/07dec/agenda/rl2n.txt >>> >>> And we updated the Proposed WG Charter: http://www.employees.org/ >>> ~jvasseur/ >>> >>> Comments welcome. >>> >>> Thanks. >>> >>> 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 > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn --Apple-Mail-4-38312016 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Somehow my message was not = posted, so I am resending it....

Cheers,

Jaudelice.
---

From: Jaudelice = Cavalcante de Oliveira <jau@cbis.ece.drexel.edu>
Date: Wed, 14 = Nov 2007 19:42:57 -0500
To: = <rsn@ietf.org>
Cc: JP Vasseur <jvasseur@cisco.com>, Ian = Chakeres <ian.chakeres@gmail.com>
Subject: Re: ** = ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda = and WG charter


I have been following the discussions on the list since = its creation and have=A0read=A0
the = excellent documents posted. I am planning to attend tomorrow's meeting = and I also=A0
attended = the Routing area meeting in Chicago, where I saw strong support for this = work.

I am = excited to finally see this work taking place=A0at=A0the IETF. Long ago, = I had mentioned=A0
to several = colleagues that the community needed=A0a WG at the IETF, given the = number=A0
of proprietary solutions out there, = and the need for good open protocols and, moreover,
IP based solutions.

I think = the group has come a long=A0way already, taking the right steps, (I like = the=A0
application-specific approach --=A0it = makes a lot of sense to me, specially for sensor networks = --=A0
and the three selected=A0deployment = scenarios)=A0and I look forward to a Working Group = being=A0
formed to work on=A0the = charter.=A0While the=A0recently proposed charter may=A0not be the final = one,=A0
I noticed that a long time=A0was = allocated to discuss it=A0during the Pre-WG meeting = tomorrow.

Cheers,

Jaudelice C. de = Oliveira
Assistant Professor
ECE Dept.,=A0Drexel University
http://www.ece.drexel.edu/faculty/deoliveira/<= /DIV>


On = Nov 13, 2007, at 1:54 PM, JP Vasseur wrote:

Ian,

You asked several relevant = questions in a previous email thread to which we
replied and that we took into account in the = proposed WG charter. There are
still = clarifications to be made (IPv4 / v6, ...). We plan to post early = next
week the minutes of the pre-WG = meeting that will take place this coming
Thursday = in order to get additional feed-back and adjust the proposed
charter before the BOF.

As matter of = fact, we have a good set of people with the required = background
and level of energy to make = relevant contribution that are in clear
and constructive feed-backs. = That being said, since you pointed to
these questions, which will also = allow the people on the list to express
their = opinion and make sure that we are all on the same page.

=A0 =A0 =A0 - Are the issues that = the working group plans to address
=A0 =A0 =A0 =A0 clear and = relevant to the Internet community?

JP> Based on the number of = feed-backs received so far and the comments that
we got during the Routing area meeting, it seems = quite clear but if there is
anything = unclear, we will be more happy to clarify.

=A0 =A0 =A0 - Are the goals = specific and reasonably achievable, and
=A0 =A0 =A0 =A0 achievable within = a reasonable time frame?

JP> One of the challenges = with L2Ns is that the scope may potentially be
wide. We had initially started to collect the = requirements in an ID but we
decided to = adopt an application-specific approach, which has proven to be
quite efficient in several other WGs:

" There = is wide scope of application areas for L2Ns, including = industrial
monitoring, building HVAC and = lighting control, connected home, healthcare,
environmental monitoring, agricultural, smart = cities, logistics, and
refrigeration. The L2N WG = will focus on routing solutions for a subset of
these deployment scenarios, namely industrial, = connected home/building and
smart = cities."=A0

There = are already two ID for Industrial and Connected Home driven by = authors
with a strong expertise in each = area and deployment background.

Thus the work is SCOPED and WELL = UNDERSTOOD.

=A0 =A0 =A0 = - What are the risks and urgency of the work, to = determine
=A0 =A0 =A0 =A0 the level of = effort required?

JP> See our presentation during the Routing Area = meeting in Chicago.
Proprietary solutions are = being deployed TODAY. It is thus urgent to specify
an IP standard based solution. The problem is well = understood and solutions
are deployed = so the level of risk is minor.

=A0 =A0 =A0 - Do the working = group's activities overlap with those of
=A0 =A0 =A0 =A0 another working = group?
=A0 =A0 =A0 =A0 ...

JP> = There is no overlap but of course RL2N *will* have to work with = other
WGs for sure such as 6lowpan = (see the consensual decision wrt to routing),
MANET, ... =A0

=A0 =A0 =A0 - Is there sufficient = interest within the IETF in the working
=A0 =A0 =A0 =A0 group's topic = with enough people willing to expend the effort
=A0 =A0 =A0 =A0 = to produce the desired result (e.g., a protocol = specification)?
=A0 =A0 =A0 =A0 ...

JP> = Looking at the number of people involved, it is much look like it = is.

=A0 =A0 =A0 = - Is there enough expertise within the IETF in the = working
=A0 =A0 =A0 =A0 group's topic, = and are those people interested in
=A0 =A0 =A0 =A0 contributing in = the working group?
=A0 =A0 =A0 =A0 ...

JP> = This is a key question particularly relevant here since L2Ns are = quite
specific and require a set of = areas of expertise. When we first started this
initiative we spent time making sure to have experts = in L2N (Sensor) and
Routing with a different = backgrounds (end user, Service Providers,
active participants, we will see = a good representation of each category.

=A0 =A0 =A0 - Does a base of = interested consumers (end-users) appear to
=A0 =A0 =A0 =A0 exist for the = planned work?
=A0 =A0 =A0 =A0 ...

JP> = Yes although I would prefer them to express themselves here.

=A0 =A0 =A0 - Does the IETF have = a reasonable role to play in the
=A0 =A0 =A0 =A0 determination of = the technology?
=A0 =A0 =A0 =A0 ...

JP> = If we want to see IP in L2Ns, it is definitely the case, I do not = think
that we need to argue = here.

=A0 =A0 =A0 = - Are all known intellectual property rights relevant = to
=A0 =A0 =A0= =A0 the proposed working group's efforts issues = understood?

JP> The WG may of course have to deal with IPR = issues. Nothing specific to
the area of = L2Ns.=A0

=A0 =A0 =A0 - Is the proposed = work plan an open IETF effort or is it an
=A0 =A0 =A0 =A0 attempt to = "bless" non-IETF technology where the effect of
=A0 =A0 =A0 =A0 = input from IETF participants may be limited?

JP> = With no restriction, an open IETF effort. Should a WG be formed, we = may
want to establish liaison with = other SDOs/Alliance (e.g. Zigbee) but the
work is = an open IETF effort and by no means an attempt to "bless" non = IETF
technology.

=A0 =A0 =A0 - Is there a good = understanding of any existing work that is
=A0 =A0 =A0 =A0 relevant to the = topics that the proposed working group is to
=A0 =A0 =A0 =A0 = pursue?=A0 This = includes work within the IETF and elsewhere.

JP> = Yes, see the protocol overview draft. Furthermore the participants = also
have a strong knowledge on what = being done elsewhere (SP100, Zigbee, Zwave,

=A0 =A0 =A0 = - Do the working group's goals overlap with known work = in
=A0 =A0 =A0= =A0 another standards body, and if so is adequate = liaison
=A0 =A0 =A0 =A0 in = place?

JP> This is the point that I was mentioning = before. We're planning to
discuss = potential liaisons during the pre-WG meeting this week.


JP. =A0

From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Tue, 13 Nov 2007 20:05:25 +0530
To: JP Vasseur <jvasseur@cisco.com>
Subject: Re: [RSN] BOF Schedule, proposed agenda and = WG charter

RSN/RL2N,

I think the WG charter is still = fuzzy, perhaps it will gel after the
pre-BOF = meetup.

Have you considered using an exploratory group? It = would perhaps help
create the focus = needed.



Dear = all,

So the BOF will be held on Thursday:

Oak=A0 =A0 INT=A0 =A0 mip4=A0 =A0 Mobility for IPv4 = WG
Salon 2=A0 = =A0 RAI=A0 =A0 = peppermint=A0 =A0 = Provisioning Extensions in Peering
Salon 1=A0 =A0 = RTG=A0 =A0 isis=A0 =A0 IS-IS for IP Internets = WG
Salon A/B=A0= =A0 RTG=A0 =A0 = rl2n=A0 =A0 Routing = For Low Power and Lossy Networks BOF
Cypress=A0 =A0 SEC=A0 =A0 btns=A0 =A0 Better-Than-Nothing = Security WG

I uploaded the BOF Agenda:

And we = updated the Proposed WG Charter: http://www.employees.org/~jva= sseur/

Comments welcome.


JP and David.


RSN mailing list



RSN mailing list


RSN mailing list

= --Apple-Mail-4-38312016-- --===============1689195414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1689195414==-- From rsn-bounces@ietf.org Sat Nov 17 06:07:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItLWk-0003Ie-DY; Sat, 17 Nov 2007 06:07:54 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1ItLWj-0003HT-De for rsn-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 06:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItLWj-0003GD-3r for rsn@ietf.org; Sat, 17 Nov 2007 06:07:53 -0500 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItLWf-0000Mr-87 for rsn@ietf.org; Sat, 17 Nov 2007 06:07:53 -0500 Received: from [87.93.235.160] (h235160.gprs.dnafinland.fi [87.93.235.160]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id lAHB7ZWD002223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Nov 2007 13:07:43 +0200 Message-ID: <473ECB73.7080305@sensinode.com> Date: Sat, 17 Nov 2007 13:07:31 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: rsn@ietf.org Subject: Re: [RSN] industrial requirements Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Kris, Very complete req draft. Here are my comments: draft-pister-rl2n-industrial-routing-reqs-05 Overall comments Very well written. The requirements are however encompassing some issues far beyond the scope of IP routing and rl2n, e.g. MAC-layer slotting, QoS priority mechanisms etc. which yes are encompassed by ISA100 as a whole. But should the requirements for an r2ln draft be so broad? I'd like to hear justification on this, although I see reason for some of it. Others may have the same feeling? How do these requirements relate to ISA100, are they taken directly or do we have something special for rl2n here? Section 2.1 In addition to mentioning equipment monitoring, the general class of asset monitoring and tracking can be mentioned as belonging to classes 4-5. Also access control could be mentioned as an application, although it has overlap of course with commercial building automation. Section 3 Can we demand 10ms timeslots from the r2ln point of view? What if the L2 protocol is not able to provide that? Do 10ms time-slots make sense for classes 3-5 at all? They at least don't make sense for sparse events and bulk non-critical transfers. Section 8 We have also seen lots of applications for field device mobile monitoring and for mounting on mobile equipment. Very happy to see both here as requirements. Looking forward to the expansion of Section 9. - Zach Kris Pister wrote: > Version 0 of the routing requirements for industrial automation is now available. > Comments and questions are eagerly awaited. > > http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00.txt > > ksjp > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn -- Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sat Nov 17 06:12:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItLbS-00008x-Br; Sat, 17 Nov 2007 06:12:46 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1ItLbR-00008s-BY for rsn-confirm+ok@megatron.ietf.org; Sat, 17 Nov 2007 06:12:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItLbR-00008j-1w for rsn@ietf.org; Sat, 17 Nov 2007 06:12:45 -0500 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItLbN-0000VH-89 for rsn@ietf.org; Sat, 17 Nov 2007 06:12:45 -0500 Received: from [87.93.235.160] (h235160.gprs.dnafinland.fi [87.93.235.160]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id lAHBCSwP002307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Nov 2007 13:12:35 +0200 Message-ID: <473ECC96.1000004@sensinode.com> Date: Sat, 17 Nov 2007 13:12:22 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: rsn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [RSN] RL2N charter comments X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi all, In my opinion the proposed RL2N charter is already pretty good, here is some support from our experience. First I would like to stress the same as JP and Phil. There is a huge need for standardized IP WSN routing in well-scoped domains *now*, *today*, to solve *real problems*. For example here in Finland we are already rolling out fairly large 6lowpan (over 1000 node) networks in the industrial and building automation domains. Our direct 6lowpan node volume, will be well over 25k nodes in 2008. ISA100 helps next year, but for many applications a simpler 6lowpan + rl2n routing solution would be more suitable without full ISA100. Of course I assume ISA100 would apply the routing solution from rl2n eventually? Almost all customers love the IP + 802.15.4 concept. But the biggest concern they still have is a lack of a standard routing technique. So rl2n is solving an acute problem for deploying IP-based wireless sensor networks. I think the charter text is good, and scoping to these 3 areas really keeps it focused. One comment: - The relationship with 6lowpan and SP100 could be explicit in the charter text (not just work-items)? Waiting to hear how the meeting in Boston went.... JP? - Zach -- Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Nov 18 18:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IttP5-0001Ko-Ch; Sun, 18 Nov 2007 18:18:15 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IttP1-0001Kd-Ih for rsn-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 18:18:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IttOw-000186-6k for rsn@ietf.org; Sun, 18 Nov 2007 18:18:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IttOv-0000Yu-Of for rsn@ietf.org; Sun, 18 Nov 2007 18:18:06 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2007 15:18:03 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAINI10t012904; Sun, 18 Nov 2007 15:18:01 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAINHq40029927; Sun, 18 Nov 2007 23:18:01 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Nov 2007 18:17:52 -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 ; Sun, 18 Nov 2007 23:17:51 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Sun, 18 Nov 2007 18:17:48 -0500 Subject: Re: [RSN] RL2N charter comments From: JP Vasseur To: Zach Shelby , Message-ID: Thread-Topic: [RSN] RL2N charter comments Thread-Index: AcgqOTuCehxlQJYsEdyN6QANk8WjQA== In-Reply-To: <473ECC96.1000004@sensinode.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Nov 2007 23:17:52.0147 (UTC) FILETIME=[3DFBBE30:01C82A39] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15552.002 X-TM-AS-Result: No--11.184600-8.000000-4 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2196; t=1195427881; x=1196291881; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20RL2N=20charter=20comments |Sender:=20; bh=oL45dyTsB4a8x/u6ElORuDf2ozAUa0NpDryb1FnOB3A=; b=R72CdbwAlnoIgaRdtx5dyhYG5CRQxOLAH2qXyBuYLD2jDHWGu8/x3DBiEHEIddFk5G2Nq7P1 XKLdrfGKH2Q4SfwfVOpU66TzlrahlK6dU5l57267I7CdYj/iVpSTxbuhH5ayPYa3CKpgII0HQu 4XMR7mMTc0LtOrJx2pUe7uKMU=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Zach, > From: Zach Shelby > Date: Sat, 17 Nov 2007 13:12:22 +0200 > To: > Subject: [RSN] RL2N charter comments > > Hi all, > > In my opinion the proposed RL2N charter is already pretty good, here is > some support from our experience. > > First I would like to stress the same as JP and Phil. There is a huge > need for standardized IP WSN routing in well-scoped domains *now*, > *today*, to solve *real problems*. For example here in Finland we are > already rolling out fairly large 6lowpan (over 1000 node) networks in > the industrial and building automation domains. Our direct 6lowpan node > volume, will be well over 25k nodes in 2008. Thanks for the feed-back. ISA100 helps next year, but > for many applications a simpler 6lowpan + rl2n routing solution would be > more suitable without full ISA100. Of course I assume ISA100 would apply > the routing solution from rl2n eventually? The IETF cannot impose the solution other SDOs/Industrial Alliances will choose of course. We are specifying IP-based solution. > > Almost all customers love the IP + 802.15.4 concept. But the biggest > concern they still have is a lack of a standard routing technique. So > rl2n is solving an acute problem for deploying IP-based wireless sensor > networks. Thanks for your support, your participation is very welcome. > > I think the charter text is good, and scoping to these 3 areas really > keeps it focused. One comment: > > - The relationship with 6lowpan and SP100 could be explicit in the > charter text (not just work-items)? Work items are quite specific, and indeed we do plan to try to establish some liaisons with SP100. > > Waiting to hear how the meeting in Boston went.... JP? The meeting was indeed very productive and fruitful. I'll post the minutes soon along with the proposed new WG charter and Milestones. Thanks. JP. > > - Zach > > -- > Zach Shelby | CTO | +358 40 7796297 > Sensinode Ltd. www.sensinode.com > > > _______________________________________________ > 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 From rsn-bounces@ietf.org Sun Nov 18 21:10:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itw61-0007Ij-Ah; Sun, 18 Nov 2007 21:10:45 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IsSnT-0004JC-04 for rsn-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 19:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsSnS-0004Ik-M4 for rsn@ietf.org; Wed, 14 Nov 2007 19:41:30 -0500 Received: from cbis.ece.drexel.edu ([129.25.60.1] helo=coe.drexel.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsSnM-0006mZ-D7 for rsn@ietf.org; Wed, 14 Nov 2007 19:41:30 -0500 Received: from [192.168.1.47] (pool-141-158-248-21.phil.east.verizon.net [141.158.248.21]) (authenticated bits=0) by coe.drexel.edu (8.13.6/8.13.4) with ESMTP id lAF0lNvo000248; Wed, 14 Nov 2007 19:47:24 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <8827C709-FF3C-4E3A-BA61-CA3EBE2A3B96@ece.drexel.edu> From: Jaudelice Cavalcante de Oliveira Subject: Re: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter Date: Wed, 14 Nov 2007 19:42:57 -0500 To: rsn@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: ** (2.508) AWL,HTML_MESSAGE,RCVD_IN_SORBS_DUL X-Scanned-By: MIMEDefang 2.51 on 129.25.60.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: c5b976cb26c967a52d72d6069c7fc54c X-Mailman-Approved-At: Sun, 18 Nov 2007 21:10:43 -0500 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2134871881==" Errors-To: rsn-bounces@ietf.org --===============2134871881== Content-Type: multipart/alternative; boundary=Apple-Mail-7--115670572 --Apple-Mail-7--115670572 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed I have been following the discussions on the list since its creation and have read the excellent documents posted. I am planning to attend tomorrow's meeting and I also attended the Routing area meeting in Chicago, where I saw strong support for this work. I am excited to finally see this work taking place at the IETF. Long ago, I had mentioned to several colleagues that the community needed a WG at the IETF, given the number of proprietary solutions out there, and the need for good open protocols and, moreover, IP based solutions. I think the group has come a long way already, taking the right steps, (I like the application-specific approach -- it makes a lot of sense to me, specially for sensor networks -- and the three selected deployment scenarios) and I look forward to a Working Group being formed to work on the charter. While the recently proposed charter may not be the final one, I noticed that a long time was allocated to discuss it during the Pre- WG meeting tomorrow. Cheers, Jaudelice C. de Oliveira Assistant Professor ECE Dept., Drexel University http://www.ece.drexel.edu/faculty/deoliveira/ On Nov 13, 2007, at 1:54 PM, JP Vasseur wrote: > Ian, > > You asked several relevant questions in a previous email thread to > which we > replied and that we took into account in the proposed WG charter. > There are > still clarifications to be made (IPv4 / v6, ...). We plan to post > early next > week the minutes of the pre-WG meeting that will take place this > coming > Thursday in order to get additional feed-back and adjust the proposed > charter before the BOF. > > As matter of fact, we have a good set of people with the required > background > and level of energy to make relevant contribution that are in clear > agreement on what needs to be done. We have received so far lots of > positive > and constructive feed-backs. That being said, since you pointed to > draft-aboba-sg-experiment-04.txt, I'm tempted to provide a concise > reply to > these questions, which will also allow the people on the list to > express > their opinion and make sure that we are all on the same page. > > - Are the issues that the working group plans to address > clear and relevant to the Internet community? > > JP> Based on the number of feed-backs received so far and the > comments that > we got during the Routing area meeting, it seems quite clear but if > there is > anything unclear, we will be more happy to clarify. > > - Are the goals specific and reasonably achievable, and > achievable within a reasonable time frame? > > JP> One of the challenges with L2Ns is that the scope may > potentially be > wide. We had initially started to collect the requirements in an ID > but we > decided to adopt an application-specific approach, which has proven > to be > quite efficient in several other WGs: > > " There is wide scope of application areas for L2Ns, including > industrial > monitoring, building HVAC and lighting control, connected home, > healthcare, > environmental monitoring, agricultural, smart cities, logistics, and > refrigeration. The L2N WG will focus on routing solutions for a > subset of > these deployment scenarios, namely industrial, connected home/ > building and > smart cities." > > There are already two ID for Industrial and Connected Home driven > by authors > with a strong expertise in each area and deployment background. > > Thus the work is SCOPED and WELL UNDERSTOOD. > > - What are the risks and urgency of the work, to determine > the level of effort required? > > JP> See our presentation during the Routing Area meeting in Chicago. > Proprietary solutions are being deployed TODAY. It is thus urgent > to specify > an IP standard based solution. The problem is well understood and > solutions > are deployed so the level of risk is minor. > > - Do the working group's activities overlap with those of > another working group? > ... > > JP> There is no overlap but of course RL2N *will* have to work with > other > WGs for sure such as 6lowpan (see the consensual decision wrt to > routing), > MANET, ... > > - Is there sufficient interest within the IETF in the working > group's topic with enough people willing to expend the effort > to produce the desired result (e.g., a protocol > specification)? > ... > > JP> Looking at the number of people involved, it is much look like > it is. > > - Is there enough expertise within the IETF in the working > group's topic, and are those people interested in > contributing in the working group? > ... > > JP> This is a key question particularly relevant here since L2Ns > are quite > specific and require a set of areas of expertise. When we first > started this > initiative we spent time making sure to have experts in L2N > (Sensor) and > Routing with a different backgrounds (end user, Service Providers, > Sensor/L2N/Router Vendors, academic). If you look at the various > IDs and > active participants, we will see a good representation of each > category. > > - Does a base of interested consumers (end-users) appear to > exist for the planned work? > ... > > JP> Yes although I would prefer them to express themselves here. > > - Does the IETF have a reasonable role to play in the > determination of the technology? > ... > > JP> If we want to see IP in L2Ns, it is definitely the case, I do > not think > that we need to argue here. > > - Are all known intellectual property rights relevant to > the proposed working group's efforts issues understood? > > JP> The WG may of course have to deal with IPR issues. Nothing > specific to > the area of L2Ns. > > - Is the proposed work plan an open IETF effort or is it an > attempt to "bless" non-IETF technology where the effect of > input from IETF participants may be limited? > > JP> With no restriction, an open IETF effort. Should a WG be > formed, we may > want to establish liaison with other SDOs/Alliance (e.g. Zigbee) > but the > work is an open IETF effort and by no means an attempt to "bless" > non IETF > technology. > > - Is there a good understanding of any existing work that is > relevant to the topics that the proposed working group is to > pursue? This includes work within the IETF and elsewhere. > > JP> Yes, see the protocol overview draft. Furthermore the > participants also > have a strong knowledge on what being done elsewhere (SP100, > Zigbee, Zwave, > ..) > > - Do the working group's goals overlap with known work in > another standards body, and if so is adequate liaison > in place? > > JP> This is the point that I was mentioning before. We're planning to > discuss potential liaisons during the pre-WG meeting this week. > > Thanks. > > JP. > >> From: Ian Chakeres >> Date: Tue, 13 Nov 2007 20:05:25 +0530 >> To: JP Vasseur >> Cc: >> Subject: Re: [RSN] BOF Schedule, proposed agenda and WG charter >> >> RSN/RL2N, >> >> I think the WG charter is still fuzzy, perhaps it will gel after the >> pre-BOF meetup. >> >> Have you considered using an exploratory group? It would perhaps help >> create the focus needed. >> >> http://www.ietf.org/internet-drafts/draft-aboba-sg-experiment-04.txt >> >> Ian >> >> On Nov 13, 2007 12:03 AM, JP Vasseur wrote: >>> Dear all, >>> >>> So the BOF will be held on Thursday: >>> >>> 1510-1610 Afternoon Session II >>> Oak INT mip4 Mobility for IPv4 WG >>> Salon 2 RAI peppermint Provisioning Extensions in Peering >>> Registries for Multimedia INTerconnection BOF >>> Salon 1 RTG isis IS-IS for IP Internets WG >>> Salon A/B RTG rl2n Routing For Low Power and Lossy >>> Networks BOF >>> Cypress SEC btns Better-Than-Nothing Security WG >>> >>> I uploaded the BOF Agenda: >>> http://www3.ietf.org/proceedings/07dec/agenda/rl2n.txt >>> >>> And we updated the Proposed WG Charter: http://www.employees.org/ >>> ~jvasseur/ >>> >>> Comments welcome. >>> >>> Thanks. >>> >>> 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 > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn --Apple-Mail-7--115670572 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
I have been = following the discussions on the list since its creation and = have=A0read=A0
the excellent documents posted. = I am planning to attend tomorrow's meeting and I also=A0
attended the Routing area meeting in Chicago, where = I saw strong support for this work.

I am excited to finally see this work taking = place=A0at=A0the IETF. Long ago, I had mentioned=A0
to several colleagues that the community needed=A0a = WG at the IETF, given the number=A0
of = proprietary solutions out there, and the need for good open protocols = and, moreover,
IP based solutions.

I think the = group has come a long=A0way already, taking the right steps, (I like = the=A0
application-specific approach = --=A0it makes a lot of sense to me, specially for sensor networks = --=A0
and the three = selected=A0deployment scenarios)=A0and I look forward to a Working Group = being=A0
formed to work on=A0the = charter.=A0While the=A0recently proposed charter may=A0not be the final = one,=A0
I noticed that a long time=A0was = allocated to discuss it=A0during the Pre-WG meeting tomorrow.


Jaudelice C. de Oliveira
Assistant Professor
ECE = Dept.,=A0Drexel University



On Nov 13, 2007, at 1:54 PM, = JP Vasseur wrote:

Ian,

You = asked several relevant questions in a previous email thread to which = we
replied and that we took into account in the = proposed WG charter. There are
still = clarifications to be made (IPv4 / v6, ...). We plan to post early = next
week the minutes of the pre-WG = meeting that will take place this coming
Thursday = in order to get additional feed-back and adjust the proposed
charter before the BOF.

As matter of = fact, we have a good set of people with the required = background
and level of energy to make = relevant contribution that are in clear
and constructive feed-backs. = That being said, since you pointed to
these questions, which will also = allow the people on the list to express
their = opinion and make sure that we are all on the same page.

=A0 =A0 =A0 - Are the issues that = the working group plans to address
=A0 =A0 =A0 =A0 clear and = relevant to the Internet community?

JP> Based on the number of = feed-backs received so far and the comments that
we got during the Routing area meeting, it seems = quite clear but if there is
anything = unclear, we will be more happy to clarify.

=A0 =A0 =A0 - Are the goals = specific and reasonably achievable, and
=A0 =A0 =A0 =A0 achievable within = a reasonable time frame?

JP> One of the challenges = with L2Ns is that the scope may potentially be
wide. We had initially started to collect the = requirements in an ID but we
decided to = adopt an application-specific approach, which has proven to be
quite efficient in several other WGs:

" There = is wide scope of application areas for L2Ns, including = industrial
monitoring, building HVAC and = lighting control, connected home, healthcare,
environmental monitoring, agricultural, smart = cities, logistics, and
refrigeration. The L2N WG = will focus on routing solutions for a subset of
these deployment scenarios, namely industrial, = connected home/building and
smart = cities."=A0

There = are already two ID for Industrial and Connected Home driven by = authors
with a strong expertise in each = area and deployment background.

Thus the work is SCOPED and WELL = UNDERSTOOD.

=A0 =A0 =A0 = - What are the risks and urgency of the work, to = determine
=A0 =A0 =A0 =A0 the level of = effort required?

JP> See our presentation during the Routing Area = meeting in Chicago.
Proprietary solutions are = being deployed TODAY. It is thus urgent to specify
an IP standard based solution. The problem is well = understood and solutions
are deployed = so the level of risk is minor.

=A0 =A0 =A0 - Do the working = group's activities overlap with those of
=A0 =A0 =A0 =A0 another working = group?
=A0 =A0 =A0 =A0 ...

JP> = There is no overlap but of course RL2N *will* have to work with = other
WGs for sure such as 6lowpan = (see the consensual decision wrt to routing),
MANET, ... =A0

=A0 =A0 =A0 - Is there sufficient = interest within the IETF in the working
=A0 =A0 =A0 =A0 group's topic = with enough people willing to expend the effort
=A0 =A0 =A0 =A0 = to produce the desired result (e.g., a protocol = specification)?
=A0 =A0 =A0 =A0 ...

JP> = Looking at the number of people involved, it is much look like it = is.

=A0 =A0 =A0 = - Is there enough expertise within the IETF in the = working
=A0 =A0 =A0 =A0 group's topic, = and are those people interested in
=A0 =A0 =A0 =A0 contributing in = the working group?
=A0 =A0 =A0 =A0 ...

JP> = This is a key question particularly relevant here since L2Ns are = quite
specific and require a set of = areas of expertise. When we first started this
initiative we spent time making sure to have experts = in L2N (Sensor) and
Routing with a different = backgrounds (end user, Service Providers,
active participants, we will see = a good representation of each category.

=A0 =A0 =A0 - Does a base of = interested consumers (end-users) appear to
=A0 =A0 =A0 =A0 exist for the = planned work?
=A0 =A0 =A0 =A0 ...

JP> = Yes although I would prefer them to express themselves here.

=A0 =A0 =A0 - Does the IETF have = a reasonable role to play in the
=A0 =A0 =A0 =A0 determination of = the technology?
=A0 =A0 =A0 =A0 ...

JP> = If we want to see IP in L2Ns, it is definitely the case, I do not = think
that we need to argue = here.

=A0 =A0 =A0 = - Are all known intellectual property rights relevant = to
=A0 =A0 =A0= =A0 the proposed working group's efforts issues = understood?

JP> The WG may of course have to deal with IPR = issues. Nothing specific to
the area of = L2Ns.=A0

=A0 =A0 =A0 - Is the proposed = work plan an open IETF effort or is it an
=A0 =A0 =A0 =A0 attempt to = "bless" non-IETF technology where the effect of
=A0 =A0 =A0 =A0 = input from IETF participants may be limited?

JP> = With no restriction, an open IETF effort. Should a WG be formed, we = may
want to establish liaison with = other SDOs/Alliance (e.g. Zigbee) but the
work is = an open IETF effort and by no means an attempt to "bless" non = IETF
technology.

=A0 =A0 =A0 - Is there a good = understanding of any existing work that is
=A0 =A0 =A0 =A0 relevant to the = topics that the proposed working group is to
=A0 =A0 =A0 =A0 = pursue?=A0 This = includes work within the IETF and elsewhere.

JP> = Yes, see the protocol overview draft. Furthermore the participants = also
have a strong knowledge on what = being done elsewhere (SP100, Zigbee, Zwave,

=A0 =A0 =A0 = - Do the working group's goals overlap with known work = in
=A0 =A0 =A0= =A0 another standards body, and if so is adequate = liaison
=A0 =A0 =A0 =A0 in = place?

JP> This is the point that I was mentioning = before. We're planning to
discuss = potential liaisons during the pre-WG meeting this week.


JP. =A0

From: Ian Chakeres <ian.chakeres@gmail.com>
Date: Tue, 13 Nov 2007 20:05:25 +0530
To: JP Vasseur <jvasseur@cisco.com>
Subject: Re: [RSN] BOF Schedule, proposed agenda and = WG charter

RSN/RL2N,

I think the WG charter is still = fuzzy, perhaps it will gel after the
pre-BOF = meetup.

Have you considered using an exploratory group? It = would perhaps help
create the focus = needed.



Dear = all,

So the BOF will be held on Thursday:

Oak=A0 =A0 INT=A0 =A0 mip4=A0 =A0 Mobility for IPv4 = WG
Salon 2=A0 = =A0 RAI=A0 =A0 = peppermint=A0 =A0 = Provisioning Extensions in Peering
Salon 1=A0 =A0 = RTG=A0 =A0 isis=A0 =A0 IS-IS for IP Internets = WG
Salon A/B=A0= =A0 RTG=A0 =A0 = rl2n=A0 =A0 Routing = For Low Power and Lossy Networks BOF
Cypress=A0 =A0 SEC=A0 =A0 btns=A0 =A0 Better-Than-Nothing = Security WG

I uploaded the BOF Agenda:

And we = updated the Proposed WG Charter: http://www.employees.org/~jva= sseur/

Comments welcome.


JP and David.


RSN mailing list



RSN mailing list


RSN mailing list

= --Apple-Mail-7--115670572-- --===============2134871881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============2134871881==-- From rsn-bounces@ietf.org Sun Nov 18 21:10:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itw61-0007Io-JN; Sun, 18 Nov 2007 21:10:45 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IsYaJ-0005OS-1L for rsn-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 01:52:19 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IsYaI-0005OJ-Lk for rsn@ietf.org; Thu, 15 Nov 2007 01:52:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsYPo-0002nX-ER for rsn@ietf.org; Thu, 15 Nov 2007 01:41:28 -0500 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsYPn-0004Jd-Hi for rsn@ietf.org; Thu, 15 Nov 2007 01:41:27 -0500 Received: from [87.93.228.79] (h228079.gprs.dnafinland.fi [87.93.228.79]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id lAF6fEpm025141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Nov 2007 08:41:23 +0200 Message-ID: <473BEA06.10606@sensinode.com> Date: Thu, 15 Nov 2007 08:41:10 +0200 From: Zach Shelby User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: rsn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-TMDA-Confirmed: Thu, 15 Nov 2007 01:52:18 -0500 X-Mailman-Approved-At: Sun, 18 Nov 2007 21:10:43 -0500 Subject: [RSN] RL2N Comments X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi all, In my opinion the proposed RL2N charter is already pretty good, here is some support from our experience. First I would like to stress the same as JP and Phil. There is a huge need for standardized IP WSN routing in well-scoped domains *now*, *today*, to solve *real problems*. For example here in Finland we are already rolling out fairly large 6lowpan (over 1000 node) networks in the industrial and building automation domains. Our direct 6lowpan node volume, will be well over 25k nodes in 2008. SP100 helps next year, but for many applications a simpler 6lowpan + rl2n routing solution would be more suitable. Almost all customers love the IP + 802.15.4 concept. But the biggest concern they still have is a lack of a standard routing technique. I think the charter text is good, and scoping to these 3 areas really keeps it focused. One comment: - The relationship with 6lowpan and SP100 could be explicit in the charter text (not just work-items)? Have fun in Boston! - Zach -- Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Nov 19 16:11:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDtg-0006Ea-OY; Mon, 19 Nov 2007 16:11:12 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IuDte-0006DE-Lc for rsn-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 16:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDtZ-0006CC-1D for rsn@ietf.org; Mon, 19 Nov 2007 16:11:05 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDtX-00042x-Ct for rsn@ietf.org; Mon, 19 Nov 2007 16:11:05 -0500 Received: from dnab4223b6.stanford.edu ([171.66.35.182]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1IuDtV-00076n-KD for rsn@ietf.org; Mon, 19 Nov 2007 13:11:02 -0800 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2479805C-0AA9-4811-9178-4DD62894D931@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: rsn@ietf.org From: Philip Levis Date: Mon, 19 Nov 2007 13:11:01 -0800 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: a8fa315618741e04a90c2df3bc1ba398 X-Spam-Score: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Subject: [RSN] I-D ACTION: draft-levis-rl2n-overview-protocols-02.txt X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org The next version of the protocol overview draft is now online. There are several significant improvements, including analyses of existing IETF protocol routing state requirements and control packet overhead. Comments are, as always, greatly appreciated. The announcement is below. Phil > From: > Reply-To: > Date: Mon, 19 Nov 2007 14:15:02 -0500 > To: > Subject: I-D ACTION:draft-levis-rl2n-overview-protocols-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Overview of Existing Routing Protocols for Low Power and > Lossy > Networks > Author(s) : J. Vasseur, et al. > Filename : draft-levis-rl2n-overview-protocols-02.txt > Pages : 24 > Date : 2007-11-19 > > Networks of low power wireless devices introduce novel IP routing > issues. Low-power wireless devices, such as sensors, actuators and > smart objects, have difficult constraints: very limited memory, > little processing power, and long sleep periods. As most of these > devices are battery-powered, energy efficiency is critically > important. Wireless link qualities can vary significantly over > time, > requiring protocols to make agile decisions yet minimize topology > change energy costs. Such low power and lossy networks (L2Ns) have > routing requirements that existing mesh protocols only partially > address. This document provides a brief survey of the strengths > and > weaknesses of existing protocols with respect to L2Ns. It provides > guidance on how lessons from existing and prior efforts can be > leveraged in future protocol design. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-levis-rl2n-overview- > protocols-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-levis-rl2n-overview-protocols-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-levis-rl2n-overview-protocols-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-11-19134936.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Nov 20 14:42:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYyh-0004J4-Ox; Tue, 20 Nov 2007 14:41:47 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IuYyh-0004Iz-34 for rsn-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 14:41:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYyg-0004Ir-MS for rsn@ietf.org; Tue, 20 Nov 2007 14:41:46 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuYyf-0007yX-Td for rsn@ietf.org; Tue, 20 Nov 2007 14:41:46 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Nov 2007 14:41:45 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAKJfi1S001610 for ; Tue, 20 Nov 2007 14:41:44 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAKJfiwx023972 for ; Tue, 20 Nov 2007 19:41:45 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 14:41:39 -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 ; Tue, 20 Nov 2007 19:41:39 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 20 Nov 2007 14:41:35 -0500 From: JP Vasseur To: Message-ID: Thread-Topic: RL2N Pre-WG meeting minutes - Boston - November 15 Thread-Index: AcgrrVvTmiqWtpegEdy88gANk8WjQA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 19:41:39.0410 (UTC) FILETIME=[5E74AB20:01C82BAD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4635; t=1195587705; x=1196451705; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20RL2N=20Pre-WG=20meeting=20minutes=20-=20Boston=20-=20November =2015 |Sender:=20 |To:=20; bh=8qsV/MRgsxGeCeWmaBcz/J3oNSWtscqJ/a9cJR2+8kg=; b=W3R1QBihmo4jRqaAxYwdBmPgA1En0qONrGzxxUvIZ0PoHTXGbYjYC0CI34Z/CBCJtKt673kD AGW7JqgohCZoSd0tjPmgEgCZ73eUCssST8/FbPvfqzShFFmK2BDkdAm5; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear all, Please below the minutes of the RL2N pre-WG meeting that took place on Nov 15 in Boston. The meeting was extremely fruitful and productive with a excellent consensus between the attendees and we made significant progress on several fronts. Of course, nothing is decided during meetings and is shared with you on the list for comments/suggestions/... Instead of capturing the minutes in a narrative form, you will find below the outcome of productive discussions. We had an excellent representation from end-users, Service Providers, Vendors, Academia: Attendees * Kris Pister: Dust Networks * David Culler: Arch Rock * Ralph King: Crossbow * Anders Brandt: Zensys * Mary Murphy-Hoye: Intel * Ed Butker: Intel * Pete St Pierre: Sun * Andrew Mc Lachlan: British Telecom * Nabil Bitar: Verizon * Misha Dolher: France Telecom * Pierre Colle: Schneider Electric * Todd Snide: Schneider Electric * Phil Levis: Standford * Jaudelice D. Olveira: Drexel * Jim Butler: Cimetrics * JP Vasseur: Cisco * David Ward: IETF RTG AD Several people mentioned that they were interested but could not attend this meeting - Will be in Vancouver. Agenda And Objectives - Review of the current Routing Requirements ID: - draft-brandt-rl2n-home-routing-reqs-01- Anders - draft-pister-rl2n-industrial-routing-reqs-01- Kris - draft-levis-rl2n-overview-protocols-01 - Phil - Discussion of the Proposed WG charter and Milestones - Interaction with other SDOs, Industrial Alliances - Open issues Summary JP/David: Introduction, historical background, objectives. Anders: overview of the Routing requirement for Connected Home Discussion of the specific routing requirements in the home. draft-brandt-rl2n-home-routing-reqs is a good basis, further discussion on the list. Particular attention should be given to routing manageability in home networks (self-configuration) of the routing protocols. Kris: overview of the Routing requirement for Industrial application ID already well fleshed out, driven by a strong experience in deploying sensor networks in such environments. Very specific constraints (see the ID). Phil: overview of the protocol survey The aim of the document is to serve as a base to decide whether we can borrow an existing routing protocol (potentially with adaptations), we need to define a new protocol, ... Important work item for the potential future WG. New revision to be posted for this IETF. Still several items to be covered (security, manageability, ...) in light of the use-case requirements documents. The evaluation will be made for IGPs, MANET, DTNs, ... Discussion on the proposed WG charter 1) Use cases Although the number of applications is wide, the objective is to stay very focused with a limited number of use cases from which we will derive the requirements for the routing protocol. Agreement to work on: Industrial, Connected Home, Building. Smart cities is too vague ... And will be removed from the WG charter. Use case will be used to derive routing requirements but the use of the routing protocol (TBD) will of course not be limited to these environments. Applicability statements will document how the routing protocol will be used in other environments. 2) Special attention will be given to routing manageability/self configuration considering the scale at which L2Ns may be deployed ( O(thousands of nodes)) with battery operated nodes, ... 3) Security issues: key work item. Clear consensus to work on a Routing Security Framework for L2Ns (many attacks are L2Ns specific due to the traffic pattern nature, use of wireless links, ...). 4) Interaction with other IETF WGs, Industrial Alliances, SDOs, ... The interaction with the 6lowpan WG is clear: the effort exclusively focuses on the layer 3 routing issues (Route Over) and we will interact with 6lowpan. It is also highly desirable to establish some liaisons with other Industrial alliances (SP100, Zigbee, ...). 5) The WG will work on both v4 and v6, need for unicast and multicast routing. 6) The WG will have to work on whether a centralized/distributed (or both) routing approach is needed and whether routing hierarchy is required. A general comment: let's use the ML a bit more rather than off-line discussions. The new proposed WG charter will be sent to the list very soon for further comments. The new Milestones will of course be aligned with the new proposed WG charter. JP and David. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Nov 20 22:54:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IugfX-0006kJ-Mn; Tue, 20 Nov 2007 22:54:31 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IugfW-0006kE-U8 for rsn-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 22:54:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IugfW-0006k6-KX for rsn@ietf.org; Tue, 20 Nov 2007 22:54:30 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IugfS-0006fD-EO for rsn@ietf.org; Tue, 20 Nov 2007 22:54:30 -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 lAL3sORd016312; Tue, 20 Nov 2007 20:54:24 -0700 (MST) Subject: Re: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 From: Geoff Mulligan To: JP Vasseur In-Reply-To: <1195617149.6326.17.camel@dellx1> References: <1195617149.6326.17.camel@dellx1> Content-Type: text/plain Date: Tue, 20 Nov 2007 20:54:25 -0700 Message-Id: <1195617266.6326.19.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Tue, 2007-11-20 at 20:52 -0700, Geoff Mulligan wrote: > JP, > You left me off of the list of attendees! > > geoff > > On Tue, 2007-11-20 at 14:41 -0500, JP Vasseur wrote: > > Dear all, > > > > Please below the minutes of the RL2N pre-WG meeting that took place on Nov > > 15 in Boston. The meeting was extremely fruitful and productive with a > > excellent consensus between the attendees and we made significant progress > > on several fronts. Of course, nothing is decided during meetings and is > > shared with you on the list for comments/suggestions/... > > > > Instead of capturing the minutes in a narrative form, you will find below > > the outcome of productive discussions. > > > > We had an excellent representation from end-users, Service Providers, > > Vendors, Academia: > > > > Attendees > > * Kris Pister: Dust Networks > > * David Culler: Arch Rock > > * Ralph King: Crossbow > > * Anders Brandt: Zensys > > * Mary Murphy-Hoye: Intel > > * Ed Butker: Intel > > * Pete St Pierre: Sun > > * Andrew Mc Lachlan: British Telecom > > * Nabil Bitar: Verizon > > * Misha Dolher: France Telecom > > * Pierre Colle: Schneider Electric > > * Todd Snide: Schneider Electric > > * Phil Levis: Standford > > * Jaudelice D. Olveira: Drexel > > * Jim Butler: Cimetrics > > * JP Vasseur: Cisco > > * David Ward: IETF RTG AD > > > > Several people mentioned that they were interested but could not attend this > > meeting - Will be in Vancouver. > > > > Agenda And Objectives > > - Review of the current Routing Requirements ID: > > - draft-brandt-rl2n-home-routing-reqs-01- Anders > > - draft-pister-rl2n-industrial-routing-reqs-01- Kris > > - draft-levis-rl2n-overview-protocols-01 - Phil > > - Discussion of the Proposed WG charter and Milestones > > - Interaction with other SDOs, Industrial Alliances > > - Open issues > > > > Summary > > > > JP/David: Introduction, historical background, objectives. > > > > Anders: overview of the Routing requirement for Connected Home > > Discussion of the specific routing requirements in the home. > > draft-brandt-rl2n-home-routing-reqs is a good basis, further discussion on > > the list. Particular attention should be given to routing manageability in > > home networks (self-configuration) of the routing protocols. > > > > Kris: overview of the Routing requirement for Industrial application > > ID already well fleshed out, driven by a strong experience in deploying > > sensor networks in such environments. Very specific constraints (see the > > ID). > > > > Phil: overview of the protocol survey > > The aim of the document is to serve as a base to decide whether we can > > borrow an existing routing protocol (potentially with adaptations), we need > > to define a new protocol, ... Important work item for the potential future > > WG. New revision to be posted for this IETF. Still several items to be > > covered (security, manageability, ...) in light of the use-case requirements > > documents. The evaluation will be made for IGPs, MANET, DTNs, ... > > > > Discussion on the proposed WG charter > > > > 1) Use cases > > Although the number of applications is wide, the objective is to stay very > > focused with a limited number of use cases from which we will derive the > > requirements for the routing protocol. > > Agreement to work on: Industrial, Connected Home, Building. > > Smart cities is too vague ... And will be removed from the WG charter. > > > > Use case will be used to derive routing requirements but the use of the > > routing protocol (TBD) will of course not be limited to these environments. > > Applicability statements will document how the routing protocol will be used > > in other environments. > > > > 2) Special attention will be given to routing manageability/self > > configuration considering the scale at which L2Ns may be deployed ( > > O(thousands of nodes)) with battery operated nodes, ... > > > > 3) Security issues: key work item. Clear consensus to work on a Routing > > Security Framework for L2Ns (many attacks are L2Ns specific due to the > > traffic pattern nature, use of wireless links, ...). > > > > 4) Interaction with other IETF WGs, Industrial Alliances, SDOs, ... > > The interaction with the 6lowpan WG is clear: the effort exclusively focuses > > on the layer 3 routing issues (Route Over) and we will interact with > > 6lowpan. It is also highly desirable to establish some liaisons with other > > Industrial alliances (SP100, Zigbee, ...). > > > > 5) The WG will work on both v4 and v6, need for unicast and multicast > > routing. > > > > 6) The WG will have to work on whether a centralized/distributed (or both) > > routing approach is needed and whether routing hierarchy is required. > > > > A general comment: let's use the ML a bit more rather than off-line > > discussions. > > > > The new proposed WG charter will be sent to the list very soon for further > > comments. > > > > > > The new Milestones will of course be aligned with the new proposed WG > > charter. > > > > 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 From rsn-bounces@ietf.org Wed Nov 21 08:04:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupG2-0004OX-RJ; Wed, 21 Nov 2007 08:04:46 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IupG2-0004Nu-5U for rsn-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 08:04:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupFv-0004M9-Rl for rsn@ietf.org; Wed, 21 Nov 2007 08:04:40 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IupFs-00049g-Jn for rsn@ietf.org; Wed, 21 Nov 2007 08:04:39 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 14:04:12 +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: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Date: Wed, 21 Nov 2007 14:05:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 thread-index: AcgrrVvTmiqWtpegEdy88gANk8WjQAAhMzbA References: From: "DOHLER Mischa RD-TECH-GRE" To: "JP Vasseur" , X-OriginalArrivalTime: 21 Nov 2007 13:04:12.0908 (UTC) FILETIME=[033EFAC0:01C82C3F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear JP, Thanks for the minutes. Since you asked to use the list, here a comment = and a question: 1) As said before, I understand and support your 'application-driven' = spec approach and - as you highlighted below - I also think that it is = important to stay focused per application. However, with the removal of = Smart City, there is no application left which is outdoors and truly = large-scale. We and likely other service providers/operators believe = that there is business for this type of scenario and would hence like it = - in modified form - to be included in the charter. We have had an = offline exchange where you proposed a different naming and approach, = which we will follow whilst preparing a draft so as to comply with IETF = requirements. 2) I had left the PhC when you discussed this but what exactly do you = mean by centralized and distributed routing in the context of = (range-limited) multi-hop RL2Ns? Thanks and kind regards, Mischa. PS: Please, don't forget to change my name from Misha Dolher to Mischa = Dohler :). _______________________________________ Dr Mischa Dohler France Telecom R&D Senior Research Expert Tel: +33 4 76 76 45 14 Fax: +33 4 76 76 44 50 Mob: +33 6 74 70 86 75 http://perso.rd.francetelecom.fr/dohler _______________________________________ ... visit http://www.pimrc2008.org/ ... _______________________________________ -----Message d'origine----- De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : mardi 20 novembre 2007 20:42 =C0 : rsn@ietf.org Objet : [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Dear all, Please below the minutes of the RL2N pre-WG meeting that took place on = Nov 15 in Boston. The meeting was extremely fruitful and productive with a = excellent consensus between the attendees and we made significant = progress on several fronts. Of course, nothing is decided during = meetings and is shared with you on the list for comments/suggestions/... Instead of capturing the minutes in a narrative form, you will find = below the outcome of productive discussions. We had an excellent representation from end-users, Service Providers, = Vendors, Academia: Attendees * Kris Pister: Dust Networks * David Culler: Arch Rock * Ralph King: Crossbow * Anders Brandt: Zensys * Mary Murphy-Hoye: Intel * Ed Butker: Intel * Pete St Pierre: Sun * Andrew Mc Lachlan: British Telecom * Nabil Bitar: Verizon * Misha Dolher: France Telecom * Pierre Colle: Schneider Electric * Todd Snide: Schneider Electric * Phil Levis: Standford * Jaudelice D. Olveira: Drexel * Jim Butler: Cimetrics * JP Vasseur: Cisco * David Ward: IETF RTG AD Several people mentioned that they were interested but could not attend = this meeting - Will be in Vancouver. Agenda And Objectives - Review of the current Routing Requirements ID: - draft-brandt-rl2n-home-routing-reqs-01- Anders - draft-pister-rl2n-industrial-routing-reqs-01- Kris - draft-levis-rl2n-overview-protocols-01 - Phil - Discussion of the Proposed WG charter and Milestones - Interaction with other SDOs, Industrial Alliances - Open issues =20 Summary JP/David: Introduction, historical background, objectives. Anders: overview of the Routing requirement for Connected Home = Discussion of the specific routing requirements in the home. draft-brandt-rl2n-home-routing-reqs is a good basis, further discussion = on the list. Particular attention should be given to routing = manageability in home networks (self-configuration) of the routing = protocols. Kris: overview of the Routing requirement for Industrial application ID = already well fleshed out, driven by a strong experience in deploying = sensor networks in such environments. Very specific constraints (see the = ID).=20 Phil: overview of the protocol survey The aim of the document is to serve as a base to decide whether we can = borrow an existing routing protocol (potentially with adaptations), we = need to define a new protocol, ... Important work item for the potential = future WG. New revision to be posted for this IETF. Still several items = to be covered (security, manageability, ...) in light of the use-case = requirements documents. The evaluation will be made for IGPs, MANET, = DTNs, ... Discussion on the proposed WG charter 1) Use cases Although the number of applications is wide, the objective is to stay = very focused with a limited number of use cases from which we will = derive the requirements for the routing protocol. Agreement to work on: Industrial, Connected Home, Building. Smart cities is too vague ... And will be removed from the WG charter. Use case will be used to derive routing requirements but the use of the = routing protocol (TBD) will of course not be limited to these = environments. Applicability statements will document how the routing protocol will be = used in other environments. 2) Special attention will be given to routing manageability/self = configuration considering the scale at which L2Ns may be deployed ( = O(thousands of nodes)) with battery operated nodes, ... 3) Security issues: key work item. Clear consensus to work on a Routing = Security Framework for L2Ns (many attacks are L2Ns specific due to the = traffic pattern nature, use of wireless links, ...). 4) Interaction with other IETF WGs, Industrial Alliances, SDOs, ... The interaction with the 6lowpan WG is clear: the effort exclusively = focuses on the layer 3 routing issues (Route Over) and we will interact = with 6lowpan. It is also highly desirable to establish some liaisons = with other Industrial alliances (SP100, Zigbee, ...). 5) The WG will work on both v4 and v6, need for unicast and multicast = routing. 6) The WG will have to work on whether a centralized/distributed (or = both) routing approach is needed and whether routing hierarchy is = required. A general comment: let's use the ML a bit more rather than off-line = discussions. The new proposed WG charter will be sent to the list very soon for = further comments. The new Milestones will of course be aligned with the new proposed WG = charter. 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 From rsn-bounces@ietf.org Wed Nov 21 11:38:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iusas-0007rn-Hl; Wed, 21 Nov 2007 11:38:30 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iusar-0007rb-80 for rsn-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 11:38:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iusaq-0007rT-BS for rsn@ietf.org; Wed, 21 Nov 2007 11:38:28 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iusap-0007Pd-Lj for rsn@ietf.org; Wed, 21 Nov 2007 11:38:28 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Nov 2007 11:38:27 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALGcRB5013488; Wed, 21 Nov 2007 11:38:27 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALGc8Kf001498; Wed, 21 Nov 2007 16:38:27 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 11:38:19 -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 ; Wed, 21 Nov 2007 16:38:19 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 21 Nov 2007 11:38:14 -0500 Subject: Re: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 From: JP Vasseur To: JP Vasseur , , Geoff Mulligan Message-ID: Thread-Topic: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Thread-Index: AcgrrVvTmiqWtpegEdy88gANk8WjQAAr41Ow In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Nov 2007 16:38:19.0783 (UTC) FILETIME=[EC948970:01C82C5C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5632; t=1195663107; x=1196527107; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20RL2N=20Pre-WG=20meeting=20minutes=20-=20Bosto n=20-=20November=2015 |Sender:=20 |To:=20JP=20Vasseur=20, =20, =0A=20=20=20 =20=20=20=20=20Geoff=20Mulligan=20; bh=cfHJGjIJEoEYvb6CK+s3ZN8nE7JAdvsCDmfWdYCfKcw=; b=QFuRvgvjVnFBllB42hrWPTq0/vuWRbw4hCZDJKGBO89MQykpLTTF/8bdcubbBF7OcxSpZiiy ZFLHGwQT7JBze/0lB78vOXrOx6hd20ds6dYy0aR2vANSSe8u95bx4AXF; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org *Correction* Geoff Mulligan (co-chair of 6lowpan) did actively participate to the meeting. Geoff thanks again for having attended ! I had started that email saying that I would avoid the narrative form for the minutes, I should have ;-) since I started the meeting, thanking you for your implication in this work and day-1 support of the RL2N initiative. Cheers. JP. > From: JP Vasseur > Date: Tue, 20 Nov 2007 14:41:35 -0500 > To: > Conversation: RL2N Pre-WG meeting minutes - Boston - November 15 > Subject: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 > > Dear all, > > Please below the minutes of the RL2N pre-WG meeting that took place on Nov > 15 in Boston. The meeting was extremely fruitful and productive with a > excellent consensus between the attendees and we made significant progress > on several fronts. Of course, nothing is decided during meetings and is > shared with you on the list for comments/suggestions/... > > Instead of capturing the minutes in a narrative form, you will find below > the outcome of productive discussions. > > We had an excellent representation from end-users, Service Providers, > Vendors, Academia: > > Attendees > * Kris Pister: Dust Networks > * David Culler: Arch Rock > * Ralph King: Crossbow > * Anders Brandt: Zensys > * Mary Murphy-Hoye: Intel > * Ed Butker: Intel > * Pete St Pierre: Sun > * Andrew Mc Lachlan: British Telecom > * Nabil Bitar: Verizon > * Misha Dolher: France Telecom > * Pierre Colle: Schneider Electric > * Todd Snide: Schneider Electric > * Phil Levis: Standford > * Jaudelice D. Olveira: Drexel > * Jim Butler: Cimetrics > * JP Vasseur: Cisco > * David Ward: IETF RTG AD > > Several people mentioned that they were interested but could not attend this > meeting - Will be in Vancouver. > > Agenda And Objectives > - Review of the current Routing Requirements ID: > - draft-brandt-rl2n-home-routing-reqs-01- Anders > - draft-pister-rl2n-industrial-routing-reqs-01- Kris > - draft-levis-rl2n-overview-protocols-01 - Phil > - Discussion of the Proposed WG charter and Milestones > - Interaction with other SDOs, Industrial Alliances > - Open issues > > Summary > > JP/David: Introduction, historical background, objectives. > > Anders: overview of the Routing requirement for Connected Home > Discussion of the specific routing requirements in the home. > draft-brandt-rl2n-home-routing-reqs is a good basis, further discussion on > the list. Particular attention should be given to routing manageability in > home networks (self-configuration) of the routing protocols. > > Kris: overview of the Routing requirement for Industrial application > ID already well fleshed out, driven by a strong experience in deploying > sensor networks in such environments. Very specific constraints (see the > ID). > > Phil: overview of the protocol survey > The aim of the document is to serve as a base to decide whether we can > borrow an existing routing protocol (potentially with adaptations), we need > to define a new protocol, ... Important work item for the potential future > WG. New revision to be posted for this IETF. Still several items to be > covered (security, manageability, ...) in light of the use-case requirements > documents. The evaluation will be made for IGPs, MANET, DTNs, ... > > Discussion on the proposed WG charter > > 1) Use cases > Although the number of applications is wide, the objective is to stay very > focused with a limited number of use cases from which we will derive the > requirements for the routing protocol. > Agreement to work on: Industrial, Connected Home, Building. > Smart cities is too vague ... And will be removed from the WG charter. > > Use case will be used to derive routing requirements but the use of the > routing protocol (TBD) will of course not be limited to these environments. > Applicability statements will document how the routing protocol will be used > in other environments. > > 2) Special attention will be given to routing manageability/self > configuration considering the scale at which L2Ns may be deployed ( > O(thousands of nodes)) with battery operated nodes, ... > > 3) Security issues: key work item. Clear consensus to work on a Routing > Security Framework for L2Ns (many attacks are L2Ns specific due to the > traffic pattern nature, use of wireless links, ...). > > 4) Interaction with other IETF WGs, Industrial Alliances, SDOs, ... > The interaction with the 6lowpan WG is clear: the effort exclusively focuses > on the layer 3 routing issues (Route Over) and we will interact with > 6lowpan. It is also highly desirable to establish some liaisons with other > Industrial alliances (SP100, Zigbee, ...). > > 5) The WG will work on both v4 and v6, need for unicast and multicast > routing. > > 6) The WG will have to work on whether a centralized/distributed (or both) > routing approach is needed and whether routing hierarchy is required. > > A general comment: let's use the ML a bit more rather than off-line > discussions. > > The new proposed WG charter will be sent to the list very soon for further > comments. > > > The new Milestones will of course be aligned with the new proposed WG > charter. > > 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 From rsn-bounces@ietf.org Wed Nov 21 12:15:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutB4-0001sS-Sm; Wed, 21 Nov 2007 12:15:54 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IutB3-0001o3-TL for rsn-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 12:15:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IutB3-0001l6-GJ for rsn@ietf.org; Wed, 21 Nov 2007 12:15:53 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IutB2-0000IU-GM for rsn@ietf.org; Wed, 21 Nov 2007 12:15:53 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Nov 2007 12:15:52 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALHFq4g032264; Wed, 21 Nov 2007 12:15:52 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALHFpKT014347; Wed, 21 Nov 2007 17:15:52 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 12:15:47 -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 ; Wed, 21 Nov 2007 17:15:47 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 21 Nov 2007 12:15:42 -0500 Subject: Re: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 From: JP Vasseur To: DOHLER Mischa RD-TECH-GRE , Message-ID: Thread-Topic: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Thread-Index: AcgrrVvTmiqWtpegEdy88gANk8WjQAAhMzbAAAv/GHc= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 21 Nov 2007 17:15:47.0576 (UTC) FILETIME=[285E8780:01C82C62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8127; t=1195665352; x=1196529352; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20RL2N=20Pre-WG=20meeting=20minutes=20-=20Bosto n=20-=20November=2015 |Sender:=20 |To:=20DOHLER=20Mischa=20RD-TECH-GRE=20 ,=0A=20=20=20=20=20=20=20=20; bh=k3vlBBz5Q9VPSgaYcGJLil4UfsyWKDre1fCg/aAnQo4=; b=jRAS69OKB72ON3MXdBz+luFly+vBUCCohW9HAKE9av8vn9dLqj1ulnBMarSeSbvqv3VNKS2v ALCvzJ/4MfVpVs9CkBV75E2Btyu7V+PzMBQF6uniV+TkC+nFWD08iUbl; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Mischa, > From: DOHLER Mischa RD-TECH-GRE > Date: Wed, 21 Nov 2007 14:05:55 +0100 > To: JP Vasseur , > Conversation: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 > Subject: RE: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >=20 > Dear JP, >=20 > Thanks for the minutes. Since you asked to use the list, here a comment a= nd a > question: >=20 > 1) As said before, I understand and support your 'application-driven' spe= c > approach and - as you highlighted below - I also think that it is importa= nt to > stay focused per application. However, with the removal of Smart City, th= ere > is no application left which is outdoors and truly large-scale. We and li= kely > other service providers/operators believe that there is business for this= type > of scenario and would hence like it - in modified form - to be included i= n the > charter. We have had an offline exchange where you proposed a different n= aming > and approach, which we will follow whilst preparing a draft so as to comp= ly > with IETF requirements. You're absolutely right and this will reflected in the new proposed charter= , which should be sent very shortly. We're in sync. It would be nice to have = a first draft of the corresponding requirements document before the BOF. We passed the cut-off to submit it but I can host it on the non official web page for the moment. >=20 > 2) I had left the PhC when you discussed this but what exactly do you mea= n by > centralized and distributed routing in the context of (range-limited) > multi-hop RL2Ns? Referring to the two known path computation models: (1) distributed (IGPs, AODV, ...) (3) Centralized where a path computation engine computes the routes for all elements in the networks. There are many pros and cons with each model (in term of scalability, route optimality, robustness, ...). So we will have to have that discussion: do we need a distributed and a centralized or both models for RL2N in light of the use case requirements? Makes sense ? >=20 > Thanks and kind regards, > Mischa. >=20 > PS: Please, don't forget to change my name from Misha Dolher to Mischa Do= hler > :). Sure ;-) Cheers. Jean-Philipp Vassuer (this is usually how people write my name too ;-)) >=20 >=20 > _______________________________________ >=20 > Dr Mischa Dohler > France Telecom R&D > Senior Research Expert >=20 > Tel: +33 4 76 76 45 14 > Fax: +33 4 76 76 44 50 > Mob: +33 6 74 70 86 75 >=20 > http://perso.rd.francetelecom.fr/dohler > _______________________________________ >=20 > ... visit http://www.pimrc2008.org/ ... > _______________________________________ >=20 >=20 > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : mardi 20 novembre 2007 20:42 > =C0 : rsn@ietf.org > Objet : [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >=20 > Dear all, >=20 > Please below the minutes of the RL2N pre-WG meeting that took place on No= v > 15 in Boston. The meeting was extremely fruitful and productive with a > excellent consensus between the attendees and we made significant progres= s on > several fronts. Of course, nothing is decided during meetings and is shar= ed > with you on the list for comments/suggestions/... >=20 > Instead of capturing the minutes in a narrative form, you will find below= the > outcome of productive discussions. >=20 > We had an excellent representation from end-users, Service Providers, Ven= dors, > Academia: >=20 > Attendees > * Kris Pister: Dust Networks > * David Culler: Arch Rock > * Ralph King: Crossbow > * Anders Brandt: Zensys > * Mary Murphy-Hoye: Intel > * Ed Butker: Intel > * Pete St Pierre: Sun > * Andrew Mc Lachlan: British Telecom > * Nabil Bitar: Verizon > * Misha Dolher: France Telecom > * Pierre Colle: Schneider Electric > * Todd Snide: Schneider Electric > * Phil Levis: Standford > * Jaudelice D. Olveira: Drexel > * Jim Butler: Cimetrics > * JP Vasseur: Cisco > * David Ward: IETF RTG AD >=20 > Several people mentioned that they were interested but could not attend t= his > meeting - Will be in Vancouver. >=20 > Agenda And Objectives > - Review of the current Routing Requirements ID: > - draft-brandt-rl2n-home-routing-reqs-01- Anders > - draft-pister-rl2n-industrial-routing-reqs-01- Kris > - draft-levis-rl2n-overview-protocols-01 - Phil > - Discussion of the Proposed WG charter and Milestones > - Interaction with other SDOs, Industrial Alliances > - Open issues > =20 > Summary >=20 > JP/David: Introduction, historical background, objectives. >=20 > Anders: overview of the Routing requirement for Connected Home Discussion= of > the specific routing requirements in the home. > draft-brandt-rl2n-home-routing-reqs is a good basis, further discussion o= n the > list. Particular attention should be given to routing manageability in ho= me > networks (self-configuration) of the routing protocols. >=20 > Kris: overview of the Routing requirement for Industrial application ID > already well fleshed out, driven by a strong experience in deploying sens= or > networks in such environments. Very specific constraints (see the ID). >=20 > Phil: overview of the protocol survey > The aim of the document is to serve as a base to decide whether we can bo= rrow > an existing routing protocol (potentially with adaptations), we need to d= efine > a new protocol, ... Important work item for the potential future WG. New > revision to be posted for this IETF. Still several items to be covered > (security, manageability, ...) in light of the use-case requirements > documents. The evaluation will be made for IGPs, MANET, DTNs, ... >=20 > Discussion on the proposed WG charter >=20 > 1) Use cases > Although the number of applications is wide, the objective is to stay ver= y > focused with a limited number of use cases from which we will derive the > requirements for the routing protocol. > Agreement to work on: Industrial, Connected Home, Building. > Smart cities is too vague ... And will be removed from the WG charter. >=20 > Use case will be used to derive routing requirements but the use of the > routing protocol (TBD) will of course not be limited to these environment= s. > Applicability statements will document how the routing protocol will be u= sed > in other environments. >=20 > 2) Special attention will be given to routing manageability/self configur= ation > considering the scale at which L2Ns may be deployed ( O(thousands of node= s)) > with battery operated nodes, ... >=20 > 3) Security issues: key work item. Clear consensus to work on a Routing > Security Framework for L2Ns (many attacks are L2Ns specific due to the tr= affic > pattern nature, use of wireless links, ...). >=20 > 4) Interaction with other IETF WGs, Industrial Alliances, SDOs, ... > The interaction with the 6lowpan WG is clear: the effort exclusively focu= ses > on the layer 3 routing issues (Route Over) and we will interact with 6low= pan. > It is also highly desirable to establish some liaisons with other Industr= ial > alliances (SP100, Zigbee, ...). >=20 > 5) The WG will work on both v4 and v6, need for unicast and multicast rou= ting. >=20 > 6) The WG will have to work on whether a centralized/distributed (or both= ) > routing approach is needed and whether routing hierarchy is required. >=20 > A general comment: let's use the ML a bit more rather than off-line > discussions. >=20 > The new proposed WG charter will be sent to the list very soon for furthe= r > comments. >=20 >=20 > The new Milestones will of course be aligned with the new proposed WG cha= rter. >=20 > JP and David. >=20 >=20 > _______________________________________________ > 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 From rsn-bounces@ietf.org Wed Nov 21 15:18:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuw28-0008ND-KX; Wed, 21 Nov 2007 15:18:52 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iuw27-0008N6-8M for rsn-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:18:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuw26-0008Mt-M7 for rsn@ietf.org; Wed, 21 Nov 2007 15:18:50 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuw23-0002M3-C0 for rsn@ietf.org; Wed, 21 Nov 2007 15:18:50 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2007 12:18:46 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lALKIkvh029341 for ; Wed, 21 Nov 2007 12:18:46 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lALKIWba001344 for ; Wed, 21 Nov 2007 20:18:46 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 15:18:44 -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 ; Wed, 21 Nov 2007 20:18:44 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 21 Nov 2007 15:18:39 -0500 From: JP Vasseur To: Message-ID: Thread-Topic: Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQA== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 21 Nov 2007 20:18:44.0197 (UTC) FILETIME=[B6F1F950:01C82C7B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4160; t=1195676326; x=1196540326; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Here=20is=20the=20new=20RL2N=20Proposed=20Working=20Charter |Sender:=20; bh=R0HuF7475kMdZK26Fmeh6CCMLbV/1ohlT0WlVbkgoN0=; b=RAQhr67S6+I17Hia8lcwABLrhQhL5+6OuWfjV+vdYLKoeh4eIIAt/NcDbyXbDDIY92OMNB3u 5UMtKxvEMtBHQV2/k/vBND6awGsZFs94UE/xW46FSB8E5PxSSighglm83Dov4btYhYzVoJ6eVK Wml5Lzl1CmBMiASlSyCZSl9mw=; Authentication-Results: sj-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [RSN] Here is the new RL2N Proposed Working Charter X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org 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 =20 Description of Working Group =20 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.=20 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. =20 Work Items: =20 - Produce use cases documents for Industrial, Connected Home, Building and urban application networks. Each document will describe the use case and th= e 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. =20 - Specification of routing metrics used in path calculation. This includes static and dynamic link/nodes attributes required for routing in L2Ns. =20 - Provide an architectural framework for routing and path selection at Laye= r 3 (Routing for L2N Architecture) =B7 Decide whether the L2Ns routing protocol require a distributed, centralized path computation models or both. =B7 Decide whether the L2N routing protocol requires a hierarchical routing approach. =20 - Produce a security framework for routing in L2Ns. =20 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. =20 August 2008: Submit Routing metrics for L2Ns document to the IESG to be considered as an Informational RFC. =20 September 2008: Submit first draft of the Routing for L2Ns Architecture document (summary of requirements, path computation model, flat/hierarchy,=8A). =20 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 considere= d 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. =20 March 2009: Recharter. =20 Please comment/suggest/... See you in Vancouver. JP and David. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Nov 21 15:22:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuw63-0003N3-LG; Wed, 21 Nov 2007 15:22:55 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iuw62-0003B5-52 for rsn-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:22:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuw61-00037T-N5 for rsn@ietf.org; Wed, 21 Nov 2007 15:22:53 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuw5y-0002Yn-21 for rsn@ietf.org; Wed, 21 Nov 2007 15:22:53 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 21:22:22 +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: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Date: Wed, 21 Nov 2007 21:24:01 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 thread-index: AcgrrVvTmiqWtpegEdy88gANk8WjQAAhMzbAAAv/GHcABbWe4A== References: From: "DOHLER Mischa RD-TECH-GRE" To: "JP Vasseur" , X-OriginalArrivalTime: 21 Nov 2007 20:22:22.0752 (UTC) FILETIME=[3936D200:01C82C7C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear JP, "Referring to the two known path computation models: (1) distributed = (IGPs, AODV, ...) (3) Centralized where a path computation engine = computes the routes for all elements in the networks. There are many = pros and cons with each model (in term of scalability, route optimality, = robustness, ...). So we will have to have that discussion: do we need a = distributed and a centralized or both models for RL2N in light of the = use case requirements? Makes sense ?" Not really. The reason why I asked is because we are likely to propose a = protocol which is neither one nor the other as per your definition = above. I actually wouldn't specify 'distributed' or 'centralised' in the = charter so as to leave the doors open for novel and creative routing = approaches. What do you and the others think? Kind regards, Mischa. _______________________________________ Dr Mischa Dohler France Telecom R&D Senior Research Expert Tel: +33 4 76 76 45 14 Fax: +33 4 76 76 44 50 Mob: +33 6 74 70 86 75 http://perso.rd.francetelecom.fr/dohler _______________________________________ ... visit http://www.pimrc2008.org/ ... _______________________________________ -----Message d'origine----- De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : mercredi 21 novembre 2007 18:16 =C0 : DOHLER Mischa RD-TECH-GRE; rsn@ietf.org Objet : Re: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Hi Mischa, > From: DOHLER Mischa RD-TECH-GRE > Date: Wed, 21 Nov 2007 14:05:55 +0100 > To: JP Vasseur , > Conversation: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 > Subject: RE: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >=20 > Dear JP, >=20 > Thanks for the minutes. Since you asked to use the list, here a=20 > comment and a > question: >=20 > 1) As said before, I understand and support your 'application-driven'=20 > spec approach and - as you highlighted below - I also think that it is = > important to stay focused per application. However, with the removal=20 > of Smart City, there is no application left which is outdoors and=20 > truly large-scale. We and likely other service providers/operators=20 > believe that there is business for this type of scenario and would=20 > hence like it - in modified form - to be included in the charter. We=20 > have had an offline exchange where you proposed a different naming and = > approach, which we will follow whilst preparing a draft so as to = comply with IETF requirements. You're absolutely right and this will reflected in the new proposed = charter, which should be sent very shortly. We're in sync. It would be = nice to have a first draft of the corresponding requirements document = before the BOF. We passed the cut-off to submit it but I can host it on = the non official web page for the moment. >=20 > 2) I had left the PhC when you discussed this but what exactly do you=20 > mean by centralized and distributed routing in the context of=20 > (range-limited) multi-hop RL2Ns? Referring to the two known path computation models: (1) distributed = (IGPs, AODV, ...) (3) Centralized where a path computation engine = computes the routes for all elements in the networks. There are many = pros and cons with each model (in term of scalability, route optimality, = robustness, ...). So we will have to have that discussion: do we need a = distributed and a centralized or both models for RL2N in light of the = use case requirements? Makes sense ? >=20 > Thanks and kind regards, > Mischa. >=20 > PS: Please, don't forget to change my name from Misha Dolher to Mischa = > Dohler :). Sure ;-) Cheers. Jean-Philipp Vassuer (this is usually how people write my name too ;-)) >=20 >=20 > _______________________________________ >=20 > Dr Mischa Dohler > France Telecom R&D > Senior Research Expert >=20 > Tel: +33 4 76 76 45 14 > Fax: +33 4 76 76 44 50 > Mob: +33 6 74 70 86 75 >=20 > http://perso.rd.francetelecom.fr/dohler > _______________________________________ >=20 > ... visit http://www.pimrc2008.org/ ... > _______________________________________ >=20 >=20 > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com] Envoy=E9 : mardi 20 = novembre=20 > 2007 20:42 =C0 : rsn@ietf.org Objet : [RSN] RL2N Pre-WG meeting = minutes=20 > - Boston - November 15 >=20 > Dear all, >=20 > Please below the minutes of the RL2N pre-WG meeting that took place on = > Nov > 15 in Boston. The meeting was extremely fruitful and productive with a = > excellent consensus between the attendees and we made significant=20 > progress on several fronts. Of course, nothing is decided during=20 > meetings and is shared with you on the list for = comments/suggestions/... >=20 > Instead of capturing the minutes in a narrative form, you will find=20 > below the outcome of productive discussions. >=20 > We had an excellent representation from end-users, Service Providers,=20 > Vendors, > Academia: >=20 > Attendees > * Kris Pister: Dust Networks > * David Culler: Arch Rock > * Ralph King: Crossbow > * Anders Brandt: Zensys > * Mary Murphy-Hoye: Intel > * Ed Butker: Intel > * Pete St Pierre: Sun > * Andrew Mc Lachlan: British Telecom > * Nabil Bitar: Verizon > * Misha Dolher: France Telecom > * Pierre Colle: Schneider Electric > * Todd Snide: Schneider Electric > * Phil Levis: Standford > * Jaudelice D. Olveira: Drexel > * Jim Butler: Cimetrics > * JP Vasseur: Cisco > * David Ward: IETF RTG AD >=20 > Several people mentioned that they were interested but could not=20 > attend this meeting - Will be in Vancouver. >=20 > Agenda And Objectives > - Review of the current Routing Requirements ID: > - draft-brandt-rl2n-home-routing-reqs-01- Anders > - draft-pister-rl2n-industrial-routing-reqs-01- Kris > - draft-levis-rl2n-overview-protocols-01 - Phil > - Discussion of the Proposed WG charter and Milestones > - Interaction with other SDOs, Industrial Alliances > - Open issues > =20 > Summary >=20 > JP/David: Introduction, historical background, objectives. >=20 > Anders: overview of the Routing requirement for Connected Home=20 > Discussion of the specific routing requirements in the home. > draft-brandt-rl2n-home-routing-reqs is a good basis, further=20 > discussion on the list. Particular attention should be given to=20 > routing manageability in home networks (self-configuration) of the = routing protocols. >=20 > Kris: overview of the Routing requirement for Industrial application=20 > ID already well fleshed out, driven by a strong experience in=20 > deploying sensor networks in such environments. Very specific = constraints (see the ID). >=20 > Phil: overview of the protocol survey > The aim of the document is to serve as a base to decide whether we can = > borrow an existing routing protocol (potentially with adaptations), we = > need to define a new protocol, ... Important work item for the=20 > potential future WG. New revision to be posted for this IETF. Still=20 > several items to be covered (security, manageability, ...) in light of = > the use-case requirements documents. The evaluation will be made for = IGPs, MANET, DTNs, ... >=20 > Discussion on the proposed WG charter >=20 > 1) Use cases > Although the number of applications is wide, the objective is to stay=20 > very focused with a limited number of use cases from which we will=20 > derive the requirements for the routing protocol. > Agreement to work on: Industrial, Connected Home, Building. > Smart cities is too vague ... And will be removed from the WG charter. >=20 > Use case will be used to derive routing requirements but the use of=20 > the routing protocol (TBD) will of course not be limited to these = environments. > Applicability statements will document how the routing protocol will=20 > be used in other environments. >=20 > 2) Special attention will be given to routing manageability/self=20 > configuration considering the scale at which L2Ns may be deployed (=20 > O(thousands of nodes)) with battery operated nodes, ... >=20 > 3) Security issues: key work item. Clear consensus to work on a=20 > Routing Security Framework for L2Ns (many attacks are L2Ns specific=20 > due to the traffic pattern nature, use of wireless links, ...). >=20 > 4) Interaction with other IETF WGs, Industrial Alliances, SDOs, ... > The interaction with the 6lowpan WG is clear: the effort exclusively=20 > focuses on the layer 3 routing issues (Route Over) and we will = interact with 6lowpan. > It is also highly desirable to establish some liaisons with other=20 > Industrial alliances (SP100, Zigbee, ...). >=20 > 5) The WG will work on both v4 and v6, need for unicast and multicast = routing. >=20 > 6) The WG will have to work on whether a centralized/distributed (or=20 > both) routing approach is needed and whether routing hierarchy is = required. >=20 > A general comment: let's use the ML a bit more rather than off-line=20 > discussions. >=20 > The new proposed WG charter will be sent to the list very soon for=20 > further comments. >=20 >=20 > The new Milestones will of course be aligned with the new proposed WG = charter. >=20 > JP and David. >=20 >=20 > _______________________________________________ > 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 From rsn-bounces@ietf.org Wed Nov 21 15:40:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwMw-0005dG-TB; Wed, 21 Nov 2007 15:40:22 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IuwMv-0005ct-PR for rsn-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:40:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwMv-0005cX-Cx for rsn@ietf.org; Wed, 21 Nov 2007 15:40:21 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuwMu-0008Kt-90 for rsn@ietf.org; Wed, 21 Nov 2007 15:40:21 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Nov 2007 15:40:20 -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 lALKeJUN014509; Wed, 21 Nov 2007 15:40:19 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALKeJxX012150; Wed, 21 Nov 2007 20:40:19 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 15:40:04 -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 ; Wed, 21 Nov 2007 20:40:04 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 21 Nov 2007 15:39:59 -0500 Subject: Re: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 From: JP Vasseur To: DOHLER Mischa RD-TECH-GRE Message-ID: Thread-Topic: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Thread-Index: AcgrrVvTmiqWtpegEdy88gANk8WjQAAhMzbAAAv/GHcABbWe4AABbNE3 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 21 Nov 2007 20:40:04.0534 (UTC) FILETIME=[B215E560:01C82C7E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10749; t=1195677619; x=1196541619; 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[RSN]=20RL2N=20Pre-WG=20meeting=20minutes=20-=20Bosto n=20-=20November=2015 |Sender:=20 |To:=20DOHLER=20Mischa=20RD-TECH-GRE=20; bh=GZQ8PJgaKBc0ibe2VeiIclIJHrlmiuFYqW01BxwOAm0=; b=sPKB/G6ifDN75Kt5CwZSU5AQY0+9HGGlrk40RzFGy4mnswMTn78ClVG/w7luLDCMjKBfSDAw j4AENg8uiZbxxJHYFUjGJeF1qAlOGEJyXpYUgdwp5xeyVHIIt2JHPYKM; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Mischa, > From: DOHLER Mischa RD-TECH-GRE > Date: Wed, 21 Nov 2007 21:24:01 +0100 > To: JP Vasseur , > Conversation: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 > Subject: RE: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >=20 > Dear JP, >=20 > "Referring to the two known path computation models: (1) distributed (IGP= s, > AODV, ...) (3) Centralized where a path computation engine computes the r= outes > for all elements in the networks. There are many pros and cons with each = model > (in term of scalability, route optimality, robustness, ...). So we will h= ave > to have that discussion: do we need a distributed and a centralized or bo= th > models for RL2N in light of the use case requirements? > Makes sense ?" >=20 > Not really. The reason why I asked is because we are likely to propose a > protocol which is neither one nor the other as per your definition above.= I > actually wouldn't specify 'distributed' or 'centralised' in the charter s= o as > to leave the doors open for novel and creative routing approaches. What d= o you > and the others think? *if* the WG decides that none of the existing routing protocols satisfy the requirements and a novel/new/... Path computation model needs to be adopted= , there is clearly no issue there in term of charter. The notion of distributed/centralized is purely indicative and not a black and white choice. Note that the (proposed) WG would not be chartered at this point to specify a protocol, just to discuss the requirements, propose a routing architecture, ...=20 Thanks for your comment. Cheers. JP. >=20 > Kind regards, > Mischa. >=20 > _______________________________________ >=20 > Dr Mischa Dohler > France Telecom R&D > Senior Research Expert >=20 > Tel: +33 4 76 76 45 14 > Fax: +33 4 76 76 44 50 > Mob: +33 6 74 70 86 75 >=20 > http://perso.rd.francetelecom.fr/dohler > _______________________________________ >=20 > ... visit http://www.pimrc2008.org/ ... > _______________________________________ >=20 >=20 > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : mercredi 21 novembre 2007 18:16 > =C0 : DOHLER Mischa RD-TECH-GRE; rsn@ietf.org > Objet : Re: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >=20 > Hi Mischa, >=20 >=20 >> From: DOHLER Mischa RD-TECH-GRE >> Date: Wed, 21 Nov 2007 14:05:55 +0100 >> To: JP Vasseur , >> Conversation: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >> Subject: RE: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >>=20 >> Dear JP, >>=20 >> Thanks for the minutes. Since you asked to use the list, here a >> comment and a >> question: >>=20 >> 1) As said before, I understand and support your 'application-driven' >> spec approach and - as you highlighted below - I also think that it is >> important to stay focused per application. However, with the removal >> of Smart City, there is no application left which is outdoors and >> truly large-scale. We and likely other service providers/operators >> believe that there is business for this type of scenario and would >> hence like it - in modified form - to be included in the charter. We >> have had an offline exchange where you proposed a different naming and >> approach, which we will follow whilst preparing a draft so as to comply = with >> IETF requirements. >=20 > You're absolutely right and this will reflected in the new proposed chart= er, > which should be sent very shortly. We're in sync. It would be nice to hav= e a > first draft of the corresponding requirements document before the BOF. We > passed the cut-off to submit it but I can host it on the non official web= page > for the moment. >=20 >>=20 >> 2) I had left the PhC when you discussed this but what exactly do you >> mean by centralized and distributed routing in the context of >> (range-limited) multi-hop RL2Ns? >=20 > Referring to the two known path computation models: (1) distributed (IGPs= , > AODV, ...) (3) Centralized where a path computation engine computes the r= outes > for all elements in the networks. There are many pros and cons with each = model > (in term of scalability, route optimality, robustness, ...). So we will h= ave > to have that discussion: do we need a distributed and a centralized or bo= th > models for RL2N in light of the use case requirements? > Makes sense ? >=20 >>=20 >> Thanks and kind regards, >> Mischa. >>=20 >> PS: Please, don't forget to change my name from Misha Dolher to Mischa >> Dohler :). >=20 > Sure ;-) >=20 > Cheers. >=20 > Jean-Philipp Vassuer (this is usually how people write my name too ;-)) >=20 >>=20 >>=20 >> _______________________________________ >>=20 >> Dr Mischa Dohler >> France Telecom R&D >> Senior Research Expert >>=20 >> Tel: +33 4 76 76 45 14 >> Fax: +33 4 76 76 44 50 >> Mob: +33 6 74 70 86 75 >>=20 >> http://perso.rd.francetelecom.fr/dohler >> _______________________________________ >>=20 >> ... visit http://www.pimrc2008.org/ ... >> _______________________________________ >>=20 >>=20 >> -----Message d'origine----- >> De : JP Vasseur [mailto:jvasseur@cisco.com] Envoy=E9 : mardi 20 novembre >> 2007 20:42 =C0 : rsn@ietf.org Objet : [RSN] RL2N Pre-WG meeting minutes >> - Boston - November 15 >>=20 >> Dear all, >>=20 >> Please below the minutes of the RL2N pre-WG meeting that took place on >> Nov >> 15 in Boston. The meeting was extremely fruitful and productive with a >> excellent consensus between the attendees and we made significant >> progress on several fronts. Of course, nothing is decided during >> meetings and is shared with you on the list for comments/suggestions/... >>=20 >> Instead of capturing the minutes in a narrative form, you will find >> below the outcome of productive discussions. >>=20 >> We had an excellent representation from end-users, Service Providers, >> Vendors, >> Academia: >>=20 >> Attendees >> * Kris Pister: Dust Networks >> * David Culler: Arch Rock >> * Ralph King: Crossbow >> * Anders Brandt: Zensys >> * Mary Murphy-Hoye: Intel >> * Ed Butker: Intel >> * Pete St Pierre: Sun >> * Andrew Mc Lachlan: British Telecom >> * Nabil Bitar: Verizon >> * Misha Dolher: France Telecom >> * Pierre Colle: Schneider Electric >> * Todd Snide: Schneider Electric >> * Phil Levis: Standford >> * Jaudelice D. Olveira: Drexel >> * Jim Butler: Cimetrics >> * JP Vasseur: Cisco >> * David Ward: IETF RTG AD >>=20 >> Several people mentioned that they were interested but could not >> attend this meeting - Will be in Vancouver. >>=20 >> Agenda And Objectives >> - Review of the current Routing Requirements ID: >> - draft-brandt-rl2n-home-routing-reqs-01- Anders >> - draft-pister-rl2n-industrial-routing-reqs-01- Kris >> - draft-levis-rl2n-overview-protocols-01 - Phil >> - Discussion of the Proposed WG charter and Milestones >> - Interaction with other SDOs, Industrial Alliances >> - Open issues >> =20 >> Summary >>=20 >> JP/David: Introduction, historical background, objectives. >>=20 >> Anders: overview of the Routing requirement for Connected Home >> Discussion of the specific routing requirements in the home. >> draft-brandt-rl2n-home-routing-reqs is a good basis, further >> discussion on the list. Particular attention should be given to >> routing manageability in home networks (self-configuration) of the routi= ng >> protocols. >>=20 >> Kris: overview of the Routing requirement for Industrial application >> ID already well fleshed out, driven by a strong experience in >> deploying sensor networks in such environments. Very specific constraint= s >> (see the ID). >>=20 >> Phil: overview of the protocol survey >> The aim of the document is to serve as a base to decide whether we can >> borrow an existing routing protocol (potentially with adaptations), we >> need to define a new protocol, ... Important work item for the >> potential future WG. New revision to be posted for this IETF. Still >> several items to be covered (security, manageability, ...) in light of >> the use-case requirements documents. The evaluation will be made for IGP= s, >> MANET, DTNs, ... >>=20 >> Discussion on the proposed WG charter >>=20 >> 1) Use cases >> Although the number of applications is wide, the objective is to stay >> very focused with a limited number of use cases from which we will >> derive the requirements for the routing protocol. >> Agreement to work on: Industrial, Connected Home, Building. >> Smart cities is too vague ... And will be removed from the WG charter. >>=20 >> Use case will be used to derive routing requirements but the use of >> the routing protocol (TBD) will of course not be limited to these >> environments. >> Applicability statements will document how the routing protocol will >> be used in other environments. >>=20 >> 2) Special attention will be given to routing manageability/self >> configuration considering the scale at which L2Ns may be deployed ( >> O(thousands of nodes)) with battery operated nodes, ... >>=20 >> 3) Security issues: key work item. Clear consensus to work on a >> Routing Security Framework for L2Ns (many attacks are L2Ns specific >> due to the traffic pattern nature, use of wireless links, ...). >>=20 >> 4) Interaction with other IETF WGs, Industrial Alliances, SDOs, ... >> The interaction with the 6lowpan WG is clear: the effort exclusively >> focuses on the layer 3 routing issues (Route Over) and we will interact = with >> 6lowpan. >> It is also highly desirable to establish some liaisons with other >> Industrial alliances (SP100, Zigbee, ...). >>=20 >> 5) The WG will work on both v4 and v6, need for unicast and multicast >> routing. >>=20 >> 6) The WG will have to work on whether a centralized/distributed (or >> both) routing approach is needed and whether routing hierarchy is requir= ed. >>=20 >> A general comment: let's use the ML a bit more rather than off-line >> discussions. >>=20 >> The new proposed WG charter will be sent to the list very soon for >> further comments. >>=20 >>=20 >> The new Milestones will of course be aligned with the new proposed WG >> charter. >>=20 >> JP and David. >>=20 >>=20 >> _______________________________________________ >> 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 From rsn-bounces@ietf.org Wed Nov 21 15:51:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwXn-00087Y-Q4; Wed, 21 Nov 2007 15:51:35 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IuwXl-00087M-MJ for rsn-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 15:51:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwXl-00087E-AE for rsn@ietf.org; Wed, 21 Nov 2007 15:51:33 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuwXj-0000MZ-UY for rsn@ietf.org; Wed, 21 Nov 2007 15:51:33 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 21:51:28 +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: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Date: Wed, 21 Nov 2007 21:52:50 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 thread-index: AcgrrVvTmiqWtpegEdy88gANk8WjQAAhMzbAAAv/GHcABbWe4AABbNE3AABZLYA= References: From: "DOHLER Mischa RD-TECH-GRE" To: "JP Vasseur" X-OriginalArrivalTime: 21 Nov 2007 20:51:28.0292 (UTC) FILETIME=[49A31640:01C82C80] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4515df9441674711565101d9d5c4f63f Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org I see, JP. Great! Thanks, Mischa :) PS: I am currently drafting the 4th = application spec which should be ready by Friday ... -----Message d'origine----- De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : mercredi 21 novembre 2007 21:40 =C0 : DOHLER Mischa RD-TECH-GRE Cc : rsn@ietf.org Objet : Re: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 Hi Mischa, > From: DOHLER Mischa RD-TECH-GRE > Date: Wed, 21 Nov 2007 21:24:01 +0100 > To: JP Vasseur , > Conversation: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 > Subject: RE: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >=20 > Dear JP, >=20 > "Referring to the two known path computation models: (1) distributed=20 > (IGPs, AODV, ...) (3) Centralized where a path computation engine=20 > computes the routes for all elements in the networks. There are many=20 > pros and cons with each model (in term of scalability, route=20 > optimality, robustness, ...). So we will have to have that discussion: = > do we need a distributed and a centralized or both models for RL2N in = light of the use case requirements? > Makes sense ?" >=20 > Not really. The reason why I asked is because we are likely to propose = > a protocol which is neither one nor the other as per your definition=20 > above. I actually wouldn't specify 'distributed' or 'centralised' in=20 > the charter so as to leave the doors open for novel and creative=20 > routing approaches. What do you and the others think? *if* the WG decides that none of the existing routing protocols satisfy = the requirements and a novel/new/... Path computation model needs to be = adopted, there is clearly no issue there in term of charter. The notion = of distributed/centralized is purely indicative and not a black and = white choice. Note that the (proposed) WG would not be chartered at this = point to specify a protocol, just to discuss the requirements, propose a = routing architecture, ...=20 Thanks for your comment. Cheers. JP. >=20 > Kind regards, > Mischa. >=20 > _______________________________________ >=20 > Dr Mischa Dohler > France Telecom R&D > Senior Research Expert >=20 > Tel: +33 4 76 76 45 14 > Fax: +33 4 76 76 44 50 > Mob: +33 6 74 70 86 75 >=20 > http://perso.rd.francetelecom.fr/dohler > _______________________________________ >=20 > ... visit http://www.pimrc2008.org/ ... > _______________________________________ >=20 >=20 > -----Message d'origine----- > De : JP Vasseur [mailto:jvasseur@cisco.com] Envoy=E9 : mercredi 21=20 > novembre 2007 18:16 =C0 : DOHLER Mischa RD-TECH-GRE; rsn@ietf.org = Objet=20 > : Re: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >=20 > Hi Mischa, >=20 >=20 >> From: DOHLER Mischa RD-TECH-GRE >> Date: Wed, 21 Nov 2007 14:05:55 +0100 >> To: JP Vasseur , >> Conversation: [RSN] RL2N Pre-WG meeting minutes - Boston - November=20 >> 15 >> Subject: RE: [RSN] RL2N Pre-WG meeting minutes - Boston - November 15 >>=20 >> Dear JP, >>=20 >> Thanks for the minutes. Since you asked to use the list, here a=20 >> comment and a >> question: >>=20 >> 1) As said before, I understand and support your 'application-driven' >> spec approach and - as you highlighted below - I also think that it=20 >> is important to stay focused per application. However, with the=20 >> removal of Smart City, there is no application left which is outdoors = >> and truly large-scale. We and likely other service=20 >> providers/operators believe that there is business for this type of=20 >> scenario and would hence like it - in modified form - to be included=20 >> in the charter. We have had an offline exchange where you proposed a=20 >> different naming and approach, which we will follow whilst preparing=20 >> a draft so as to comply with IETF requirements. >=20 > You're absolutely right and this will reflected in the new proposed=20 > charter, which should be sent very shortly. We're in sync. It would be = > nice to have a first draft of the corresponding requirements document=20 > before the BOF. We passed the cut-off to submit it but I can host it=20 > on the non official web page for the moment. >=20 >>=20 >> 2) I had left the PhC when you discussed this but what exactly do you = >> mean by centralized and distributed routing in the context of >> (range-limited) multi-hop RL2Ns? >=20 > Referring to the two known path computation models: (1) distributed=20 > (IGPs, AODV, ...) (3) Centralized where a path computation engine=20 > computes the routes for all elements in the networks. There are many=20 > pros and cons with each model (in term of scalability, route=20 > optimality, robustness, ...). So we will have to have that discussion: = > do we need a distributed and a centralized or both models for RL2N in = light of the use case requirements? > Makes sense ? >=20 >>=20 >> Thanks and kind regards, >> Mischa. >>=20 >> PS: Please, don't forget to change my name from Misha Dolher to=20 >> Mischa Dohler :). >=20 > Sure ;-) >=20 > Cheers. >=20 > Jean-Philipp Vassuer (this is usually how people write my name too=20 > ;-)) >=20 >>=20 >>=20 >> _______________________________________ >>=20 >> Dr Mischa Dohler >> France Telecom R&D >> Senior Research Expert >>=20 >> Tel: +33 4 76 76 45 14 >> Fax: +33 4 76 76 44 50 >> Mob: +33 6 74 70 86 75 >>=20 >> http://perso.rd.francetelecom.fr/dohler >> _______________________________________ >>=20 >> ... visit http://www.pimrc2008.org/ ... >> _______________________________________ >>=20 >>=20 >> -----Message d'origine----- >> De : JP Vasseur [mailto:jvasseur@cisco.com] Envoy=E9 : mardi 20=20 >> novembre >> 2007 20:42 =C0 : rsn@ietf.org Objet : [RSN] RL2N Pre-WG meeting = minutes >> - Boston - November 15 >>=20 >> Dear all, >>=20 >> Please below the minutes of the RL2N pre-WG meeting that took place=20 >> on Nov >> 15 in Boston. The meeting was extremely fruitful and productive with=20 >> a excellent consensus between the attendees and we made significant=20 >> progress on several fronts. Of course, nothing is decided during=20 >> meetings and is shared with you on the list for = comments/suggestions/... >>=20 >> Instead of capturing the minutes in a narrative form, you will find=20 >> below the outcome of productive discussions. >>=20 >> We had an excellent representation from end-users, Service Providers, = >> Vendors, >> Academia: >>=20 >> Attendees >> * Kris Pister: Dust Networks >> * David Culler: Arch Rock >> * Ralph King: Crossbow >> * Anders Brandt: Zensys >> * Mary Murphy-Hoye: Intel >> * Ed Butker: Intel >> * Pete St Pierre: Sun >> * Andrew Mc Lachlan: British Telecom >> * Nabil Bitar: Verizon >> * Misha Dolher: France Telecom >> * Pierre Colle: Schneider Electric >> * Todd Snide: Schneider Electric >> * Phil Levis: Standford >> * Jaudelice D. Olveira: Drexel >> * Jim Butler: Cimetrics >> * JP Vasseur: Cisco >> * David Ward: IETF RTG AD >>=20 >> Several people mentioned that they were interested but could not=20 >> attend this meeting - Will be in Vancouver. >>=20 >> Agenda And Objectives >> - Review of the current Routing Requirements ID: >> - draft-brandt-rl2n-home-routing-reqs-01- Anders >> - draft-pister-rl2n-industrial-routing-reqs-01- Kris >> - draft-levis-rl2n-overview-protocols-01 - Phil >> - Discussion of the Proposed WG charter and Milestones >> - Interaction with other SDOs, Industrial Alliances >> - Open issues >> =20 >> Summary >>=20 >> JP/David: Introduction, historical background, objectives. >>=20 >> Anders: overview of the Routing requirement for Connected Home=20 >> Discussion of the specific routing requirements in the home. >> draft-brandt-rl2n-home-routing-reqs is a good basis, further=20 >> discussion on the list. Particular attention should be given to=20 >> routing manageability in home networks (self-configuration) of the=20 >> routing protocols. >>=20 >> Kris: overview of the Routing requirement for Industrial application=20 >> ID already well fleshed out, driven by a strong experience in=20 >> deploying sensor networks in such environments. Very specific=20 >> constraints (see the ID). >>=20 >> Phil: overview of the protocol survey The aim of the document is to=20 >> serve as a base to decide whether we can borrow an existing routing=20 >> protocol (potentially with adaptations), we need to define a new=20 >> protocol, ... Important work item for the potential future WG. New=20 >> revision to be posted for this IETF. Still several items to be=20 >> covered (security, manageability, ...) in light of the use-case=20 >> requirements documents. The evaluation will be made for IGPs, MANET,=20 >> DTNs, ... >>=20 >> Discussion on the proposed WG charter >>=20 >> 1) Use cases >> Although the number of applications is wide, the objective is to stay = >> very focused with a limited number of use cases from which we will=20 >> derive the requirements for the routing protocol. >> Agreement to work on: Industrial, Connected Home, Building. >> Smart cities is too vague ... And will be removed from the WG = charter. >>=20 >> Use case will be used to derive routing requirements but the use of=20 >> the routing protocol (TBD) will of course not be limited to these=20 >> environments. >> Applicability statements will document how the routing protocol will=20 >> be used in other environments. >>=20 >> 2) Special attention will be given to routing manageability/self=20 >> configuration considering the scale at which L2Ns may be deployed (=20 >> O(thousands of nodes)) with battery operated nodes, ... >>=20 >> 3) Security issues: key work item. Clear consensus to work on a=20 >> Routing Security Framework for L2Ns (many attacks are L2Ns specific=20 >> due to the traffic pattern nature, use of wireless links, ...). >>=20 >> 4) Interaction with other IETF WGs, Industrial Alliances, SDOs, ... >> The interaction with the 6lowpan WG is clear: the effort exclusively=20 >> focuses on the layer 3 routing issues (Route Over) and we will=20 >> interact with 6lowpan. >> It is also highly desirable to establish some liaisons with other=20 >> Industrial alliances (SP100, Zigbee, ...). >>=20 >> 5) The WG will work on both v4 and v6, need for unicast and multicast = >> routing. >>=20 >> 6) The WG will have to work on whether a centralized/distributed (or >> both) routing approach is needed and whether routing hierarchy is = required. >>=20 >> A general comment: let's use the ML a bit more rather than off-line=20 >> discussions. >>=20 >> The new proposed WG charter will be sent to the list very soon for=20 >> further comments. >>=20 >>=20 >> The new Milestones will of course be aligned with the new proposed WG = >> charter. >>=20 >> JP and David. >>=20 >>=20 >> _______________________________________________ >> 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 From rsn-bounces@ietf.org Wed Nov 21 16:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iux6b-00016b-1j; Wed, 21 Nov 2007 16:27:33 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iux6Z-00016O-Rx for rsn-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:27:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iux6Z-00016G-A9 for rsn@ietf.org; Wed, 21 Nov 2007 16:27:31 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iux6Y-0002Dt-TF for rsn@ietf.org; Wed, 21 Nov 2007 16:27:31 -0500 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Iux6V-0000zJ-QO; Wed, 21 Nov 2007 13:27:28 -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: <632DB6C3-CC05-4603-8EF1-DD822C37493E@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter Date: Wed, 21 Nov 2007 13:27:29 -0800 To: JP Vasseur 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: 6214ac49f2cb083a0c8190805312a710 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Nov 21, 2007, at 12:18 PM, JP Vasseur wrote: > > > 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. > JP (and Mischa), I'll reiterate what I said in the meeting: I think we need a different term than "smart cities." Interpreted literally, "smart cities" encompasses *all* of the other use cases except agricultural, and introduces all sorts of other concerns outside our general area of interest, such as vehicular networks, traffic control systems, and law enforcement. While densely networked urban areas certainly raise a lot of technical issues due to their scale, I feel that we should focus on real applications today. It's hard to define application use cases for research visions, e.g. general ubiquitous computing. I could just be mistaken on this one, but I have yet to hear a clear articulation of what a "smart city" is or what technical issues it raises. If the issues we want to make sure we keep in mind are outdoor, very large scale urban networks, surely there is a more precise application use case? If we can pull out the concrete issues that smart cities introduce and define a concrete use case that clearly articulate them, then that would be great. But, I mean, is "refrigeration" really on the same playing field in terms of scope as "smart cities?" Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Nov 22 08:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCO7-0005sr-87; Thu, 22 Nov 2007 08:46:39 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvCO6-0005sm-O6 for rsn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 08:46:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCO1-0005sF-1T for rsn@ietf.org; Thu, 22 Nov 2007 08:46:33 -0500 Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCNx-0000p7-1N for rsn@ietf.org; Thu, 22 Nov 2007 08:46:32 -0500 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: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter Date: Thu, 22 Nov 2007 14:46:22 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB687ED@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter Thread-Index: AcgmJq1o7AvDiJIZEdyAEAANk8WjQAA2xa9AAXft9kA= References: From: "Anders Brandt" To: "DOHLER Mischa RD-TECH-GRE" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org In response to Mischa's comment on home control routing: =20 >5) We think that the three chosen categories makes sense: home automation (high node type diversity), industrial control >(low latency), >smart city (longivity). However, home automation solutions have relatively low hop-counts; we might be >wrong but we believe that routing is not really an issue and that proposed solutions (e.g. ZigBee Pro) should do for a >commercially viable roll-out. Industrial control roll-outs hamper today, mainly because of the latency problem; however, >e.g. the recently proposed IEEE 802.15.4e has the minimisation of latency as a design goal. We agree, however, with the >proposed drafts that there is still a lot of scope in optimising the energy consumption of the protocols. Our experience with Z-Wave home control over the last 5 years shows that routing is certainly an issue. Yes, distances are short, but antenna conditions are often problematic. Plugin modules may lie on the floor next to a noisy switch-mode converter or a Wi-Fi router Built-in wall switches may have metal housing due to safety regulations. The same applies to ceiling outlets. All the abovementioned examples causes not only reduced reception sensitivity but also direction-dependent reception conditions. An antenna built into a metal box does not show reception properties even close to omni-directional. Reinforced concrete, refrigerator doors and other metal objects - and people too - also may dampen/distort the signal I would claim that it is a lot easier to do a good antenna design in industrial devices as you have the room needed and can place a proper wip antenna on the top of the device in a proper high location without having to consider the WAF (Wife Acceptance Factor). Increasing the tx power may not help a lot if the target is almost deaf in the direction of the sender. Thus, you should expect to see both 3 and 4 hops in the home control domain. Extending that to building control, the end-to-end hop count may grow significantly. Obviously, you may decide to leave the node hopping to mesh-under transport in the individual subnets. ROLL routing may still benefit from data link information, such as the number of layer-2 hops needed to get to the actual node / the worst case absolute delay / etc. in case multiple gateways provide access to a subnet. (read: subnets may be running different data link technologies) Cheers, Anders _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Nov 22 08:59:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCak-0002v2-0k; Thu, 22 Nov 2007 08:59:42 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvCai-0002uv-Q0 for rsn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 08:59:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCai-0002un-GQ for rsn@ietf.org; Thu, 22 Nov 2007 08:59:40 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCae-0001Gg-OF for rsn@ietf.org; Thu, 22 Nov 2007 08:59:40 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 14:59:13 +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: [RSN] Here is the new RL2N Proposed Working Charter Date: Thu, 22 Nov 2007 14:59:09 +0100 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A0FB898C6@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAAk1ICw References: From: "JACQUENET Christian RD-DDEV-REN" To: "JP Vasseur" , X-OriginalArrivalTime: 22 Nov 2007 13:59:13.0103 (UTC) FILETIME=[DCBA85F0:01C82D0F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear all, Thanks to Jean-Philippe for posting the updated charter. A couple of comments inline.=20 [snip] =20 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. CJ: I would agree with the above sentence, especially based upon the protocol analysis draft that has been posted so far. But there is another sentence in the "Work Items" section of the charter that somewhat contradicts this statement, and I would therefore suggest we fix this, by smoothing this wording a little bit. Maybe something like: "Preliminary analysis of existing routing protocols such as OPSF, IS-IS, AODV and OLSR seems to indicate that the L2N-specific requirements are not addressed by such protocols, but part of the proposed WG charter will further investigate, as mentioned below." [snip] Work Items: =20 - 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. CJ: I'm fine with this wording, assuming a rewording of the corresponding statement above (see previous comment). =20 - Specification of routing metrics used in path calculation. This includes static and dynamic link/nodes attributes required for routing in L2Ns. CJ: I would put the above sentence after the following paragraph that discusses the production of a routing framework. I think I would first specify the routing framework and then elaborate on the metrics to be used by the protocol. But that's cosmetics :-) =20 - 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. =20 - Produce a security framework for routing in L2Ns. =20 Cheers, Christian. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Nov 22 08:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCaq-0002yw-Ca; Thu, 22 Nov 2007 08:59:48 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvCap-0002yn-Du for rsn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 08:59:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCap-0002yf-3p for rsn@ietf.org; Thu, 22 Nov 2007 08:59:47 -0500 Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCal-0001Gs-DR for rsn@ietf.org; Thu, 22 Nov 2007 08:59:47 -0500 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-2" Content-Transfer-Encoding: quoted-printable Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Thu, 22 Nov 2007 14:59:42 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB687EE@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAAk6WNw References: From: "Anders Brandt" To: "JP Vasseur" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Thanks for a productive meeting in Boston. The charter looks fine to me. I have no additional comments for now. b.r. Anders -R-S-N- -R-L-2-N- R O L L ! ! ! -----Original Message----- From: JP Vasseur [mailto:jvasseur@cisco.com]=20 Sent: 21. november 2007 21:19 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 =20 Description of Working Group =20 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.=20 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. =20 Work Items: =20 - 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. =20 - Specification of routing metrics used in path calculation. This = includes static and dynamic link/nodes attributes required for routing = in L2Ns. =20 - 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. =20 - Produce a security framework for routing in L2Ns. =20 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. =20 August 2008: Submit Routing metrics for L2Ns document to the IESG to be = considered as an Informational RFC. =20 September 2008: Submit first draft of the Routing for L2Ns Architecture = document (summary of requirements, path computation model, = flat/hierarchy,=A9). =20 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. =20 March 2009: Recharter. =20 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 From rsn-bounces@ietf.org Thu Nov 22 09:02:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCdB-0005Sp-QK; Thu, 22 Nov 2007 09:02:13 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvCdA-0005Sk-JH for rsn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:02:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCdA-0005Sc-9j for rsn@ietf.org; Thu, 22 Nov 2007 09:02:12 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCd7-0001Mw-5c for rsn@ietf.org; Thu, 22 Nov 2007 09:02:12 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Nov 2007 09:02:07 -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 lAME26gb018139; Thu, 22 Nov 2007 09:02:06 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAME26xX023772; Thu, 22 Nov 2007 14:02:06 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 09:02:06 -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 ; Thu, 22 Nov 2007 14:02:06 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Nov 2007 09:02:02 -0500 Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter From: JP Vasseur To: JACQUENET Christian RD-DDEV-REN , Message-ID: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAAk1ICwAABO49Q= In-Reply-To: <8AA97249241F7148BE6D3D8B93D83F5A0FB898C6@ftrdmel2> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Nov 2007 14:02:06.0860 (UTC) FILETIME=[444BBCC0:01C82D10] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3028; t=1195740126; x=1196604126; 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[RSN]=20Here=20is=20the=20new=20RL2N=20Proposed=20Wor king=20Charter |Sender:=20 |To:=20JACQUENET=20Christian=20RD-DDEV-REN=20,=0A=20=20=20=20=20=20=20=20; bh=CCyGBjJyBqKXAtlkgV0qPMj5l6tytRb6g4xvVRAcJJo=; b=TgXp8gDRrBAaat3GWVlsybwICIYwZfDB4ow5Mki34rmevXzRz6nMDsDgQIE141z3ibxSho33 mQAHsKCibTKxLeOPb3eIgxzaQe9GPysJ0TxTQJpgQUkWToSbVDXXxy++; 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: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Christian, Thanks for your continuous support and constructive comments. See inline, > From: JACQUENET Christian RD-DDEV-REN > Date: Thu, 22 Nov 2007 14:59:09 +0100 > To: JP Vasseur , > Conversation: [RSN] Here is the new RL2N Proposed Working Charter > Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter > > Dear all, > > Thanks to Jean-Philippe for posting the updated charter. A couple of > comments inline. > > [snip] > > > 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. > > CJ: I would agree with the above sentence, especially based upon the > protocol analysis draft that has been posted so far. But there is > another sentence in the "Work Items" section of the charter that > somewhat contradicts this statement, and I would therefore suggest we > fix this, by smoothing this wording a little bit. Maybe something like: > "Preliminary analysis of existing routing protocols such as OPSF, IS-IS, > AODV and OLSR seems to indicate that the L2N-specific requirements are > not addressed by such protocols, but part of the proposed WG charter > will further investigate, as mentioned below." That makes a lot of sense. We will reword along those lines. > > > [snip] > Work Items: > > - 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. > > CJ: I'm fine with this wording, assuming a rewording of the > corresponding statement above (see previous comment). OK. > > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/nodes attributes required for routing > in L2Ns. > > CJ: I would put the above sentence after the following paragraph that > discusses the production of a routing framework. I think I would first > specify the routing framework and then elaborate on the metrics to be > used by the protocol. But that's cosmetics :-) Yes, cosmetic is fine too ;-) > > - 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. > > Cheers, Thanks. JP. > > Christian. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Nov 22 09:16:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCrB-00070j-5K; Thu, 22 Nov 2007 09:16:41 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvCr9-00070c-O6 for rsn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:16:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCr9-00070U-Eb for rsn@ietf.org; Thu, 22 Nov 2007 09:16:39 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCr5-0001mL-MY for rsn@ietf.org; Thu, 22 Nov 2007 09:16:39 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Nov 2007 09:16:35 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAMEGZBG004429; Thu, 22 Nov 2007 09:16:35 -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 lAMEGYKH021251; Thu, 22 Nov 2007 14:16:34 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 09:16:34 -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 ; Thu, 22 Nov 2007 14:16:34 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Thu, 22 Nov 2007 09:16:30 -0500 Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter From: JP Vasseur To: Anders Brandt , Message-ID: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAAk6WNwAAC7WCE= In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3EB687EE@zensys17.zensys.local> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 22 Nov 2007 14:16:34.0704 (UTC) FILETIME=[49923900:01C82D12] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5604; t=1195740995; x=1196604995; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Here=20is=20the=20new=20RL2N=20Proposed=20Wor king=20Charter |Sender:=20 |To:=20Anders=20Brandt=20,=20; bh=hgQPnN8KBKzQaOiWvU5bvhs+GZjfEq6Z/QsaZKghPjI=; b=EF+t+NhSwMc9Srgp8B5r46cPwm5L2D4YFg6FCDfX4Ztw0ddusKwUUanDEQpwTuMK+8hPFLbA FGBmOjYJnnkJC7Qy/B5ktm8k8uvwmsVoPWlKeoZ4RKeM7eyrhCx6gPD2; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Thanks for your feed-back on the charter. For you all, we discussed a new potential name ... RSN - RL2N - ...=20 *should* a WG be formed, various proposals were made including ROLL (Routin= g Over Low power and Loosy network) =3D David's idea. I also like this one. Cheers. JP. > From: Anders Brandt > Date: Thu, 22 Nov 2007 14:59:42 +0100 > To: JP Vasseur , > Conversation: [RSN] Here is the new RL2N Proposed Working Charter > Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter >=20 >=20 > Thanks for a productive meeting in Boston. >=20 > The charter looks fine to me. I have no additional comments for now. >=20 >=20 > b.r. Anders >=20 >=20 > -R-S-N- -R-L-2-N- R O L L ! ! ! >=20 >=20 > -----Original Message----- > From: JP Vasseur [mailto:jvasseur@cisco.com] > Sent: 21. november 2007 21:19 > To: rsn@ietf.org > Subject: [RSN] Here is the new RL2N Proposed Working Charter >=20 > Dear all, >=20 > As promised, here is the new proposed Working Group, which reflects the n= umber > of comments/suggestions that we received, the pre-WG consensus, ... >=20 > Thanks to Dave Ward (RTD AD) for his input. >=20 > Proposed RL2N WG Charter > =20 > Description of Working Group > =20 > L2Ns (Low power and Lossy networks) are typically composed of many embedd= ed > devices with limited power, memory, and processing resources interconnect= ed by > a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low Power = WiFi. >=20 > L2Ns are transitioning to an end-to-end IP-based solution to avoid the > problems of non-interoperable networks interconnected by protocol transla= tion > gateways and proxies. In addition, L2Ns have specific routing requirement= s > that are not currently met by existing routing protocols, such as OSPF, I= S-IS, > AODV, and OLSR. L2N path selection must be designed to take into consider= ation > the specific power, capabilities, attributes and functional characteristi= cs of > the links and nodes in the network. >=20 >=20 > There is a wide scope of application areas for L2Ns, including industrial > monitoring, building automation (HVAC, lighting/access control), connecte= d > 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 G= roup > will determine the routing requirements for these scenarios. >=20 >=20 > 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 wit= h > very modest memory and CPU pressure. >=20 >=20 > The Working Group will pay a particular attention to routing security and > manageability (e.g self managing/configuration) issues, which are particu= larly > critical for L2Ns. > =20 > Work Items: > =20 > - Produce use cases documents for Industrial, Connected Home, Building an= d > 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). >=20 >=20 > - 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. > =20 > - Specification of routing metrics used in path calculation. This include= s > static and dynamic link/nodes attributes required for routing in L2Ns. > =20 > - Provide an architectural framework for routing and path selection at La= yer > 3 (Routing for L2N Architecture) > * Decide whether the L2Ns routing protocol require a distributed, central= ized > path computation models or both. > * Decide whether the L2N routing protocol requires a hierarchical routing > approach. > =20 > - Produce a security framework for routing in L2Ns. > =20 > Goals And Milestones: >=20 >=20 > April 2008 Submit Use case/Routing requirements for Industrial, Connected > Home, Building and Urban networks applications to the IESG to be consider= ed as > an Informational RFC. > =20 > August 2008: Submit Routing metrics for L2Ns document to the IESG to be > considered as an Informational RFC. > =20 > September 2008: Submit first draft of the Routing for L2Ns Architecture > document (summary of requirements, path computation model, flat/hierarch= y,=A9). > =20 > November 2008: Submit Protocol Survey to the IESG to be considered as an > Informational RFC. >=20 > January 2009 Submit Security Framework for L2Ns to the IESG to be conside= red > as an Informational RFC >=20 > February 2009: Submit the Routing for L2Ns Architecture document (summar= y of > requirements, metrics and attributes, path selection model) to the IESG a= s an > Informational RFC. > =20 > March 2009: Recharter. > =20 >=20 > Please comment/suggest/... >=20 > See you in Vancouver. >=20 > JP and David. >=20 >=20 > _______________________________________________ > 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 From rsn-bounces@ietf.org Thu Nov 22 09:19:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCtr-0001at-QL; Thu, 22 Nov 2007 09:19:27 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvCtp-0001ak-RC for rsn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 09:19:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCtp-0001aX-ER for rsn@ietf.org; Thu, 22 Nov 2007 09:19:25 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvCto-0008KY-JD for rsn@ietf.org; Thu, 22 Nov 2007 09:19:25 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 15:19:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Thu, 22 Nov 2007 15:18:55 +0100 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A0FB89908@ftrdmel2> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAAk6WNwAAC7WCEAAA5IAA== References: <6D9687E95918C04A8B30A7D6DA805A3EB687EE@zensys17.zensys.local> From: "JACQUENET Christian RD-DDEV-REN" To: "JP Vasseur" , "Anders Brandt" , X-OriginalArrivalTime: 22 Nov 2007 14:19:20.0197 (UTC) FILETIME=[AC367350:01C82D12] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1428458891==" Errors-To: rsn-bounces@ietf.org --===============1428458891== Content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Um9sbCdzIHZlcnkgY29vbCBpbmRlZWQgOi0pDQoNCktlZXAgcm9ja2luJyA7LSkNCg0KQ2hlZXJz LA0KDQpDaHJpc3RpYW4uDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGUgOiBKUCBW YXNzZXVyIFttYWlsdG86anZhc3NldXJAY2lzY28uY29tXSANCkVudm95w6kgOiBqZXVkaSAyMiBu b3ZlbWJyZSAyMDA3IDE1OjE3DQrDgCA6IEFuZGVycyBCcmFuZHQ7IHJzbkBpZXRmLm9yZw0KT2Jq ZXQgOiBSZTogW1JTTl0gSGVyZSBpcyB0aGUgbmV3IFJMMk4gUHJvcG9zZWQgV29ya2luZyBDaGFy dGVyDQoNClRoYW5rcyBmb3IgeW91ciBmZWVkLWJhY2sgb24gdGhlIGNoYXJ0ZXIuDQoNCkZvciB5 b3UgYWxsLCB3ZSBkaXNjdXNzZWQgYSBuZXcgcG90ZW50aWFsIG5hbWUgLi4uDQoNClJTTiAtIFJM Mk4gLSAuLi4gDQoNCipzaG91bGQqIGEgV0cgYmUgZm9ybWVkLCB2YXJpb3VzIHByb3Bvc2FscyB3 ZXJlIG1hZGUgaW5jbHVkaW5nIFJPTEwgKFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvb3N5 IG5ldHdvcmspID0gRGF2aWQncyBpZGVhLiBJIGFsc28gbGlrZSB0aGlzIG9uZS4NCg0KQ2hlZXJz Lg0KDQpKUC4NCg0KDQo+IEZyb206IEFuZGVycyBCcmFuZHQgPGFickB6ZW4tc3lzLmNvbT4NCj4g RGF0ZTogVGh1LCAyMiBOb3YgMjAwNyAxNDo1OTo0MiArMDEwMA0KPiBUbzogSlAgVmFzc2V1ciA8 anZhc3NldXJAY2lzY28uY29tPiwgPHJzbkBpZXRmLm9yZz4NCj4gQ29udmVyc2F0aW9uOiBbUlNO XSBIZXJlIGlzIHRoZSBuZXcgUkwyTiBQcm9wb3NlZCBXb3JraW5nIENoYXJ0ZXINCj4gU3ViamVj dDogUkU6IFtSU05dIEhlcmUgaXMgdGhlIG5ldyBSTDJOIFByb3Bvc2VkIFdvcmtpbmcgQ2hhcnRl cg0KPiANCj4gDQo+IFRoYW5rcyBmb3IgYSBwcm9kdWN0aXZlIG1lZXRpbmcgaW4gQm9zdG9uLg0K PiANCj4gVGhlIGNoYXJ0ZXIgbG9va3MgZmluZSB0byBtZS4gSSBoYXZlIG5vIGFkZGl0aW9uYWwg Y29tbWVudHMgZm9yIG5vdy4NCj4gDQo+IA0KPiBiLnIuIEFuZGVycw0KPiANCj4gDQo+IC1SLVMt Ti0gICAtUi1MLTItTi0gICAgUiBPIEwgTCAgICEgISAhDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSlAgVmFzc2V1ciBbbWFpbHRvOmp2YXNzZXVyQGNpc2Nv LmNvbV0NCj4gU2VudDogMjEuIG5vdmVtYmVyIDIwMDcgMjE6MTkNCj4gVG86IHJzbkBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBbUlNOXSBIZXJlIGlzIHRoZSBuZXcgUkwyTiBQcm9wb3NlZCBXb3JraW5n IENoYXJ0ZXINCj4gDQo+IERlYXIgYWxsLA0KPiANCj4gQXMgcHJvbWlzZWQsIGhlcmUgaXMgdGhl IG5ldyBwcm9wb3NlZCBXb3JraW5nIEdyb3VwLCB3aGljaCByZWZsZWN0cyANCj4gdGhlIG51bWJl ciBvZiBjb21tZW50cy9zdWdnZXN0aW9ucyB0aGF0IHdlIHJlY2VpdmVkLCB0aGUgcHJlLVdHIGNv bnNlbnN1cywgLi4uDQo+IA0KPiBUaGFua3MgdG8gRGF2ZSBXYXJkIChSVEQgQUQpIGZvciBoaXMg aW5wdXQuDQo+IA0KPiBQcm9wb3NlZCBSTDJOIFdHIENoYXJ0ZXINCj4gIA0KPiBEZXNjcmlwdGlv biBvZiBXb3JraW5nIEdyb3VwDQo+ICANCj4gTDJOcyAoTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3 b3JrcykgYXJlIHR5cGljYWxseSBjb21wb3NlZCBvZiBtYW55IA0KPiBlbWJlZGRlZCBkZXZpY2Vz IHdpdGggbGltaXRlZCBwb3dlciwgbWVtb3J5LCBhbmQgcHJvY2Vzc2luZyByZXNvdXJjZXMgDQo+ IGludGVyY29ubmVjdGVkIGJ5IGEgdmFyaWV0eSBvZiB3aXJlbGVzcyBsaW5rcywgc3VjaCBhcyBJ RUVFIDgwMi4xNS40LCBCbHVldG9vdGgsIExvdyBQb3dlciBXaUZpLg0KPiANCj4gTDJOcyBhcmUg dHJhbnNpdGlvbmluZyB0byBhbiBlbmQtdG8tZW5kIElQLWJhc2VkIHNvbHV0aW9uIHRvIGF2b2lk IHRoZSANCj4gcHJvYmxlbXMgb2Ygbm9uLWludGVyb3BlcmFibGUgbmV0d29ya3MgaW50ZXJjb25u ZWN0ZWQgYnkgcHJvdG9jb2wgDQo+IHRyYW5zbGF0aW9uIGdhdGV3YXlzIGFuZCBwcm94aWVzLiBJ biBhZGRpdGlvbiwgTDJOcyBoYXZlIHNwZWNpZmljIA0KPiByb3V0aW5nIHJlcXVpcmVtZW50cyB0 aGF0IGFyZSBub3QgY3VycmVudGx5IG1ldCBieSBleGlzdGluZyByb3V0aW5nIA0KPiBwcm90b2Nv bHMsIHN1Y2ggYXMgT1NQRiwgSVMtSVMsIEFPRFYsIGFuZCBPTFNSLiBMMk4gcGF0aCBzZWxlY3Rp b24gDQo+IG11c3QgYmUgZGVzaWduZWQgdG8gdGFrZSBpbnRvIGNvbnNpZGVyYXRpb24gdGhlIHNw ZWNpZmljIHBvd2VyLCANCj4gY2FwYWJpbGl0aWVzLCBhdHRyaWJ1dGVzIGFuZCBmdW5jdGlvbmFs IGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbGlua3MgYW5kIG5vZGVzIGluIHRoZSBuZXR3b3JrLg0K PiANCj4gDQo+IFRoZXJlIGlzIGEgd2lkZSBzY29wZSBvZiBhcHBsaWNhdGlvbiBhcmVhcyBmb3Ig TDJOcywgaW5jbHVkaW5nIA0KPiBpbmR1c3RyaWFsIG1vbml0b3JpbmcsIGJ1aWxkaW5nIGF1dG9t YXRpb24gKEhWQUMsIGxpZ2h0aW5nL2FjY2VzcyANCj4gY29udHJvbCksIGNvbm5lY3RlZCBob21l LCBoZWFsdGhjYXJlLCBlbnZpcm9ubWVudGFsIG1vbml0b3JpbmcsIA0KPiBhZ3JpY3VsdHVyYWws IHNtYXJ0IGNpdGllcywgbG9naXN0aWNzLCBhc3NldHMgdHJhY2tpbmcsIGFuZCANCj4gcmVmcmln ZXJhdGlvbi4gVGhlIEwyTiBXRyB3aWxsIGZvY3VzIG9uIHJvdXRpbmcgc29sdXRpb25zIGZvciBh IHN1YnNldCANCj4gb2YgdGhlc2UgZGVwbG95bWVudCBzY2VuYXJpb3MsIG5hbWVseSBpbmR1c3Ry aWFsLCBjb25uZWN0ZWQgDQo+IGhvbWUvYnVpbGRpbmcgYW5kIHVyYmFuIGFwcGxpY2F0aW9ucy4g VGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBkZXRlcm1pbmUgdGhlIHJvdXRpbmcgcmVxdWlyZW1lbnRz IGZvciB0aGVzZSBzY2VuYXJpb3MuDQo+IA0KPiANCj4gVGhlIFdvcmtpbmcgR3JvdXAgd2lsbCBw cm92aWRlIGEgcm91dGluZyBmcmFtZXdvcmsgZm9yIHRoZXNlIA0KPiBhcHBsaWNhdGlvbiBzY2Vu YXJpb3MgdGhhdCBwcm92aWRlcyBoaWdoIHJlbGlhYmlsaXR5IGluIHRoZSBwcmVzZW5jZSANCj4g b2YgdGltZSB2YXJ5aW5nIGxvc3MgY2hhcmFjdGVyaXN0aWNzIGFuZCBjb25uZWN0aXZpdHkgd2hp bGUgcGVybWl0dGluZyANCj4gbG93LXBvd2VyIG9wZXJhdGlvbiB3aXRoIHZlcnkgbW9kZXN0IG1l bW9yeSBhbmQgQ1BVIHByZXNzdXJlLg0KPiANCj4gDQo+IFRoZSBXb3JraW5nIEdyb3VwIHdpbGwg cGF5IGEgcGFydGljdWxhciBhdHRlbnRpb24gdG8gcm91dGluZyBzZWN1cml0eSANCj4gYW5kIG1h bmFnZWFiaWxpdHkgKGUuZyBzZWxmIG1hbmFnaW5nL2NvbmZpZ3VyYXRpb24pIGlzc3Vlcywgd2hp Y2ggYXJlIA0KPiBwYXJ0aWN1bGFybHkgY3JpdGljYWwgZm9yIEwyTnMuDQo+ICANCj4gV29yayBJ dGVtczoNCj4gIA0KPiAtIFByb2R1Y2UgdXNlIGNhc2VzIGRvY3VtZW50cyBmb3IgSW5kdXN0cmlh bCwgQ29ubmVjdGVkIEhvbWUsIEJ1aWxkaW5nIA0KPiBhbmQgdXJiYW4gYXBwbGljYXRpb24gbmV0 d29ya3MuIEVhY2ggZG9jdW1lbnQgd2lsbCBkZXNjcmliZSB0aGUgdXNlIA0KPiBjYXNlIGFuZCB0 aGUgYXNzb2NpYXRlZCByb3V0aW5nIHByb3RvY29sIHJlcXVpcmVtZW50cy4gVGhlIGRvY3VtZW50 cyANCj4gd2lsbCBwcm9ncmVzcyBpbiBjb2xsYWJvcmF0aW9uIHdpdGggdGhlIDZsb3dwYW4gV29y a2luZyBHcm91cCAoSU5UIGFyZWEpLg0KPiANCj4gDQo+IC0gU3VydmV5IHRoZSBhcHBsaWNhYmls aXR5IG9mIGV4aXN0aW5nIHByb3RvY29scyB0byBMMk5zLiBUaGUgYWltIG9mIA0KPiB0aGlzIGRv Y3VtZW50IHdpbGwgYmUgdG8gYW5hbHl6ZSB0aGUgc2NhbGluZyBhbmQgY2hhcmFjdGVyaXN0aWNz IG9mIA0KPiBleGlzdGluZyBwcm90b2NvbHMgYW5kIGlkZW50aWZ5IHdoZXRoZXIgb3Igbm90IHRo ZXkgbWVldCB0aGUgcm91dGluZyANCj4gcmVxdWlyZW1lbnRzIG9mIHRoZSBMMk5zIGFwcGxpY2F0 aW9ucyBpZGVudGlmaWVkIGFib3ZlLiBFeGlzdGluZyBJR1BzLCANCj4gTUFORVQsIE5FTU8sIERU TiByb3V0aW5nIHByb3RvY29scyB3aWxsIGJlIHBhcnQgb2YgZXZhbHVhdGlvbi4NCj4gIA0KPiAt IFNwZWNpZmljYXRpb24gb2Ygcm91dGluZyBtZXRyaWNzIHVzZWQgaW4gcGF0aCBjYWxjdWxhdGlv bi4gVGhpcyANCj4gaW5jbHVkZXMgc3RhdGljIGFuZCBkeW5hbWljIGxpbmsvbm9kZXMgYXR0cmli dXRlcyByZXF1aXJlZCBmb3Igcm91dGluZyBpbiBMMk5zLg0KPiAgDQo+IC0gUHJvdmlkZSBhbiBh cmNoaXRlY3R1cmFsIGZyYW1ld29yayBmb3Igcm91dGluZyBhbmQgcGF0aCBzZWxlY3Rpb24gYXQg DQo+IExheWVyDQo+IDMgKFJvdXRpbmcgZm9yIEwyTiBBcmNoaXRlY3R1cmUpDQo+ICogRGVjaWRl IHdoZXRoZXIgdGhlIEwyTnMgcm91dGluZyBwcm90b2NvbCByZXF1aXJlIGEgZGlzdHJpYnV0ZWQs IA0KPiBjZW50cmFsaXplZCBwYXRoIGNvbXB1dGF0aW9uIG1vZGVscyBvciBib3RoLg0KPiAqIERl Y2lkZSB3aGV0aGVyIHRoZSBMMk4gcm91dGluZyBwcm90b2NvbCByZXF1aXJlcyBhIGhpZXJhcmNo aWNhbCANCj4gcm91dGluZyBhcHByb2FjaC4NCj4gIA0KPiAtIFByb2R1Y2UgYSBzZWN1cml0eSBm cmFtZXdvcmsgZm9yIHJvdXRpbmcgaW4gTDJOcy4NCj4gIA0KPiBHb2FscyBBbmQgTWlsZXN0b25l czoNCj4gDQo+IA0KPiBBcHJpbCAyMDA4IFN1Ym1pdCBVc2UgY2FzZS9Sb3V0aW5nIHJlcXVpcmVt ZW50cyBmb3IgSW5kdXN0cmlhbCwgDQo+IENvbm5lY3RlZCBIb21lLCBCdWlsZGluZyBhbmQgVXJi YW4gbmV0d29ya3MgYXBwbGljYXRpb25zIHRvIHRoZSBJRVNHIA0KPiB0byBiZSBjb25zaWRlcmVk IGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KPiAgDQo+IEF1Z3VzdCAyMDA4OiBTdWJtaXQgUm91 dGluZyBtZXRyaWNzIGZvciBMMk5zIGRvY3VtZW50IHRvIHRoZSBJRVNHIHRvIA0KPiBiZSBjb25z aWRlcmVkIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KPiAgDQo+IFNlcHRlbWJlciAyMDA4OiBT dWJtaXQgZmlyc3QgZHJhZnQgb2YgdGhlIFJvdXRpbmcgZm9yIEwyTnMgDQo+IEFyY2hpdGVjdHVy ZSBkb2N1bWVudCAgKHN1bW1hcnkgb2YgcmVxdWlyZW1lbnRzLCBwYXRoIGNvbXB1dGF0aW9uIG1v ZGVsLCBmbGF0L2hpZXJhcmNoeSzFoCkuDQo+ICANCj4gTm92ZW1iZXIgMjAwODogU3VibWl0IFBy b3RvY29sIFN1cnZleSB0byB0aGUgSUVTRyB0byBiZSBjb25zaWRlcmVkIGFzIA0KPiBhbiBJbmZv cm1hdGlvbmFsIFJGQy4NCj4gDQo+IEphbnVhcnkgMjAwOSBTdWJtaXQgU2VjdXJpdHkgRnJhbWV3 b3JrIGZvciBMMk5zIHRvIHRoZSBJRVNHIHRvIGJlIA0KPiBjb25zaWRlcmVkIGFzIGFuIEluZm9y bWF0aW9uYWwgUkZDDQo+IA0KPiBGZWJydWFyeSAyMDA5OiBTdWJtaXQgdGhlIFJvdXRpbmcgZm9y IEwyTnMgQXJjaGl0ZWN0dXJlIGRvY3VtZW50ICANCj4gKHN1bW1hcnkgb2YgcmVxdWlyZW1lbnRz LCBtZXRyaWNzIGFuZCBhdHRyaWJ1dGVzLCBwYXRoIHNlbGVjdGlvbiANCj4gbW9kZWwpIHRvIHRo ZSBJRVNHIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDLg0KPiAgDQo+IE1hcmNoIDIwMDk6IFJlY2hh cnRlci4NCj4gIA0KPiANCj4gUGxlYXNlIGNvbW1lbnQvc3VnZ2VzdC8uLi4NCj4gDQo+IFNlZSB5 b3UgaW4gVmFuY291dmVyLg0KPiANCj4gSlAgYW5kIERhdmlkLg0KPiANCj4gDQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJTTiBtYWlsaW5nIGxp c3QNCj4gUlNOQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Jzbg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpSU04gbWFpbGluZyBsaXN0DQpSU05AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Jzbg0K --===============1428458891== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1428458891==-- From rsn-bounces@ietf.org Thu Nov 22 10:43:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvECj-0005Bs-DM; Thu, 22 Nov 2007 10:43:01 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvECi-00054y-6d for rsn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 10:43:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvECh-00052Z-SI for rsn@ietf.org; Thu, 22 Nov 2007 10:42:59 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvECd-0004dw-T7 for rsn@ietf.org; Thu, 22 Nov 2007 10:42:59 -0500 X-IronPort-AV: E=Sophos;i="4.21,452,1188770400"; d="scan'208";a="158539842" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2007 16:42:22 +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 lAMFgEhT020953; Thu, 22 Nov 2007 16:42:14 +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 lAMFfua9017446; Thu, 22 Nov 2007 15:42:09 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 16:42:01 +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-2" Content-Transfer-Encoding: quoted-printable Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Thu, 22 Nov 2007 16:41:56 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04CEBD24@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAAk6WNwAAC7WCEAAr7SsA== References: <6D9687E95918C04A8B30A7D6DA805A3EB687EE@zensys17.zensys.local> From: "Pascal Thubert (pthubert)" To: "Jean Philippe Vasseur (jvasseur)" , "Anders Brandt" , X-OriginalArrivalTime: 22 Nov 2007 15:42:01.0200 (UTC) FILETIME=[39336F00:01C82D1E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6046; t=1195746134; x=1196610134; 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[RSN]=20Here=20is=20the=20new=20RL2N=20Proposed=20Wor king=20Charter |Sender:=20; bh=nIF8FWEx09TlV/z7fAQwkyDhd18LE1C+6ZCEZBp04Kg=; b=LwVpHA8QOzk2Jm/JiKqGq9vl4Z49MJOeoDCrIa8ylkA0mP6ez9/Msancq5lhwhqXCKTkXoC+ b47JOQjx7IMKWdMdbzVvWFrW7hYTSWPPSTCMAodAewgH6dD+SBcPoJ0L; 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: 501044f827b673024f6a4cb1d46e67d2 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org I like it too... It rocks :) Pascal >-----Original Message----- >From: Jean Philippe Vasseur (jvasseur) >Sent: Thursday, November 22, 2007 3:17 PM >To: Anders Brandt; rsn@ietf.org >Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > >Thanks for your feed-back on the charter. > >For you all, we discussed a new potential name ... > >RSN - RL2N - ... > >*should* a WG be formed, various proposals were made including ROLL = (Routing >Over Low power and Loosy network) =3D David's idea. I also like this = one. > >Cheers. > >JP. > > >> From: Anders Brandt >> Date: Thu, 22 Nov 2007 14:59:42 +0100 >> To: JP Vasseur , >> Conversation: [RSN] Here is the new RL2N Proposed Working Charter >> Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter >> >> >> Thanks for a productive meeting in Boston. >> >> The charter looks fine to me. I have no additional comments for now. >> >> >> b.r. Anders >> >> >> -R-S-N- -R-L-2-N- R O L L ! ! ! >> >> >> -----Original Message----- >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: 21. november 2007 21:19 >> 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 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Nov 22 16:43:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvJpY-0008El-29; Thu, 22 Nov 2007 16:43:28 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvJpW-00083f-Kf for rsn-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 16:43:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvJpW-00080J-31 for rsn@ietf.org; Thu, 22 Nov 2007 16:43:26 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvJpR-0008TX-M3 for rsn@ietf.org; Thu, 22 Nov 2007 16:43:26 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 22:43:19 +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: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter Date: Thu, 22 Nov 2007 22:44:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ** ALL, Please read and comment ** Re: [RSN] BOF Schedule, proposed agenda and WG charter thread-index: AcgmJq1o7AvDiJIZEdyAEAANk8WjQAA2xa9AAXft9kAAG8vhIA== References: <6D9687E95918C04A8B30A7D6DA805A3EB687ED@zensys17.zensys.local> From: "DOHLER Mischa RD-TECH-GRE" To: "Anders Brandt" , X-OriginalArrivalTime: 22 Nov 2007 21:43:19.0978 (UTC) FILETIME=[B2C270A0:01C82D50] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear Anders, Thanks for your response. It makes, effectively, sense now to me.=20 Kind regards,=20 Mischa. PS: I also like ROLL! =20 _______________________________________ Dr Mischa Dohler France Telecom R&D Senior Research Expert Tel: +33 4 76 76 45 14 Fax: +33 4 76 76 44 50 Mob: +33 6 74 70 86 75 http://perso.rd.francetelecom.fr/dohler _______________________________________ ... visit http://www.pimrc2008.org/ ... _______________________________________ -----Message d'origine----- De : Anders Brandt [mailto:abr@zen-sys.com]=20 Envoy=E9 : jeudi 22 novembre 2007 14:46 =C0 : DOHLER Mischa RD-TECH-GRE; rsn@ietf.org Objet : RE: ** ALL, Please read and comment ** Re: [RSN] BOF = Schedule,proposed agenda and WG charter In response to Mischa's comment on home control routing: =20 >5) We think that the three chosen categories makes sense: home automation (high node type diversity), industrial control >(low latency), >smart city (longivity). However, home automation solutions have relatively low hop-counts; we might be >wrong but we believe that routing is not really an issue and that proposed solutions (e.g. ZigBee Pro) should do for a >commercially viable roll-out. Industrial control roll-outs hamper today, mainly because of the latency problem; however, >e.g. the recently proposed IEEE 802.15.4e has the minimisation of latency as a design goal. We agree, however, with the >proposed drafts that there is still a lot of scope in optimising the energy consumption of the protocols. Our experience with Z-Wave home control over the last 5 years shows that = routing is certainly an issue. Yes, distances are short, but antenna conditions are often problematic. Plugin modules may lie on the floor next to a noisy switch-mode = converter or a Wi-Fi router Built-in wall switches may have metal = housing due to safety regulations. The same applies to ceiling outlets. All the abovementioned examples causes not only reduced reception = sensitivity but also direction-dependent reception conditions. An antenna built into a metal box does not show reception properties = even close to omni-directional. Reinforced concrete, refrigerator doors and other metal objects - and = people too - also may dampen/distort the signal I would claim that it is a lot easier to do a good antenna design in = industrial devices as you have the room needed and can place a proper = wip antenna on the top of the device in a proper high location without = having to consider the WAF (Wife Acceptance Factor). Increasing the tx power may not help a lot if the target is almost deaf = in the direction of the sender. Thus, you should expect to see both 3 and 4 hops in the home control = domain. Extending that to building control, the end-to-end hop count may = grow significantly. Obviously, you may decide to leave the node hopping to mesh-under = transport in the individual subnets. ROLL routing may still benefit from data link information, such as the = number of layer-2 hops needed to get to the actual node / the worst case = absolute delay / etc. in case multiple gateways provide access to a = subnet. (read: subnets may be running different data link technologies) Cheers, Anders _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Nov 23 06:36:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvWpx-0004mv-Bt; Fri, 23 Nov 2007 06:36:45 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvWpt-0004fV-VZ for rsn-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 06:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvWpo-0004Wz-J9 for rsn@ietf.org; Fri, 23 Nov 2007 06:36:36 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvWpl-0005Hh-3Q for rsn@ietf.org; Fri, 23 Nov 2007 06:36:36 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 12:36: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: [RSN] connected home requirements v02 Date: Fri, 23 Nov 2007 12:37:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] connected home requirements v02 thread-index: Acgj6ZrhDFSoecGrTzGViHzdoeuq+gB5U6HAAfp+8GA= References: <4736317C.5030809@eecs.berkeley.edu> <6D9687E95918C04A8B30A7D6DA805A3EB687B7@zensys17.zensys.local> From: "DOHLER Mischa RD-TECH-GRE" To: "Anders Brandt" , X-OriginalArrivalTime: 23 Nov 2007 11:36:10.0381 (UTC) FILETIME=[0B70D3D0:01C82DC5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear Anders, We are currently writing a draft for urban L2Ns and I have the remote = feeling that there is one passage in your draft which could be very = useful for our draft. To make sure, however, that I understand well, = would you please be so kind and elaborate a little more on Section 4.1. = "Support of groupcast"?=20 Many thanks and kind regards, Mischa. _______________________________________ Dr Mischa Dohler France Telecom R&D Senior Research Expert Tel: +33 4 76 76 45 14 Fax: +33 4 76 76 44 50 Mob: +33 6 74 70 86 75 http://perso.rd.francetelecom.fr/dohler _______________________________________ ... visit http://www.pimrc2008.org/ ... _______________________________________ -----Message d'origine----- De : Anders Brandt [mailto:abr@zen-sys.com]=20 Envoy=E9 : mardi 13 novembre 2007 09:30 =C0 : rsn@ietf.org Objet : [RSN] connected home requirements v02 Gentlemen, Version 2 of the routing requirements for the connected home is now = available. http://www.ietf.org/internet-drafts/draft-brandt-rl2n-home-routing-reqs- 02.txt Please do not hesitate to comment or post clarifying questions. Best regards, Anders Brandt _______________________________________________ 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 From rsn-bounces@ietf.org Fri Nov 23 07:15:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXRd-0003yW-83; Fri, 23 Nov 2007 07:15:41 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IvXRc-0003yM-Hm for rsn-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 07:15:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXRc-0003yE-75 for rsn@ietf.org; Fri, 23 Nov 2007 07:15:40 -0500 Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvXRb-0006zU-Hd for rsn@ietf.org; Fri, 23 Nov 2007 07:15:39 -0500 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: [RSN] connected home requirements v02 Date: Fri, 23 Nov 2007 13:15:37 +0100 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB687FA@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] connected home requirements v02 Thread-Index: Acgj6ZrhDFSoecGrTzGViHzdoeuq+gB5U6HAAfp+8GAABDsxwA== References: <4736317C.5030809@eecs.berkeley.edu> <6D9687E95918C04A8B30A7D6DA805A3EB687B7@zensys17.zensys.local> From: "Anders Brandt" To: "DOHLER Mischa RD-TECH-GRE" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Mischa Consider a large group of devices, e.g. all lamps in the ground floor. In order to make sure all lamps are turned off, obviously, one has to = communicate to all devices in the actual group. Timing out on a single = failing node or having to wait for other traffic in the air, = communication may be spread in time, causing lamps to turn off like, one = here, one there, one over there. We call it "the popcorn effect". To improve the user experience, we want = to be able to throw out an unacknowledged message that addresses all = nodes in the group (in the same subnet) without defining any multicast = groups upfront. Afterwards, all nodes are addressed individually. Please feel free to get inspired. I see no problem in multiple applications having some requirements in = common. br.=20 Anders ------------- Anders Brandt Senior Software Architect =20 Zensys Emdrupvej 26 DK-2100 Copenhagen O DENMARK =20 direct: +45 39130039=20 office: +45 70209940 fax: +4570209950 mail: abr@zen-sys.com web: www.zen-sys.com -----Original Message----- From: DOHLER Mischa RD-TECH-GRE = [mailto:mischa.dohler@orange-ftgroup.com]=20 Sent: 23. november 2007 12:38 To: Anders Brandt; rsn@ietf.org Subject: RE: [RSN] connected home requirements v02 Dear Anders, We are currently writing a draft for urban L2Ns and I have the remote = feeling that there is one passage in your draft which could be very = useful for our draft. To make sure, however, that I understand well, = would you please be so kind and elaborate a little more on Section 4.1. = "Support of groupcast"?=20 Many thanks and kind regards, Mischa. _______________________________________ Dr Mischa Dohler France Telecom R&D Senior Research Expert Tel: +33 4 76 76 45 14 Fax: +33 4 76 76 44 50 Mob: +33 6 74 70 86 75 http://perso.rd.francetelecom.fr/dohler _______________________________________ ... visit http://www.pimrc2008.org/ ... _______________________________________ -----Message d'origine----- De : Anders Brandt [mailto:abr@zen-sys.com] Envoy=E9 : mardi 13 novembre = 2007 09:30 =C0 : rsn@ietf.org Objet : [RSN] connected home requirements = v02 Gentlemen, Version 2 of the routing requirements for the connected home is now = available. http://www.ietf.org/internet-drafts/draft-brandt-rl2n-home-routing-reqs- 02.txt Please do not hesitate to comment or post clarifying questions. Best regards, Anders Brandt _______________________________________________ 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 From rsn-bounces@ietf.org Sat Nov 24 14:36:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw0o1-0002Xc-QE; Sat, 24 Nov 2007 14:36:45 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iw0ny-0002XO-Dc for rsn-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 14:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw0nt-0002X2-8f for rsn@ietf.org; Sat, 24 Nov 2007 14:36:37 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw0no-0007KB-DH for rsn@ietf.org; Sat, 24 Nov 2007 14:36:37 -0500 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 20:36:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C82ED1.4FCA4FA7" Date: Sat, 24 Nov 2007 20:37:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-dohler-rl2n-urban-routing-reqs-00 thread-index: Acgse7PY8iGzi5huEdy88gANk8WjQAABNUowABbrUtAACvHJtwAAG5HQAADtRuAAABxr+QAANa5wAAAx6XAABMt1UABEGBrgAAAZtiAAAE2mggAnYF4g References: From: "DOHLER Mischa RD-TECH-GRE" To: X-OriginalArrivalTime: 24 Nov 2007 19:36:18.0642 (UTC) FILETIME=[48EA5B20:01C82ED1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 713965ef965c5660ee5d9a664a73ef4a Cc: CHEGARAY Gabriel RD-TECH-GRE Subject: [RSN] draft-dohler-rl2n-urban-routing-reqs-00 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C82ED1.4FCA4FA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, Please, find a first draft on urban lossy and low power networks attached to this email. There are still pieces missing and also IDNits still gives some warnings, but I think it should do for a first round of comments. Thanks and kind regards, Mischa. _______________________________________ Dr Mischa Dohler France Telecom R&D Senior Research Expert Tel: +33 4 76 76 45 14 Fax: +33 4 76 76 44 50 Mob: +33 6 74 70 86 75 http://perso.rd.francetelecom.fr/dohler _______________________________________ ... visit http://www.pimrc2008.org/ ... _______________________________________ ------_=_NextPart_001_01C82ED1.4FCA4FA7 Content-Type: text/plain; name="draft-dohler-rl2n-urban-routing-reqs-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-dohler-rl2n-urban-routing-reqs-00.txt Content-Disposition: attachment; filename="draft-dohler-rl2n-urban-routing-reqs-00.txt" TmV0d29ya2luZyBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTS4gRG9obGVyDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEcuIE1hZGh1c3VkYW4NCkludGVuZGVkIHN0YXR1czogSW5mb3Jt YXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBDaGVnYXJheQ0KRXhwaXJl czogTWF5IDI1LCAyMDA4ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQu IFdhdHRleW5lDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDLiBKYWNxdWVuZXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEZyYW5jZSBUZWxlY29tIFImRA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vdmVtYmVyIDI0LCAy MDA3DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KICAgIFVyYmFuIFdTTnMgUm91dGluZyBSZXF1aXJlbWVudHMgaW4gTG93IFBvd2VyIGFu ZCBMb3NzeSBOZXR3b3Jrcw0KICAgICAgICAgICAgICAgIGRyYWZ0LWRvaGxlci1ybDJuLXVyYmFu LXJvdXRpbmctcmVxcy0wMA0KDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0 dGluZyB0aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55 DQogICBhcHBsaWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9y IHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55 IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVzDQogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwg aW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQog ICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAg Tm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC0NCiAgIERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFy ZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBh bmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1l bnRzIGF0DQogICBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0 LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0 aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2ll dGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g TWF5IDI1LCAyMDA4Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhl IElFVEYgVHJ1c3QgKDIwMDcpLg0KDQpBYnN0cmFjdA0KDQogICBUaGUgYXBwbGljYXRpb24gc3Bl Y2lmaWMgcm91dGluZyByZXF1aXJlbWVudHMgZm9yIFVyYmFuIExvdyBQb3dlciBhbmQNCiAgIExv c3N5IE5ldHdvcmtzIChVLUwyTnMpIGFyZSBwcmVzZW50ZWQgaW4gdGhpcyBkb2N1bWVudC4gSW4g dGhlIG5lYXINCiAgIGZ1dHVyZSwgc2Vuc2luZyBhbmQgYWN0dWF0aW5nIG5vZGVzIHdpbGwgYmUg cGxhY2VkIG91dGRvb3JzIGluIHVyYmFuDQogICBlbnZpcm9ubWVudHMgc28gYXMgdG8gaW1wcm92 ZSB0aGUgY2l0aXplbnMnIGxpdmluZyBjb25kaXRpb25zIGFzIHdlbGwNCg0KDQpEb2hsZXIsIGV0 IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAyNSwgMjAwOCAgICAgICAgICAgICAgICAgW1Bh Z2UgMV0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgIGRyYWZ0LWRvaGxlci1ybDJuLXVyYmFuLXJvdXRp bmctcmVxcy0wMCAgIE5vdmVtYmVyIDIwMDcNCg0KDQogICBhcyB0byBtb25pdG9yIGNvbXBsaWFu Y2Ugd2l0aCBpbmNyZWFzaW5nbHkgc3RyaWN0IGVudmlyb25tZW50YWwgbGF3cy4NCiAgIFRoZXNl IGZpZWxkIG5vZGVzIGFyZSBleHBlY3RlZCB0byBtZWFzdXJlIGFuZCByZXBvcnQgYSB3aWRlIGdh bXV0IG9mDQogICBkYXRhLCBzdWNoIGFzIHJlcXVpcmVkIGluIHNtYXJ0IG1ldGVyaW5nLCB3YXN0 ZSBkaXNwb3NhbCwNCiAgIG1ldGVvcm9sb2dpY2FsLCBwb2xsdXRpb24gYW5kIGFsbGVyZ3kgcmVw b3J0aW5nIGFwcGxpY2F0aW9ucy4gVGhlDQogICBtYWpvcml0eSBvZiB0aGVzZSBub2RlcyBpcyBl eHBlY3RlZCB0byBjb21tdW5pY2F0ZSB3aXJlbGVzc2x5IHdoaWNoDQogICAtIGdpdmVuIHRoZSBs aW1pdGVkIHJhZGlvIHJhbmdlIC0gcmVxdWlyZXMgdGhlIHVzZSBvZiBzdWl0YWJsZQ0KICAgbXVs dGktaG9wIHJvdXRpbmcgcHJvdG9jb2xzLiBUaGUgZGVzaWduIG9mIHN1Y2ggcHJvdG9jb2xzIHdp bGwgYmUNCiAgIG1haW5seSBpbXBhY3RlZCBieSB0aGUgbGltaXRlZCByZXNvdXJjZXMgb2YgdGhl IG5vZGVzIChtZW1vcnksDQogICBwcm9jZXNzaW5nIHBvd2VyLCBiYXR0ZXJ5LCBldGMpIGFuZCB0 aGUgcGFydGljdWxhcml0aWVzIG9mIHRoZQ0KICAgb3V0ZG9vcnMgdXJiYW4gYXBwbGljYXRpb24g c2NlbmFyaW8uIEFzIHN1Y2gsIGZvciBhIHdpcmVsZXNzIFJMMk4NCiAgIHNvbHV0aW9uIHRvIGJl IGNvbXBldGl0aXZlIHdpdGggb3RoZXIgaW5jdW1iZW50IGFuZCBlbWVyZ2luZw0KICAgc29sdXRp b25zLCB0aGUgcHJvdG9jb2wgb3VnaHQgdG8gYmUgZW5lcmd5LWVmZmljaWVudCwgc2NhbGFibGUg YW5kDQogICBhdXRvbm9tb3VzLiBUaGlzIGRvY3VtZW50cyBhaW1zIHRvIHNwZWNpZnkgYSBzZXQg b2YgcmVxdWlyZW1lbnRzDQogICByZWZsZWN0aW5nIHRoZXNlIGFuZCBmdXJ0aGVyIFUtTDJOcyB0 YWlsb3JlZCBjaGFyYWN0ZXJpc3RpY3MuDQoNClJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KDQogICBU aGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNI QUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZ IiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJl dGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCkRvaGxlciwgZXQgYWwuICAg ICAgICAgICAgIEV4cGlyZXMgTWF5IDI1LCAyMDA4ICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0K DQoNCkludGVybmV0LURyYWZ0ICAgZHJhZnQtZG9obGVyLXJsMm4tdXJiYW4tcm91dGluZy1yZXFz LTAwICAgTm92ZW1iZXIgMjAwNw0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBUZXJt aW5vbG9neSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNA0KICAgMi4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAzLiAgVXJiYW4gTDJOIGFwcGxpY2F0aW9uIHNjZW5h cmlvcy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgMy4xLiAgRGVwbG95 bWVudCBvZiBub2Rlcy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0K ICAgICAzLjIuICBBc3NvY2lhdGlvbiBhbmQgZGlzYXNzb2NpYXRpb24vZGlzYXBwZWFyYW5jZSBv ZiBub2Rlcy4gLiAuICA3DQogICAgIDMuMy4gIFJlZ3VsYXIgbWVhc3VyZW1lbnQgcmVwb3J0aW5n LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgICAgMy40LiAgUXVlcmllZCBtZWFz dXJlbWVudCByZXBvcnRpbmcuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICAz LjUuICBBbGVydCByZXBvcnRpbmcuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA5DQogICA0LiAgVW5pcXVlIHJlcXVpcmVtZW50cyBvZiB1cmJhbiBMMk4gYXBwbGlj YXRpb25zLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgICAgNC4xLiAgIFNjYWxhYmlsaXR5Li4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICA0LjIuICAg UGFyYW1ldGVyIGNvbnN0cmFpbmVkIHJvdXRpbmcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDEwDQogICAgIDQuMy4gICBTdXBwb3J0IG9mIGF1dG9ub21vdXMgYW5kIGFsaWVuIGNvbmZpZ3Vy YXRpb24gLiAuIC4gLiAuIC4gMTANCiAgICAgNC40LiAgIFN1cHBvcnQgb2YgaGlnaGx5IGRpcmVj dGVkIGluZm9ybWF0aW9uIGZsb3dzLiAuIC4gLiAuIC4gLiAxMQ0KICAgICA0LjUuICAgU3VwcG9y dCBvZiBoZXRlcm9nZW5lb3VzIGZpZWxkIGRldmljZXMuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQog ICAgIDQuNi4gICBTdXBwb3J0IG9mIG11bHRpIGFuZCBncm91cGNhc3QuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMTENCiAgICAgNC43LiAgIE5ldHdvcmsgZHluYW1pY2l0eS4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KICAgICA0LjguICAgTGF0ZW5jeS4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLjEyDQogICA1LiAg VHJhZmZpYyBQYXR0ZXJuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuMTINCiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4xMg0KICAgNy4gIE9wZW4gSXNzdWVzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLjEzDQogICA4LiAgSUFOQSBD b25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu MTMNCiAgIDkuICBBY2tub3dsZWRnZW1lbnRzLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4xMw0KICAgMTAuICBSZWZlcmVuY2VzLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICAgIDEwLjEgICBOb3JtYXRp dmUgUmVmZXJlbmNlcy4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAg ICAgMTAuMiAgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxNA0KQXV0aG9ycycgQWRkcmVzc2VzLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE0DQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRG9obGVyLCBldCBhbC4gICAgICAgICAgICAg RXhwaXJlcyBNYXkgMjUsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoNCg0KSW50ZXJu ZXQtRHJhZnQgICBkcmFmdC1kb2hsZXItcmwybi11cmJhbi1yb3V0aW5nLXJlcXMtMDAgICBOb3Zl bWJlciAyMDA3DQoNCg0KMS4gIFRlcm1pbm9sb2d5DQoNCiAgIEFjY2VzcyBQb2ludDogVGhlIGFj Y2VzcyBwb2ludCBpcyBhbiBpbmZyYXN0cnVjdHVyZSBkZXZpY2UgdGhhdA0KICAgY29ubmVjdHMg dGhlIGxvdyBwb3dlciBhbmQgbG9zc3kgbmV0d29yayBzeXN0ZW0gdG8gYSBiYWNrYm9uZQ0KICAg bmV0d29yay4NCg0KICAgQWN0dWF0b3I6IGEgZmllbGQgZGV2aWNlIHRoYXQgbW92ZXMgb3IgY29u dHJvbHMgZXF1aXBtZW50Lg0KDQogICBGaWVsZCBEZXZpY2U6IHBoeXNpY2FsIGRldmljZSBwbGFj ZWQgaW4gdGhlIHVyYmFuIG9wZXJhdGluZw0KICAgZW52aXJvbm1lbnQuIEZpZWxkIGRldmljZXMg aW5jbHVkZSBzZW5zb3JzLCBhY3R1YXRvcnMgYW5kIHJlcGVhdGVycy4NCg0KICAgTDJOOiBMb3cg UG93ZXIgYW5kIExvc3N5IE5ldHdvcmsgDQoNCiAgIFNjaGVkdWxlOiBBbiBhZ3JlZWQgZXhlY3V0 aW9uLCB3YWtlLXVwLCB0cmFuc21pc3Npb24sIHJlY2VwdGlvbiwgZXRjLA0KICAgdGltZS10YWJs ZSBiZXR3ZWVuIHR3byBvciBtb3JlIGZpZWxkIGRldmljZXMuDQoNCiAgIFRpbWVzbG90OiBBIGZp eGVkIHRpbWUgaW50ZXJ2YWwgdGhhdCBtYXkgYmUgdXNlZCBmb3IgdGhlIHRyYW5zbWlzc2lvbg0K ICAgb3IgcmVjZXB0aW9uIG9mIGEgcGFja2V0IGJldHdlZW4gdHdvIGZpZWxkIGRldmljZXMuICBB IHRpbWVzbG90IHVzZWQNCiAgIGZvciBjb21tdW5pY2F0aW9ucyBpcyBhc3NvY2lhdGVkIHdpdGgg YSBzbG90dGVkLWxpbmsuICANCg0KICAgUkwyTjogUm91dGluZyBpbiBMb3cgcG93ZXIgYW5kIExv c3N5IE5ldHdvcmtzDQoNCjIuICBJbnRyb2R1Y3Rpb24NCg0KICAgV2UgZGV0YWlsIGhlcmUgc29t ZSBhcHBsaWNhdGlvbiBzcGVjaWZpYyByb3V0aW5nIHJlcXVpcmVtZW50cyBmb3INCiAgIFVyYmFu IExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKFUtTDJOcykuIEEgVS1MMk4gaXMgdW5kZXJz dG9vZCB0bw0KICAgYmUgYSBuZXR3b3JrIGNvbXBvc2VkIG9mIGZvdXIga2V5IGVsZW1lbnRzLCBp LmUuIA0KICAgIDEpIHNlbnNvcnMsIA0KICAgIDIpIGFjdHVhdG9ycywgDQogICAgMykgcmVwZWF0 ZXJzLCBhbmQNCiAgICA0KSBhY2Nlc3MgcG9pbnRzLCANCndoaWNoIGNvbW11bmljYXRlIHdpcmVs ZXNzbHkuIA0KDQpUaGUgYWNjZXNzIHBvaW50IGNhbiBiZSB1c2VkIGFzOg0KICAgIDEpIGdhdGV3 YXkgdG8gYSB3aWRlciBpbmZyYXN0cnVjdHVyZSAoZS5nLiBJbnRlcm5ldCksDQogICAgMikgZGF0 YSBzaW5rIChlLmcuIGRhdGEgY29sbGVjdGlvbiAmIHByb2Nlc3NpbmcgZnJvbSBzZW5zb3JzKSwg YW5kDQogICAgMykgZGF0YSBzb3VyY2UgKGUuZy4gaW5zdHJ1Y3Rpb25zIHRvd2FyZHMgYWN0dWF0 b3JzKS4NClRoZXJlIGNhbiBiZSBzZXZlcmFsIGFjY2VzcyBwb2ludHMgY29ubmVjdGVkIHRvIHRo ZSBzYW1lIFUtTDJOOyBob3dldmVyLCANCnRoZSBudW1iZXIgb2YgYWNjZXNzIHBvaW50cyBpcyB3 ZWxsIGJlbG93IHRoZSBhbW91bnQgb2Ygc2Vuc2luZyBub2Rlcy4gDQpUaGUgYWNjZXNzIHBvaW50 cyBhcmUgbWFpbmx5IHN0YXRpYywgaS5lLiBmaXhlZCB0byBhIHJhbmRvbSBvciBwcmUtDQpwbGFu bmVkIGxvY2F0aW9uLCBidXQgY2FuIGJlIG5vbWFkaWMsIGkuZS4gaW4gZm9ybSBvZiBhIHdhbGtp bmcgDQpzdXBlcnZpc29yLiBBY2Nlc3MgcG9pbnRzIG1heSBidXQgZ2VuZXJhbGx5IGRvIG5vdCBz dWZmZXIgZnJvbSBhbnkgZm9ybSANCm9mIChsb25nLXRlcm0pIHJlc291cmNlIGNvbnN0cmFpbnQs IGV4Y2VwdCB0aGF0IHRoZXkgbmVlZCB0byBiZSBzbWFsbCANCmFuZCBzdWZmaWNpZW50bHkgY2hl YXAuDQoNCg0KDQoNCkRvaGxlciwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDI1LCAy MDA4ICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDQoNCkludGVybmV0LURyYWZ0ICAgZHJhZnQt ZG9obGVyLXJsMm4tdXJiYW4tcm91dGluZy1yZXFzLTAwICAgTm92ZW1iZXIgMjAwNw0KDQoNClJl cGVhdGVycyBnZW5lcmFsbHkgYWN0IGFzIHJlbGF5cyB3aXRoIHRoZSBhaW0gdG8gY2xvc2UgY292 ZXJhZ2UgYW5kIA0Kcm91dGluZyBnYXBzOyBleGFtcGxlcyBvZiB0aGVpciB1c2UgYXJlOg0KICAg IDEpIHByb2xvbmcgdGhlIFUtTDJOJ3MgbGlmZXRpbWUsDQogICAgMikgYmFsYW5jZSBub2Rlcycg ZW5lcmd5IGRlcGxldGlvbiwNCiAgICAzKSBidWlsZCBhZHZhbmNlZCBzZW5zaW5nIGluZnJhc3Ry dWN0dXJlcy4NClRoZXJlIGNhbiBiZSBzZXZlcmFsIHJlcGVhdGVycyBzdXBwb3J0aW5nIHRoZSBz YW1lIFUtTDJOOyBob3dldmVyLCB0aGUgDQpudW1iZXIgb2YgcmVwZWF0ZXJzIGlzIHdlbGwgYmVs b3cgdGhlIGFtb3VudCBvZiBzZW5zaW5nIG5vZGVzLiBUaGUgDQpyZXBlYXRlcnMgYXJlIG1haW5s eSBzdGF0aWMsIGkuZS4gZml4ZWQgdG8gYSByYW5kb20gb3IgcHJlLXBsYW5uZWQgDQpsb2NhdGlv bi4gUmVwZWF0ZXJzIG1heSBidXQgZ2VuZXJhbGx5IGRvIG5vdCBzdWZmZXIgZnJvbSBhbnkgZm9y bSBvZiANCihsb25nLXRlcm0pIHJlc291cmNlIGNvbnN0cmFpbnQsIGV4Y2VwdCB0aGF0IHRoZXkg bmVlZCB0byBiZSBzbWFsbCBhbmQgDQpzdWZmaWNpZW50bHkgY2hlYXAuDQoNCkFjdHVhdG9yIG5v ZGVzIGNvbnRyb2wgdXJiYW4gZGV2aWNlcyB1cG9uIGJlaW5nIGluc3RydWN0ZWQgYnkgc2lnbmFs aW5nIA0KYXJyaXZpbmcgZnJvbSB0aGUgYWNjZXNzIHBvaW50KHMpOyBleGFtcGxlcyBhcmUgc3Ry ZWV0IG9yIHRyYWZmaWMgbGlnaHRzLiANClRoZSBhbW91bnQgb2YgYWN0dWF0b3IgcG9pbnRzIGlz IHdlbGwgYmVsb3cgdGhlIG51bWJlciBvZiBzZW5zaW5nIG5vZGVzLiANCkFjdHVhdG9ycyBhcmUg Y2FwYWJsZSB0byByZWxheSwgaS5lLiByb3V0ZSBkYXRhLiBBY3R1YXRvcnMgbWF5IGdlbmVyYWxs eSANCmJlIG1vYmlsZSBidXQgYXJlIGxpa2VseSB0byBiZSBzdGF0aWMgaW4gdGhlIG1ham9yaXR5 IG9mIG5lYXItZnV0dXJlIA0Kcm9sbC1vdXRzLiBTaW1pbGFyIHRvIHRoZSBhY2Nlc3MgcG9pbnRz LCBhY3R1YXRvciBub2RlcyBkbyBub3Qgc3VmZmVyIA0KZnJvbSBhbnkgbG9uZy10ZXJtIHJlc291 cmNlIGNvbnN0cmFpbnRzLiANCg0KU2Vuc2luZyBub2RlcyBtZWFzdXJlIGEgd2lkZSBnYW11dCBv ZiBwaHlzaWNhbCBkYXRhLCBpbmNsdWRpbmcgYnV0IG5vdCANCmxpbWl0ZWQgdG86DQogICAxKSBt dW5pY2lwYWwgY29uc3VtcHRpb24gZGF0YSwgc3VjaCBhcyB0aGUgc21hcnQtbWV0ZXJpbmcgb2Yg Z2FzLCANCiAgICAgIHdhdGVyLCBlbGVjdHJpY2l0eSwgd2FzdGUsIGV0YzsNCiAgIDIpIG1ldGVv cm9sb2dpY2FsIGRhdGEsIHN1Y2ggYXMgdGVtcGVyYXR1cmUsIHByZXNzdXJlLCBodW1pZGl0eSwg c3VuIA0KICAgICAgaW5kZXgsIHN0cmVuZ3RoIGFuZCBkaXJlY3Rpb24gb2Ygd2luZCwgZXRjOw0K ICAgMykgcG9sbHV0aW9uIGRhdGEsIHN1Y2ggYXMgcG9sbHV0aW5nIGdhc2VzIChTTzIsIE5PeCwg Q08sIE96b25lKSwgDQogICAgICBoZWF2eSBtZXRhbHMgKGUuZy4gTWVyY3VyeSksIHBILCByYWRp b2FjdGl2aXR5LCBldGM7DQogICA0KSBhbWJpZW50IGRhdGEsIHN1Y2ggYXMgYWxsZXJnaWMgZWxl bWVudHMgKHBvbGxlbiwgZHVzdCksIEVNIA0KcG9sbHV0aW9uLCBub2lzZSBsZXZlbHMsIGV0Yy4N CldoaWxzdCBtaWxsaW9uIG9mIHNlbnNpbmcgbm9kZXMgbWF5IHZlcnkgd2VsbCBiZSBkZXBsb3ll ZCBpbiBhbiB1cmJhbiANCmFyZWEsIHRoZXkgYXJlIGxpa2VseSB0byBiZSBhc3NvY2lhdGVkIHRv IG1vcmUgdGhhbiBvbmUgbmV0d29yayB3aGVyZSANCnRoZXNlIG5ldHdvcmtzIG1heSBvciBtYXkg bm90IGNvbW11bmljYXRlIGJldHdlZW4gZWFjaCBvdGhlci4gVGhlIG51bWJlciANCm9mIHNlbnNp bmcgbm9kZXMgY29ubmVjdGVkIHRvIGEgc2luZ2xlIG5ldHdvcmsgaXMgZXhwZWN0ZWQgdG8gYmUg aW4gdGhlIA0Kb3JkZXIgb2YgMTBeMi0xMF40OyB0aGlzIGlzIHN0aWxsIHZlcnkgbGFyZ2UgYW5k IHVucHJlY2VkZW50ZWQgaW4gDQpjdXJyZW50IHJvbGwtb3V0cy4gRGVwbG95bWVudCBvZiBub2Rl cyBpcyBsaWtlbHkgdG8gaGFwcGVuIGluIGJhdGNoZXMsIA0KaS5lLiBhIGJveCBvZiBodW5kcmVk cyBvZiBub2RlcyBhcnJpdmVzIGFuZCBpcyBkZXBsb3llZC4gVGhlIGxvY2F0aW9uIG9mIA0KdGhl IG5vZGVzIGlzIHJhbmRvbSB3aXRoaW4gZ2l2ZW4gdG9wb2xvZ2ljYWwgY29uc3RyYWludHMsIGUu Zy4gcGxhY2VtZW50IA0KYWxvbmcgYSByb2FkIG9yIHJpdmVyLiBUaGUgbm9kZXMgYXJlIGhpZ2hs eSByZXNvdXJjZSBjb25zdHJhaW50LCBpLmUuIA0KY2hlYXAgaGFyZHdhcmUsIGxvdyBtZW1vcnkg YW5kIG5vIGluZmluaXRlIGVuZXJneSBzb3VyY2UuIERpZmZlcmVudCBub2RlIA0KcG93ZXJpbmcg bWVjaGFuaXNtcyBhcmUgYXZhaWxhYmxlLCBzdWNoIGFzOg0KICAgMSkgbm9uLXJlY2hhcmdlYWJs ZSBiYXR0ZXJ5Ow0KICAgMikgcmVjaGFyZ2VhYmxlIGJhdHRlcnkgd2l0aCByZWd1bGFyIHJlY2hh cmdpbmcgKGUuZy4gc3VubGlnaHQpOw0KICAgMykgcmVjaGFyZ2VhYmxlIGJhdHRlcnkgd2l0aCBp cnJlZ3VsYXIgcmVjaGFyZ2luZyAoZS5nLiBvcHBvcnR1bmlzdGljIA0KZW5lcmd5IHNjYXZlbmdp bmcpOw0KDQoNCg0KRG9obGVyLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjUsIDIw MDggICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICBkcmFmdC1k b2hsZXItcmwybi11cmJhbi1yb3V0aW5nLXJlcXMtMDAgICBOb3ZlbWJlciAyMDA3DQoNCg0KICAg IDQpIGNhcGFjaXRpdmUvaW5kdWN0aXZlIGVuZXJneSBwcm92aXNpb24gKGUuZy4gYWN0aXZlIFJG SUQpLg0KVGhlIGJhdHRlcnkgbGlmZS10aW1lIGlzIHVzdWFsbHkgaW4gdGhlIG9yZGVyIG9mIDEw LTE1IHllYXJzLCByZW5kZXJpbmcgDQpuZXR3b3JrIGxpZmV0aW1lIG1heGltaXphdGlvbiB3aXRo IGJhdHRlcnktcG93ZXJlZCBub2RlcyBiZXlvbmQgdGhpcyANCmxpZmVzcGFuIHVzZWxlc3MuIA0K DQpUaGUgcGh5c2ljYWwgYW5kIGVsZWN0cm9tYWduZXRpYyBkaXN0YW5jZXMgYmV0d2VlbiB0aGUg Zm91ciBrZXkgZWxlbWVudHMsIA0KaS5lLiBzZW5zb3JzLCBhY3R1YXRvcnMsIHJlcGVhdGVycyBh bmQgYWNjZXNzIHBvaW50cywgY2FuIGdlbmVyYWxseSBiZSANCnZlcnkgbGFyZ2UsIGkuZS4gZnJv bSBzZXZlcmFsIGh1bmRyZWRzIG9mIG1ldGVycyB0byBvbmUga2lsb21ldGVyLiBOb3QgDQpldmVy eSBmaWVsZCBub2RlIGlzIGxpa2VseSB0byByZWFjaCB0aGUgYWNjZXNzIHBvaW50IGluIGEgc2lu Z2xlIGhvcCwgDQp0aGVyZWJ5IHJlcXVpcmluZyBzdWl0YWJsZSBtdWx0aS1ob3Agcm91dGluZyBw cm90b2NvbHMgd2hpY2ggbWFuYWdlIHRoZSANCmluZm9ybWF0aW9uIGZsb3cgaW4gYW4gZW5lcmd5 LWVmZmljaWVudCBtYW5uZXIuIFNlbnNvciBub2RlcyBhcmUgY2FwYWJsZSANCnRvIHJlbGF5LCBp LmUuIHJvdXRlIGRhdGEuDQoNClVubGlrZSB0cmFkaXRpb25hbCBhZCBob2MgbmV0d29ya3MsIHRo ZSBpbmZvcm1hdGlvbiBmbG93IGluIFUtTDJOcyBpcyANCmhpZ2hseSBkaXJlY3RlZC4gVGhlcmUg YXJlIHRocmVlIG1haW4gZmxvd3MgdG8gYmUgZGlzdGluZ3Vpc2hlZDoNCiAgICAxKSBzZW5zZWQg aW5mb3JtYXRpb24gZnJvbSB0aGUgc2Vuc2luZyBub2RlcyB0b3dhcmRzIHRoZSBhY2Nlc3MgDQog ICAgICAgcG9pbnQocyk7DQogICAgMikgcXVlcnkgcmVxdWVzdHMgZnJvbSB0aGUgYWNjZXNzIHBv aW50KHMpIHRvd2FyZHMgdGhlIHNlbnNpbmcgbm9kZXM7IA0KICAgICAgIGFuZA0KICAgIDMpIGNv bnRyb2wgaW5mb3JtYXRpb24gZnJvbSB0aGUgYWNjZXNzIHBvaW50KHMpIHRvd2FyZHMgdGhlIGFj dHVhdG9ycy4gDQpTb21lIG9mIHRoZSBmbG93cyBtYXkgbmVlZCB0aGUgcmV2ZXJzZSByb3V0ZSBm b3IgZGVsaXZlcmluZyANCmFja25vd2xlZGdlbWVudHMuDQoNClNlbnNlZCBkYXRhIGlzIGxpa2Vs eSB0byBiZSBoaWdobHkgY29ycmVsYXRlZCBpbiBzcGFjZSwgdGltZSBhbmQgDQpvYnNlcnZlZCBl dmVudHM7IGFuIGV4YW1wbGUgb2YgdGhlIGxhdHRlciBpcyB3aGVuIHRlbXBlcmF0dXJlIGFuZCAN Cmh1bWlkaXR5IGluY3JlYXNlIGFzIHRoZSBkYXkgY29tbWVuY2VzLiBEYXRhIG1heSBiZSBzZW5z ZWQgYW5kIGRlbGl2ZXJlZCANCmF0IGRpZmZlcmVudCByYXRlcyB3aXRoIGJvdGggcmF0ZXMgYmVp bmcgdHlwaWNhbGx5IGZhaXJseSBsb3csIGkuZS4gaW4gDQp0aGUgcmFuZ2Ugb2YgaG91cnMsIGRh eXMsIGV0Yy4gRGF0YSBtYXkgYmUgZGVsaXZlcmVkIHJlZ3VsYXJseSBhY2NvcmRpbmcgDQp0byBh IHNjaGVkdWxlIG9yIGEgcmVndWxhciBxdWVyeTsgaXQgbWF5IGFsc28gYmUgZGVsaXZlcmVkIGly cmVndWxhcmx5IA0KYWZ0ZXIgYW4gZXh0ZXJuYWxseSB0cmlnZ2VyZWQgcXVlcnk7IGl0IG1heSBh bHNvIGJlIHRyaWdnZXJlZCBhZnRlciBhIA0Kc3VkZGVuIG5ldHdvcmstaW50ZXJuYWwgZXZlbnQg b3IgYWxlcnQuIFRoZSBuZXR3b3JrIGhlbmNlIG5lZWRzIHRvIGJlIA0KYWJsZSB0byBhZGp1c3Qg dG8gdGhlIHZhcnlpbmcgYWN0aXZpdHkgZHV0eSBjeWNsZXMsIGFzIHdlbGwgYXMgdG8gcGVyaW9k IA0KYW5kIGFwZXJpb2RpYyB0cmFmZmljLiBBbHNvLCBzZW5zZWQgZGF0YSBvdWdodCB0byBiZSBz ZWN1cmVkIGFuZCANCmxvY2F0YWJsZS4gDQoNCkZpbmFsbHksIHRoZSBvdXRkb29ycyBkZXBsb3lt ZW50IG9mIFUtTDJOcyBoYXMgYWxzbyBpbXBsaWNhdGlvbnMgZm9yIHRoZSANCmludGVyZmVyZW5j ZSB0ZW1wZXJhdHVyZSBhbmQgaGVuY2UgbGluayByZWxpYWJpbGl0eSBhbmQgcmFuZ2UgaWYgSVNN IA0KYmFuZHMgYXJlIHRvIGJlIHVzZWQuIEZvciBpbnN0YW5jZSwgaWYgdGhlIDIuNEdIeiBJU00g YmFuZCBpcyB1c2VkIHRvIA0KZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gVS1MMk4g bm9kZXMsIHRoZW4gaGVhdmlseSBsb2FkZWQgV0xBTiANCmhvdC1zcG90cyBiZWNvbWUgYSBkZXRy aW1lbnRhbCBwZXJmb3JtYW5jZSBmYWN0b3IgamVvcGFyZGl6aW5nIHRoZSANCnJlbGlhYmlsaXR5 IG9mIHRoZSBVLUwyTi4NCg0KU2VjdGlvbiAzIGRlc2NyaWJlcyBhIGZldyB0eXBpY2FsIHVzZSBj YXNlcyBmb3IgdGhlIHVyYmFuIEwyTiANCmFwcGxpY2F0aW9ucy4gU2VjdGlvbiA0IGRpc2N1c3Nl cyB0aGUgcm91dGluZyByZXF1aXJlbWVudHMgZm9yIG5ldHdvcmtzIA0KY29tcHJpc2luZyBzdWNo IGNvbnN0cmFpbmVkIGRldmljZXMgaW4gYSBVLUwyTiBlbnZpcm9ubWVudC4gVGhlc2UgDQoNCg0K RG9obGVyLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjUsIDIwMDggICAgICAgICAg ICAgICAgIFtQYWdlIDZdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICBkcmFmdC1kb2hsZXItcmwybi11 cmJhbi1yb3V0aW5nLXJlcXMtMDAgICBOb3ZlbWJlciAyMDA3DQoNCg0KcmVxdWlyZW1lbnRzIG1h eSBiZSBvdmVybGFwcGluZyByZXF1aXJlbWVudHMgZGVyaXZlZCBmcm9tIG90aGVyIA0KYXBwbGlj YXRpb24tc3BlY2lmaWMgcmVxdWlyZW1lbnRzIGRvY3VtZW50cyBvciBhcyBsaXN0ZWQgaW4gW0kt RC5jdWxsZXItDQpybDJuLXJvdXRpbmctcmVxc10uDQoNCjMuICBVcmJhbiBMMk4gYXBwbGljYXRp b24gc2NlbmFyaW9zDQoNClVyYmFuIGFwcGxpY2F0aW9ucyByZXByZXNlbnQgYSBzcGVjaWFsIHNl Z21lbnQgb2YgTDJOcyB3aXRoIGl0cyB1bmlxdWUgDQpzZXQgb2YgcmVxdWlyZW1lbnRzLiAgVG8g ZmFjaWxpdGF0ZSB0aGUgcmVxdWlyZW1lbnRzIGRpc2N1c3Npb24gaW4gDQpTZWN0aW9uIDQsIHRo aXMgc2VjdGlvbiBsaXN0cyBhIGZldyB0eXBpY2FsIGJ1dCBub3QgZXhoYXVzdGl2ZSANCmRlcGxv eW1lbnQgcHJvYmxlbXMgYW5kIHVzYWdlIGNhc2VzIG9mIFUtTDJOLiAgDQoNCjMuMS4gICBEZXBs b3ltZW50IG9mIG5vZGVzDQoNCkNvbnRyYXJ5IHRvIG90aGVyIEwyTiBhcHBsaWNhdGlvbnMsIGRl cGxveW1lbnQgb2Ygbm9kZXMgaXMgbGlrZWx5IHRvIA0KaGFwcGVuIGluIGJhdGNoZXMgb3V0IG9m IGEgYm94LiBUeXBpY2FsbHksIGh1bmRyZWRzIG9mIG5vZGVzIGFyZSBiZWluZyANCnNoaXBwZWQg YnkgdGhlIG1hbnVmYWN0dXJlciB3aXRoIHByZS1wcm9ncmFtbWVkIGZ1bmN0aW9uYWxpdGllcyB3 aGljaCANCmFyZSB0aGVuIHJvbGxlZC1vdXQgYnkgYSBzZXJ2aWNlIHByb3ZpZGVyIG9yIHN1YmNv bnRyYWN0ZWQgZW50aXRpZXMuIA0KUHJpb3Igb3IgYWZ0ZXIgcm9sbC1vdXQsIHRoZSBuZXR3b3Jr IG5lZWRzIHRvIGJlIHJhbXBlZC11cC4gVGhpcyANCmluaXRpYWxpemF0aW9uIHBoYXNlIG1heSBp bmNsdWRlLCBhbW9uZyBvdGhlcnMsIGFsbG9jYXRpb24gb2YgYWRkcmVzc2VzLCANCihoaWVyYXJj aGljYWwpIHJvbGVzIGluIHRoZSBuZXR3b3JrLCBzeW5jaHJvbml6YXRpb24sIGRldGVybWluYXRp b24gb2YgDQpzY2hlZHVsZXMsIGV0Yy4gDQoNCklmIGluaXRpYWxpemF0aW9uIGlzIHBlcmZvcm1l ZCBwcmlvciB0byByb2xsLW91dCwgYWxsIG5vZGVzIGFyZSBsaWtlbHkgDQp0byBiZSBpbiBlYWNo IG90aGVycyAxLWhvcCByYWRpbyBuZWlnaGJvcmhvb2QuIFByZS1wcm9ncmFtbWVkIE1BQyBhbmQg DQpyb3V0aW5nIHByb3RvY29scyBtYXkgaGVuY2UgZmFpbCB0byBmdW5jdGlvbiBwcm9wZXJseSwg dGhlcmVieSB3YXN0aW5nIGEgDQpsYXJnZSBhbW91bnQgb2YgZW5lcmd5LiBXaGlsc3QgdGhlIG1h am9yIGJ1cmRlbiB3aWxsIGJlIG9uIHJlc29sdmluZyBNQUMgDQpjb25mbGljdHMsIGFueSBwcm9w b3NlZCBVLUwyTiByb3V0aW5nIHByb3RvY29sIG5lZWRzIHRvIGNhdGVyIGZvciBzdWNoIGEgDQpj YXNlLg0KDQpJZiBpbml0aWFsaXphdGlvbiBpcyBwZXJmb3JtZWQgYWZ0ZXIgcm9sbC1vdXQsIG5v ZGVzIHdpbGwgaGF2ZSBhIGZpbml0ZSANCnNldCBvZiBvbmUtaG9wIG5laWdoYm9ycywgbGlrZWx5 IG9mIGxvdyBjYXJkaW5hbGl0eS4gQW55IHByb3Bvc2VkIEwyTiANCnJvdXRpbmcgcHJvdG9jb2wg b3VnaHQgdG8gc3VwcG9ydCB0aGUgYXV0b25vbW91cyBvcmdhbml6YXRpb24gYW5kIA0KY29uZmln dXJhdGlvbiBvZiB0aGUgbmV0d29yayBhdCBsb3dlc3QgcG9zc2libGUgZW5lcmd5IGNvc3QgW0x1 MjAwN10uIA0KVGhlIHJlc3VsdCBvZiBzdWNoIG9yZ2FuaXphdGlvbiBvdWdodCB0byBiZSB0aGF0 IGVhY2ggbm9kZSBvciBzZXRzIG9mIA0Kbm9kZXMgYXJlIHVuaXF1ZWx5IGFkZHJlc3NhYmxlIHNv IGFzIHRvIGZhY2lsaXRhdGUgdGhlIHNldCB1cCBvZiANCnNjaGVkdWxlcywgZXRjLiBUaGUgTDJO IHByb3RvY29sIGhlbmNlIG91Z2h0IHRvIHN1cHBvcnQgdW5pY2FzdCBhbmQgDQptdWx0aWNhc3Qg dHJhbnNtaXNzaW9uIHNjaGVtZXMsIGFtb25nIG90aGVycy4gU29sdXRpb25zIHNob3VsZCByZWZy YWluIA0KZnJvbSBicm9hZGNhc3RpbmcuDQoNCjMuMi4gICBBc3NvY2lhdGlvbiBhbmQgZGlzYXNz b2NpYXRpb24vZGlzYXBwZWFyYW5jZSBvZiBub2Rlcw0KDQpBZnRlciB0aGUgaW5pdGlhbGl6YXRp b24gcGhhc2UgYW5kIHBvc3NpYmx5IHNvbWUgb3BlcmF0aW9uYWwgdGltZSwgbmV3IA0Kbm9kZXMg bWF5IGJlIGluamVjdGVkIGludG8gdGhlIG5ldHdvcmsgYXMgd2VsbCBhcyBleGlzdGluZyBub2Rl cyByZW1vdmVkIA0KZnJvbSB0aGUgbmV0d29yay4gVGhlIGZvcm1lciBtaWdodCBiZSBiZWNhdXNl IGEgcmVtb3ZlZCBub2RlIGlzIHJlcGxhY2VkLCANCmRlbnNlciByZWFkaW5ncy9hY3R1YXRpb25z IGFyZSBuZWVkZWQgb3IgdGhlIHByb3RvY29sIHJlcG9ydHMgDQoNCg0KRG9obGVyLCBldCBhbC4g ICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjUsIDIwMDggICAgICAgICAgICAgICAgIFtQYWdlIDdd DQoNCg0KSW50ZXJuZXQtRHJhZnQgICBkcmFmdC1kb2hsZXItcmwybi11cmJhbi1yb3V0aW5nLXJl cXMtMDAgICBOb3ZlbWJlciAyMDA3DQoNCg0KY29ubmVjdGl2aXR5IHByb2JsZW1zLiBUaGUgbGF0 dGVyIG1pZ2h0IGJlIGJlY2F1c2UgYSBub2RlknMgYmF0dGVyeSBpcyANCmRlcGxldGVkLCB0aGUg bm9kZSBpcyByZW1vdmVkIGZvciBtYWludGVuYW5jZSwgdGhlIG5vZGUgaXMgc3RvbGVuIG9yIA0K YWNjaWRlbnRhbGx5IGRlc3Ryb3llZCwgZXRjLiBEaWZmZXJlbnRpYXRpb24gc2hvdWxkIGJlIG1h ZGUgYmV0d2VlbiBub2RlIA0KZGlzYXNzb2NpYXRpb24sIHdoZXJlIHRoZSBub2RlIGhhcyBlbm91 Z2ggdGltZSB0byBpbmZvcm0gdGhlIG5ldHdvcmsgDQphYm91dCBpdHMgcmVtb3ZhbCwgYW5kIGRp c2FwcGVhcmFuY2UsIHdoZXJlIHRoZSBub2RlIHNpbXBseSBkaXNhcHBlYXJzIA0Kd2l0aG91dCBw cmlvciBub3RpZmljYXRpb24uDQoNClRoZSBwcm90b2NvbCBoZW5jZSBvdWdodCB0byBzdXBwb3J0 IHRoZSBwaW5wb2ludGluZyBvZiBwcm9ibGVtYXRpYyANCnJvdXRpbmcgYXJlYXMgYXMgd2VsbCBh cyBhbiBvcmdhbml6YXRpb24gb2YgdGhlIG5ldHdvcmsgd2hpY2ggDQpmYWNpbGl0YXRlcyByZWNv bmZpZ3VyYXRpb24gaW4gdGhlIGNhc2Ugb2YgYXNzb2NpYXRpb24gYW5kIA0KZGlzYXNzb2NpYXRp b24vZGlzYXBwZWFyYW5jZSBvZiBub2RlcyBhdCBsb3dlc3QgcG9zc2libGUgZW5lcmd5IGFuZCAN CmRlbGF5LiBUaGUgbGF0dGVyIG1heSBpbmNsdWRlIHRoZSBjaGFuZ2Ugb2YgaGllcmFyY2hpZXMs IHJvdXRpbmcgcGF0aHMsIA0Kc2NoZWR1bGVzLCBldGMuIEZ1cnRoZXJtb3JlLCB0byBpbmZvcm0g dGhlIGFjY2VzcyBwb2ludChzKSBvZiB0aGUgbm9kZZJzIA0KYXJyaXZhbCBhbmQgYXNzb2NpYXRp b24gd2l0aCB0aGUgbmV0d29yaywgdW5pY2FzdCBhbmQgbXVsdGljYXN0IHNob3VsZCANCmJlIHN1 cHBvcnRlZC4gVG8gaW5mb3JtIGZyZXNobHkgYXNzb2NpYXRlZCBub2RlcyBhYm91dCBzY2hlZHVs ZXMsIHJvbGVzLCANCmV0YywgdW5pY2FzdCBvdWdodCB0byBiZSBzdXBwb3J0ZWQuDQoNCjMuMy4g ICBSZWd1bGFyIG1lYXN1cmVtZW50IHJlcG9ydGluZw0KDQpUaGUgbWFqb3JpdHkgb2Ygc2Vuc2lu ZyBub2RlcyB3aWxsIGJlIGNvbmZpZ3VyZWQgdG8gcmVwb3J0IHRoZWlyIA0KcmVhZGluZ3Mgb24g YSByZWd1bGFyIGJhc2lzLiBUaGUgZnJlcXVlbmN5IG9mIGRhdGEgc2Vuc2luZyBhbmQgcmVwb3J0 aW5nIA0KbWF5IGJlIGRpZmZlcmVudCBidXQgaXMgZ2VuZXJhbGx5IGV4cGVjdGVkIHRvIGJlIGZh aXJseSBsb3csIGkuZS4gaW4gdGhlIA0KcmFuZ2Ugb2Ygb25jZSBwZXIgaG91ciwgcGVyIGRheSwg ZXRjLiBUaGUgcmF0aW8gYmV0d2VlbiBkYXRhIHNlbnNpbmcgYW5kIA0KcmVwb3J0aW5nIGZyZXF1 ZW5jaWVzIHdpbGwgZGV0ZXJtaW5lIHRoZSBtZW1vcnkgYW5kIGRhdGEgYWdncmVnYXRpb24gDQpj YXBhYmlsaXRpZXMgb2YgdGhlIG5vZGVzLiBMYXRlbmN5IG9mIGFuIGVuZC10by1lbmQgZGVsaXZl cnkgYW5kIA0KYWNrbm93bGVkZ2VtZW50cyBvZiBhIHN1Y2Nlc3NmdWwgZGF0YSBkZWxpdmVyeSBh cmUgbm90IHZpdGFsIGFzIHNlbnNpbmcgDQpvdXRhZ2VzIGNhbiBiZSBvYnNlcnZlZCBhdCB0aGUg YWNjZXNzIHBvaW50KHMpIC0gd2hlbiwgZm9yIGluc3RhbmNlLCANCnRoZXJlIGlzIG5vIHJlYWRp bmcgYXJyaXZpbmcgZnJvbSBhIGdpdmVuIHNlbnNvciBvciBjbHVzdGVyIG9mIHNlbnNvcnMgDQp3 aXRoaW4gYSBkYXkuIEluIHRoaXMgY2FzZSwgYSBxdWVyeSBjYW4gYmUgbGF1bmNoZWQgdG8gY2hl Y2sgdXBvbiB0aGUgDQpzdGF0ZSBhbmQgYXZhaWxhYmlsaXR5IG9mIGEgc2Vuc2luZyBub2RlIG9y IHNlbnNpbmcgY2x1c3Rlci4NCg0KVGhlIHByb3RvY29sIGhlbmNlIG91Z2h0IHRvIHN1cHBvcnQg YSBsYXJnZSBudW1iZXIgb2YgaGlnaGx5IGRpcmVjdGVkIA0KdW5pY2FzdCBmbG93cyBmcm9tIHRo ZSBzZW5zaW5nIG5vZGVzIG9yIHNlbnNpbmcgY2x1c3RlcnMgdG93YXJkcyB0aGUgDQphY2Nlc3Mg cG9pbnQgb3IgaGlnaGx5IGRpcmVjdGVkIG11bHRpY2FzdCBvciBhbnljYXN0IGZsb3dzIGZyb20g dGhlIA0Kbm9kZXMgdG93YXJkcyBtdWx0aXBsZSBhY2Nlc3MgcG9pbnRzLiBSb3V0aW5nIHBhdGhz IG1heSBkZXBlbmQgb24gdGhlIA0KdHJhbnNtaXR0ZWQgaW5mb3JtYXRpb24sIHRoZSBmcmVxdWVu Y3kgb2YgcmVwb3J0aW5nLCB0aGUgYW1vdW50IG9mIA0KZW5lcmd5IHJlbWFpbmluZyBpbiB0aGUg cm91dGluZyBub2RlcywgdGhlIHJlY2hhcmdpbmcgcGF0dGVybiBvZiBlbmVyZ3ktDQpzY2F2ZW5n ZWQgbm9kZXMsIGV0Yy4gRm9yIGluc3RhbmNlLCB0ZW1wZXJhdHVyZSByZWFkaW5ncyBhcmUgcmVw b3J0ZWQgDQpldmVyeSBob3VyIHZpYSBvbmUgc2V0IG9mIHJvdXRpbmcgcGF0aHMsIHdoZXJlYXMg YWlyIHF1YWxpdHkgaW5kaWNhdG9ycyANCmFyZSByZXBvcnRlZCBldmVyeSBxdWFydGVyIG9mIGFu IGhvdXIgdmlhIGRpZmZlcmVudCBwYXRocy4gT3IsIGNlcnRhaW4gDQpyb3V0aW5nIGFyZWFzIGFy ZSBhdm9pZGVkIGF0IG5pZ2h0IGJ1dCBoZWF2aWx5IHVzZWQgZHVyaW5nIHRoZSBkYXkgd2hlbiAN Cm5vZGVzIGFyZSBzY2F2ZW5naW5nIGZyb20gc3VubGlnaHQuIA0KDQoNCg0KDQpEb2hsZXIsIGV0 IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAyNSwgMjAwOCAgICAgICAgICAgICAgICAgW1Bh Z2UgOF0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgIGRyYWZ0LWRvaGxlci1ybDJuLXVyYmFuLXJvdXRp bmctcmVxcy0wMCAgIE5vdmVtYmVyIDIwMDcNCg0KDQozLjQuICAgUXVlcmllZCBtZWFzdXJlbWVu dCByZXBvcnRpbmcNCg0KT2NjYXNpb25hbGx5LCBuZXR3b3JrIGV4dGVybmFsIGRhdGEgcXVlcmll cyBjYW4gYmUgbGF1bmNoZWQgYnkgb25lIG9yIA0Kc2V2ZXJhbCBhY2Nlc3MgcG9pbnRzLiBGb3Ig aW5zdGFuY2UsIGl0IGlzIGRlc2lyYWJsZSB0byBrbm93IHRoZSBsZXZlbCANCm9mIHBvbGx1dGlv biBhdCBhIHNwZWNpZmljIHBvaW50IG9yIGFsb25nIGEgZ2l2ZW4gcm9hZCBpbiB0aGUgdXJiYW4g DQplbnZpcm9ubWVudC4gVGhlIHF1ZXJpZXOSIHJhdGVzIG9mIG9jY3VycmVuY2UgYXJlIG5vdCBy ZWd1bGFyIGJ1dCByYXRoZXIgDQpyYW5kb20sIHdoZXJlIGhlYXZ5LXRhaWwgZGlzdHJpYnV0aW9u cyBzZWVtIGFwcHJvcHJpYXRlIHRvIG1vZGVsIHRoZWlyIA0KYmVoYXZpb3IuIFF1ZXJpZXMgZG8g bm90IG5lY2Vzc2FyaWx5IG5lZWQgdG8gYmUgcmVwb3J0ZWQgYmFjayB0byB0aGUgDQpzYW1lIGFj Y2VzcyBwb2ludCBmcm9tIHdoZXJlIHRoZSBxdWVyeSB3YXMgbGF1bmNoZWQuIFJvdW5kLXRyaXAg dGltZXMsIA0KaS5lLiBmcm9tIHRoZSBsYXVuY2ggb2YgYSBxdWVyeSBmcm9tIGFuIGFjY2VzcyBw b2ludCB0b3dhcmRzIHRoZSANCmRlbGl2ZXJ5IG9mIHRoZSBtZWFzdXJlZCBkYXRhIHRvIGFuIGFj Y2VzcyBwb2ludCwgYXJlIG9mIGltcG9ydGFuY2UuIA0KSG93ZXZlciwgdGhleSBhcmUgbm90IHZl cnkgc3RyaW5nZW50IHdoZXJlIGxhdGVuY2llcyBzaG91bGQgc2ltcGx5IGJlIA0Kc3VmZmljaWVu dGx5IHNtYWxsZXIgdGhhbiB0eXBpY2FsIHJlcG9ydGluZyBpbnRlcnZhbHM7IGZvciBpbnN0YW5j ZSwgaW4gDQp0aGUgb3JkZXIgb2Ygc2Vjb25kcyBvciBtaW51dGUuIFRvIGZhY2lsaXRhdGUgdGhl IHF1ZXJ5IHByb2Nlc3MsIFUtTDJOIA0KbmV0d29yayBkZXZpY2VzIHNob3VsZCBzdXBwb3J0IHVu aWNhc3QgYW5kIG11bHRpY2FzdCByb3V0aW5nIA0KY2FwYWJpbGl0aWVzLg0KDQpUaGUgc2FtZSBh cHByb2FjaCBpcyBhbHNvIGFwcGxpY2FibGUgZm9yIHNjaGVkdWxlIHVwZGF0ZSwgcHJvdmlzaW9u aW5nIA0Kb2YgcGF0Y2hlcyBhbmQgdXBncmFkZXMsIGV0Yy4gSW4gdGhpcyBjYXNlLCBob3dldmVy LCB0aGUgcHJvdmlzaW9uIG9mIA0KYWNrbm93bGVkZ2VtZW50cyBhbmQgdGhlIHN1cHBvcnQgb2Yg YnJvYWRjYXN0IChpbiBhZGRpdGlvbiB0byB1bmljYXN0IA0KYW5kIG11bHRpY2FzdCkgYXJlIG9m IGltcG9ydGFuY2UuDQoNCjMuNS4gICBBbGVydCByZXBvcnRpbmcNCg0KUmFyZWx5LCB0aGUgc2Vu c2luZyBub2RlcyB3aWxsIG1lYXN1cmUgYW4gZXZlbnQgd2hpY2ggY2xhc3NpZmllcyBhcyANCmFs YXJtIHdoZXJlIHN1Y2ggYSBjbGFzc2lmaWNhdGlvbiBpcyB0eXBpY2FsbHkgZG9uZSBsb2NhbGx5 IHdpdGhpbiBlYWNoIA0Kbm9kZSBieSBtZWFucyBvZiBhIHByZS1wcm9ncmFtbWVkIG9yIHByaW9y IGRpZmZ1c2VkIHRocmVzaG9sZC4gTm90ZSB0aGF0IA0Kb24gYXBwcm9hY2hpbmcgdGhlIGFsZXJ0 IHRocmVzaG9sZCBsZXZlbCwgbm9kZXMgbWF5IHdpc2ggdG8gY2hhbmdlIHRoZWlyIA0Kc2Vuc2lu ZyBhbmQgcmVwb3J0aW5nIGN5Y2xlcy4gQW4gYWxhcm0gaXMgbGlrZWx5IGJlaW5nIHJlZ2lzdGVy ZWQgYnkgYSANCnBsdXJhbGl0eSBvZiBzZW5zaW5nIG5vZGVzIHdoZXJlIHRoZSBkZWxpdmVyeSBv ZiBhIHNpbmdsZSBhbGVydCBtZXNzYWdlIA0Kd2l0aCBpdHMgbG9jYXRpb24gb2Ygb3JpZ2luIHN1 ZmZpY2VzIGluIG1vc3QgY2FzZXMuIE9uZSBleGFtcGxlIG9mIGFsZXJ0IA0KcmVwb3J0aW5nIGlz IGlmIHRoZSBsZXZlbCBvZiB0b3hpYyBnYXNlcyByaXNlcyBhYm92ZSBhIHRocmVzaG9sZCwgDQp0 aGVyZXVwb24gdGhlIHNlbnNpbmcgbm9kZXMgaW4gdGhlIHZpY2luaXR5IG9mIHRoaXMgZXZlbnQg cmVwb3J0IHRoZSANCmRhbmdlci4gQW5vdGhlciBleGFtcGxlIG9mIGFsZXJ0IHJlcG9ydGluZyBp cyB3aGVuIGEgZ2xhc3MgY29udGFpbmVyIC0gDQplcXVpcHBlZCB3aXRoIGEgc2Vuc29yIG1lYXN1 cmluZyBpdHMgbGV2ZWwgb2Ygb2NjdXBhbmN5IC0gcmVwb3J0cyB0aGF0IA0KdGhlIGNvbnRhaW5l ciBpcyBmdWxsIGFuZCBoZW5jZSBuZWVkcyB0byBiZSBlbXB0aWVkLiANCg0KUm91dGVzIGNsZWFy bHkgbmVlZCB0byBiZSB1bmljYXN0ICh0b3dhcmRzIG9uZSBhY2Nlc3MgcG9pbnQpIG9yIA0KbXVs dGljYXN0ICh0b3dhcmRzIG11bHRpcGxlIGFjY2VzcyBwb2ludHMpLiBEZWxheXMgYW5kIGxhdGVu Y2llcyBhcmUgDQppbXBvcnRhbnQ7IGhvd2V2ZXIsIGFnYWluLCBkZWxpdmVyaWVzIHdpdGhpbiBz ZWNvbmRzIHNob3VsZCBzdWZmaWNlIGluIA0KbW9zdCBvZiB0aGUgY2FzZXMuIA0KDQoNCg0KDQpE b2hsZXIsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAyNSwgMjAwOCAgICAgICAgICAg ICAgICAgW1BhZ2UgOV0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgIGRyYWZ0LWRvaGxlci1ybDJuLXVy YmFuLXJvdXRpbmctcmVxcy0wMCAgIE5vdmVtYmVyIDIwMDcNCg0KDQo0LiAgVW5pcXVlIHJlcXVp cmVtZW50cyBvZiB1cmJhbiBMMk4gYXBwbGljYXRpb25zDQoNClVyYmFuIGxvdyBwb3dlciBhbmQg bG9zc3kgbmV0d29yayBhcHBsaWNhdGlvbnMgaGF2ZSBhIG51bWJlciBvZiBzcGVjaWZpYyANCnJl cXVpcmVtZW50cyByZWxhdGVkIHRvIHRoZSBzZXQgb2Ygb3BlcmF0aW5nIGNvbmRpdGlvbnMsIGFz IGV4ZW1wbGlmaWVkIA0KaW4gdGhlIHByZXZpb3VzIHNlY3Rpb24uDQoNCjQuMS4gICBTY2FsYWJp bGl0eQ0KDQpUaGUgbGFyZ2UgYW5kIGRpdmVyc2UgbWVhc3VyZW1lbnQgc3BhY2Ugb2YgVS1MMk4g bm9kZXMgLSBjb3VwbGVkIHdpdGggDQp0aGUgdHlwaWNhbGx5IGxhcmdlIHVyYmFuIGFyZWFzIC0g d2lsbCB5aWVsZCBleHRyZW1lbHkgbGFyZ2UgbmV0d29yayANCnNpemVzLiBDdXJyZW50IHVyYmFu IHJvbGwtb3V0cyBhcmUgY29tcG9zZWQgb2Ygc29tZXRpbWVzIG1vcmUgdGhhbiANCmh1bmRyZWQg bm9kZXM7IGZ1dHVyZSByb2xsLW91dHMsIGhvd2V2ZXIsIG1heSBlYXNpbHkgcmVhY2ggbnVtYmVy cyBpbiANCnRoZSB0ZW50aCBvZiB0aG91c2FuZHMuIE9uZSBvZiB0aGUgdXRtb3N0IGltcG9ydGFu dCBMMk4gcm91dGluZyBwcm90b2NvbCANCmRlc2lnbiBjcml0ZXJpYSBpcyBoZW5jZSBzY2FsYWJp bGl0eS4gDQoNClRoZSByb3V0aW5nIHByb3RvY29sIE1VU1QgYmUgc2NhbGFibGUgdG8gYmUgYWJs ZSB0byBhY2NvbW1vZGF0ZSBhIHZlcnkgDQpsYXJnZSBhbmQgaW5jcmVhc2luZyBudW1iZXIgb2Yg bm9kZXMgd2l0aG91dCBkZXRlcmlvcmF0aW5nIHRvLWJlLQ0Kc3BlY2lmaWVkIHBlcmZvcm1hbmNl IHBhcmFtZXRlcnMgYmVsb3cgdG8tYmUtc3BlY2lmaWVkIHRocmVzaG9sZHMuIA0KDQo0LjIuICAg UGFyYW1ldGVyIGNvbnN0cmFpbmVkIHJvdXRpbmcNCg0KQmF0dGVyaWVzIGluIHNvbWUgbm9kZXMg bWF5IGRlcGxldGUgcXVpY2tlciB0aGFuIGluIG90aGVyczsgdGhlIA0KZXhpc3RlbmNlIG9mIG9u ZSBub2RlIGZvciB0aGUgbWFpbnRlbmFuY2Ugb2YgYSByb3V0aW5nIHBhdGggbWF5IG5vdCBiZSAN CmFzIGltcG9ydGFudCBhcyBvZiBhbm90aGVyIG5vZGU7IHRoZSBiYXR0ZXJ5IHNjYXZlbmdpbmcg bWV0aG9kcyBtYXkgDQpyZWNoYXJnZSB0aGUgYmF0dGVyeSBhdCByZWd1bGFyIG9yIGlycmVndWxh ciBpbnRlcnZhbHM7IHNvbWUgbm9kZXMgbWF5IA0KaGF2ZSBhIGxhcmdlciBtZW1vcnkgYW5kIGFy ZSBoZW5jZSBiZSBhYmxlIHRvIHN0b3JlIG1vcmUgbmVpZ2hib3Job29kIA0KaW5mb3JtYXRpb247 IHNvbWUgbm9kZXMgbWF5IGhhdmUgYSBzdHJvbmdlciBDUFUgYW5kIGFyZSBoZW5jZSBhYmxlIHRv IA0KcGVyZm9ybSBtb3JlIHNvcGhpc3RpY2F0ZWQgZGF0YSBhZ2dyZWdhdGlvbiBtZXRob2RzOyBl dGMuIA0KDQpUbyB0aGlzIGVuZCwgdGhlIHJvdXRpbmcgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IHBh cmFtZXRlciBjb25zdHJhaW5lZCANCnJvdXRpbmcsIHdoZXJlIGV4YW1wbGVzIG9mIHN1Y2ggcGFy YW1ldGVycyBoYXZlIGJlZW4gZ2l2ZW4gaW4gdGhlIA0KcHJldmlvdXMgcGFyYWdyYXBoLg0KDQo0 LjMuICAgU3VwcG9ydCBvZiBhdXRvbm9tb3VzIGFuZCBhbGllbiBjb25maWd1cmF0aW9uDQoNCldp dGggdGhlIGxhcmdlIG51bWJlciBvZiBub2RlcywgbWFudWFsbHkgY29uZmlndXJpbmcgYW5kIHRy b3VibGVzaG9vdGluZyANCmVhY2ggbm9kZSBpcyBub3QgcG9zc2libGUuIFRoZSBuZXR3b3JrIGlz IGV4cGVjdGVkIHRvIHNlbGYtb3JnYW5pemUgYW5kIA0Kc2VsZi1jb25maWd1cmUgYWNjb3JkaW5n IHRvIHNvbWUgcHJpb3IgZGVmaW5lZCBydWxlcyBhbmQgcHJvdG9jb2xzLCBhcyANCndlbGwgYXMg dG8gc3VwcG9ydCBleHRlcm5hbGx5IHRyaWdnZXJlZCBjb25maWd1cmF0aW9ucyAoZm9yIGluc3Rh bmNlIA0KdGhyb3VnaCBhIGNvbW1pc3Npb25pbmcgdG9vbCB3aGljaCBtYXkgZmFjaWxpdGF0ZSB0 aGUgb3JnYW5pemF0aW9uIG9mIA0KdGhlIG5ldHdvcmsgYXQgYSBtaW5pbXVtIGVuZXJneSBjb3N0 KS4NCg0KVG8gdGhpcyBlbmQsIHRoZSByb3V0aW5nIHByb3RvY29sIE1VU1QgcHJvdmlkZSBhIHNl dCBvZiBmZWF0dXJlcyANCmluY2x1ZGluZyAwLWNvbmZpZ3VyYXRpb24gYXQgbmV0d29yayByYW1w LXVwLCAobmV0d29yay1pbnRlcm5hbCkgc2VsZi0NCm9yZ2FuaXphdGlvbiBhbmQgY29uZmlndXJh dGlvbiBkdWUgdG8gdG9wb2xvZ2ljYWwgY2hhbmdlcywgYWJpbGl0eSB0byANCg0KDQoNCkRvaGxl ciwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDI1LCAyMDA4ICAgICAgICAgICAgICAg IFtQYWdlIDEwXQ0KDQoNCkludGVybmV0LURyYWZ0ICAgZHJhZnQtZG9obGVyLXJsMm4tdXJiYW4t cm91dGluZy1yZXFzLTAwICAgTm92ZW1iZXIgMjAwNw0KDQoNCnN1cHBvcnQgKG5ldHdvcmstZXh0 ZXJuYWwpIHBhdGNoZXMgYW5kIGNvbmZpZ3VyYXRpb24gdXBkYXRlcy4gRm9yIHRoZSANCmxhdHRl ciwgdGhlIHByb3RvY29sIFNIT1VMRCBzdXBwb3J0IG11bHRpY2FzdCBhbmQgYnJvYWRjYXN0IGFk ZHJlc3NpbmcuIA0KVGhlIHByb3RvY29sIFNIT1VMRCBhbHNvIHN1cHBvcnQgdGhlIGZvcm1hdGlv biBhbmQgaWRlbnRpZmljYXRpb24gb2YgDQpncm91cHMgb2YgZmllbGQgZGV2aWNlcyBpbiB0aGUg bmV0d29yay4NCg0KNC40LiAgIFN1cHBvcnQgb2YgaGlnaGx5IGRpcmVjdGVkIGluZm9ybWF0aW9u IGZsb3dzDQoNClRoZSByZXBvcnRpbmcgb2YgdGhlIGRhdGEgcmVhZGluZ3MgYnkgYSBsYXJnZSBh bW91bnQgb2Ygc3BhdGlhbGx5IA0KZGlzcGVyc2VkIG5vZGVzIHRvd2FyZHMgYSBmZXcgYWNjZXNz IHBvaW50cyB3aWxsIGxlYWQgdG8gaGlnaGx5IGRpcmVjdGVkIA0KaW5mb3JtYXRpb24gZmxvd3Mu IA0KDQpUbyB0aGlzIGVuZCwgdGhlIHJvdXRpbmcgcHJvdG9jb2wgU0hPVUxEIHN1cHBvcnQgYW5k IHV0aWxpemUgdGhpcyBmYWN0IA0KdG8gZmFjaWxpdGF0ZSBzY2FsYWJpbGl0eSBhbmQgcGFyYW1l dGVyIGNvbnN0cmFpbmVkIHJvdXRpbmcuDQoNCjQuNS4gICBTdXBwb3J0IG9mIGhldGVyb2dlbmVv dXMgZmllbGQgZGV2aWNlcw0KDQpUaGUgc2hlZXIgYW1vdW50IG9mIGRpZmZlcmVudCBmaWVsZCBk ZXZpY2VzIHdpbGwgdW5saWtlbHkgYmUgcHJvdmlkZWQgYnkgDQphIHNpbmdsZSBtYW51ZmFjdHVy ZXIuIEEgaGV0ZXJvZ2VuZW91cyByb2xsLW91dCB3aXRoIG5vZGVzIHVzaW5nIA0KZGlmZmVyZW50 IHBoeXNpY2FsIGFuZCBtZWRpdW0gYWNjZXNzIGNvbnRyb2wgbGF5ZXJzIGlzIGhlbmNlIHZlcnkg bGlrZWx5LiANCg0KVG8gdGhpcyBlbmQsIHRoZSByb3V0aW5nIHByb3RvY29scyBwcm9wb3NlZCBp biBVLUwyTiBTSE9VTEQgc3VwcG9ydCBhIA0KdmFyaWV0eSBvZiBkaWZmZXJlbnQgZGV2aWNlcyB3 aXRob3V0IGNvbXByb21pc2luZyB0aGUgb3BlcmFiaWxpdHkgYW5kIA0KZW5lcmd5IGVmZmljaWVu Y3kgb2YgdGhlIG5ldHdvcmsuIA0KDQo0LjYuICAgU3VwcG9ydCBvZiBtdWx0aSBhbmQgZ3JvdXBj YXN0DQoNClNvbWUgdXJiYW4gc2Vuc2luZyBzeXN0ZW1zIHJlcXVpcmUgbG93LWxldmVsIGFkZHJl c3Npbmcgb2YgYSBncm91cCBvZiANCm5vZGVzIGluIHRoZSBzYW1lIHN1Ym5ldCB3aXRob3V0IGFu eSBwcmlvciBjcmVhdGlvbiBvZiBtdWx0aWNhc3QgZ3JvdXBzLCANCnNpbXBseSBjYXJyeWluZyBh IGxpc3Qgb2YgcmVjaXBpZW50cyBpbiB0aGUgc3VibmV0IFtkcmFmdC1icmFuZHQtcmwybi0NCmhv bWUtcm91dGluZy1yZXFzLTAxXS4NCg0KVG8gdGhpcyBlbmQsIHRoZSByb3V0aW5nIHByb3RvY29s IE1VU1Qgc3VwcG9ydCBtdWx0aWNhc3QsIHdoZXJlIHRoZSANCnJvdXRpbmcgcHJvdG9jb2wgTVVT VCBwcm92aWRlIHRoZSBhYmlsaXR5IHRvIHJvdXRlIGEgcGFja2V0IHRvd2FyZHMgYSANCnNpbmds ZSBmaWVsZCBkZXZpY2UgKHVuaWNhc3QpIG9yIGEgc2V0IG9mIGRldmljZXMsIHdoaWNoIGV4cGxp Y2l0bHkgDQoobXVsdGljYXN0KSBvciBpbXBsaWNpdGx5IChncm91cGNhc3QpIGJlbG9uZyB0byB0 aGUgc2FtZSBncm91cC9jYXN0LiANCk5vdGUgdGhhdCBpZiBncm91cHMgY29ycmVzcG9uZCB0byBh IGdlb2dyYXBoaWNhbCBhcmVhLCBncm91cGNhc3QgaXMgDQpzeW5vbnltb3VzIHRvIGdlb2Nhc3Qu DQoNClRoZSBzdXBwb3J0IG9mIHVuaWNhc3QsIGdyb3VwY2FzdCBhbmQgbXVsdGljYXN0IGFsc28g aGFzIGFuIGltcGxpY2F0aW9uIA0Kb24gdGhlIGFkZHJlc3Npbmcgc2NoZW1lIGJ1dCBpcyBiZXlv bmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQgdGhhdCANCmZvY3VzZXMgb24gdGhlIHJvdXRp bmcgcmVxdWlyZW1lbnRzIGFzcGVjdHMuDQoNCk5vdGU6IHdpdGggSVAgbXVsdGljYXN0LCBzaWdu YWxpbmcgbWVjaGFuaXNtcyBhcmUgdXNlZCBieSBhIHJlY2VpdmVyIHRvIA0Kam9pbiBhIGdyb3Vw IGFuZCB0aGUgc2VuZGVyIGRvZXMgbm90IG5lY2Vzc2FyaWx5IGtub3cgdGhlIHJlY2VpdmVycyBv ZiANCnRoZSBncm91cC4gV2hhdCBpcyByZXF1aXJlZCBpcyB0aGUgYWJpbGl0eSB0byBhZGRyZXNz IGEgZ3JvdXAgb2YgDQoNCg0KDQpEb2hsZXIsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1h eSAyNSwgMjAwOCAgICAgICAgICAgICAgICBbUGFnZSAxMV0NCg0KDQpJbnRlcm5ldC1EcmFmdCAg IGRyYWZ0LWRvaGxlci1ybDJuLXVyYmFuLXJvdXRpbmctcmVxcy0wMCAgIE5vdmVtYmVyIDIwMDcN Cg0KDQpyZWNlaXZlcnMga25vd24gYnkgdGhlIHNlbmRlciBldmVuIGlmIHRoZSByZWNlaXZlcnMg ZG8gbm90IG5lZWQgdG8ga25vdyANCnRoYXQgdGhleSBoYXZlIGJlZW4gZ3JvdXBlZCBieSB0aGUg ICBzZW5kZXIgKHNpbmNlIHJlcXVlc3RpbmcgZWFjaCANCmluZGl2aWR1YWwgbm9kZSB0byBqb2lu IGEgbXVsdGljYXN0IGdyb3VwIHdvdWxkIGJlIHZlcnkgZW5lcmd5LQ0KY29uc3VtaW5nKS4NCg0K NC43LiAgIE5ldHdvcmsgZHluYW1pY2l0eQ0KDQpBbHRob3VnaCBtb2JpbGl0eSBpcyBhc3N1bWVk IHRvIGJlIGxvdyBpbiB1cmJhbiBMMk5zLCBuZXR3b3JrIGR5bmFtaWNpdHkgDQpkdWUgdG8gbm9k ZSBhc3NvY2lhdGlvbiwgZGlzYXNzb2NpYXRpb24gYW5kIGRpc2FwcGVhcmFuY2UgaXMgbm90IA0K bmVnbGlnaWJsZS4gVGhpcyBpbiB0dXJuIGltcGFjdHMgcmUtb3JnYW5pemF0aW9uIGFuZCByZS1j b25maWd1cmF0aW9uIA0KY29udmVyZ2VuY2UgYXMgd2VsbCBhcyByb3V0ZSBlc3RhYmxpc2htZW50 IHRpbWVzLiANCg0KVG8gdGhpcyBlbmQsIGxvY2FsIG5ldHdvcmsgZHluYW1pY3MgU0hPVUxEIE5P VCBpbXBhY3QgdGhlIGVudGlyZSBuZXR3b3JrIA0KdG8gYmUgcmUtb3JnYW5pemVkIG9yIHJlLXJl Y29uZmlndXJlZDsgaG93ZXZlciwgdGhlIG5ldHdvcmsgU0hPVUxEIGJlIA0KbG9jYWxseSBvcHRp bWl6ZWQgdG8gY2F0ZXIgZm9yIHRoZSBlbmNvdW50ZXJlZCBjaGFuZ2VzLiBDb252ZXJnZW5jZSBh bmQgDQpyb3V0ZSBlc3RhYmxpc2htZW50IHRpbWVzIFNIT1VMRCBiZSBzaWduaWZpY2FudGx5IGxv d2VyIHRoYW4gdGhlIGludmVyc2UgDQpvZiB0aGUgc21hbGxlc3QgcmVwb3J0aW5nIGN5Y2xlLg0K DQo0LjguICAgTGF0ZW5jeQ0KDQpXaXRoIHRoZSBleGNlcHRpb24gb2YgYWxlcnQgcmVwb3J0aW5n IHNvbHV0aW9ucyBhbmQgdG8gYSBjZXJ0YWluIGV4dGVudCANCnF1ZXJpZWQgcmVwb3J0aW5nLCBV LUwyTiBhcmUgZGVsYXkgdG9sZXJhbnQgYXMgbG9uZyBhcyB0aGUgaW5mb3JtYXRpb24gDQphcnJp dmVzIHdpdGhpbiBhIGZyYWN0aW9uIG9mIHRoZSBpbnZlcnNlIG9mIHRoZSByZXNwZWN0aXZlIHJl cG9ydGluZyANCmN5Y2xlLiANCg0KVG8gdGhpcyBlbmQsIHRoZSByb3V0aW5nIHByb3RvY29sIGlz IFJFQ09NTUVOREVEIHRvIHN1cHBvcnQgbWluaW11bSANCmxhdGVuY3kgZm9yIGFsZXJ0IHJlcG9y dGluZyBhbmQgdGltZS1jcml0aWNhbCBkYXRhIHF1ZXJpZXMuIEZvciByZWd1bGFyIA0KZGF0YSBy ZXBvcnRpbmcsIGl0IFNIT1VMRCBzdXBwb3J0IGxhdGVuY2llcyBub3QgZXhjZWVkaW5nIGEgZnJh Y3Rpb24gb2YgDQp0aGUgaW52ZXJzZSBvZiB0aGUgcmVzcGVjdGl2ZSByZXBvcnRpbmcgY3ljbGUu DQoNCjUuICBUcmFmZmljIFBhdHRlcm4NCg0KdGJkDQoNCjYuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucw0KDQpBcyBldmVyeSBuZXR3b3JrLCBhbHNvIFUtTDJOcyBhcmUgZXhwb3NlZCB0byBzZWN1 cml0eSB0aHJlYXRzIHdoaWNoLCBpZiANCm5vdCBwcm9wZXJseSBhZGRyZXNzZWQsIGV4Y2x1ZGUg dGhlbSB0byBiZSBkZXBsb3llZCBpbiB0aGUgZW52aXNhZ2VkIA0Kc2NlbmFyaW9zLiBUaGUgd2ly ZWxlc3MgYW5kIGRpc3RyaWJ1dGVkIG5hdHVyZSBvZiB0aGVzZSBuZXR3b3JrcyANCmRyYXN0aWNh bGx5IGluY3JlYXNlcyB0aGUgc3BlY3RydW0gb2YgcG90ZW50aWFsIHNlY3VyaXR5IHRocmVhdHM7 IHRoaXMgDQppcyBmdXJ0aGVyIGFtcGxpZmllZCBieSB0aGUgc2VyaW91cyBjb25zdHJhaW50cyBp biBub2RlIGJhdHRlcnkgcG93ZXIsIA0KdGhlcmVieSBwcmV2ZW50aW5nIHByZXZpb3VzbHkga25v d24gc2VjdXJpdHkgYXBwcm9hY2hlcyB0byBiZSBkZXBsb3llZC4gDQpBYm92ZSBtZW50aW9uZWQg aXNzdWVzIHJlcXVpcmUgc3BlY2lhbCBhdHRlbnRpb24gZHVyaW5nIHRoZSBkZXNpZ24gDQpwcm9j ZXNzLCBzbyBhcyB0byBmYWNpbGl0YXRlIGEgY29tbWVyY2lhbGx5IGF0dHJhY3RpdmUgZGVwbG95 bWVudC4NCg0KDQoNCg0KRG9obGVyLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjUs IDIwMDggICAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoNCg0KSW50ZXJuZXQtRHJhZnQgICBkcmFm dC1kb2hsZXItcmwybi11cmJhbi1yb3V0aW5nLXJlcXMtMDAgICBOb3ZlbWJlciAyMDA3DQoNCg0K QSBzZWN1cmUgY29tbXVuaWNhdGlvbiBpbiBhIHdpcmVsZXNzIG5ldHdvcmsgZW5jb21wYXNzZXMg dGhyZWUgbWFpbiANCmVsZW1lbnRzLCBpLmUuIGNvbmZpZGVudGlhbGl0eSAoZW5jcnlwdGlvbiBv ZiBkYXRhKSwgaW50ZWdyaXR5IA0KKGNvcnJlY3RuZXNzIG9mIGRhdGEpLCBhbmQgYXV0aGVudGlj YXRpb24gKGxlZ2l0aW1hY3kgb2YgZGF0YSkuIFNpbmNlIA0KdGhlIG1ham9yaXR5IG9mIG1lYXN1 cmVkIGRhdGUgaW4gVS1MMk5zIGlzIHB1YmxpY2x5IGF2YWlsYWJsZSwgdGhlIG1haW4gDQplbXBo YXNpcyBpcyBvbiBpbnRlZ3JpdHkgYW5kIGF1dGhlbnRpY2l0eSBvZiBkYXRhIHJlcG9ydGluZ3Mu IA0KQXV0aGVudGljYXRpb24gY2FuIGUuZy4gYmUgdmlvbGF0ZWQgaWYgZXh0ZXJuYWwgc291cmNl cyBpbnNlcnQgaW5jb3JyZWN0IA0KZGF0YSBwYWNrZXRzOyBpbnRlZ3JpdHkgY2FuIGUuZy4gYmUg dmlvbGF0ZWQgaWYgbm9kZXMgc3RhcnQgdG8gYnJlYWsgDQpkb3duIGFuZCBoZW5jZSBjb21tZW5j ZSBtZWFzdXJpbmcgYW5kIHJlbGF5aW5nIGRhdGEgaW5jb3JyZWN0bHkuIA0KTm9uZXRoZWxlc3Ms IHNvbWUgc2Vuc29yIHJlYWRpbmdzIGFzIHdlbGwgYXMgdGhlIGFjdHVhdG9yIGNvbnRyb2wgDQpz aWduYWxzIG5lZWQgdG8gYmUgY29uZmlkZW50aWFsLiANCg0KRnVydGhlciBleGFtcGxlIHNlY3Vy aXR5IGlzc3VlcyB3aGljaCBtYXkgYXJpc2UgYXJlIHRoZSBhYm5vcm1hbCANCmJlaGF2aW9yIG9m IG5vZGVzIHdoaWNoIGV4aGliaXQgYW4gZWdvaXN0aWMgY29uZHVjdCwgc3VjaCBhcyBub3Qgb2Jl eWluZyANCm5ldHdvcmsgcnVsZXMsIG9yIGZvcndhcmRpbmcgbm8gb3IgZmFsc2UgcGFja2V0cy4g T3RoZXIgaW1wb3J0YW50IGlzc3VlcyANCm1heSBhcmlzZSBpbiB0aGUgY29udGV4dCBvZiBEZW5p YWwgb2YgU2VydmljZSAoRG9TKSBhdHRhY2tzLCBtYWxpY2lvdXMgDQphZGRyZXNzIHNwYWNlIGFs bG9jYXRpb25zLCBhZHZlcnRpc2VtZW50IG9mIHZhcmlhYmxlIGFkZHJlc3NlcywgYSB3cm9uZyAN Cm5laWdoYm9yaG9vZCwgZXh0ZXJuYWwgYXR0YWNrcyBhaW1lZCBhdCBpbmplY3RpbmcgZHVtbXkg dHJhZmZpYyB0byBkcmFpbiANCnRoZSBuZXR3b3JrIHBvd2VyLCBldGMuDQoNClRoZSBjaG9pY2Ug b2YgdGhlIHNlY3VyaXR5IHNvbHV0aW9ucyB3aWxsIGhhdmUgYW4gaW1wYWN0IG9udG8gcm91dGlu ZyANCnByb3RvY29scy4gVG8gdGhpcyBlbmQsIHJvdXRpbmcgcHJvdG9jb2xzIHByb3Bvc2VkIGlu IHRoZSBjb250ZXh0IG9mIFUtDQpMMk5zIE1VU1Qgc3VwcG9ydCBpbnRlZ3JpdHkgbWVhc3VyZXMg YW5kIFNIT1VMRCBzdXBwb3J0IGNvbmZpZGVudGlhbGl0eSANCihzZWN1cml0eSkgbWVhc3VyZXMu DQoNCjcuICBPcGVuIElzc3Vlcw0KDQpPdGhlciBpdGVtcyB0byBiZSBhZGRyZXNzZWQgaW4gZnVy dGhlciByZXZpc2lvbnMgb2YgdGhpcyBkb2N1bWVudCANCmluY2x1ZGU6DQogICAqIG5vZGUgbW9i aWxpdHk7IGFuZCANCiAgICogdHJhZmZpYyBwYXR0ZXJucy4NCg0KOC4gIElBTkEgQ29uc2lkZXJh dGlvbnMNCg0KVGhpcyBkb2N1bWVudCBpbmNsdWRlcyBubyByZXF1ZXN0IHRvIElBTkEuDQoNCjku ICBBY2tub3dsZWRnZW1lbnRzDQoNCjEwLiAgUmVmZXJlbmNlcw0KDQoxMC4xICAgTm9ybWF0aXZl IFJlZmVyZW5jZXMNCg0KW1JGQzIxMTldICANClMuIEJyYWRuZXIsICJLZXkgd29yZHMgZm9yIHVz ZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVscyIsIA0KQkNQIDE0LCBSRkMg MjExOSwgTWFyY2ggMTk5Ny4NCg0KDQoNCg0KRG9obGVyLCBldCBhbC4gICAgICAgICAgICAgRXhw aXJlcyBNYXkgMjUsIDIwMDggICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoNCg0KSW50ZXJuZXQt RHJhZnQgICBkcmFmdC1kb2hsZXItcmwybi11cmJhbi1yb3V0aW5nLXJlcXMtMDAgICBOb3ZlbWJl ciAyMDA3DQoNCg0KMTAuMiAgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KW0ktRC5jdWxsZXIt cmwybi1yb3V0aW5nLXJlcXNdIA0KSi5QLiBWYXNzZXVyIGFuZCBELiBDdWxsZXIsICJSb3V0aW5n IFJlcXVpcmVtZW50cyBmb3IgTG93LVBvd2VyIFdpcmVsZXNzIA0KTmV0d29ya3MiLCBkcmFmdC1j dWxsZXItcmwybi1yb3V0aW5nLXJlcXMtMDAgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBKdWx5IA0KMjAw Ny4NCg0KW0x1MjAwN10NCkouTC4gTHUsIEYuIFZhbG9pcywgRC4gQmFydGhlbCwgTS4gRG9obGVy LCAiRklTQ086IEEgRnVsbHkgSW50ZWdyYXRlZCANClNjaGVtZSBvZiBTZWxmLUNvbmZpZ3VyYXRp b24gYW5kIFNlbGYtT3JnYW5pemF0aW9uIGZvciBXU04sIiBJRUVFIFdDTkMgDQoyMDA3LCBIb25n IEtvbmcsIENoaW5hLCAxMS0xNSBNYXJjaCAyMDA3LCBwcC4gMzM3MC0zMzc1Lg0KDQpbZHJhZnQt YnJhbmR0LXJsMm4taG9tZS1yb3V0aW5nLXJlcXMtMDFdDQpBLiBCcmFuZCBhbmQgSi5QLiBWYXNz ZXVyLCCTSG9tZSBBdXRvbWF0aW9uIFJvdXRpbmcgUmVxdWlyZW1lbnQgaW4gTG93IA0KUG93ZXIg YW5kIExvc3N5IE5ldHdvcmtzLJQgZHJhZnQtYnJhbmR0LXJsMm4taG9tZS1yb3V0aW5nLXJlcXMt MDEgKHdvcmsgDQppbiBwcm9ncmVzcyksIEp1bHkgMjAwNy4NCg0KQXV0aG9ycycgQWRkcmVzc2Vz DQoNCk1pc2NoYSBEb2hsZXINCkZyYW5jZSBUZWxlY29tIFImRA0KMjggQ2hlbWluIGR1IFZpZXV4 IENoZW5lDQozODI0MyBNZXlsYW4gQ2VkZXgNCkZyYW5jZSANCkVtYWlsOiBtaXNjaGEuZG9obGVy QG9yYW5nZS1mdGdyb3VwLmNvbQ0KDQpHaXl5YXJwdXJhbSBNYWRodXN1ZGFuDQpGcmFuY2UgVGVs ZWNvbSBSJkQNCjI4IENoZW1pbiBkdSBWaWV1eCBDaGVuZQ0KMzgyNDMgTWV5bGFuIENlZGV4DQpG cmFuY2UgDQpFbWFpbDogZ2l5eWFycHVyYW0ubWFkaHVzdWRhbkBvcmFuZ2UtZnRncm91cC5jb20N Cg0KR2FicmllbCBDaGVnYXJheQ0KRnJhbmNlIFRlbGVjb20gUiZEDQoyOCBDaGVtaW4gZHUgVmll dXggQ2hlbmUNCjM4MjQzIE1leWxhbiBDZWRleA0KRnJhbmNlIA0KRW1haWw6IGdhYnJpZWwuY2hl Z2FyYXlAb3JhbmdlLWZ0Z3JvdXAuY29tDQoNClRob21hcyBXYXR0ZXluZQ0KRnJhbmNlIFRlbGVj b20gUiZEDQoyOCBDaGVtaW4gZHUgVmlldXggQ2hlbmUNCjM4MjQzIE1leWxhbiBDZWRleA0KRnJh bmNlIA0KRW1haWw6IHRob21hcy53YXR0ZXluZUBvcmFuZ2UtZnRncm91cC5jb20NCg0KDQpEb2hs ZXIsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAyNSwgMjAwOCAgICAgICAgICAgICAg ICBbUGFnZSAxNF0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgIGRyYWZ0LWRvaGxlci1ybDJuLXVyYmFu LXJvdXRpbmctcmVxcy0wMCAgIE5vdmVtYmVyIDIwMDcNCg0KDQpDaHJpc3RpYW4gSmFjcXVlbmV0 IA0KRnJhbmNlIFRlbGVjb20gUiZEDQo0IHJ1ZSBkdSBDbG9zIENvdXJ0ZWwgQlAgOTEyMjYgDQoz NTUxMiBDZXNzb24gU2V2aWduZQ0KRnJhbmNlIA0KRW1haWw6IGNocmlzdGlhbi5qYWNxdWVuZXRA b3JhbmdlLWZ0Z3JvdXAuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpEb2hsZXIsIGV0 IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE1heSAyNSwgMjAwOCAgICAgICAgICAgICAgICBbUGFn ZSAxNV0NCg0KDQpJbnRlcm5ldC1EcmFmdCAgIGRyYWZ0LWRvaGxlci1ybDJuLXVyYmFuLXJvdXRp bmctcmVxcy0wMCAgIE5vdmVtYmVyIDIwMDcNCg0KDQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQN Cg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSUVURiBUcnVzdCAoMjAwNykuDQoNCiAgIFRoaXMgZG9j dW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25z DQogICBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWlu LCB0aGUgYXV0aG9ycw0KICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNCiAgIFRoaXMgZG9j dW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBv biBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFU SU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRI RSBJTlRFUk5FVCBTT0NJRVRZLCBUSEUgSUVURiBUUlVTVCBBTkQNCiAgIFRIRSBJTlRFUk5FVCBF TkdJTkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTDQog ICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBU SEFUIFRIRSBVU0UgT0YNCiAgIFRIRSBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklO R0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFC SUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KSW50ZWxsZWN0 dWFsIFByb3BlcnR5DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0 aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmln aHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4g dG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQg aW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1 bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9y IGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBl ZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRo ZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4g YmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRp c2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJh bmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBh bg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNz aW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1l bnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQg ZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3Lmll dGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0 byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBw YXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQg bWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQog ICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJ RVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBG dW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBwcm92aWRlZCBieSB0aGUgSUVU Rg0KICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSkuDQoNCg0KRG9obGVy LCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBNYXkgMjUsIDIwMDggICAgICAgICAgICAgICAg W1BhZ2UgMTZdDQoNCg0KDQo= ------_=_NextPart_001_01C82ED1.4FCA4FA7 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn ------_=_NextPart_001_01C82ED1.4FCA4FA7-- From rsn-bounces@ietf.org Sun Nov 25 23:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVlB-0007aI-7e; Sun, 25 Nov 2007 23:39:53 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IwVl9-0007aD-L6 for rsn-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 23:39:51 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IwVl9-0007a5-Bo for rsn@ietf.org; Sun, 25 Nov 2007 23:39:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVjx-00065r-Mf for rsn@ietf.org; Sun, 25 Nov 2007 23:38:37 -0500 Received: from web70109.mail.krs.yahoo.com ([202.165.108.51]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwVjw-0004dg-EB for rsn@ietf.org; Sun, 25 Nov 2007 23:38:37 -0500 Received: (qmail 99172 invoked by uid 60001); 26 Nov 2007 04:38:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.kr; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=lIwXtEaL/9YvupgZ8Gt+JNJMa41HWXaXD4vuIKYQJUoSIzZrxo4E5TtKBgn9R1I2NPBdw4Cx+VKTxjBM0FuJh3JjQh9aanQxY7ZgSP/Iut92C73Q4QiLKe964tgr79mxnhxxee8ZZ03Sw374LPpHFVOD5GZqj/RJzGHYJbmFF3o=; X-YMail-OSG: lifGS8EVM1kBVi_t..JC0XK2FjPMq8LrMtlZEFKbQUmgdkW8BBQe413VbdaheILQ5Mr9VLAiXda9Xoq9sN702gx5ppEZBB18r2x8.w-- Received: from [210.94.41.89] by web70109.mail.krs.yahoo.com via HTTP; Mon, 26 Nov 2007 13:38:34 KST Date: Mon, 26 Nov 2007 13:38:34 +0900 (KST) From: =?euc-kr?q?=B1=E8=C1=F8=C7=FC?= Subject: Re:[RSN] RL2N Comments - Question about Finland Deployment. To: rsn@ietf.org MIME-Version: 1.0 Message-ID: <331719.98690.qm@web70109.mail.krs.yahoo.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b X-TMDA-Confirmed: Sun, 25 Nov 2007 23:39:51 -0500 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1502300438==" Errors-To: rsn-bounces@ietf.org --===============1502300438== Content-Type: multipart/alternative; boundary="0-2004925155-1196051914=:98690" Content-Transfer-Encoding: 8bit --0-2004925155-1196051914=:98690 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit Hi all, I subscribed RL2N mailing list just now. I read the following post from the arciives. I have a question about "Finland Deployment" Zach Shelby said "For example here in Finland we are already rolling out fairly large 6lowpan (over 1000 node) networks in the industrial and building automation domains." To deploy 6lowpan node over 1000, I think there should be scalability issue. In current 6lowpan architecture having adaptation layer, the adaption layer should perform mesh routing. How can you solve this problem? And, I want to know the industrial and building automation domains expample in detail. Is it deployed in commercial site? or test-bed? Can I get the more information about Filand Deployment? Where or How? Thanks in advance. Jin Hyoung Kim | Engineer | Samsung Electronics. ====================================================== -Hi all, -In my opinion the proposed RL2N charter is already pretty -good, here is some support from our experience. First I would like to stress the same as JP and Phil. There is a huge need for standardized IP WSN routing in well-scoped domains *now*, *today*, to solve *real problems*. For example here in Finland we are already rolling out fairly large 6lowpan (over 1000 node) networks in the industrial and building automation domains. Our direct 6lowpan node volume, will be well over 25k nodes in 2008. SP100 helps next year, but for many applications a simpler 6lowpan + rl2n routing solution would be more suitable. Almost all customers love the IP + 802.15.4 concept. But the biggest concern they still have is a lack of a standard routing technique. I think the charter text is good, and scoping to these 3 areas really keeps it focused. One comment: - The relationship with 6lowpan and SP100 could be explicit in the charter text (not just work-items)? Have fun in Boston! - Zach -- Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com --------------------------------- ¿Ã ÇÑÇØ °í¸¶¿ü´ø »ç¶÷µé¿¡°Ô ¸Þ½ÃÁö º¸³»°í ¼±¹°¹ÞÀ¸¼¼¿ä! ¸ðµÎ°¡ ÇູÇÑ ¼¼»óÀÌ µË´Ï´Ù. UCC Âü¿©Çϱâ --0-2004925155-1196051914=:98690 Content-Type: text/html; charset=euc-kr Content-Transfer-Encoding: 8bit 
Hi all, 
I subscribed RL2N mailing list just now. 
I read the following post from the arciives. 
I have a question about "Finland Deployment"
 
Zach Shelby said "For example here in Finland 
we are already rolling out fairly large 6lowpan 
(over 1000 node) networks in the industrial 
and building automation domains."
 
To deploy 6lowpan node over 1000, I think there 
should be scalability issue. In current 6lowpan architecture
having adaptation layer, the adaption
 layer should perform
mesh routing. How can you solve this problem?
 
And, I want to know the industrial and 
building automation domains expample in detail.
Is it deployed in commercial site? or test-bed?
Can I get the more information about Filand Deployment?
Where or How?
 
Thanks in advance. 
 
Jin Hyoung Kim | Engineer | 
Samsung Electronics. 
 
 
======================================================
-Hi all,

-In my opinion the proposed RL2N charter is already pretty -good, here is some support from our experience.

First I would like to stress the same as JP and Phil. There is a huge need for standardized IP WSN routing in well-scoped domains *now*, *today*, to solve *real problems*. For example here in Finland we are already rolling out fairly large 6lowpan (over 1000 node) networks in the industrial and building automation domains. Our direct 6lowpan node volume, will be well over 25k nodes in 2008. SP100 helps next year, but for many applications a simpler 6lowpan + rl2n routing solution would be more suitable.

Almost all customers love the IP + 802.15.4 concept. But the biggest concern they still have is a lack of a standard routing technique.

I think the charter text is good, and scoping to these 3 areas really keeps it focused. One comment:

- The relationship with 6lowpan and SP100 could be explicit in the charter text (not just work-items)?

Have fun in Boston!

- Zach

--  Zach Shelby | CTO | +358 40 7796297  Sensinode Ltd.   www.sensinode.com

¿Ã ÇÑÇØ °í¸¶¿ü´ø »ç¶÷µé¿¡°Ô ¸Þ½ÃÁö º¸³»°í ¼±¹°¹ÞÀ¸¼¼¿ä!
¸ðµÎ°¡ ÇູÇÑ ¼¼»óÀÌ µË´Ï´Ù. UCC Âü¿©Çϱâ

--0-2004925155-1196051914=:98690-- --===============1502300438== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1502300438==-- From rsn-bounces@ietf.org Mon Nov 26 11:31:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgrX-0004st-RN; Mon, 26 Nov 2007 11:31:11 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IwgrW-0004sR-DZ for rsn-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:31:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwgrP-0004r9-KR for rsn@ietf.org; Mon, 26 Nov 2007 11:31:04 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwgrC-0002XR-Do for rsn@ietf.org; Mon, 26 Nov 2007 11:31:03 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Nov 2007 11:30: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 lAQGUo5j028206; Mon, 26 Nov 2007 11:30:50 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAQGUWKZ018240; Mon, 26 Nov 2007 16:30:50 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 11:30:38 -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, 26 Nov 2007 16:30:38 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 26 Nov 2007 11:30:37 -0500 Subject: Re: [RSN] RL2N Comments - Question about Finland Deployment. From: JP Vasseur To: =?EUC-KR?B?sejB+Mf8IA==?= Message-ID: Thread-Topic: [RSN] RL2N Comments - Question about Finland Deployment. Thread-Index: AcgwSazO6zIPG5w8Edyp5QANk8WjQA== In-Reply-To: <331719.98690.qm@web70109.mail.krs.yahoo.com> Mime-version: 1.0 X-OriginalArrivalTime: 26 Nov 2007 16:30:38.0810 (UTC) FILETIME=[ADE263A0:01C83049] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9926; t=1196094650; x=1196958650; 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[RSN]=20RL2N=20Comments=20-=20Question=20about=20Finl and=20Deployment.=20 |Sender:=20 |To:=20=3D?EUC-KR?B?sejB+Mf8IA=3D=3D?=3D; bh=yr+rIyf8LkCUKFK1qsuxBONz7fco+RresABUDe+TGKg=; b=O0L2lDaR1BmaA2bqb0zQU8xdNxhyiv9SWoQaI7bLVr+sYFfhzaMJeb+s5M3OCbZwYJIJPvTD i/arsiLYQGvPaL+yZEuIALFCxgh81rG+gCyDg+DyXtJhTRtAcLEK2JHD; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -2.2 (--) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0797430289==" Errors-To: rsn-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0797430289== Content-type: multipart/alternative; boundary="B_3278921437_3412796" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3278921437_3412796 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Dear Jin, Few comments in line, From: =B1=E8=C1=F8=C7=FC Date: Mon, 26 Nov 2007 13:38:34 +0900 (KST) To: Subject: Re:[RSN] RL2N Comments - Question about Finland Deployment. Hi all,=20 I subscribed RL2N mailing list just now. I read the following post from the arciives. I have a question about "Finland Deployment" =20 Zach Shelby said "For example here in Finland we are already rolling out fairly large 6lowpan (over 1000 node) networks in the industrial and building automation domains." =20 To deploy 6lowpan node over 1000, I think there should be scalability issue. In current 6lowpan architecture having adaptation layer, the adaption layer should perform mesh routing. How can you solve this problem? =20 JP> Routing in large scale networks in constrained environments in for sure a challenging technical problem, and the reason why we=A1=AFll be having a BOF = in Vancouver in order to have a WG working on those issues. And, I want to know the industrial and building automation domains expample in detail. Is it deployed in commercial site? or test-bed? Can I get the more information about Filand Deployment? Where or How? JP> There are many deployments in several areas and the various requirement= s IDs are inspired by concrete deployments based (today) on non-IP systems. S= o the issue is solvable for sure, we now need to work on an IP-based solution= . Do not be surprised if you do not receive detailed deployments designs ... Such design are usually the property of the customer and cannot (most of time) be disclosed. This is not specific to L2Ns of course. This is why the requirements ID provides concrete use cases from where the requirements are derived. You are very welcome to contribute to the work. Thanks. JP. =20 =20 Thanks in advance.=20 =20 Jin Hyoung Kim | Engineer | Samsung Electronics. =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -Hi all, -In my opinion the proposed RL2N charter is already pretty -good, here is some support from our experience. First I would like to stress the same as JP and Phil. There is a huge need for standardized IP WSN routing in well-scoped domains *now*, *today*, to solve *real problems*. For example here in Finland we are already rolling out fairly large 6lowpan (over 1000 node) networks in the industrial and building automation domains. Our direct 6lowpan node volume, will be well over 25k nodes in 2008. SP100 helps next year, but for many applications a simpler 6lowpan + rl2n routing solution would be more suitable. Almost all customers love the IP + 802.15.4 concept. But the biggest concer= n they still have is a lack of a standard routing technique. I think the charter text is good, and scoping to these 3 areas really keeps it focused. One comment: - The relationship with 6lowpan and SP100 could be explicit in the charter text (not just work-items)? Have fun in Boston! - Zach -- Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com =20 =20 =BF=C3 =C7=D1=C7=D8 =B0=ED=B8=B6=BF=FC=B4=F8 =BB=E7=B6=F7=B5=E9=BF=A1=B0=D4 =B8=DE=BD=C3=C1=F6 =BA=B8=B3=BB=B0=ED =BC=B1=B9=B0=B9=DE=C0=B8=BC=BC=BF=E4! =B8=F0=B5=CE=B0=A1 =C7=E0=BA=B9=C7=D1 =BC=BC=BB=F3=C0=CC =B5=CB=B4=CF=B4=D9. UCC =C2=FC=BF=A9=C7=CF=B1=E2 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --B_3278921437_3412796 Content-type: text/html; charset="EUC-KR" Content-transfer-encoding: quoted-printable Re: [RSN] RL2N Comments - Question about Finland Deployment. </TITLE= > </HEAD> <BODY> <FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12.0px'>Dear = Jin,<BR> <BR> Few comments in line,<BR> <BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"><B>From: </B>=B1=E8=C1=F8=C7=FC <jhkim1112@yah= oo.co.kr><BR> <B>Date: </B>Mon, 26 Nov 2007 13:38:34 +0900 (KST)<BR> <B>To: </B><rsn@ietf.org><BR> <B>Subject: </B>Re:[RSN] RL2N Comments - Question about Finland Deployment.= <BR> <BR> Hi all, <BR> I subscribed RL2N mailing list just now. <BR> I read the following post from the arciives. <BR> I have a question about "Finland Deployment"<BR>  <BR> Zach Shelby said "For example here in Finland <BR> we are already rolling out fairly large 6lowpan <BR> (over 1000 node) networks in the industrial <BR> and building automation domains."<BR>  <BR> To deploy 6lowpan node over 1000, I think there <BR> should be scalability issue. In current 6lowpan architecture<BR> having adaptation layer, the adaption<BR>  layer should perform<BR> mesh routing. How can you solve this problem?<BR>  <BR> JP> Routing in large scale networks in constrained environments in for s= ure a challenging technical problem, and the reason why we’ll be havin= g a BOF in Vancouver in order to have a WG working on those issues.<BR> <BR> <BR> And, I want to know the industrial and <BR> building automation domains expample in detail.<BR> Is it deployed in commercial site? or test-bed?<BR> Can I get the more information about Filand Deployment?<BR> Where or How?<BR> <BR> JP> There are <B>many</B> deployments in several areas and the various r= equirements IDs are inspired by concrete deployments based (today) on non-IP= systems. So the issue is solvable for sure, we now need to work on an IP-ba= sed solution. <BR> Do not be surprised if you do not receive detailed deployments designs ... = Such design are usually the property of the customer and cannot (most of tim= e) be disclosed. This is not specific to L2Ns of course. This is why the req= uirements ID provides concrete use cases from where the requirements are der= ived.<BR> <BR> You are very welcome to contribute to the work.<BR> <BR> Thanks.<BR> <BR> JP.  <BR>  <BR> Thanks in advance. <BR>  <BR> Jin Hyoung Kim | Engineer | <BR> Samsung Electronics. <BR>  <BR>  <BR> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR> -Hi all,<BR> <BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>-In my opinion the proposed RL2N charter is already pretty= -good, here is some support from our experience.<BR> </SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'fo= nt-size:12.0px'><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>First I would like to stress the same as JP and Phil. Ther= e is a huge need for standardized IP WSN routing in well-scoped domains *now= *, *today*, to solve *real problems*. For example here in Finland we are alr= eady rolling out fairly large 6lowpan (over 1000 node) networks in the indus= trial and building automation domains. Our direct 6lowpan node volume, will = be well over 25k nodes in 2008. SP100 helps next year, but for many applicat= ions a simpler 6lowpan + rl2n routing solution would be more suitable.<BR> </SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'fo= nt-size:12.0px'><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>Almost all customers love the IP + 802.15.4 concept. But t= he biggest concern they still have is a lack of a standard routing technique= .<BR> </SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'fo= nt-size:12.0px'><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>I think the charter text is good, and scoping to these 3 a= reas really keeps it focused. One comment:<BR> </SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'fo= nt-size:12.0px'><BR> </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'= font-size:10.0px'>- The relationship with 6lowpan and SP100 could be explici= t in the charter text (not just work-items)?<BR> </SPAN></FONT></FONT><FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN STYLE=3D'fo= nt-size:12.0px'><BR> Have fun in Boston!<BR> <BR> - Zach<BR> <BR> --  Zach Shelby | CTO | +358 40 7796297  Sensinode Ltd.  &nb= sp;www.sensinode.com<BR>   <BR> <HR ALIGN=3DCENTER SIZE=3D"1" WIDTH=3D"100%"> <BR> <BR> <B>=BF=C3 =C7=D1=C7=D8 =B0=ED=B8=B6=BF=FC=B4=F8 =BB=E7=B6=F7=B5=E9=BF=A1=B0=D4 =B8=DE=BD=C3=C1=F6 =BA=B8=B3=BB=B0=ED =BC=B1=B9=B0=B9=DE=C0=B8=BC=BC=BF=E4!<BR> </B>=B8=F0=B5=CE=B0=A1 =C7=E0=BA=B9=C7=D1 =BC=BC=BB=F3=C0=CC =B5=CB=B4=CF=B4=D9. UCC =C2=FC=BF=A9=C7=CF=B1=E2 <a href=3D"http://us.rd.yahoo.c= om/mail_kr/taglines/2007_7thankyou/*http://kr.fun.kids.yahoo.com/funnybox/th= ankyou.html"><http://us.rd.yahoo.com/mail_kr/taglines/2007_7thankyou/*htt= p://kr.fun.kids.yahoo.com/funnybox/thankyou.html></a> <BR> <BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><FONT SIZE=3D"2"><FONT FA= CE=3D"Monaco, Courier New"><SPAN STYLE=3D'font-size:10.0px'>____________________= ___________________________<BR> RSN mailing list<BR> RSN@ietf.org<BR> https://www1.ietf.org/mailman/listinfo/rsn<BR> </SPAN></FONT></FONT> </BODY> </HTML> --B_3278921437_3412796-- --===============0797430289== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0797430289==-- From rsn-bounces@ietf.org Mon Nov 26 11:32:34 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgss-0005Cq-Nu; Mon, 26 Nov 2007 11:32:34 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iwgsq-0005CW-NJ for rsn-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:32:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgsq-0005CM-CN for rsn@ietf.org; Mon, 26 Nov 2007 11:32:32 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwgsp-0005CI-Vl for rsn@ietf.org; Mon, 26 Nov 2007 11:32:32 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Nov 2007 11:32:31 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAQGWV8Y018517; Mon, 26 Nov 2007 11:32:31 -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 lAQGWRxb023186; Mon, 26 Nov 2007 16:32:31 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, 26 Nov 2007 11:32:28 -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, 26 Nov 2007 16:32:28 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 26 Nov 2007 11:32:25 -0500 Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter From: JP Vasseur <jvasseur@cisco.com> To: Philip Levis <pal@cs.stanford.edu> Message-ID: <C3705F49.18766%jvasseur@cisco.com> Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: AcgwSe0tK6c0i5w9Edyp5QANk8WjQA== In-Reply-To: <632DB6C3-CC05-4603-8EF1-DD822C37493E@cs.stanford.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 16:32:28.0294 (UTC) FILETIME=[EF245260:01C83049] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2310; t=1196094751; x=1196958751; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[RSN]=20Here=20is=20the=20new=20RL2N=20Proposed=20Wor king=20Charter |Sender:=20 |To:=20Philip=20Levis=20<pal@cs.stanford.edu>; bh=SZii0rK/9YZE5gRmawQYwexed+e44nJgjEqQHSvBtaM=; b=0Yl/Qz1X75LT3WfcGrgxjNUJ+23w639P0/1qB3thDcXj+a5yjckfcG4y/25UJXCXS3GJPOQf maHjS16jOOUptP0hKwtLowS3cB8OZxs0EnacpYGLg01a2DN7Fr5UkUBe; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Hi Phil, The text had not been updated everywhere: the term "urban network" is now consistently used in the new proposed charter. http://www.employees.org/~jvasseur/ Are we in sync? Cheers. JP. > From: Philip Levis <pal@cs.stanford.edu> > Date: Wed, 21 Nov 2007 13:27:29 -0800 > To: JP Vasseur <jvasseur@cisco.com> > Cc: <rsn@ietf.org> > Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > > On Nov 21, 2007, at 12:18 PM, JP Vasseur wrote: > >> >> >> 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. >> > > JP (and Mischa), > > I'll reiterate what I said in the meeting: I think we need a > different term than "smart cities." Interpreted literally, "smart > cities" encompasses *all* of the other use cases except agricultural, > and introduces all sorts of other concerns outside our general area > of interest, such as vehicular networks, traffic control systems, and > law enforcement. > > While densely networked urban areas certainly raise a lot of > technical issues due to their scale, I feel that we should focus on > real applications today. It's hard to define application use cases > for research visions, e.g. general ubiquitous computing. I could just > be mistaken on this one, but I have yet to hear a clear articulation > of what a "smart city" is or what technical issues it raises. If the > issues we want to make sure we keep in mind are outdoor, very large > scale urban networks, surely there is a more precise application use > case? > > If we can pull out the concrete issues that smart cities introduce > and define a concrete use case that clearly articulate them, then > that would be great. But, I mean, is "refrigeration" really on the > same playing field in terms of scope as "smart cities?" > > Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Nov 26 12:24:17 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhgv-0002Cy-CL; Mon, 26 Nov 2007 12:24:17 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iwhgt-0002Ck-R7 for rsn-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:24:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhgt-0002CN-DA for rsn@ietf.org; Mon, 26 Nov 2007 12:24:15 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwhgt-0007Y0-2P for rsn@ietf.org; Mon, 26 Nov 2007 12:24:15 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 26 Nov 2007 12:24:15 -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 lAQHOEoV027337; Mon, 26 Nov 2007 12:24:14 -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 lAQHOEKJ010370; Mon, 26 Nov 2007 17:24:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 12:24:05 -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, 26 Nov 2007 17:24:04 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 26 Nov 2007 12:24:04 -0500 Subject: Re: [RSN] draft-dohler-rl2n-urban-routing-reqs-00 From: JP Vasseur <jvasseur@cisco.com> To: DOHLER Mischa RD-TECH-GRE <mischa.dohler@orange-ftgroup.com>, <rsn@ietf.org> Message-ID: <C3706B64.1878E%jvasseur@cisco.com> Thread-Topic: [RSN] draft-dohler-rl2n-urban-routing-reqs-00 Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAABNUowABbrUtAACvHJtwAAG5HQAADtRuAAABxr+QAANa5wAAAx6XAABMt1UABEGBrgAAAZtiAAAE2mggAnYF4gAGARl2w= In-Reply-To: <B877D90AB2240C4D84DF56169F1EAFED04ADFC0D@ftrdmel3> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Nov 2007 17:24:05.0031 (UTC) FILETIME=[24F0E370:01C83051] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1197; t=1196097854; x=1196961854; 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<jvasseur@cisco.com> |Subject:=20Re=3A=20[RSN]=20draft-dohler-rl2n-urban-routing-reqs-00 |Sender:=20 |To:=20DOHLER=20Mischa=20RD-TECH-GRE=20<mischa.dohler@orange-ftgroup.com> ,=0A=20=20=20=20=20=20=20=20<rsn@ietf.org>; bh=jXEi2JFOVGm5GY5tQAEqG3Kf1oXJbF3/FRqL1AmoM1A=; b=fZoYkOhvb2xOm2AXkw91DYmbuBG3L/QT5L0iWyaUFVgbYECtYS1iPel463DdmFKbhIUjOr8/ JccJbHH+WW4GQ4w7XqDVndjpBk82sjTxsWOhcZDSfeNaVdcenVUoBM87; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: CHEGARAY Gabriel RD-TECH-GRE <gabriel.chegaray@orange-ftgroup.com> X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Draft also available at: http://www.employees.org/~jvasseur/ > From: DOHLER Mischa RD-TECH-GRE <mischa.dohler@orange-ftgroup.com> > Date: Sat, 24 Nov 2007 20:37:52 +0100 > To: <rsn@ietf.org> > Cc: CHEGARAY Gabriel RD-TECH-GRE <gabriel.chegaray@orange-ftgroup.com> > Conversation: draft-dohler-rl2n-urban-routing-reqs-00 > Subject: [RSN] draft-dohler-rl2n-urban-routing-reqs-00 > > Dear all, > > Please, find a first draft on urban lossy and low power networks > attached to this email. There are still pieces missing and also IDNits > still gives some warnings, but I think it should do for a first round of > comments. > > Thanks and kind regards, > Mischa. > > _______________________________________ > > Dr Mischa Dohler > France Telecom R&D > Senior Research Expert > > Tel: +33 4 76 76 45 14 > Fax: +33 4 76 76 44 50 > Mob: +33 6 74 70 86 75 > > http://perso.rd.francetelecom.fr/dohler > _______________________________________ > > ... visit http://www.pimrc2008.org/ ... > _______________________________________ > _______________________________________________ > 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 From rsn-bounces@ietf.org Mon Nov 26 12:56:30 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiC6-0005C9-Cf; Mon, 26 Nov 2007 12:56:30 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IwiC5-0005Bn-6n for rsn-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:56:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiC4-0005BK-Qx for rsn@ietf.org; Mon, 26 Nov 2007 12:56:28 -0500 Received: from cs-smtp-3.stanford.edu ([171.64.64.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwiC1-0006br-Sj for rsn@ietf.org; Mon, 26 Nov 2007 12:56:28 -0500 Received: from dnab422266.stanford.edu ([171.66.34.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1IwiC0-0005yW-P5; Mon, 26 Nov 2007 09:56:25 -0800 In-Reply-To: <C3705F49.18766%jvasseur@cisco.com> References: <C3705F49.18766%jvasseur@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <75133134-9612-4286-967F-29601F1AD25B@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis <pal@cs.stanford.edu> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter Date: Mon, 26 Nov 2007 09:56:30 -0800 To: JP Vasseur <jvasseur@cisco.com> 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-3.Stanford.EDU X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011 X-Spam-Score: -4.0 (----) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org On Nov 26, 2007, at 8:32 AM, JP Vasseur wrote: > Hi Phil, > > The text had not been updated everywhere: the term "urban network" > is now > consistently used in the new proposed charter. > http://www.employees.org/~jvasseur/ > > Are we in sync? SYN + ACK! One nit: The Working Group will pay a particular attention to routing -> The Working Group will pay particular attention to routing Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Nov 26 15:55:35 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkzP-0006QX-Ji; Mon, 26 Nov 2007 15:55:35 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IwkzN-0006Q7-Hj for rsn-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 15:55:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkzN-0006Pi-5H for rsn@ietf.org; Mon, 26 Nov 2007 15:55:33 -0500 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwkzM-0004sK-5c for rsn@ietf.org; Mon, 26 Nov 2007 15:55:32 -0500 Received: from [10.0.1.3] (213-216-255-167-Tuira-TR1.suomi.net [213.216.255.167]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id lAQKtRQU010278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 22:55:27 +0200 Message-ID: <474B32BD.1080905@sensinode.com> Date: Mon, 26 Nov 2007 22:55:25 +0200 From: Zach Shelby <zach@sensinode.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: =?EUC-KR?B?sejB+Mf8?= <jhkim1112@yahoo.co.kr> Subject: Re: [RSN] RL2N Comments - Question about Finland Deployment. References: <C3705EDD.18761%jvasseur@cisco.com> In-Reply-To: <C3705EDD.18761%jvasseur@cisco.com> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auth-smtp.nebula.fi id lAQKtRQU010278 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Hi Jin, Glad to see you're interested, and welcome to rl2n. My comments in-line. > Zach Shelby said "For example here in Finland > we are already rolling out fairly large 6lowpan > (over 1000 node) networks in the industrial > and building automation domains." > =20 > To deploy 6lowpan node over 1000, I think there > should be scalability issue. In current 6lowpan architecture > having adaptation layer, the adaption > layer should perform > mesh routing. How can you solve this problem? > =20 > JP> Routing in large scale networks in constrained environments in for = sure > a challenging technical problem, and the reason why we=A1=AFll be havin= g a BOF in > Vancouver in order to have a WG working on those issues. Correct, networks of this size create interesting scalability problems. In e.g. our industrial case there is a problem of handling even up to 150 RFD nodes per FFD coordinator. This is a MAC and implementation problem mainly. Aggregation occurs at the coordinator, so the bulk of RFD devices do not participate in routing. We then use Sensinode's own implementation of 6lowpan mesh under to conne= ct coordinators to gateways over 1-3 hops, also employing ICMP nd to find the gateways. This is still small enough to handle with mesh-under. However one main challenge for rl2n is to scale routing with these networks, e.g. if all those devices would be FFDs and participate in routing. > And, I want to know the industrial and > building automation domains expample in detail. > Is it deployed in commercial site? or test-bed? > Can I get the more information about Filand Deployment? > Where or How? > JP> There are many deployments in several areas and the various require= ments > IDs are inspired by concrete deployments based (today) on non-IP system= s. So > the issue is solvable for sure, we now need to work on an IP-based solu= tion. > Do not be surprised if you do not receive detailed deployments designs = ... > Such design are usually the property of the customer and cannot (most o= f > time) be disclosed. This is not specific to L2Ns of course. This is why= the > requirements ID provides concrete use cases from where the requirements= are > derived. Details are not yet available publicly. Soon there will however be a press release on the industrial roll-out, which is for monitoring a process in a metallurgy plant here in Finland initially. The building roll-out I hope I can share more on early next year. > Jin Hyoung Kim | Engineer | > Samsung Electronics. Cheers, Zach --=20 Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Nov 26 17:08:03 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwm7X-0002kA-BK; Mon, 26 Nov 2007 17:08:03 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Iwm7V-0002jk-Gg for rsn-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 17:08:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwm7U-0002ja-0n for rsn@ietf.org; Mon, 26 Nov 2007 17:08:01 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwm7P-0002p8-T6 for rsn@ietf.org; Mon, 26 Nov 2007 17:08:00 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Nov 2007 17:07:55 -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 lAQM7t9f021971; Mon, 26 Nov 2007 17:07:55 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAQM7gKP029631; Mon, 26 Nov 2007 22:07:55 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 17:07:47 -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, 26 Nov 2007 22:07:47 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 26 Nov 2007 17:07:46 -0500 From: JP Vasseur <jvasseur@cisco.com> To: DOHLER Mischa RD-TECH-GRE <mischa.dohler@orange-ftgroup.com>, CHEGARAY Gabriel RD-TECH-GRE <gabriel.chegaray@orange-ftgroup.com> Message-ID: <C370ADE2.18870%jvasseur@cisco.com> Thread-Topic: Comments on draft-dohler-rl2n-urban-routing-reqs-00 Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAABNUowABbrUtAACvHJtwAAG5HQAADtRuAAABxr+QAANa5wAAAx6XAABMt1UABEGBrgAAAZtiAAAE2mggAnYF4gAGn6EeU= In-Reply-To: <B877D90AB2240C4D84DF56169F1EAFED04ADFC0D@ftrdmel3> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 26 Nov 2007 22:07:47.0949 (UTC) FILETIME=[C76409D0:01C83078] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5026; t=1196114875; x=1196978875; 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<jvasseur@cisco.com> |Subject:=20Comments=20on=20draft-dohler-rl2n-urban-routing-reqs-00 |Sender:=20 |To:=20DOHLER=20Mischa=20RD-TECH-GRE=20<mischa.dohler@orange-ftgroup.com> , =0A=20=20=20=20=20=20=20=20CHEGARAY=20Gabriel=20RD-TECH-GRE=20<gabriel.ch egaray@orange-ftgroup.com>; bh=1U0b61bgERa4ZkuTLVcAyp47hucbc0cYwyz90YPjMMs=; b=Ykcs5Sv18OJ74kF9WgiKN6EuWCsoMSDRblCnoppfO16ZYmnm4eBkRaKUm3DWqTiCoLAMa89Y vBjrvzs2ZbT/Nv5VOCZu0rnMeOlsaEWRBhDX8/AyJJkVyz+Cq5AFPv94; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -3.8 (---) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: rsn@ietf.org Subject: [RSN] Comments on draft-dohler-rl2n-urban-routing-reqs-00 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Hi Mischa and Gabriel, Excellent first draft. Please find below a few comments (skipping comments on ID Nits/acronyms expansion/references/... Issues for the moment): 1) Section 2: you may want to elaborate a bit more on what you refer to as "repeaters". The following text may deserve further clarifications: Repeaters generally act as relays with the aim to close coverage and routing gaps; examples of their use are: prolong the U-L2N=B9s lifetime, balance nodes=B9 energy depletion, build advanced sensing infrastructures. 2) " The battery life-time is usually in the order of 10-15 years, renderin= g network lifetime maximization with battery-powered nodes beyond this lifespan useless. " You may want to say that this is highly application dependant since the frequency at which sensed data are sent to the sink may substantially vary. 3) I do agree with your structured pattern statement wrt to L2N in urban networks. That being said, we will very likely see more collaborative scenarios with inter-device traffic flows. This is especially true if network processing actions can be triggered upon the occurrence a set of specific events, thus avoiding to rely on a central decision point. This would undoubtedly help in saving energy and will decrease the reaction time= . Again fully agree with you on the current structured patterns but we need t= o kind in mind that inter-device communication is likely to be needed at some point. 4) Typo section 4.1 " tenth of thousands" -> " tens of thousands" 5) " the routing protocol MUST support parameter constrained Routing" - This is indeed one of the key functions that RL2N MUST achieve (also true for industrial application). Just reword as dynamic/static node constraints.=20 6) Section 4.1 " To this end, the routing protocol SHOULD support and utilize this fact to facilitate scalability and parameter constrained routing." -> You may want to elaborate here. I think that you refer to the ability to make use of asymmetrical load balancing, to avoid traffic concentration on a few specific paths as we get closer to the sink, which i= s I think a key requirement. Is this also what you have in mind? 7) Section 4.5 " To this end, the routing protocols proposed in U-L2N SHOUL= D support a variety of different devices without compromising the operability and energy efficiency of the network." This section probably requires explanation. Is this (as I think) another node constraint or are you thinking of another form of routing constraint? 8) In section 4.3 "For the latter, the protocol SHOULD support multicast and broadcast addressing." - sounds more of a MUST to me. And then in section 4.6 " To this end, the routing protocol MUST support multicast, where the routing protocol MUST provide the ability to route a packet towards a single field device (unicast) or a set of devices, which explicitly (multicast) or implicitly (groupcast) belong to the same group/cast. " I guess that the bottom line is a MUST for multicast support. 9) I would suggest to move " Convergence and route establishment times SHOULD be significantly lower than the inverse of the smallest reporting cycle." to a new scalability section where you could add number in term of = # nodes, ... That have been provided in section 2. 10) Latency: do you think that multi-topology routing is required in light of these requirements? By MTR I refer to the ability to decompose the network in multiple logical topologies based on their characteristics (low delay, ...)? 11) Just a minor comment on the security section, which deals a large set o= f L2Ns security issues, including non routing issues. We have time to work on these in further revisions of the document and in light of the security framework item. Thanks. JP. > From: DOHLER Mischa RD-TECH-GRE <mischa.dohler@orange-ftgroup.com> > Date: Sat, 24 Nov 2007 20:37:52 +0100 > To: <rsn@ietf.org> > Cc: CHEGARAY Gabriel RD-TECH-GRE <gabriel.chegaray@orange-ftgroup.com> > Conversation: draft-dohler-rl2n-urban-routing-reqs-00 > Subject: [RSN] draft-dohler-rl2n-urban-routing-reqs-00 >=20 > Dear all, >=20 > Please, find a first draft on urban lossy and low power networks > attached to this email. There are still pieces missing and also IDNits > still gives some warnings, but I think it should do for a first round of > comments. >=20 > Thanks and kind regards, > Mischa. >=20 > _______________________________________ >=20 > Dr Mischa Dohler > France Telecom R&D > Senior Research Expert >=20 > Tel: +33 4 76 76 45 14 > Fax: +33 4 76 76 44 50 > Mob: +33 6 74 70 86 75 >=20 > http://perso.rd.francetelecom.fr/dohler > _______________________________________ >=20 > ... visit http://www.pimrc2008.org/ ... > _______________________________________ > _______________________________________________ > 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 From rsn-bounces@ietf.org Wed Nov 28 08:10:54 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMgo-0002PY-KG; Wed, 28 Nov 2007 08:10:54 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IxMgm-00026E-LJ for rsn-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:10:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMgg-0001sN-38 for rsn@ietf.org; Wed, 28 Nov 2007 08:10:46 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxMgf-0007QU-1y for rsn@ietf.org; Wed, 28 Nov 2007 08:10:46 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194217200"; d="scan'208";a="159007786" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Nov 2007 14:10:42 +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 lASDAgbE014262; Wed, 28 Nov 2007 14:10:42 +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 lASDAb3d026938; Wed, 28 Nov 2007 13:10:42 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, 28 Nov 2007 14:10:38 +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-2" Content-Transfer-Encoding: quoted-printable Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Wed, 28 Nov 2007 14:10:34 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> In-Reply-To: <C369FCCF.18317%jvasseur@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAFPloAQ References: <C369FCCF.18317%jvasseur@cisco.com> From: "Pascal Thubert (pthubert)" <pthubert@cisco.com> To: "Jean Philippe Vasseur (jvasseur)" <jvasseur@cisco.com> X-OriginalArrivalTime: 28 Nov 2007 13:10:38.0219 (UTC) FILETIME=[11CD05B0:01C831C0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6621; t=1196255442; x=1197119442; 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<pthubert@cisco.com> |Subject:=20RE=3A=20[RSN]=20Here=20is=20the=20new=20RL2N=20Proposed=20Wor king=20Charter |Sender:=20; bh=ZdHBa/Wz9K2aDhYzPAdoFs/yMuIddyPZJXlbRtiz6t8=; b=bv9K6r0B+cbpLvm6f6hwt3uOKGDIjddks8gsgjI4celiSm2CfpQxQ+CnYIzpFe50O8v5Tw5m pLyFGo9+Xkh51LX53e9K8YpnWWlX30wt5KkkS+8AhvXqujDtfD51E7oE; 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: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Hi JP: Thanks a bunch for this charter. I'll try not to rephrase what was = already discussed with Christian, Anders, Philip and Misha.=20 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.=20 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... =20 Being able to define one minimum set and maybe a few other profiles for = the use cases that we selected could help tremendously.=20 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 From rsn-bounces@ietf.org Wed Nov 28 08:29:56 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMzE-00054x-1y; Wed, 28 Nov 2007 08:29:56 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IxMzD-00054j-0g for rsn-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:29:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMzC-00054a-L2 for rsn@ietf.org; Wed, 28 Nov 2007 08:29:54 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxMzB-0005FV-Oz for rsn@ietf.org; Wed, 28 Nov 2007 08:29:54 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2007 08:29:54 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASDTrQS021632; Wed, 28 Nov 2007 08:29:53 -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 lASDTnBc010918; Wed, 28 Nov 2007 13:29:53 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 08:29:50 -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 ; Wed, 28 Nov 2007 13:29:50 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Wed, 28 Nov 2007 08:29:48 -0500 Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter From: JP Vasseur <jvasseur@cisco.com> To: "Pascal Thubert (pthubert)" <pthubert@cisco.com> Message-ID: <C372D77C.18C3A%jvasseur@cisco.com> Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgse7PY8iGzi5huEdy88gANk8WjQAFPloAQAAIsUY4= In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-2" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 28 Nov 2007 13:29:50.0465 (UTC) FILETIME=[C097CF10:01C831C2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8010; t=1196256593; x=1197120593; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20<jvasseur@cisco.com> |Subject:=20Re=3A=20[RSN]=20Here=20is=20the=20new=20RL2N=20Proposed=20Wor king=20Charter |Sender:=20 |To:=20=22Pascal=20Thubert=20(pthubert)=22=20<pthubert@cisco.com>; bh=b188R6FP+rm3M7g7vrWQITSrF0alNokMCbJ42ikWccI=; b=DJoXET33x7fpSn9mkQXcPb+IaVLScQHMVxjhh9FFXu4YnZ2GfT4nnJhtOcw3KAZW9N0wZ4u2 gxfuGGhl75d3cximb2HUqSDVZceSyMLtBGhnmep4cFW8EIUXVtWFU50c; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Hi Pascal, Thanks for the feed-back and support - in line, > From: "Pascal Thubert (pthubert)" <pthubert@cisco.com> > Date: Wed, 28 Nov 2007 08:10:34 -0500 > To: "Jean Philippe Vasseur (jvasseur)" <jvasseur@cisco.com> > Cc: <rsn@ietf.org>, 6lowpan <6lowpan@lists.ietf.org> > Conversation: [RSN] Here is the new RL2N Proposed Working Charter > Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter >=20 > Hi JP: >=20 > Thanks a bunch for this charter. I'll try not to rephrase what was alread= y > discussed with Christian, Anders, Philip and Misha. >=20 > 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. >=20 > 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. >=20 > 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.tx > t). Maybe NULL encryption and authentication is enough etc, etc... > =20 > Being able to define one minimum set and maybe a few other profiles for t= he > use cases that we selected could help tremendously. I cannot agree more but this certainly belongs more to 6lowpan if they want to work on this item. If a RL2N WG gets formed, we should contribute to thi= s work for the routing aspects. >=20 > Otherwise I find the charter real well written and easy to digest. From t= he > MANEMO experience, I expect that some arguments about the relative > applicability of existing MANET protocols will be difficult to prove with= out > some good simulation work running agreed-upon scenarios. This is indeed a key work item. The work has started in the protocol overview draft (still more work is undoubtedly required). >=20 > 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 wh= en > trouble comes and things can not be done in a common fashion for both IP > protocols, hen we prioritize IPv6. >=20 It is indeed important to have a RL2N solution for both v4 *and* v6, I do not think that we should try to "prioritize" between the two. > Unfortunately, I can not make it to Vancouver, Too bad ... But should a WG be formed, I hope that we'll have you contribut= e to this work. but I do feel that the work is > really needed so please count my vote in for the adoption of the WG. Will do. Thanks. JP. >=20 > Cheers, >=20 > Pascal >=20 >> -----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 >>=20 >> Dear all, >>=20 >> As promised, here is the new proposed Working Group, which reflects the >> number of comments/suggestions that we received, the pre-WG consensus, .= .. >>=20 >> Thanks to Dave Ward (RTD AD) for his input. >>=20 >> Proposed RL2N WG Charter >>=20 >> Description of Working Group >>=20 >> L2Ns (Low power and Lossy networks) are typically composed of many embed= ded >> devices with limited power, memory, and processing resources interconnec= ted >> by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low Po= wer >> WiFi. >>=20 >> 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 routin= g >> requirements that are not currently met by existing routing protocols, s= uch >> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be designed to t= ake >> into consideration the specific power, capabilities, attributes and >> functional characteristics of the links and nodes in the network. >>=20 >>=20 >> There is a wide scope of application areas for L2Ns, including industria= l >> monitoring, building automation (HVAC, lighting/access control), connect= ed >> 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. >>=20 >>=20 >> 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 operati= on >> with very modest memory and CPU pressure. >>=20 >>=20 >> The Working Group will pay a particular attention to routing security an= d >> manageability (e.g self managing/configuration) issues, which are >> particularly critical for L2Ns. >>=20 >> Work Items: >>=20 >> - Produce use cases documents for Industrial, Connected Home, Building a= nd >> 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). >>=20 >>=20 >> - Survey the applicability of existing protocols to L2Ns. The aim of thi= s >> 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. >>=20 >> - Specification of routing metrics used in path calculation. This includ= es >> static and dynamic link/nodes attributes required for routing in L2Ns. >>=20 >> - Provide an architectural framework for routing and path selection at L= ayer >> 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 routin= g >> approach. >>=20 >> - Produce a security framework for routing in L2Ns. >>=20 >> Goals And Milestones: >>=20 >>=20 >> April 2008 Submit Use case/Routing requirements for Industrial, Connecte= d >> Home, Building and Urban networks applications to the IESG to be conside= red >> as an Informational RFC. >>=20 >> August 2008: Submit Routing metrics for L2Ns document to the IESG to be >> considered as an Informational RFC. >>=20 >> September 2008: Submit first draft of the Routing for L2Ns Architecture >> document (summary of requirements, path computation model, >> flat/hierarchy,=A9). >>=20 >> November 2008: Submit Protocol Survey to the IESG to be considered as an >> Informational RFC. >>=20 >> January 2009 Submit Security Framework for L2Ns to the IESG to be consid= ered >> as an Informational RFC >>=20 >> February 2009: Submit the Routing for L2Ns Architecture document (summa= ry >> of requirements, metrics and attributes, path selection model) to the IE= SG >> as an Informational RFC. >>=20 >> March 2009: Recharter. >>=20 >>=20 >> Please comment/suggest/... >>=20 >> See you in Vancouver. >>=20 >> JP and David. >>=20 >>=20 >> _______________________________________________ >> 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 From rsn-bounces@ietf.org Wed Nov 28 18:42:22 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWXt-0007AP-P3; Wed, 28 Nov 2007 18:42:21 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IxWXs-0007A8-28 for rsn-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 18:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWXr-00079z-NG for rsn@ietf.org; Wed, 28 Nov 2007 18:42:19 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWXq-0001SF-Tg for rsn@ietf.org; Wed, 28 Nov 2007 18:42: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 lASNgGRp008019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2007 15:42:18 -0800 (PST) Message-ID: <474DFCD3.10209@eecs.berkeley.edu> Date: Wed, 28 Nov 2007 15:42:11 -0800 From: Kris Pister <pister@eecs.berkeley.edu> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Zach Shelby <zach@sensinode.com> Subject: Re: [RSN] industrial requirements References: <473ECB73.7080305@sensinode.com> In-Reply-To: <473ECB73.7080305@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Zach - thanks for the positive feedback. Your questions about MAC-layer slotting and QoS are a great starting point for discussion. I understand that traditionally these issues do not belong in a routing discussion, but at the same time I feel that provisioning of layer 2 must both inform and be directed by routing decisions at layer 3, and transport requirements at layer 4. Just to be clear, this is what I'm calling L2 provisioning: Most/all of the low power MAC protocols have a way to trade off power consumption against performance. Provisioning is setting the parameter(s) that govern that tradeoff on a mote-by-mote basis. Provisioning could in principle happen automatically at each node or pair of nodes based on traffic level and queue length. But what if what Holger&Karl have called Topology Management has segregated the network so that my discovery protocols can't discover the path that I'm looking for without reprovisioning the network? I'm not saying that we'll be that stupid, rather that we need to consider provisioning early on to avoid traps like that. As for ~10ms time slots, clearly they are not a requirement for L2Ns, but they are what industrial automation has adopted in the existing standard (HART) and the in-development standard (sp100). If 15.4E goes according to the PAR (not at all a sure bet), then they'll be a part of the IEEE standard that underlies much of what we're trying to achieve. I'm happy to take the specifics of TSMP out of the draft, but I think that it's very important that they be replaced with some L2 abstractions that we can work with. I think that Phil was interested in talking about this in 6LoWPAN. Maybe a group of us can get together thursday morning in Vancouver? ksjp Zach Shelby wrote: > Hi Kris, > > Very complete req draft. Here are my comments: > > draft-pister-rl2n-industrial-routing-reqs-05 > > Overall comments > > Very well written. The requirements are however encompassing some > issues far beyond the scope of IP routing and rl2n, e.g. MAC-layer > slotting, QoS priority mechanisms etc. which yes are encompassed by > ISA100 as a whole. But should the requirements for an r2ln draft be so > broad? I'd like to hear justification on this, although I see reason > for some of it. Others may have the same feeling? > > How do these requirements relate to ISA100, are they taken directly or > do we have something special for rl2n here? > > Section 2.1 > > In addition to mentioning equipment monitoring, the general class of > asset monitoring and tracking can be mentioned as belonging to classes > 4-5. Also access control could be mentioned as an application, > although it has overlap of course with commercial building automation. > > Section 3 > > Can we demand 10ms timeslots from the r2ln point of view? What if the > L2 protocol is not able to provide that? Do 10ms time-slots make sense > for classes 3-5 at all? They at least don't make sense for sparse > events and bulk non-critical transfers. > > Section 8 > > We have also seen lots of applications for field device mobile > monitoring and for mounting on mobile equipment. Very happy to see > both here as requirements. > > Looking forward to the expansion of Section 9. > > - Zach > > > Kris Pister wrote: > > Version 0 of the routing requirements for industrial automation is > now available. > > Comments and questions are eagerly awaited. > > > > > http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00.txt > > > > > ksjp > > > > > > _______________________________________________ > > 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 From rsn-bounces@ietf.org Wed Nov 28 21:28:50 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZ8w-0003VW-86; Wed, 28 Nov 2007 21:28:46 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IxZ8u-0003NY-V3 for rsn-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 21:28:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZ8u-0003L2-IM for rsn@ietf.org; Wed, 28 Nov 2007 21:28:44 -0500 Received: from el-out-1112.google.com ([209.85.162.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxZ8t-0006mv-Iq for rsn@ietf.org; Wed, 28 Nov 2007 21:28:44 -0500 Received: by el-out-1112.google.com with SMTP id r23so990967elf for <rsn@ietf.org>; Wed, 28 Nov 2007 18:28:43 -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=k9FWaT2xrLxOQmEiUgVb1PK3j48XdtwHRAA0xv7Xe50=; b=x5hhhierxLmRD1JveILOQ78v4oXx0oyyOOH/krXzkGoJ25CPqDzVtyqIUzuhO//Q1/Ze5gT3db+kp6NRm+OgdF9TwmD7N3mDafjqEunDOQmTAc2JFhEmL4TTOhQk3gJYQeVZOt/6rrVNDJp24cUR7Ns+/7+vEDYI8GE9ilpXYPM= 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=tCaHyu1frKU2C92MgwWEDeBTFm8ZGUwtwH5bb9eDxLMlf1wA9pASxnBHLI7yGVYVbTelnCwD/pO+xB/yVBKglh3aHwtmKzm5koAK9G1loLWXSkUnlDDAbvdFsmjrI0kVHPXeL09muXGgrPmczBXKLV5jS+F9yDpVotAqzDkrleo= Received: by 10.142.125.5 with SMTP id x5mr1754658wfc.1196303322097; Wed, 28 Nov 2007 18:28:42 -0800 (PST) Received: by 10.142.105.17 with HTTP; Wed, 28 Nov 2007 18:28:42 -0800 (PST) Message-ID: <77f1dba80711281828g36249b26nbe1fd894789f933a@mail.gmail.com> Date: Thu, 29 Nov 2007 11:28:42 +0900 From: "Eunsook \"Eunah\" Kim" <eunah.ietf@gmail.com> To: "JP Vasseur" <jvasseur@cisco.com> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter In-Reply-To: <C372D77C.18C3A%jvasseur@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <C372D77C.18C3A%jvasseur@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: rsn@ietf.org, 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Dear Pascal and JP, I'm very happy to see the same thought of me on RFC 4294. I agree on JP that this work is more on 6LoWPAN in general and RL2N (or ROLL - I like this idea ^^) can check it in routing perspective, if any. I once discussed with Carsten about the necessity of this issue. I've discussed this matter with some other Korean developers from sensor node companies. We quite agreed on the necessity, and I and my colleagues already proposed this work as korean domestic standard first. The proposal has been accepted, and korean experts will start to discuss it more to develop domestic standard. It must be great if we can discuss it with IETF experts as well. Pascal, I think it would be good if we can check each other's profiling and collaborate to make one profile based on them. :) -eunsook "eunah" kim On 11/28/07, JP Vasseur <jvasseur@cisco.com> wrote: > Hi Pascal, > > Thanks for the feed-back and support - in line, > > > > From: "Pascal Thubert (pthubert)" <pthubert@cisco.com> > > Date: Wed, 28 Nov 2007 08:10:34 -0500 > > To: "Jean Philippe Vasseur (jvasseur)" <jvasseur@cisco.com> > > Cc: <rsn@ietf.org>, 6lowpan <6lowpan@lists.ietf.org> > > Conversation: [RSN] Here is the new RL2N Proposed Working Charter > > Subject: RE: [RSN] Here is the new RL2N Proposed Working Charter > > > > Hi JP: > > > > Thanks a bunch for this charter. I'll try not to rephrase what was alre= ady > > discussed with Christian, Anders, Philip and Misha. > > > > There's an additional item I'd wish to see either in ROLL or 6LoWPAN an= d 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 i= n > > general, whether they act as hosts or as routers. > > > > I've seen IPv6 presented as a Pandora box that drags just too much stuf= f to be > > incorporated in a sensory device. For instance, at the moment, SP100.11= a > > 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 witho= ut > > multicast at all if ND is supported some other way (such as suggested i= n: > > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-route= r-00.tx > > t). 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. > > I cannot agree more but this certainly belongs more to 6lowpan if they wa= nt > to work on this item. If a RL2N WG gets formed, we should contribute to t= his > work for the routing aspects. > > > > > 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 wi= thout > > some good simulation work running agreed-upon scenarios. > > This is indeed a key work item. The work has started in the protocol > overview draft (still more work is undoubtedly required). > > > > > 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 I= P > > protocols, hen we prioritize IPv6. > > > > It is indeed important to have a RL2N solution for both v4 *and* v6, I do > not think that we should try to "prioritize" between the two. > > > Unfortunately, I can not make it to Vancouver, > > Too bad ... But should a WG be formed, I hope that we'll have you contrib= ute > to this work. > > but I do feel that the work is > > really needed so please count my vote in for the adoption of the WG. > > Will do. > > Thanks. > > JP. > > > > > 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 th= e > >> 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 emb= edded > >> devices with limited power, memory, and processing resources interconn= ected > >> 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 rout= ing > >> 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 industr= ial > >> monitoring, building automation (HVAC, lighting/access control), conne= cted > >> home, healthcare, environmental monitoring, agricultural, smart cities= , > >> logistics, assets tracking, and refrigeration. The L2N WG will focus o= n > >> routing solutions for a subset of these deployment scenarios, namely > >> industrial, connected home/building and urban applications. The Workin= g > >> Group will determine the routing requirements for these scenarios. > >> > >> > >> The Working Group will provide a routing framework for these applicati= on > >> scenarios that provides high reliability in the presence of time varyi= ng > >> loss characteristics and connectivity while permitting low-power opera= tion > >> 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 a= nd 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 t= his > >> document will be to analyze the scaling and characteristics of existin= g > >> protocols and identify whether or not they meet the routing requiremen= ts of > >> the L2Ns applications identified above. Existing IGPs, MANET, NEMO, DT= N > >> routing protocols will be part of evaluation. > >> > >> - Specification of routing metrics used in path calculation. This incl= udes > >> 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 rout= ing > >> approach. > >> > >> - Produce a security framework for routing in L2Ns. > >> > >> Goals And Milestones: > >> > >> > >> April 2008 Submit Use case/Routing requirements for Industrial, Connec= ted > >> Home, Building and Urban networks applications to the IESG to be consi= dered > >> as an Informational RFC. > >> > >> August 2008: Submit Routing metrics for L2Ns document to the IESG to b= e > >> considered as an Informational RFC. > >> > >> September 2008: Submit first draft of the Routing for L2Ns Architectur= e > >> 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 cons= idered > >> as an Informational RFC > >> > >> February 2009: Submit the Routing for L2Ns Architecture document (sum= mary > >> 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 > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Nov 28 23:57:02 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxbSQ-0007MV-1J; Wed, 28 Nov 2007 23:57:02 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IxbSP-0007ME-57 for rsn-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 23:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxbSO-0007KX-PP for rsn@ietf.org; Wed, 28 Nov 2007 23:57:00 -0500 Received: from el-out-1112.google.com ([209.85.162.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxbSO-0007GQ-Bn for rsn@ietf.org; Wed, 28 Nov 2007 23:57:00 -0500 Received: by el-out-1112.google.com with SMTP id r23so1015447elf for <rsn@ietf.org>; Wed, 28 Nov 2007 20:57:00 -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=CqmktQrU5N3XmelIl80Y1opkW2YL5lRA2lEtt+khM2g=; b=q4+5/pEgdvQV+u/qEPFvvTckVjoVkz0Me7IMClS241a9K1EvrYkYOpqn8JYVD4ohsv1qzOEmZ6xt73cQDV2k4hJbH21YVmmLx5AcpGeXVUt56RhD32Q/Fd6omm1PJiEWbVm2vM7gIYoB1lhENLZKjBpUheM+YuPqI9/HhES/hJA= 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=jRynvtsGA/hVsRBRvq+5yuTwfFmtca4kLQb+x9PGrIF54h7zVXjvDUzlQSeNbuTMmICHNrNEVA+a3j2M3Q1/FMweZyR2+MQdMfnqXGIQ3pIwm9rqCWWL5ULr2aVelp74SQxkRzupSVNvEkaGUflOJUocTM6vANV6YgLhsIRaw+A= Received: by 10.142.191.2 with SMTP id o2mr1768068wff.1196312218977; Wed, 28 Nov 2007 20:56:58 -0800 (PST) Received: by 10.142.156.7 with HTTP; Wed, 28 Nov 2007 20:56:58 -0800 (PST) Message-ID: <2a3692de0711282056i100d30e2l35ad780fc0f0fced@mail.gmail.com> Date: Thu, 29 Nov 2007 13:56:58 +0900 From: "Dominik Kaspar" <dokaspar.ietf@gmail.com> To: "JP Vasseur" <jvasseur@cisco.com> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter In-Reply-To: <C36AF96E.18434%jvasseur@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6D9687E95918C04A8B30A7D6DA805A3EB687EE@zensys17.zensys.local> <C36AF96E.18434%jvasseur@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org How about "Routing Over Faulty Links"? *rofl* Dominik On 11/22/07, JP Vasseur <jvasseur@cisco.com> wrote: > Thanks for your feed-back on the charter. > > For you all, we discussed a new potential name ... > > RSN - RL2N - ... > > *should* a WG be formed, various proposals were made including ROLL (Routing > Over Low power and Loosy network) = David's idea. I also like this one. > > Cheers. > > JP. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Nov 29 14:53:32 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxpRz-0000Wx-Vw; Thu, 29 Nov 2007 14:53:31 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IxpRx-0000Wd-Gv for rsn-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 14:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxpRr-0000VF-PA for rsn@ietf.org; Thu, 29 Nov 2007 14:53:23 -0500 Received: from smtp1-g19.free.fr ([212.27.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxpRp-00066G-SC for rsn@ietf.org; Thu, 29 Nov 2007 14:53:23 -0500 Received: from smtp1-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp1-g19.free.fr (Postfix) with ESMTP id 931221AB321; Thu, 29 Nov 2007 20:53:20 +0100 (CET) Received: from [192.168.0.2] (mir01-2-82-245-104-81.fbx.proxad.net [82.245.104.81]) by smtp1-g19.free.fr (Postfix) with ESMTP id 611F71AB2CD; Thu, 29 Nov 2007 20:53:20 +0100 (CET) In-Reply-To: <C369FCCF.18317%jvasseur@cisco.com> References: <C369FCCF.18317%jvasseur@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <AD74C889-515F-4DC9-8D16-ECB82E0A77B7@ens-lyon.fr> Content-Transfer-Encoding: quoted-printable From: Bernard Tourancheau <Bernard.Tourancheau@ens-lyon.fr> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter Date: Thu, 29 Nov 2007 20:53:19 +0100 To: JP Vasseur <jvasseur@cisco.com> X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Hi all, I would like to propose some help in the 2nd item which is doing =20 survey work by giving some inputs concerning the ANA6 proposal from =20 the Ad-Hoc world. I will also follow and participate to items 3 and 4. Best regards, Bernard Tourancheau. -- LIP, ENS-Lyon, France. Le 21 nov. 07 =E0 21:18, JP Vasseur a =E9crit : > Dear all, > > As promised, here is the new proposed Working Group, which reflects =20= > 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 many =20 > 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 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 designed =20= > 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 =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, namely > 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, NEMO, =20= > 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 L2Ns. > > - Provide an architectural framework for routing and path selection =20= > at Layer > 3 (Routing for L2N Architecture) > =B7 Decide whether the L2Ns routing protocol require a distributed, > centralized path computation models or both. > =B7 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,=85). > > November 2008: Submit Protocol Survey to the IESG to be considered =20 > 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 From rsn-bounces@ietf.org Thu Nov 29 17:01:53 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrSD-0005EH-OJ; Thu, 29 Nov 2007 17:01:53 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1IxrSB-0005Dn-Fu for rsn-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 17:01:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrSB-0005DH-3y for rsn@ietf.org; Thu, 29 Nov 2007 17:01:51 -0500 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrS9-0007DM-VG for rsn@ietf.org; Thu, 29 Nov 2007 17:01:50 -0500 Received: from [10.0.1.3] (213-216-238-102-Tuira-TR1.suomi.net [213.216.238.102]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id lATM1dct001427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Nov 2007 00:01:39 +0200 Message-ID: <474F36C4.8080009@sensinode.com> Date: Fri, 30 Nov 2007 00:01:40 +0200 From: Zach Shelby <zach@sensinode.com> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Kris Pister <pister@eecs.berkeley.edu> Subject: Re: [RSN] industrial requirements References: <473ECB73.7080305@sensinode.com> <474DFCD3.10209@eecs.berkeley.edu> In-Reply-To: <474DFCD3.10209@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: c83ccb5cc10e751496398f1233ca9c3a Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Kris, No we're talking, no arguments on a theoretical basis, cross-layer is the way to go here. But I am definitely for using a reasonable L2 abstraction rather than such specific coupling as the text has now. Would also rather see the TSMP specifics behind that abstraction. I think the L2 abstraction is out of scope from 6lowpan these days, so it lies on rl2n's shoulders. JP: Should the L2 abstraction actually be a separate draft shared between req drafts? - Zach Kris Pister wrote: > Zach - thanks for the positive feedback. Your questions about MAC-layer > slotting and QoS are a great starting point for discussion. I > understand that traditionally these issues do not belong in a routing > discussion, but at the same time I feel that provisioning of layer 2 > must both inform and be directed by routing decisions at layer 3, and > transport requirements at layer 4. Just to be clear, this is what I'm > calling L2 provisioning: Most/all of the low power MAC protocols have a > way to trade off power consumption against performance. Provisioning is > setting the parameter(s) that govern that tradeoff on a mote-by-mote basis. > Provisioning could in principle happen automatically at each node or > pair of nodes based on traffic level and queue length. But what if what > Holger&Karl have called Topology Management has segregated the network > so that my discovery protocols can't discover the path that I'm looking > for without reprovisioning the network? I'm not saying that we'll be > that stupid, rather that we need to consider provisioning early on to > avoid traps like that. > > As for ~10ms time slots, clearly they are not a requirement for L2Ns, > but they are what industrial automation has adopted in the existing > standard (HART) and the in-development standard (sp100). If 15.4E goes > according to the PAR (not at all a sure bet), then they'll be a part of > the IEEE standard that underlies much of what we're trying to achieve. > > I'm happy to take the specifics of TSMP out of the draft, but I think > that it's very important that they be replaced with some L2 abstractions > that we can work with. I think that Phil was interested in talking > about this in 6LoWPAN. Maybe a group of us can get together thursday > morning in Vancouver? > > ksjp > > Zach Shelby wrote: >> Hi Kris, >> >> Very complete req draft. Here are my comments: >> >> draft-pister-rl2n-industrial-routing-reqs-05 >> >> Overall comments >> >> Very well written. The requirements are however encompassing some >> issues far beyond the scope of IP routing and rl2n, e.g. MAC-layer >> slotting, QoS priority mechanisms etc. which yes are encompassed by >> ISA100 as a whole. But should the requirements for an r2ln draft be so >> broad? I'd like to hear justification on this, although I see reason >> for some of it. Others may have the same feeling? >> >> How do these requirements relate to ISA100, are they taken directly or >> do we have something special for rl2n here? >> >> Section 2.1 >> >> In addition to mentioning equipment monitoring, the general class of >> asset monitoring and tracking can be mentioned as belonging to classes >> 4-5. Also access control could be mentioned as an application, >> although it has overlap of course with commercial building automation. >> >> Section 3 >> >> Can we demand 10ms timeslots from the r2ln point of view? What if the >> L2 protocol is not able to provide that? Do 10ms time-slots make sense >> for classes 3-5 at all? They at least don't make sense for sparse >> events and bulk non-critical transfers. >> >> Section 8 >> >> We have also seen lots of applications for field device mobile >> monitoring and for mounting on mobile equipment. Very happy to see >> both here as requirements. >> >> Looking forward to the expansion of Section 9. >> >> - Zach >> >> >> Kris Pister wrote: >> > Version 0 of the routing requirements for industrial automation is >> now available. >> > Comments and questions are eagerly awaited. >> > >> > >> http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00.txt >> >> > >> > ksjp >> > >> > >> > _______________________________________________ >> > RSN mailing list >> > RSN@ietf.org >> > https://www1.ietf.org/mailman/listinfo/rsn >> >> -- Zach Shelby | CTO | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Nov 30 08:38:08 2007 Return-path: <rsn-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy64F-0004MP-JU; Fri, 30 Nov 2007 08:38:07 -0500 Received: from rsn by megatron.ietf.org with local (Exim 4.43) id 1Ixx9v-0001VT-KB for rsn-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 23:07:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixx9v-0001VH-9v for rsn@ietf.org; Thu, 29 Nov 2007 23:07:23 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixx9u-000514-Dq for rsn@ietf.org; Thu, 29 Nov 2007 23:07: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 lAU47FtS015319; Thu, 29 Nov 2007 21:07:20 -0700 (MST) Subject: Re: [RSN] industrial requirements From: Geoff Mulligan <geoff@mulligan.com> To: Zach Shelby <zach@sensinode.com> In-Reply-To: <474F36C4.8080009@sensinode.com> References: <473ECB73.7080305@sensinode.com> <474DFCD3.10209@eecs.berkeley.edu> <474F36C4.8080009@sensinode.com> Content-Type: text/plain Date: Thu, 29 Nov 2007 21:07:13 -0700 Message-Id: <1196395633.5692.81.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-Mailman-Approved-At: Fri, 30 Nov 2007 08:38:06 -0500 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks <rsn.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/rsn> List-Post: <mailto:rsn@ietf.org> List-Help: <mailto:rsn-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rsn>, <mailto:rsn-request@ietf.org?subject=subscribe> Errors-To: rsn-bounces@ietf.org Actually L2 is out of the scope of the IETF. I do not think that L2 lies in ROLL. geoff On Fri, 2007-11-30 at 00:01 +0200, Zach Shelby wrote: > Kris, > > No we're talking, no arguments on a theoretical basis, cross-layer is > the way to go here. But I am definitely for using a reasonable L2 > abstraction rather than such specific coupling as the text has now. > Would also rather see the TSMP specifics behind that abstraction. > > I think the L2 abstraction is out of scope from 6lowpan these days, so > it lies on rl2n's shoulders. JP: Should the L2 abstraction actually be a > separate draft shared between req drafts? > > - Zach > > Kris Pister wrote: > > Zach - thanks for the positive feedback. Your questions about MAC-layer > > slotting and QoS are a great starting point for discussion. I > > understand that traditionally these issues do not belong in a routing > > discussion, but at the same time I feel that provisioning of layer 2 > > must both inform and be directed by routing decisions at layer 3, and > > transport requirements at layer 4. Just to be clear, this is what I'm > > calling L2 provisioning: Most/all of the low power MAC protocols have a > > way to trade off power consumption against performance. Provisioning is > > setting the parameter(s) that govern that tradeoff on a mote-by-mote basis. > > Provisioning could in principle happen automatically at each node or > > pair of nodes based on traffic level and queue length. But what if what > > Holger&Karl have called Topology Management has segregated the network > > so that my discovery protocols can't discover the path that I'm looking > > for without reprovisioning the network? I'm not saying that we'll be > > that stupid, rather that we need to consider provisioning early on to > > avoid traps like that. > > > > As for ~10ms time slots, clearly they are not a requirement for L2Ns, > > but they are what industrial automation has adopted in the existing > > standard (HART) and the in-development standard (sp100). If 15.4E goes > > according to the PAR (not at all a sure bet), then they'll be a part of > > the IEEE standard that underlies much of what we're trying to achieve. > > > > I'm happy to take the specifics of TSMP out of the draft, but I think > > that it's very important that they be replaced with some L2 abstractions > > that we can work with. I think that Phil was interested in talking > > about this in 6LoWPAN. Maybe a group of us can get together thursday > > morning in Vancouver? > > > > ksjp > > > > Zach Shelby wrote: > >> Hi Kris, > >> > >> Very complete req draft. Here are my comments: > >> > >> draft-pister-rl2n-industrial-routing-reqs-05 > >> > >> Overall comments > >> > >> Very well written. The requirements are however encompassing some > >> issues far beyond the scope of IP routing and rl2n, e.g. MAC-layer > >> slotting, QoS priority mechanisms etc. which yes are encompassed by > >> ISA100 as a whole. But should the requirements for an r2ln draft be so > >> broad? I'd like to hear justification on this, although I see reason > >> for some of it. Others may have the same feeling? > >> > >> How do these requirements relate to ISA100, are they taken directly or > >> do we have something special for rl2n here? > >> > >> Section 2.1 > >> > >> In addition to mentioning equipment monitoring, the general class of > >> asset monitoring and tracking can be mentioned as belonging to classes > >> 4-5. Also access control could be mentioned as an application, > >> although it has overlap of course with commercial building automation. > >> > >> Section 3 > >> > >> Can we demand 10ms timeslots from the r2ln point of view? What if the > >> L2 protocol is not able to provide that? Do 10ms time-slots make sense > >> for classes 3-5 at all? They at least don't make sense for sparse > >> events and bulk non-critical transfers. > >> > >> Section 8 > >> > >> We have also seen lots of applications for field device mobile > >> monitoring and for mounting on mobile equipment. Very happy to see > >> both here as requirements. > >> > >> Looking forward to the expansion of Section 9. > >> > >> - Zach > >> > >> > >> Kris Pister wrote: > >> > Version 0 of the routing requirements for industrial automation is > >> now available. > >> > Comments and questions are eagerly awaited. > >> > > >> > > >> http://www.ietf.org/internet-drafts/draft-pister-rl2n-indus-routing-reqs-00.txt > >> > >> > > >> > ksjp > >> > > >> > > >> > _______________________________________________ > >> > 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