From 6lowpan-bounces@ietf.org Thu Nov 01 02:59:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0V-0002X2-Es; Thu, 01 Nov 2007 02:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0U-0002Wi-Bu for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 02:58:22 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InU0N-0000z1-AI for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 02:58:22 -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 Subject: 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> 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 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Kris Pister wrote: > 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 01 02:59:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0a-0002gs-1g; Thu, 01 Nov 2007 02:58:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0Y-0002YU-AZ for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 02:58:26 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InU0R-0000zh-39 for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 02:58:26 -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 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 01 02:59:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0V-0002X2-Es; Thu, 01 Nov 2007 02:58:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0U-0002Wi-Bu for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 02:58:22 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InU0N-0000z1-AI for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 02:58:22 -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 Subject: 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> 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 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Kris Pister wrote: > 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 01 02:59:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0a-0002gs-1g; Thu, 01 Nov 2007 02:58:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU0Y-0002YU-AZ for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 02:58:26 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InU0R-0000zh-39 for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 02:58:26 -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 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 01 09:21:36 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZy2-00064h-RK; Thu, 01 Nov 2007 09:20:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZy0-00062I-Ne for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 09:20:12 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InZxv-0001Gz-R4 for 6lowpan@lists.ietf.org; Thu, 01 Nov 2007 09:20:12 -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 Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 05 07:31:11 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip16j-00074y-C9; Mon, 05 Nov 2007 07:31:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip16h-00071w-TJ for 6lowpan@lists.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-0005P4-ST for 6lowpan@lists.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: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Geoff: 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 09 19:55:47 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqedR-0004vK-C6; Fri, 09 Nov 2007 19:55:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqedP-0004jl-Cu for 6lowpan@lists.ietf.org; Fri, 09 Nov 2007 19:55:39 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqedM-0006EQ-Ag for 6lowpan@lists.ietf.org; Fri, 09 Nov 2007 19:55:39 -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 lAA0tX0f017436 for <6lowpan@lists.ietf.org>; Fri, 9 Nov 2007 17:55:35 -0700 (MST) From: Geoff Mulligan To: 6lowpan <6lowpan@lists.ietf.org> Content-Type: text/plain Date: Fri, 09 Nov 2007 17:55:37 -0700 Message-Id: <1194656137.5777.131.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: Subject: [6lowpan] working group drafts and agenda for next IETF X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Folks, Even though we do not have an approved recharter text we have a WG meeting slot at the next IETF and we need to set the agenda. >From the last IETF meeting I think that we reached consensus on the work items for the group: 1. Bootstrapping / Neighbor Discovery 2. Stateful Header Compression 3. Architecture 4. Applications 5. Security Analysis We decided that we would hold off on Mesh Under (Layer 2 routing) at this time until the path becomes more clear with respect to the RL2N proposal. This group has generated a number of I-Ds, though many are now expired. Some of the active and expired I-Ds seem closely related to the work items above. I have included in this message a list of both the Active and Expired I-Ds that have been submitted and their abstracts so that you don't have to search for the I-D information. Taking into account the above work items, if any of the authors are interested in presenting their drafts at this next IETF, please let Carsten or I know soon. I do hope that we will dust off the ND and security analysis drafts. If anyone else is planning on submitting a draft, please let us know soon and also get it submitted - the deadline is the 12th. geoff ============== Active Drafts =============== --- draft-daniel-6lowpan-commissioning-00 The commisioning process defines the startup procedure taken by the 6LoWPAN device. This document defines the startup procedure that all kinds of devices must take to become part of the network. --- draft-daniel-6lowpan-hilow-hierarchical-routing-01 The EUI-64 identifier of a 6LoWPAN device can be used as the interface identifier of the IPv6 address, which can be used for for on-demand multi-hop routing in 6LoWPAN. One of the distinctive feature of 6LoWPAN is the capability of the dynamic assignment of 16- bit short addresses. By utilizing this dynamically assigned short address, a hierarchical routing which is very scalable can be employed. This This document defines a dynamic address assignment scheme and hierarchical routing HiLow) based on the assignment. --- draft-daniel-6lowpan-load-adhoc-routing-03 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) is intended for use by IEEE 802.15.4 devices in a 6LoWPAN. It is a simplified on-demand routing protocol based on AODV. --- draft-daniel-6lowpan-sslp-01 The Simple Service Location Protocol (SSLP) provides a framework for the discovery and selection of the services working on 6LoWPAN. The protocol has a simple structure that is easy to be implemented on 6LoWPAN devices that are characterized by short range, low bit rate and low power. The protocol also offers a mechanism for interoperability with the IP networks under SLP. It enables communication between 6LoWPAN and other IP networks. --- draft-dokaspar-6lowpan-routreq-02 This document provides the problem statement for mesh routing below the IP layer (in 6LoWPAN's adaptation layer). It also defines major design goals and requirements for 6LoWPAN mesh routing considering the low-power characteristics of the network and its devices. --- draft-ekim-6lowpan-scenarios-00 This document investigates potential application scenarios and use cases for low-power wireless personal area networks (LoWPANs). --- draft-hui-6lowpan-hc1g-00 This document specifies a stateless IP header compression scheme for IPv6 packet delivery in 6LoWPAN subnetworks. The compression scheme focuses on LoWPAN nodes that may have global unicast addresses assigned to their interfaces. --- draft-hui-6lowpan-interop-00 This memo defines a first step in testing and demonstrating the interoperability of independent 6LoWPAN implementations. --- draft-montenegro-6lowpan-dymo-low-routing-03 This document specifies how to use the Dynamic MANET On-demand Routing Protocol over IEEE802.15.4 networks. --- draft-oh-6lowpan-packetbb-dymoapp-01 This document describes the applicability of the generalized MANET packet/message format (packetbb) and the dynamic MANET on-demand (DYMO) routing protocol over 6LoWPAN. In order to achieve low memory usage and low processing overhead, this document suggests what is to be modified from the MANET base specifications. --- draft-shin-6lowpan-mobility-00 This draft lists mobility scenarios and suggests solutions of how to provide mobility support in IPv6 low-power personal area networks (6LoWPANs). --- draft-thubert-lowpan-backbone-router-00 ISA100.11a is a Working Group at the ISA SP100 standard committee that covers Wireless Systems for Industrial Automation and Process Control. The WG is mandated to design a scalable, industrial grade LowPAN for devices such as sensors, valves, and actuators. The upcoming standard uses the 6LoWPAN format for the network header. It also introduces the concept of a Backbone Router to merge small LoWPANs via a high speed transit and scale the ISA100.11a network. This paper proposes an IPv6 version of the Backbone Router concept. =============== Expired Drafts =============== --- draft-chakrabarti-6lowpan-ipv6-nd-03 IETF 6LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have multicast support, although it supports broadcast. Due to the nature of LowPan network or sensor networks, broadcast messages should be minimized. This document suggests some optimizations to IPv6 Neighbor Discovery related multicast messages in order to reduce signaling in the low-cost low-powered network. --- draft-chakrabarti-mobopts-lowpan-req-01 IETF LowPan working group defines IPv6 over low-power personal area network (IEEE 802.15.4). Lowpan architecture allows routing to take place at the link layer in order to save payload overhead over the IEEE 802.15.4 link and thus more efficient routing for low power, low data-rate networks such as sensor networks. This document discusses a few scenarios of mobility in LowPan network and states mobility requirements and goals for LowPan networks. --- draft-daniel-6lowpan-interoperability-01 This document specifies the gateway architecture for the interoperability between 6LoWPAN and external IPv6 networks. The gateway does the compression and decompression of IPv6 packets and performs the mapping between 16 bit short addresses and the IPv6 addresses for both the external IPv6 networks and 6LowPAN, respectively. --- draft-daniel-6lowpan-security-analysis-01 This document discusses possible threats and security options for IPv6-over-IEEE802.15.4 networks. It is an informational document to raise awareness of security issues in IPv6 lowPan networks. --- draft-guha-lowpan-mobility-protocol-req-00 In this draft, we propose some protocol requirements for mobility in LowPAN networks within the context of the IETF LowPAN working group (IPv6 over IEEE 802.15.4). To achieve mobility in LowPAN networks, there may be inter-domain movement of network elements across different LowPAN domains or across domains that do not comprise LowPAN autonomous systems. To address routing issues in inter-domain LowPAN networks that conform to fitting within a single IEEE 802.15.4 frame, there are needs for collaborative and distributed methodologies for route computation, information storage and retrieval, and security issues in protocols targeted to LowPAN mobility. This draft proposes some requirements of mobility in LowPAN protocols from the perspective of protocol-independent metrics, algorithm complexities, scalability and security criteria. --- draft-montenegro-lowpan-aodv-00 This document describes how to use the Ad Hoc On-Demand Vector Protocol (AODV) in IEEE 802.15.4 networks. --- draft-sarikaya-6lowpan-forwarding-00 This document describes a simple approach to interconnect IEEE 802.15.4 sensor nodes to IPv6 Internet. The technique requires a gateway node that is connected to both the sensor network and the IPv6 Internet. The gateway node runs the serial forwarder over IPv6. Sensor nodes run the open-source TinyOS operating system and generate TinyOS packets. The sensor network can be accessed from IPv6 Internet using a Web interface and the serial forwarder that runs in the applets enables reception/transmission of TinyOS packets over IPv6. _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Nov 10 09:40:16 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqrVK-0005Ww-5i; Sat, 10 Nov 2007 09:40:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqrVI-0005TO-L2 for 6lowpan@lists.ietf.org; Sat, 10 Nov 2007 09:40:08 -0500 Received: from smtp1-g19.free.fr ([212.27.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqrVD-0001bn-1S for 6lowpan@lists.ietf.org; Sat, 10 Nov 2007 09:40:08 -0500 Received: from smtp1-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp1-g19.free.fr (Postfix) with ESMTP id 070D51AB2FB; Sat, 10 Nov 2007 15:40:02 +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 87B921AB2AE; Sat, 10 Nov 2007 15:40:01 +0100 (CET) In-Reply-To: <1194656137.5777.131.camel@dellx1> References: <1194656137.5777.131.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <629B7DDA-BA06-41BF-8F54-AB28BFF562BD@ens-lyon.fr> Content-Transfer-Encoding: quoted-printable From: Bernard Tourancheau Subject: Re: [6lowpan] working group drafts and agenda for next IETF Date: Sat, 10 Nov 2007 15:40:00 +0100 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Le 10 nov. 07 =E0 01:55, Geoff Mulligan a =E9crit : > Folks, > Even though we do not have an approved recharter text we have a WG > meeting slot at the next IETF and we need to set the agenda. > >> =46rom the last IETF meeting I think that we reached consensus on =20 >> the work > items for the group: > > 1. Bootstrapping / Neighbor Discovery > 2. Stateful Header Compression > 3. Architecture > 4. Applications > 5. Security Analysis > > We decided that we would hold off on Mesh Under (Layer 2 routing) at > this time until the path becomes more clear with respect to the RL2N > proposal. On that subject, We are studying several possibilities and http://www.watersprings.org/=20= pub/id/draft-chelius-adhoc-ipv6-00.txt seems to be very appropriate =20 for the discussion. Bernard. > > This group has generated a number of I-Ds, though many are now =20 > expired. > Some of the active and expired I-Ds seem closely related to the work > items above. > > I have included in this message a list of both the Active and Expired > I-Ds that have been submitted and their abstracts so that you don't =20= > have > to search for the I-D information. > > Taking into account the above work items, if any of the authors are > interested in presenting their drafts at this next IETF, please let > Carsten or I know soon. > > I do hope that we will dust off the ND and security analysis drafts. > > If anyone else is planning on submitting a draft, please let us know > soon and also get it submitted - the deadline is the 12th. > > geoff > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Active Drafts = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- draft-daniel-6lowpan-commissioning-00 > The commisioning process defines the startup procedure taken by the > 6LoWPAN device. This document defines the startup procedure that all > kinds of devices must take to become part of the network. > > --- draft-daniel-6lowpan-hilow-hierarchical-routing-01 > The EUI-64 identifier of a 6LoWPAN device can be used as the interface > identifier of the IPv6 address, which can be used for for on-demand > multi-hop routing in 6LoWPAN. One of the distinctive feature of =20 > 6LoWPAN > is the capability of the dynamic assignment of 16- bit short =20 > addresses. > By utilizing this dynamically assigned short address, a hierarchical > routing which is very scalable can be employed. This This document > defines a dynamic address assignment scheme and hierarchical routing > HiLow) based on the assignment. > > --- draft-daniel-6lowpan-load-adhoc-routing-03 > 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) is intended =20= > for > use by IEEE 802.15.4 devices in a 6LoWPAN. It is a simplified on-=20 > demand > routing protocol based on AODV. > > --- draft-daniel-6lowpan-sslp-01 > The Simple Service Location Protocol (SSLP) provides a framework =20 > for the > discovery and selection of the services working on 6LoWPAN. The =20 > protocol > has a simple structure that is easy to be implemented on 6LoWPAN =20 > devices > that are characterized by short range, low bit rate and low power. The > protocol also offers a mechanism for interoperability with the IP > networks under SLP. It enables communication between 6LoWPAN and other > IP networks. > > --- draft-dokaspar-6lowpan-routreq-02 > This document provides the problem statement for mesh routing below =20= > the > IP layer (in 6LoWPAN's adaptation layer). It also defines major design > goals and requirements for 6LoWPAN mesh routing considering the > low-power characteristics of the network and its devices. > > --- draft-ekim-6lowpan-scenarios-00 > This document investigates potential application scenarios and use =20 > cases > for low-power wireless personal area networks (LoWPANs). > > --- draft-hui-6lowpan-hc1g-00 > This document specifies a stateless IP header compression scheme for > IPv6 packet delivery in 6LoWPAN subnetworks. The compression scheme > focuses on LoWPAN nodes that may have global unicast addresses =20 > assigned > to their interfaces. > > --- draft-hui-6lowpan-interop-00 > This memo defines a first step in testing and demonstrating the > interoperability of independent 6LoWPAN implementations. > > --- draft-montenegro-6lowpan-dymo-low-routing-03 > This document specifies how to use the Dynamic MANET On-demand Routing > Protocol over IEEE802.15.4 networks. > > --- draft-oh-6lowpan-packetbb-dymoapp-01 > This document describes the applicability of the generalized MANET > packet/message format (packetbb) and the dynamic MANET on-demand =20 > (DYMO) > routing protocol over 6LoWPAN. In order to achieve low memory usage =20= > and > low processing overhead, this document suggests what is to be modified > from the MANET base specifications. > > --- draft-shin-6lowpan-mobility-00 > This draft lists mobility scenarios and suggests solutions of how to > provide mobility support in IPv6 low-power personal area networks > (6LoWPANs). > > --- draft-thubert-lowpan-backbone-router-00 > ISA100.11a is a Working Group at the ISA SP100 standard committee that > covers Wireless Systems for Industrial Automation and Process Control. > The WG is mandated to design a scalable, industrial grade LowPAN for > devices such as sensors, valves, and actuators. The upcoming standard > uses the 6LoWPAN format for the network header. It also introduces the > concept of a Backbone Router to merge small LoWPANs via a high speed > transit and scale the ISA100.11a network. This paper proposes an IPv6 > version of the Backbone Router concept. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Expired Drafts = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- draft-chakrabarti-6lowpan-ipv6-nd-03 > IETF 6LowPan working group defines IPv6 over low-power personal area > network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have > multicast support, although it supports broadcast. Due to the =20 > nature of > LowPan network or sensor networks, broadcast messages should be > minimized. This document suggests some optimizations to IPv6 Neighbor > Discovery related multicast messages in order to reduce signaling =20 > in the > low-cost low-powered network. > > --- draft-chakrabarti-mobopts-lowpan-req-01 > IETF LowPan working group defines IPv6 over low-power personal area > network (IEEE 802.15.4). Lowpan architecture allows routing to take > place at the link layer in order to save payload overhead over the =20 > IEEE > 802.15.4 link and thus more efficient routing for low power, low > data-rate networks such as sensor networks. This document discusses a > few scenarios of mobility in LowPan network and states mobility > requirements and goals for LowPan networks. > > --- draft-daniel-6lowpan-interoperability-01 > This document specifies the gateway architecture for the > interoperability between 6LoWPAN and external IPv6 networks. The =20 > gateway > does the compression and decompression of IPv6 packets and performs =20= > the > mapping between 16 bit short addresses and the IPv6 addresses for both > the external IPv6 networks and 6LowPAN, respectively. > > --- draft-daniel-6lowpan-security-analysis-01 > This document discusses possible threats and security options for > IPv6-over-IEEE802.15.4 networks. It is an informational document to > raise awareness of security issues in IPv6 lowPan networks. > > --- draft-guha-lowpan-mobility-protocol-req-00 > In this draft, we propose some protocol requirements for mobility in > LowPAN networks within the context of the IETF LowPAN working group > (IPv6 over IEEE 802.15.4). To achieve mobility in LowPAN networks, =20 > there > may be inter-domain movement of network elements across different =20 > LowPAN > domains or across domains that do not comprise LowPAN autonomous > systems. To address routing issues in inter-domain LowPAN networks =20 > that > conform to fitting within a single IEEE 802.15.4 frame, there are =20 > needs > for collaborative and distributed methodologies for route computation, > information storage and retrieval, and security issues in protocols > targeted to LowPAN mobility. This draft proposes some requirements of > mobility in LowPAN protocols from the perspective of > protocol-independent metrics, algorithm complexities, scalability and > security criteria. > > --- draft-montenegro-lowpan-aodv-00 > This document describes how to use the Ad Hoc On-Demand Vector =20 > Protocol > (AODV) in IEEE 802.15.4 networks. > > --- draft-sarikaya-6lowpan-forwarding-00 > This document describes a simple approach to interconnect IEEE =20 > 802.15.4 > sensor nodes to IPv6 Internet. The technique requires a gateway node > that is connected to both the sensor network and the IPv6 Internet. =20= > The > gateway node runs the serial forwarder over IPv6. Sensor nodes run the > open-source TinyOS operating system and generate TinyOS packets. The > sensor network can be accessed from IPv6 Internet using a Web =20 > interface > and the serial forwarder that runs in the applets enables > reception/transmission of TinyOS packets over IPv6. > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 15 02:52:42 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZWj-0004vD-EB; Thu, 15 Nov 2007 02:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZWh-0004qg-Bb for 6lowpan@lists.ietf.org; Thu, 15 Nov 2007 02:52:39 -0500 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsZWe-0000tD-3q for 6lowpan@lists.ietf.org; Thu, 15 Nov 2007 02:52:39 -0500 Received: by an-out-0708.google.com with SMTP id c18so115098anc for <6lowpan@lists.ietf.org>; Wed, 14 Nov 2007 23:52:35 -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=hWSumwe5qc4hpv6A+8r/20uq8c7J00v/R3qBJkSYXO0=; b=pj0Z4V67GU/acsbCDLuXynISH6GaQ8UA3jckImLBQZZnzN+5WMr72ZW+mhNYu3oy9Wxdz4rdQy2SjIkopM57/SItqlwMbNJMqRpkNKj4milkqOM5tVcU8kJonG/xHorkZDxsbIbnbsXLeNPZ5dq6jtPFP/K3uzKQKgd9E5hIJmk= 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=Fak1anBESzZIgTbTmvEj5fFBn7dEmU8/sn1sgpoY4+EGBlt65ATzqSbS1fvEN4pchyPxzAkw9Rve0V0GeAB1fSFsNxCSwSUDFTt+STQTKoe9IGrjvG+P9Ak4cbTG3/+/SXlpDXrdzhLOYz4UTfMizz+qNthF2zKdu68bK0Wls40= Received: by 10.143.161.3 with SMTP id n3mr39408wfo.1195113154888; Wed, 14 Nov 2007 23:52:34 -0800 (PST) Received: by 10.142.105.17 with HTTP; Wed, 14 Nov 2007 23:52:34 -0800 (PST) Message-ID: <77f1dba80711142352p69c60049g9625764b5a1bfc8a@mail.gmail.com> Date: Thu, 15 Nov 2007 16:52:34 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" , cabo@tzi.org Subject: Re: [6lowpan] working group drafts and agenda for next IETF In-Reply-To: <1194656137.5777.131.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1194656137.5777.131.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Dear Geoff, We submitted application-scenario-01 already. And, as I remember we agreed to handle 'routing requirements' for 6lowpan mesh routing, although we don't handle the solutions. Dominik and I will submit routreq-03 for discussion. We updated the draft based on the meeting discussion. Thanks, -eunah (eunsook) On 11/10/07, Geoff Mulligan wrote: > Folks, > Even though we do not have an approved recharter text we have a WG > meeting slot at the next IETF and we need to set the agenda. > > >From the last IETF meeting I think that we reached consensus on the work > items for the group: > > 1. Bootstrapping / Neighbor Discovery > 2. Stateful Header Compression > 3. Architecture > 4. Applications > 5. Security Analysis > > We decided that we would hold off on Mesh Under (Layer 2 routing) at > this time until the path becomes more clear with respect to the RL2N > proposal. > > This group has generated a number of I-Ds, though many are now expired. > Some of the active and expired I-Ds seem closely related to the work > items above. > > I have included in this message a list of both the Active and Expired > I-Ds that have been submitted and their abstracts so that you don't have > to search for the I-D information. > > Taking into account the above work items, if any of the authors are > interested in presenting their drafts at this next IETF, please let > Carsten or I know soon. > > I do hope that we will dust off the ND and security analysis drafts. > > If anyone else is planning on submitting a draft, please let us know > soon and also get it submitted - the deadline is the 12th. > > geoff > > > ============== Active Drafts =============== > --- draft-daniel-6lowpan-commissioning-00 > The commisioning process defines the startup procedure taken by the > 6LoWPAN device. This document defines the startup procedure that all > kinds of devices must take to become part of the network. > > --- draft-daniel-6lowpan-hilow-hierarchical-routing-01 > The EUI-64 identifier of a 6LoWPAN device can be used as the interface > identifier of the IPv6 address, which can be used for for on-demand > multi-hop routing in 6LoWPAN. One of the distinctive feature of 6LoWPAN > is the capability of the dynamic assignment of 16- bit short addresses. > By utilizing this dynamically assigned short address, a hierarchical > routing which is very scalable can be employed. This This document > defines a dynamic address assignment scheme and hierarchical routing > HiLow) based on the assignment. > > --- draft-daniel-6lowpan-load-adhoc-routing-03 > 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) is intended for > use by IEEE 802.15.4 devices in a 6LoWPAN. It is a simplified on-demand > routing protocol based on AODV. > > --- draft-daniel-6lowpan-sslp-01 > The Simple Service Location Protocol (SSLP) provides a framework for the > discovery and selection of the services working on 6LoWPAN. The protocol > has a simple structure that is easy to be implemented on 6LoWPAN devices > that are characterized by short range, low bit rate and low power. The > protocol also offers a mechanism for interoperability with the IP > networks under SLP. It enables communication between 6LoWPAN and other > IP networks. > > --- draft-dokaspar-6lowpan-routreq-02 > This document provides the problem statement for mesh routing below the > IP layer (in 6LoWPAN's adaptation layer). It also defines major design > goals and requirements for 6LoWPAN mesh routing considering the > low-power characteristics of the network and its devices. > > --- draft-ekim-6lowpan-scenarios-00 > This document investigates potential application scenarios and use cases > for low-power wireless personal area networks (LoWPANs). > > --- draft-hui-6lowpan-hc1g-00 > This document specifies a stateless IP header compression scheme for > IPv6 packet delivery in 6LoWPAN subnetworks. The compression scheme > focuses on LoWPAN nodes that may have global unicast addresses assigned > to their interfaces. > > --- draft-hui-6lowpan-interop-00 > This memo defines a first step in testing and demonstrating the > interoperability of independent 6LoWPAN implementations. > > --- draft-montenegro-6lowpan-dymo-low-routing-03 > This document specifies how to use the Dynamic MANET On-demand Routing > Protocol over IEEE802.15.4 networks. > > --- draft-oh-6lowpan-packetbb-dymoapp-01 > This document describes the applicability of the generalized MANET > packet/message format (packetbb) and the dynamic MANET on-demand (DYMO) > routing protocol over 6LoWPAN. In order to achieve low memory usage and > low processing overhead, this document suggests what is to be modified > from the MANET base specifications. > > --- draft-shin-6lowpan-mobility-00 > This draft lists mobility scenarios and suggests solutions of how to > provide mobility support in IPv6 low-power personal area networks > (6LoWPANs). > > --- draft-thubert-lowpan-backbone-router-00 > ISA100.11a is a Working Group at the ISA SP100 standard committee that > covers Wireless Systems for Industrial Automation and Process Control. > The WG is mandated to design a scalable, industrial grade LowPAN for > devices such as sensors, valves, and actuators. The upcoming standard > uses the 6LoWPAN format for the network header. It also introduces the > concept of a Backbone Router to merge small LoWPANs via a high speed > transit and scale the ISA100.11a network. This paper proposes an IPv6 > version of the Backbone Router concept. > > =============== Expired Drafts =============== > --- draft-chakrabarti-6lowpan-ipv6-nd-03 > IETF 6LowPan working group defines IPv6 over low-power personal area > network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have > multicast support, although it supports broadcast. Due to the nature of > LowPan network or sensor networks, broadcast messages should be > minimized. This document suggests some optimizations to IPv6 Neighbor > Discovery related multicast messages in order to reduce signaling in the > low-cost low-powered network. > > --- draft-chakrabarti-mobopts-lowpan-req-01 > IETF LowPan working group defines IPv6 over low-power personal area > network (IEEE 802.15.4). Lowpan architecture allows routing to take > place at the link layer in order to save payload overhead over the IEEE > 802.15.4 link and thus more efficient routing for low power, low > data-rate networks such as sensor networks. This document discusses a > few scenarios of mobility in LowPan network and states mobility > requirements and goals for LowPan networks. > > --- draft-daniel-6lowpan-interoperability-01 > This document specifies the gateway architecture for the > interoperability between 6LoWPAN and external IPv6 networks. The gateway > does the compression and decompression of IPv6 packets and performs the > mapping between 16 bit short addresses and the IPv6 addresses for both > the external IPv6 networks and 6LowPAN, respectively. > > --- draft-daniel-6lowpan-security-analysis-01 > This document discusses possible threats and security options for > IPv6-over-IEEE802.15.4 networks. It is an informational document to > raise awareness of security issues in IPv6 lowPan networks. > > --- draft-guha-lowpan-mobility-protocol-req-00 > In this draft, we propose some protocol requirements for mobility in > LowPAN networks within the context of the IETF LowPAN working group > (IPv6 over IEEE 802.15.4). To achieve mobility in LowPAN networks, there > may be inter-domain movement of network elements across different LowPAN > domains or across domains that do not comprise LowPAN autonomous > systems. To address routing issues in inter-domain LowPAN networks that > conform to fitting within a single IEEE 802.15.4 frame, there are needs > for collaborative and distributed methodologies for route computation, > information storage and retrieval, and security issues in protocols > targeted to LowPAN mobility. This draft proposes some requirements of > mobility in LowPAN protocols from the perspective of > protocol-independent metrics, algorithm complexities, scalability and > security criteria. > > --- draft-montenegro-lowpan-aodv-00 > This document describes how to use the Ad Hoc On-Demand Vector Protocol > (AODV) in IEEE 802.15.4 networks. > > --- draft-sarikaya-6lowpan-forwarding-00 > This document describes a simple approach to interconnect IEEE 802.15.4 > sensor nodes to IPv6 Internet. The technique requires a gateway node > that is connected to both the sensor network and the IPv6 Internet. The > gateway node runs the serial forwarder over IPv6. Sensor nodes run the > open-source TinyOS operating system and generate TinyOS packets. The > sensor network can be accessed from IPv6 Internet using a Web interface > and the serial forwarder that runs in the applets enables > reception/transmission of TinyOS packets over IPv6. > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Nov 19 03:43:57 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2ER-0003d9-1E; Mon, 19 Nov 2007 03:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2EQ-0003cu-0v for 6lowpan@lists.ietf.org; Mon, 19 Nov 2007 03:43:50 -0500 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu2EM-0008Qd-7C for 6lowpan@lists.ietf.org; Mon, 19 Nov 2007 03:43:49 -0500 Received: by nf-out-0910.google.com with SMTP id 4so1403563nfv for <6lowpan@lists.ietf.org>; Mon, 19 Nov 2007 00:43:45 -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=lfqF8cq7Ab0AcxujHqSv/xRftRYSsPHcecUZW3tawfk=; b=FhFGb2snTTFifTWIy11TeZCNc3pRdmysDjveT+d5UCys4untaxjGLY2tFpBdYGCAKG43y+KjcG5VreGuLjsh7E97pSqDNnruxLOTt+nT4QfSnlbgFpxih6XSS02y9Gz6012fFpuQdHn+hUAWHEyIF2idQMnlQHQXiomyj9JAT5E= 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=D3fEptoumfDtn0tf65G1lFnrriIvw430RSxqWiXX5DNrV2eKzaQXCxV/VN9pKe3E5B07xJFBivYsTInJ4ClcTZMZrGwlc9l6KIa3bQBU49/M2ujIUYJDlQxJC2ZN+uRClmOoSgdb0LVbESrei4twmI/i2sZQGGZkWquii9guGQo= Received: by 10.86.78.4 with SMTP id a4mr3532505fgb.1195461825416; Mon, 19 Nov 2007 00:43:45 -0800 (PST) Received: by 10.86.2.7 with HTTP; Mon, 19 Nov 2007 00:43:45 -0800 (PST) Message-ID: <43b91d370711190043u49e7daa6u177b2d2f96f87e5@mail.gmail.com> Date: Mon, 19 Nov 2007 00:43:45 -0800 From: "Samita Chakrabarti" To: "Geoff Mulligan" Subject: Re: [6lowpan] working group drafts and agenda for next IETF In-Reply-To: <1194656137.5777.131.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1194656137.5777.131.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: 6lowpan <6lowpan@lists.ietf.org>, Dave Thaler , "Bound, Jim" X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Geoff, Please see in-line. > > Taking into account the above work items, if any of the authors are > interested in presenting their drafts at this next IETF, please let > Carsten or I know soon. Regarding the 6lowpan-nd draft, we had a presentation at the Chicago IETF and received comments. We requested for working group approval at that time, but I was asked to wait for the architecture document. I had updated the 6lowpan wiki based on architectural assumptions that 6lowpan-nd draft makes. If anyone has any comments on the topology assumptions, that would be helpful. For example, should we stick to the hierarchical topology as depicted in the IEEE802.15.4 doc? Or should 6lowpan-nd goal be to also support a small mesh-network (not only hierarchical mesh as it discusses now)? I had a request from Jim Bound to think about that option as well. So far, there is no plan for presentation of this draft in this IETF. But comments through Wiki or mailing list would be really helpful. > > I do hope that we will dust off the ND and security analysis drafts. draft-chakrabarti-6lowpan-ipv6-nd version 04 has just been submitted. The changes are very minimal from 03 currently; it addresses some editorial comments from Dave Thaler. We are working on discussing off-line addressing Dave's techical comments. There will be another revision of the draft before the Philadelphia IETF. Besides, if bootstrapping is added as part of that draft, then this draft will need more update. Thanks so much, -Samita > > If anyone else is planning on submitting a draft, please let us know > soon and also get it submitted - the deadline is the 12th. > > geoff > > > ============== Active Drafts =============== > --- draft-daniel-6lowpan-commissioning-00 > The commisioning process defines the startup procedure taken by the > 6LoWPAN device. This document defines the startup procedure that all > kinds of devices must take to become part of the network. > > --- draft-daniel-6lowpan-hilow-hierarchical-routing-01 > The EUI-64 identifier of a 6LoWPAN device can be used as the interface > identifier of the IPv6 address, which can be used for for on-demand > multi-hop routing in 6LoWPAN. One of the distinctive feature of 6LoWPAN > is the capability of the dynamic assignment of 16- bit short addresses. > By utilizing this dynamically assigned short address, a hierarchical > routing which is very scalable can be employed. This This document > defines a dynamic address assignment scheme and hierarchical routing > HiLow) based on the assignment. > > --- draft-daniel-6lowpan-load-adhoc-routing-03 > 6LoWPAN Ad Hoc On-Demand Distance Vector Routing (LOAD) is intended for > use by IEEE 802.15.4 devices in a 6LoWPAN. It is a simplified on-demand > routing protocol based on AODV. > > --- draft-daniel-6lowpan-sslp-01 > The Simple Service Location Protocol (SSLP) provides a framework for the > discovery and selection of the services working on 6LoWPAN. The protocol > has a simple structure that is easy to be implemented on 6LoWPAN devices > that are characterized by short range, low bit rate and low power. The > protocol also offers a mechanism for interoperability with the IP > networks under SLP. It enables communication between 6LoWPAN and other > IP networks. > > --- draft-dokaspar-6lowpan-routreq-02 > This document provides the problem statement for mesh routing below the > IP layer (in 6LoWPAN's adaptation layer). It also defines major design > goals and requirements for 6LoWPAN mesh routing considering the > low-power characteristics of the network and its devices. > > --- draft-ekim-6lowpan-scenarios-00 > This document investigates potential application scenarios and use cases > for low-power wireless personal area networks (LoWPANs). > > --- draft-hui-6lowpan-hc1g-00 > This document specifies a stateless IP header compression scheme for > IPv6 packet delivery in 6LoWPAN subnetworks. The compression scheme > focuses on LoWPAN nodes that may have global unicast addresses assigned > to their interfaces. > > --- draft-hui-6lowpan-interop-00 > This memo defines a first step in testing and demonstrating the > interoperability of independent 6LoWPAN implementations. > > --- draft-montenegro-6lowpan-dymo-low-routing-03 > This document specifies how to use the Dynamic MANET On-demand Routing > Protocol over IEEE802.15.4 networks. > > --- draft-oh-6lowpan-packetbb-dymoapp-01 > This document describes the applicability of the generalized MANET > packet/message format (packetbb) and the dynamic MANET on-demand (DYMO) > routing protocol over 6LoWPAN. In order to achieve low memory usage and > low processing overhead, this document suggests what is to be modified > from the MANET base specifications. > > --- draft-shin-6lowpan-mobility-00 > This draft lists mobility scenarios and suggests solutions of how to > provide mobility support in IPv6 low-power personal area networks > (6LoWPANs). > > --- draft-thubert-lowpan-backbone-router-00 > ISA100.11a is a Working Group at the ISA SP100 standard committee that > covers Wireless Systems for Industrial Automation and Process Control. > The WG is mandated to design a scalable, industrial grade LowPAN for > devices such as sensors, valves, and actuators. The upcoming standard > uses the 6LoWPAN format for the network header. It also introduces the > concept of a Backbone Router to merge small LoWPANs via a high speed > transit and scale the ISA100.11a network. This paper proposes an IPv6 > version of the Backbone Router concept. > > =============== Expired Drafts =============== > --- draft-chakrabarti-6lowpan-ipv6-nd-03 > IETF 6LowPan working group defines IPv6 over low-power personal area > network (IEEE 802.15.4). IEEE 802.15.4 link layer does not have > multicast support, although it supports broadcast. Due to the nature of > LowPan network or sensor networks, broadcast messages should be > minimized. This document suggests some optimizations to IPv6 Neighbor > Discovery related multicast messages in order to reduce signaling in the > low-cost low-powered network. > > --- draft-chakrabarti-mobopts-lowpan-req-01 > IETF LowPan working group defines IPv6 over low-power personal area > network (IEEE 802.15.4). Lowpan architecture allows routing to take > place at the link layer in order to save payload overhead over the IEEE > 802.15.4 link and thus more efficient routing for low power, low > data-rate networks such as sensor networks. This document discusses a > few scenarios of mobility in LowPan network and states mobility > requirements and goals for LowPan networks. > > --- draft-daniel-6lowpan-interoperability-01 > This document specifies the gateway architecture for the > interoperability between 6LoWPAN and external IPv6 networks. The gateway > does the compression and decompression of IPv6 packets and performs the > mapping between 16 bit short addresses and the IPv6 addresses for both > the external IPv6 networks and 6LowPAN, respectively. > > --- draft-daniel-6lowpan-security-analysis-01 > This document discusses possible threats and security options for > IPv6-over-IEEE802.15.4 networks. It is an informational document to > raise awareness of security issues in IPv6 lowPan networks. > > --- draft-guha-lowpan-mobility-protocol-req-00 > In this draft, we propose some protocol requirements for mobility in > LowPAN networks within the context of the IETF LowPAN working group > (IPv6 over IEEE 802.15.4). To achieve mobility in LowPAN networks, there > may be inter-domain movement of network elements across different LowPAN > domains or across domains that do not comprise LowPAN autonomous > systems. To address routing issues in inter-domain LowPAN networks that > conform to fitting within a single IEEE 802.15.4 frame, there are needs > for collaborative and distributed methodologies for route computation, > information storage and retrieval, and security issues in protocols > targeted to LowPAN mobility. This draft proposes some requirements of > mobility in LowPAN protocols from the perspective of > protocol-independent metrics, algorithm complexities, scalability and > security criteria. > > --- draft-montenegro-lowpan-aodv-00 > This document describes how to use the Ad Hoc On-Demand Vector Protocol > (AODV) in IEEE 802.15.4 networks. > > --- draft-sarikaya-6lowpan-forwarding-00 > This document describes a simple approach to interconnect IEEE 802.15.4 > sensor nodes to IPv6 Internet. The technique requires a gateway node > that is connected to both the sensor network and the IPv6 Internet. The > gateway node runs the serial forwarder over IPv6. Sensor nodes run the > open-source TinyOS operating system and generate TinyOS packets. The > sensor network can be accessed from IPv6 Internet using a Web interface > and the serial forwarder that runs in the applets enables > reception/transmission of TinyOS packets over IPv6. > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 28 08:10:50 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMgh-0001sg-7y; Wed, 28 Nov 2007 08:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMgg-0001sO-2u for 6lowpan@lists.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-0007QV-1z for 6lowpan@lists.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 Date: Wed, 28 Nov 2007 14:10:34 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@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: Acgse7PY8iGzi5huEdy88gANk8WjQAFPloAQ References: From: "Pascal Thubert (pthubert)" To: "Jean Philippe Vasseur (jvasseur)" 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 |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 Subject: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 28 08:29:56 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMzE-00055R-7p; Wed, 28 Nov 2007 08:29:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMzD-00054r-Jt for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 08:29:55 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxMzB-0000YD-O8 for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 08:29:55 -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 From: JP Vasseur To: "Pascal Thubert (pthubert)" Message-ID: 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 |Subject:=20Re=3A=20[RSN]=20Here=20is=20the=20new=20RL2N=20Proposed=20Wor king=20Charter |Sender:=20 |To:=20=22Pascal=20Thubert=20(pthubert)=22=20; 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: -4.0 (----) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: 6lowpan <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] Here is the new RL2N Proposed Working Charter X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Pascal, Thanks for the feed-back and support - in line, > From: "Pascal Thubert (pthubert)" > Date: Wed, 28 Nov 2007 08:10:34 -0500 > To: "Jean Philippe Vasseur (jvasseur)" > Cc: , 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 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 28 11:42:22 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxPzQ-0002lf-9b; Wed, 28 Nov 2007 11:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxPzO-0002jB-Lc for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 11:42:18 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxPzL-0002IO-Sb for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 11:42:18 -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 lASGgDGY028089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2007 08:42:14 -0800 (PST) Message-ID: <474D9A60.3040808@eecs.berkeley.edu> Date: Wed, 28 Nov 2007 08:42:08 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 213cf0777a99c4ccdd94bb20659dd28c Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] Re: [RSN] Here is the new RL2N Proposed Working Charter X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0062163484==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0062163484== Content-Type: multipart/alternative; boundary="------------000607040406040100080303" This is a multi-part message in MIME format. --------------000607040406040100080303 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gateway0.EECS.Berkeley.EDU id lASGgDGY028089 Is there an email thread somewhere that discusses the impact on 6LoWPAN=20 of the security requirements of 4294 and 4303? My first quick readthrough makes me very uncomfortable that some of the=20 mandates are going to be ugly from a header standpoint. ksjp Pascal Thubert (pthubert) wrote: > Hi JP: > > Thanks a bunch for this charter. I'll try not to rephrase what was alre= ady discussed with Christian, Anders, Philip and Misha.=20 > > 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 whe= ther we need to and can document how RFC 4294 applies for sensors, and M2= M 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 stuf= f to be incorporated in a sensory device. For instance, at the moment, SP= 100.11a endorses 6LoWPAN formats but it's not so clear at all that IPv6 i= tself 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 = in: http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-rou= ter-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 a= pplicability of existing MANET protocols will be difficult to prove witho= ut 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 wh= en 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 w= ork is really needed so please count my vote in for the adoption of the W= G. > > Cheers, > > 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 >> >> 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,=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 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 >> =20 > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > =20 --------------000607040406040100080303 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gateway0.EECS.Berkeley.EDU id lASGgDGY028089 Is there an email thread somewhere that discusses the impact on 6LoWPAN of the security requirements of 4294 and 4303?
My first quick readthrough makes me very uncomfortable that some of the mandates are going to be ugly from a header standpoint.

ksjp

Pascal Thubert (pthubert) wrote: 
Hi JP:

Thanks a bunch for this charter. I'll try not to rephrase what was 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 wheth=
er 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, SP10=
0.11a endorses 6LoWPAN formats but it's not so clear at all that IPv6 its=
elf is mandated. A clear spec with well-documented implementation could b=
e 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 N=
ULL 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.=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 app=
licability 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 su=
pported. 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 wor=
k 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: rs=
n@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 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 Pow=
er
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, su=
ch
as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be designed to ta=
ke
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), 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
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 operatio=
n
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 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).


- 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 include=
s
static and dynamic link/nodes attributes required for routing in L2Ns.

- 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,
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 consider=
ed
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 conside=
red
as an Informational RFC

February 2009: Submit the Routing for L2Ns Architecture document  (summar=
y
of requirements, metrics and attributes, path selection model) to the IES=
G
as an Informational RFC.

March 2009: Recharter.


Please comment/suggest/...

See you in Vancouver.

JP and David.


_______________________________________________
RSN mailing list
RSN@ie=
tf.org
https://www1.ietf.org/mailman/listinfo/rsn
    


_______________________________________________
RSN mailing list
RSN@ie=
tf.org
https://www1.ietf.org/mailman/listinfo/rsn
--------------000607040406040100080303-- --===============0062163484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0062163484==-- From 6lowpan-bounces@ietf.org Wed Nov 28 12:47:20 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxR0G-0006zS-DN; Wed, 28 Nov 2007 12:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxR0F-0006z7-6O for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 12:47:15 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxR0D-00033Q-PZ for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 12:47:15 -0500 X-IronPort-AV: E=Sophos;i="4.23,225,1194217200"; d="scan'208";a="159044684" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Nov 2007 18:46:59 +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 lASHkxWx008865; Wed, 28 Nov 2007 18:46:59 +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 lASHgA3p020439; Wed, 28 Nov 2007 17:46:57 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 18:44:45 +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 Date: Wed, 28 Nov 2007 18:44:38 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> In-Reply-To: <474D9A60.3040808@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgx3ahWilLurZ7AR9SsBOTsZLGPPwABjZXQ References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "Kris Pister" X-OriginalArrivalTime: 28 Nov 2007 17:44:45.0424 (UTC) FILETIME=[5D195700:01C831E6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7655; t=1196272019; x=1197136019; 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]=20Here=20is=20the=20new=20RL2N=20Proposed=20Wor king=20Charter |Sender:=20; bh=QJ4bk2pP/P32e/mMb+Ez54hjarEhepKBH+i84eWJwxk=; b=T+JCUi3lu8QEPDHPtMbY+iCs/vKwvzO1T4xasPkGjkgq8LIvQ16T8pCOUS/D6UrB9lbGtqC4 0CanksnQcys5V9igrr6/iHtQEZfkOjkLkPXJMb2BcsjpZHoDMRTrAAn8; 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: ff0adf256e4dd459cc25215cfa732ac1 Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Kris: For your question on ESP, AFAIK, RFC 4294 only mandates NULL encryption = and authentication for interoperability reasons.=20 On the general question of RFC 4294 itself: I'm not sure the work was = ever done. I hope someone from the list can help? If the answer is unclear, and considering that we are re-chartering the = group, maybe we could have a work item to specify the instantiation of = RFC 4294 for LoWPAN nodes? Pascal ________________________________________ From: Kris Pister [mailto:pister@eecs.berkeley.edu]=20 Sent: Wednesday, November 28, 2007 5:42 PM To: Pascal Thubert (pthubert) Cc: 6lowpan Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter Is there an email thread somewhere that discusses the impact on 6LoWPAN = of the security requirements of 4294 and 4303? My first quick readthrough makes me very uncomfortable that some of the = mandates are going to be ugly from a header standpoint. ksjp Pascal Thubert (pthubert) wrote:=20 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 =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 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 =20 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 28 14:02:43 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSBH-0001MX-8l; Wed, 28 Nov 2007 14:02:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSBG-0001MN-5e for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 14:02:42 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSBF-00030i-6g for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 14:02:42 -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 lASJ2dsR001482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 28 Nov 2007 11:02:40 -0800 (PST) Message-ID: <474DBB4A.2030605@eecs.berkeley.edu> Date: Wed, 28 Nov 2007 11:02:34 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gateway0.EECS.Berkeley.EDU id lASJ2dsR001482 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] Re: [RSN] Here is the new RL2N Proposed Working Charter X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hmm. From 4294: "However, while authentication and encryption can each be NULL, they=20 MUST NOT both be NULL." ksjp Pascal Thubert (pthubert) wrote: > Hi Kris: > > For your question on ESP, AFAIK, RFC 4294 only mandates NULL encryption= and authentication for interoperability reasons.=20 > > On the general question of RFC 4294 itself: I'm not sure the work was e= ver done. I hope someone from the list can help? > > If the answer is unclear, and considering that we are re-chartering the= group, maybe we could have a work item to specify the instantiation of R= FC 4294 for LoWPAN nodes? > > Pascal > ________________________________________ > From: Kris Pister [mailto:pister@eecs.berkeley.edu]=20 > Sent: Wednesday, November 28, 2007 5:42 PM > To: Pascal Thubert (pthubert) > Cc: 6lowpan > Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > > Is there an email thread somewhere that discusses the impact on 6LoWPAN= of the security requirements of 4294 and 4303? > My first quick readthrough makes me very uncomfortable that some of the= mandates are going to be ugly from a header standpoint. > > ksjp > > Pascal Thubert (pthubert) wrote:=20 > 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.=20 > > 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 whe= ther we need to and can document how RFC 4294 applies for sensors, and M2= M 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 stuf= f to be incorporated in a sensory device. For instance, at the moment, SP= 100.11a endorses 6LoWPAN formats but it's not so clear at all that IPv6 i= tself 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 = in: http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-rou= ter-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 a= pplicability of existing MANET protocols will be difficult to prove witho= ut 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 wh= en 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 w= ork is really needed so please count my vote in for the adoption of the W= G. > > Cheers, > > 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 > > 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 embe= dded > devices with limited power, memory, and processing resources interconne= cted > by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low P= ower > 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 routi= ng > 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 industri= al > monitoring, building automation (HVAC, lighting/access control), connec= ted > 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 applicatio= n > scenarios that provides high reliability in the presence of time varyin= g > loss characteristics and connectivity while permitting low-power operat= ion > with very modest memory and CPU pressure. > > > The Working Group will pay a particular attention to routing security a= nd > 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 an= d the > associated routing protocol requirements. The documents will progress i= n > collaboration with the 6lowpan Working Group (INT area). > > > - Survey the applicability of existing protocols to L2Ns. The aim of th= is > document will be to analyze the scaling and characteristics of existing > protocols and identify whether or not they meet the routing requirement= s 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 inclu= des > 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 routi= ng > approach. > > - Produce a security framework for routing in L2Ns. > > Goals And Milestones: > > > April 2008 Submit Use case/Routing requirements for Industrial, Connect= ed > Home, Building and Urban networks applications to the IESG to be consid= ered > 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 a= n > Informational RFC. > > January 2009 Submit Security Framework for L2Ns to the IESG to be consi= dered > as an Informational RFC > > February 2009: Submit the Routing for L2Ns Architecture document (summ= ary > of requirements, metrics and attributes, path selection model) to the I= ESG > 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 > =20 > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > =20 > =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 28 16:55:37 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUsY-0007Pn-56; Wed, 28 Nov 2007 16:55:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUsW-0007PW-EU for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 16:55:32 -0500 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxUsW-0005lQ-1m for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 16:55:32 -0500 X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from localhost (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id lASLtEh7012141; Wed, 28 Nov 2007 22:55:16 +0100 (CET) Message-Id: From: Carsten Bormann To: Kris Pister In-Reply-To: <474DBB4A.2030605@eecs.berkeley.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [6lowpan] Re: [RSN] Here is the new RL2N Proposed Working Charter Date: Wed, 28 Nov 2007 21:05:44 +0100 References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> X-Mailer: Apple Mail (2.915) X-Spam-Score: 4.5 (++++) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Nov 28 2007, at 20:02, Kris Pister wrote: > "However, while authentication and encryption can each be NULL, they > MUST NOT both be NULL." This does not surprise me that much. Why would you want to expend the overhead of an ESP encapsulation to provide no security whatsoever? Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Wed Nov 28 21:28:50 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZ8w-0003U2-0L; Wed, 28 Nov 2007 21:28:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZ8u-0003LM-Ja for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 21:28:44 -0500 Received: from rn-out-0910.google.com ([64.233.170.187] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxZ8t-0006mw-JZ for 6lowpan@lists.ietf.org; Wed, 28 Nov 2007 21:28:44 -0500 Received: by rn-out-0102.google.com with SMTP id s46so2623569rnb for <6lowpan@lists.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" To: "JP Vasseur" In-Reply-To: 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> X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: rsn@ietf.org, 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] Re: [RSN] Here is the new RL2N Proposed Working Charter X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Dear 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 wrote: > Hi Pascal, > > Thanks for the feed-back and support - in line, > > > > From: "Pascal Thubert (pthubert)" > > Date: Wed, 28 Nov 2007 08:10:34 -0500 > > To: "Jean Philippe Vasseur (jvasseur)" > > Cc: , 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 > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 08:41:19 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixjdm-0007Xc-03; Thu, 29 Nov 2007 08:41:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixjdk-0007Wf-Ij for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 08:41:16 -0500 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixjdi-00010M-Kk for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 08:41:16 -0500 Received: by py-out-1112.google.com with SMTP id u77so3561209pyb for <6lowpan@lists.ietf.org>; Thu, 29 Nov 2007 05:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=z8VQ+o8dCNyGmzKY/wWHZi7y64m39dlUBoT7SA/nIf0=; b=a1N33CvifZuLfPKmxa3DfUqEK2R67oV9ikTt9I4DdpgrEJDUYYCcpy0y67Ij9GXmnJox7ARyz+cUWU/0NTgy1ejeU6TNzzZS93ihLJXG5Qi6sLgVzHO/giayBF4Rko+7egzG0ZTFKfgGj+t/ib7DlU1o5678YvqtDNR4mgSIvTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MycN140ncmYeCGgbv4Y4Ctp/ZaG+dceBi7qU99zkQ5lr9HC8/7AlMYrvkW0W3WIGNP+PRx/XBmCzag/hZoCShuIW3SeWStImLdYEsaYfMacgw+iB2LDFj51CLYjsirbkxkoFZ8rcag309l51Vw6MAgEyLmBZihrSOuF2egnsCQk= Received: by 10.35.38.17 with SMTP id q17mr7518300pyj.1196343653492; Thu, 29 Nov 2007 05:40:53 -0800 (PST) Received: by 10.35.124.6 with HTTP; Thu, 29 Nov 2007 05:40:52 -0800 (PST) Message-ID: Date: Thu, 29 Nov 2007 22:40:52 +0900 From: "Ki-Hyung Kim" To: "Geoff Mulligan" Subject: Re: [6lowpan] working group drafts and agenda for next IETF In-Reply-To: <1194656137.5777.131.camel@dellx1> MIME-Version: 1.0 References: <1194656137.5777.131.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2027352748==" Errors-To: 6lowpan-bounces@ietf.org --===============2027352748== Content-Type: multipart/alternative; boundary="----=_Part_11134_27707592.1196343652770" ------=_Part_11134_27707592.1196343652770 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline R2VvZmYsCgpUaGUgbWFuYWdlbWVudCBkcmFmdCAoZHJhZnQtZGFuaWVsLWxvd3Bhbi1taWItMDAu dHh0KSBpcyBtaXNzaW5nIGluIHlvdXIKYWN0aXZlIGFuZCBleHBpcmVkIGRyYWZ0IGxpc3RzLgpJ dCBkZWFscyB3aXRoIHRoZSA2bG93cGFuIE1JQiBkZWZpbml0aW9uLgoKCgoKT24gMTEvMTAvMDcs IEdlb2ZmIE11bGxpZ2FuIDxnZW9mZi1pZXRmQG11bGxpZ2FuLm9yZz4gd3JvdGU6Cj4KPiBGb2xr cywKPiBFdmVuIHRob3VnaCB3ZSBkbyBub3QgaGF2ZSBhbiBhcHByb3ZlZCByZWNoYXJ0ZXIgdGV4 dCB3ZSBoYXZlIGEgV0cKPiBtZWV0aW5nIHNsb3QgYXQgdGhlIG5leHQgSUVURiBhbmQgd2UgbmVl ZCB0byBzZXQgdGhlIGFnZW5kYS4KPgo+ID5Gcm9tIHRoZSBsYXN0IElFVEYgbWVldGluZyBJIHRo aW5rIHRoYXQgd2UgcmVhY2hlZCBjb25zZW5zdXMgb24gdGhlIHdvcmsKPiBpdGVtcyBmb3IgdGhl IGdyb3VwOgo+Cj4gMS4gQm9vdHN0cmFwcGluZyAvIE5laWdoYm9yIERpc2NvdmVyeQo+IDIuIFN0 YXRlZnVsIEhlYWRlciBDb21wcmVzc2lvbgo+IDMuIEFyY2hpdGVjdHVyZQo+IDQuIEFwcGxpY2F0 aW9ucwo+IDUuIFNlY3VyaXR5IEFuYWx5c2lzCj4KPiBXZSBkZWNpZGVkIHRoYXQgd2Ugd291bGQg aG9sZCBvZmYgb24gTWVzaCBVbmRlciAoTGF5ZXIgMiByb3V0aW5nKSBhdAo+IHRoaXMgdGltZSB1 bnRpbCB0aGUgcGF0aCBiZWNvbWVzIG1vcmUgY2xlYXIgd2l0aCByZXNwZWN0IHRvIHRoZSBSTDJO Cj4gcHJvcG9zYWwuCj4KPiBUaGlzIGdyb3VwIGhhcyBnZW5lcmF0ZWQgYSBudW1iZXIgb2YgSS1E cywgdGhvdWdoIG1hbnkgYXJlIG5vdyBleHBpcmVkLgo+IFNvbWUgb2YgdGhlIGFjdGl2ZSBhbmQg ZXhwaXJlZCBJLURzIHNlZW0gY2xvc2VseSByZWxhdGVkIHRvIHRoZSB3b3JrCj4gaXRlbXMgYWJv dmUuCj4KPiBJIGhhdmUgaW5jbHVkZWQgaW4gdGhpcyBtZXNzYWdlIGEgbGlzdCBvZiBib3RoIHRo ZSBBY3RpdmUgYW5kIEV4cGlyZWQKPiBJLURzIHRoYXQgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBhbmQg dGhlaXIgYWJzdHJhY3RzIHNvIHRoYXQgeW91IGRvbid0IGhhdmUKPiB0byBzZWFyY2ggZm9yIHRo ZSBJLUQgaW5mb3JtYXRpb24uCj4KPiBUYWtpbmcgaW50byBhY2NvdW50IHRoZSBhYm92ZSB3b3Jr IGl0ZW1zLCBpZiBhbnkgb2YgdGhlIGF1dGhvcnMgYXJlCj4gaW50ZXJlc3RlZCBpbiBwcmVzZW50 aW5nIHRoZWlyIGRyYWZ0cyBhdCB0aGlzIG5leHQgSUVURiwgcGxlYXNlIGxldAo+IENhcnN0ZW4g b3IgSSBrbm93IHNvb24uCj4KPiBJIGRvIGhvcGUgdGhhdCB3ZSB3aWxsIGR1c3Qgb2ZmIHRoZSBO RCBhbmQgc2VjdXJpdHkgYW5hbHlzaXMgZHJhZnRzLgo+Cj4gSWYgYW55b25lIGVsc2UgaXMgcGxh bm5pbmcgb24gc3VibWl0dGluZyBhIGRyYWZ0LCBwbGVhc2UgbGV0IHVzIGtub3cKPiBzb29uIGFu ZCBhbHNvIGdldCBpdCBzdWJtaXR0ZWQgLSB0aGUgZGVhZGxpbmUgaXMgdGhlIDEydGguCj4KPiAg ICAgICAgZ2VvZmYKPgo+Cj4gPT09PT09PT09PT09PT0gQWN0aXZlIERyYWZ0cyA9PT09PT09PT09 PT09PT0KPiAtLS0gZHJhZnQtZGFuaWVsLTZsb3dwYW4tY29tbWlzc2lvbmluZy0wMAo+IFRoZSBj b21taXNpb25pbmcgcHJvY2VzcyBkZWZpbmVzIHRoZSBzdGFydHVwIHByb2NlZHVyZSB0YWtlbiBi eSB0aGUKPiA2TG9XUEFOIGRldmljZS4gVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBzdGFydHVw IHByb2NlZHVyZSB0aGF0IGFsbAo+IGtpbmRzIG9mIGRldmljZXMgbXVzdCB0YWtlIHRvIGJlY29t ZSBwYXJ0IG9mIHRoZSBuZXR3b3JrLgo+Cj4gLS0tIGRyYWZ0LWRhbmllbC02bG93cGFuLWhpbG93 LWhpZXJhcmNoaWNhbC1yb3V0aW5nLTAxCj4gVGhlIEVVSS02NCBpZGVudGlmaWVyIG9mIGEgNkxv V1BBTiBkZXZpY2UgY2FuIGJlIHVzZWQgYXMgdGhlIGludGVyZmFjZQo+IGlkZW50aWZpZXIgb2Yg dGhlIElQdjYgYWRkcmVzcywgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIGZvciBvbi1kZW1hbmQKPiBt dWx0aS1ob3Agcm91dGluZyBpbiA2TG9XUEFOLiBPbmUgb2YgdGhlIGRpc3RpbmN0aXZlIGZlYXR1 cmUgb2YgNkxvV1BBTgo+IGlzIHRoZSBjYXBhYmlsaXR5IG9mIHRoZSBkeW5hbWljIGFzc2lnbm1l bnQgb2YgMTYtIGJpdCBzaG9ydCBhZGRyZXNzZXMuCj4gQnkgdXRpbGl6aW5nIHRoaXMgZHluYW1p Y2FsbHkgYXNzaWduZWQgc2hvcnQgYWRkcmVzcywgYSBoaWVyYXJjaGljYWwKPiByb3V0aW5nIHdo aWNoIGlzIHZlcnkgc2NhbGFibGUgY2FuIGJlIGVtcGxveWVkLiBUaGlzIFRoaXMgZG9jdW1lbnQK PiBkZWZpbmVzIGEgZHluYW1pYyBhZGRyZXNzIGFzc2lnbm1lbnQgc2NoZW1lIGFuZCBoaWVyYXJj aGljYWwgcm91dGluZwo+IEhpTG93KSBiYXNlZCBvbiB0aGUgYXNzaWdubWVudC4KPgo+IC0tLSBk cmFmdC1kYW5pZWwtNmxvd3Bhbi1sb2FkLWFkaG9jLXJvdXRpbmctMDMKPiA2TG9XUEFOIEFkIEhv YyBPbi1EZW1hbmQgRGlzdGFuY2UgVmVjdG9yIFJvdXRpbmcgKExPQUQpIGlzIGludGVuZGVkIGZv cgo+IHVzZSBieSBJRUVFIDgwMi4xNS40IGRldmljZXMgaW4gYSA2TG9XUEFOLiBJdCBpcyBhIHNp bXBsaWZpZWQgb24tZGVtYW5kCj4gcm91dGluZyBwcm90b2NvbCBiYXNlZCBvbiBBT0RWLgo+Cj4g LS0tIGRyYWZ0LWRhbmllbC02bG93cGFuLXNzbHAtMDEKPiBUaGUgU2ltcGxlIFNlcnZpY2UgTG9j YXRpb24gUHJvdG9jb2wgKFNTTFApIHByb3ZpZGVzIGEgZnJhbWV3b3JrIGZvciB0aGUKPiBkaXNj b3ZlcnkgYW5kIHNlbGVjdGlvbiBvZiB0aGUgc2VydmljZXMgd29ya2luZyBvbiA2TG9XUEFOLiBU aGUgcHJvdG9jb2wKPiBoYXMgYSBzaW1wbGUgc3RydWN0dXJlIHRoYXQgaXMgZWFzeSB0byBiZSBp bXBsZW1lbnRlZCBvbiA2TG9XUEFOIGRldmljZXMKPiB0aGF0IGFyZSBjaGFyYWN0ZXJpemVkIGJ5 IHNob3J0IHJhbmdlLCBsb3cgYml0IHJhdGUgYW5kIGxvdyBwb3dlci4gVGhlCj4gcHJvdG9jb2wg YWxzbyBvZmZlcnMgYSBtZWNoYW5pc20gZm9yIGludGVyb3BlcmFiaWxpdHkgd2l0aCB0aGUgSVAK PiBuZXR3b3JrcyB1bmRlciBTTFAuIEl0IGVuYWJsZXMgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIDZM b1dQQU4gYW5kIG90aGVyCj4gSVAgbmV0d29ya3MuCj4KPiAtLS0gZHJhZnQtZG9rYXNwYXItNmxv d3Bhbi1yb3V0cmVxLTAyCj4gVGhpcyBkb2N1bWVudCBwcm92aWRlcyB0aGUgcHJvYmxlbSBzdGF0 ZW1lbnQgZm9yIG1lc2ggcm91dGluZyBiZWxvdyB0aGUKPiBJUCBsYXllciAoaW4gNkxvV1BBTidz IGFkYXB0YXRpb24gbGF5ZXIpLiBJdCBhbHNvIGRlZmluZXMgbWFqb3IgZGVzaWduCj4gZ29hbHMg YW5kIHJlcXVpcmVtZW50cyBmb3IgNkxvV1BBTiBtZXNoIHJvdXRpbmcgY29uc2lkZXJpbmcgdGhl Cj4gbG93LXBvd2VyIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbmV0d29yayBhbmQgaXRzIGRldmlj ZXMuCj4KPiAtLS0gZHJhZnQtZWtpbS02bG93cGFuLXNjZW5hcmlvcy0wMAo+IFRoaXMgZG9jdW1l bnQgaW52ZXN0aWdhdGVzIHBvdGVudGlhbCBhcHBsaWNhdGlvbiBzY2VuYXJpb3MgYW5kIHVzZSBj YXNlcwo+IGZvciBsb3ctcG93ZXIgd2lyZWxlc3MgcGVyc29uYWwgYXJlYSBuZXR3b3JrcyAoTG9X UEFOcykuCj4KPiAtLS0gZHJhZnQtaHVpLTZsb3dwYW4taGMxZy0wMAo+IFRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIGEgc3RhdGVsZXNzIElQIGhlYWRlciBjb21wcmVzc2lvbiBzY2hlbWUgZm9yCj4g SVB2NiBwYWNrZXQgZGVsaXZlcnkgaW4gNkxvV1BBTiBzdWJuZXR3b3Jrcy4gVGhlIGNvbXByZXNz aW9uIHNjaGVtZQo+IGZvY3VzZXMgb24gTG9XUEFOIG5vZGVzIHRoYXQgbWF5IGhhdmUgZ2xvYmFs IHVuaWNhc3QgYWRkcmVzc2VzIGFzc2lnbmVkCj4gdG8gdGhlaXIgaW50ZXJmYWNlcy4KPgo+IC0t LSBkcmFmdC1odWktNmxvd3Bhbi1pbnRlcm9wLTAwCj4gVGhpcyBtZW1vIGRlZmluZXMgYSBmaXJz dCBzdGVwIGluIHRlc3RpbmcgYW5kIGRlbW9uc3RyYXRpbmcgdGhlCj4gaW50ZXJvcGVyYWJpbGl0 eSBvZiBpbmRlcGVuZGVudCA2TG9XUEFOIGltcGxlbWVudGF0aW9ucy4KPgo+IC0tLSBkcmFmdC1t b250ZW5lZ3JvLTZsb3dwYW4tZHltby1sb3ctcm91dGluZy0wMwo+IFRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIGhvdyB0byB1c2UgdGhlIER5bmFtaWMgTUFORVQgT24tZGVtYW5kIFJvdXRpbmcKPiBQ cm90b2NvbCBvdmVyIElFRUU4MDIuMTUuNCBuZXR3b3Jrcy4KPgo+IC0tLSBkcmFmdC1vaC02bG93 cGFuLXBhY2tldGJiLWR5bW9hcHAtMDEKPiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgYXBw bGljYWJpbGl0eSBvZiB0aGUgZ2VuZXJhbGl6ZWQgTUFORVQKPiBwYWNrZXQvbWVzc2FnZSBmb3Jt YXQgKHBhY2tldGJiKSBhbmQgdGhlIGR5bmFtaWMgTUFORVQgb24tZGVtYW5kIChEWU1PKQo+IHJv dXRpbmcgcHJvdG9jb2wgb3ZlciA2TG9XUEFOLiBJbiBvcmRlciB0byBhY2hpZXZlIGxvdyBtZW1v cnkgdXNhZ2UgYW5kCj4gbG93IHByb2Nlc3Npbmcgb3ZlcmhlYWQsIHRoaXMgZG9jdW1lbnQgc3Vn Z2VzdHMgd2hhdCBpcyB0byBiZSBtb2RpZmllZAo+IGZyb20gdGhlIE1BTkVUIGJhc2Ugc3BlY2lm aWNhdGlvbnMuCj4KPiAtLS0gZHJhZnQtc2hpbi02bG93cGFuLW1vYmlsaXR5LTAwCj4gVGhpcyBk cmFmdCBsaXN0cyBtb2JpbGl0eSBzY2VuYXJpb3MgYW5kIHN1Z2dlc3RzIHNvbHV0aW9ucyBvZiBo b3cgdG8KPiBwcm92aWRlIG1vYmlsaXR5IHN1cHBvcnQgaW4gSVB2NiBsb3ctcG93ZXIgcGVyc29u YWwgYXJlYSBuZXR3b3Jrcwo+ICg2TG9XUEFOcykuCj4KPiAtLS0gZHJhZnQtdGh1YmVydC1sb3dw YW4tYmFja2JvbmUtcm91dGVyLTAwCj4gSVNBMTAwLjExYSBpcyBhIFdvcmtpbmcgR3JvdXAgYXQg dGhlIElTQSBTUDEwMCBzdGFuZGFyZCBjb21taXR0ZWUgdGhhdAo+IGNvdmVycyBXaXJlbGVzcyBT eXN0ZW1zIGZvciBJbmR1c3RyaWFsIEF1dG9tYXRpb24gYW5kIFByb2Nlc3MgQ29udHJvbC4KPiBU aGUgV0cgaXMgbWFuZGF0ZWQgdG8gZGVzaWduIGEgc2NhbGFibGUsIGluZHVzdHJpYWwgZ3JhZGUg TG93UEFOIGZvcgo+IGRldmljZXMgc3VjaCBhcyBzZW5zb3JzLCB2YWx2ZXMsIGFuZCBhY3R1YXRv cnMuIFRoZSB1cGNvbWluZyBzdGFuZGFyZAo+IHVzZXMgdGhlIDZMb1dQQU4gZm9ybWF0IGZvciB0 aGUgbmV0d29yayBoZWFkZXIuIEl0IGFsc28gaW50cm9kdWNlcyB0aGUKPiBjb25jZXB0IG9mIGEg QmFja2JvbmUgUm91dGVyIHRvIG1lcmdlIHNtYWxsIExvV1BBTnMgdmlhIGEgaGlnaCBzcGVlZAo+ IHRyYW5zaXQgYW5kIHNjYWxlIHRoZSBJU0ExMDAuMTFhIG5ldHdvcmsuIFRoaXMgcGFwZXIgcHJv cG9zZXMgYW4gSVB2Ngo+IHZlcnNpb24gb2YgdGhlIEJhY2tib25lIFJvdXRlciBjb25jZXB0Lgo+ Cj4gPT09PT09PT09PT09PT09IEV4cGlyZWQgRHJhZnRzID09PT09PT09PT09PT09PQo+IC0tLSBk cmFmdC1jaGFrcmFiYXJ0aS02bG93cGFuLWlwdjYtbmQtMDMKPiBJRVRGIDZMb3dQYW4gd29ya2lu ZyBncm91cCBkZWZpbmVzIElQdjYgb3ZlciBsb3ctcG93ZXIgcGVyc29uYWwgYXJlYQo+IG5ldHdv cmsgKElFRUUgODAyLjE1LjQpLiBJRUVFIDgwMi4xNS40IGxpbmsgbGF5ZXIgZG9lcyBub3QgaGF2 ZQo+IG11bHRpY2FzdCBzdXBwb3J0LCBhbHRob3VnaCBpdCBzdXBwb3J0cyBicm9hZGNhc3QuIER1 ZSB0byB0aGUgbmF0dXJlIG9mCj4gTG93UGFuIG5ldHdvcmsgb3Igc2Vuc29yIG5ldHdvcmtzLCBi cm9hZGNhc3QgbWVzc2FnZXMgc2hvdWxkIGJlCj4gbWluaW1pemVkLiBUaGlzIGRvY3VtZW50IHN1 Z2dlc3RzIHNvbWUgb3B0aW1pemF0aW9ucyB0byBJUHY2IE5laWdoYm9yCj4gRGlzY292ZXJ5IHJl bGF0ZWQgbXVsdGljYXN0IG1lc3NhZ2VzIGluIG9yZGVyIHRvIHJlZHVjZSBzaWduYWxpbmcgaW4g dGhlCj4gbG93LWNvc3QgbG93LXBvd2VyZWQgbmV0d29yay4KPgo+IC0tLSBkcmFmdC1jaGFrcmFi YXJ0aS1tb2JvcHRzLWxvd3Bhbi1yZXEtMDEKPiBJRVRGIExvd1BhbiB3b3JraW5nIGdyb3VwIGRl ZmluZXMgSVB2NiBvdmVyIGxvdy1wb3dlciBwZXJzb25hbCBhcmVhCj4gbmV0d29yayAoSUVFRSA4 MDIuMTUuNCkuIExvd3BhbiBhcmNoaXRlY3R1cmUgYWxsb3dzIHJvdXRpbmcgdG8gdGFrZQo+IHBs YWNlIGF0IHRoZSBsaW5rIGxheWVyIGluIG9yZGVyIHRvIHNhdmUgcGF5bG9hZCBvdmVyaGVhZCBv dmVyIHRoZSBJRUVFCj4gODAyLjE1LjQgbGluayBhbmQgdGh1cyBtb3JlIGVmZmljaWVudCByb3V0 aW5nIGZvciBsb3cgcG93ZXIsIGxvdwo+IGRhdGEtcmF0ZSBuZXR3b3JrcyBzdWNoIGFzIHNlbnNv ciBuZXR3b3Jrcy4gVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgYQo+IGZldyBzY2VuYXJpb3Mgb2Yg bW9iaWxpdHkgaW4gTG93UGFuIG5ldHdvcmsgYW5kIHN0YXRlcyBtb2JpbGl0eQo+IHJlcXVpcmVt ZW50cyBhbmQgZ29hbHMgZm9yIExvd1BhbiBuZXR3b3Jrcy4KPgo+IC0tLSBkcmFmdC1kYW5pZWwt Nmxvd3Bhbi1pbnRlcm9wZXJhYmlsaXR5LTAxCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhl IGdhdGV3YXkgYXJjaGl0ZWN0dXJlIGZvciB0aGUKPiBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4g NkxvV1BBTiBhbmQgZXh0ZXJuYWwgSVB2NiBuZXR3b3Jrcy4gVGhlIGdhdGV3YXkKPiBkb2VzIHRo ZSBjb21wcmVzc2lvbiBhbmQgZGVjb21wcmVzc2lvbiBvZiBJUHY2IHBhY2tldHMgYW5kIHBlcmZv cm1zIHRoZQo+IG1hcHBpbmcgYmV0d2VlbiAxNiBiaXQgc2hvcnQgYWRkcmVzc2VzIGFuZCB0aGUg SVB2NiBhZGRyZXNzZXMgZm9yIGJvdGgKPiB0aGUgZXh0ZXJuYWwgSVB2NiBuZXR3b3JrcyBhbmQg Nkxvd1BBTiwgcmVzcGVjdGl2ZWx5Lgo+Cj4gLS0tIGRyYWZ0LWRhbmllbC02bG93cGFuLXNlY3Vy aXR5LWFuYWx5c2lzLTAxCj4gVGhpcyBkb2N1bWVudCBkaXNjdXNzZXMgcG9zc2libGUgdGhyZWF0 cyBhbmQgc2VjdXJpdHkgb3B0aW9ucyBmb3IKPiBJUHY2LW92ZXItSUVFRTgwMi4xNS40IG5ldHdv cmtzLiBJdCBpcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRvCj4gcmFpc2UgYXdhcmVuZXNz IG9mIHNlY3VyaXR5IGlzc3VlcyBpbiBJUHY2IGxvd1BhbiBuZXR3b3Jrcy4KPgo+IC0tLSBkcmFm dC1ndWhhLWxvd3Bhbi1tb2JpbGl0eS1wcm90b2NvbC1yZXEtMDAKPiBJbiB0aGlzIGRyYWZ0LCB3 ZSBwcm9wb3NlIHNvbWUgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGZvciBtb2JpbGl0eSBpbgo+IExv d1BBTiBuZXR3b3JrcyB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlIElFVEYgTG93UEFOIHdvcmtp bmcgZ3JvdXAKPiAoSVB2NiBvdmVyIElFRUUgODAyLjE1LjQpLiBUbyBhY2hpZXZlIG1vYmlsaXR5 IGluIExvd1BBTiBuZXR3b3JrcywgdGhlcmUKPiBtYXkgYmUgaW50ZXItZG9tYWluIG1vdmVtZW50 IG9mIG5ldHdvcmsgZWxlbWVudHMgYWNyb3NzIGRpZmZlcmVudCBMb3dQQU4KPiBkb21haW5zIG9y IGFjcm9zcyBkb21haW5zIHRoYXQgZG8gbm90IGNvbXByaXNlIExvd1BBTiBhdXRvbm9tb3VzCj4g c3lzdGVtcy4gVG8gYWRkcmVzcyByb3V0aW5nIGlzc3VlcyBpbiBpbnRlci1kb21haW4gTG93UEFO IG5ldHdvcmtzIHRoYXQKPiBjb25mb3JtIHRvIGZpdHRpbmcgd2l0aGluIGEgc2luZ2xlIElFRUUg ODAyLjE1LjQgZnJhbWUsIHRoZXJlIGFyZSBuZWVkcwo+IGZvciBjb2xsYWJvcmF0aXZlIGFuZCBk aXN0cmlidXRlZCBtZXRob2RvbG9naWVzIGZvciByb3V0ZSBjb21wdXRhdGlvbiwKPiBpbmZvcm1h dGlvbiBzdG9yYWdlIGFuZCByZXRyaWV2YWwsIGFuZCBzZWN1cml0eSBpc3N1ZXMgaW4gcHJvdG9j b2xzCj4gdGFyZ2V0ZWQgdG8gTG93UEFOIG1vYmlsaXR5LiBUaGlzIGRyYWZ0IHByb3Bvc2VzIHNv bWUgcmVxdWlyZW1lbnRzIG9mCj4gbW9iaWxpdHkgaW4gTG93UEFOIHByb3RvY29scyBmcm9tIHRo ZSBwZXJzcGVjdGl2ZSBvZgo+IHByb3RvY29sLWluZGVwZW5kZW50IG1ldHJpY3MsIGFsZ29yaXRo bSBjb21wbGV4aXRpZXMsIHNjYWxhYmlsaXR5IGFuZAo+IHNlY3VyaXR5IGNyaXRlcmlhLgo+Cj4g LS0tIGRyYWZ0LW1vbnRlbmVncm8tbG93cGFuLWFvZHYtMDAKPiBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyBob3cgdG8gdXNlIHRoZSBBZCBIb2MgT24tRGVtYW5kIFZlY3RvciBQcm90b2NvbAo+IChB T0RWKSBpbiBJRUVFIDgwMi4xNS40IG5ldHdvcmtzLgo+Cj4gLS0tIGRyYWZ0LXNhcmlrYXlhLTZs b3dwYW4tZm9yd2FyZGluZy0wMAo+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc2ltcGxlIGFw cHJvYWNoIHRvIGludGVyY29ubmVjdCBJRUVFIDgwMi4xNS40Cj4gc2Vuc29yIG5vZGVzIHRvIElQ djYgSW50ZXJuZXQuIFRoZSB0ZWNobmlxdWUgcmVxdWlyZXMgYSBnYXRld2F5IG5vZGUKPiB0aGF0 IGlzIGNvbm5lY3RlZCB0byBib3RoIHRoZSBzZW5zb3IgbmV0d29yayBhbmQgdGhlIElQdjYgSW50 ZXJuZXQuIFRoZQo+IGdhdGV3YXkgbm9kZSBydW5zIHRoZSBzZXJpYWwgZm9yd2FyZGVyIG92ZXIg SVB2Ni4gU2Vuc29yIG5vZGVzIHJ1biB0aGUKPiBvcGVuLXNvdXJjZSBUaW55T1Mgb3BlcmF0aW5n IHN5c3RlbSBhbmQgZ2VuZXJhdGUgVGlueU9TIHBhY2tldHMuIFRoZQo+IHNlbnNvciBuZXR3b3Jr IGNhbiBiZSBhY2Nlc3NlZCBmcm9tIElQdjYgSW50ZXJuZXQgdXNpbmcgYSBXZWIgaW50ZXJmYWNl Cj4gYW5kIHRoZSBzZXJpYWwgZm9yd2FyZGVyIHRoYXQgcnVucyBpbiB0aGUgYXBwbGV0cyBlbmFi bGVzCj4gcmVjZXB0aW9uL3RyYW5zbWlzc2lvbiBvZiBUaW55T1MgcGFja2V0cyBvdmVyIElQdjYu Cj4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K PiA2bG93cGFuIG1haWxpbmcgbGlzdAo+IDZsb3dwYW5AaWV0Zi5vcmcKPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82bG93cGFuCj4KPgoKCi0tIApLaS1IeXVuZyBLaW0g KLHoseLH/Cwg0N3Rw/r7KQpBc3NvY2lhdGUgUHJvZmVzc29yCkRpdmlzaW9uIG9mIEluZm9ybWF0 aW9uIGFuZCBDb21wdXRlciBFbmcuLCBBam91IFVuaXZlcnNpdHksIFN1d29uLCBLb3JlYQo0NDIt NzQ5ClRlbDogKzgyLTMxLTIxOS0yNDMzLCBDZWw6ICs4Mi0xMC00NzYwLTI1NTEsICBGYXg6ICs4 Mi0zMS0yMTktMjQzMwpodHRwOi8vd3d3LjZsb3dwYW4ub3JnCg== ------=_Part_11134_27707592.1196343652770 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5HZW9mZiw8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5UaGUgbWFuYWdlbWVudCBk cmFmdCZuYnNwOyg8c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiA5cHQ7IExFVFRFUi1TUEFDSU5HOiAw LjVwdCI+ZHJhZnQtZGFuaWVsLWxvd3Bhbi1taWItMDAudHh0KSBpcyBtaXNzaW5nIGluIHlvdXIg YWN0aXZlIGFuZCBleHBpcmVkIGRyYWZ0IGxpc3RzLjwvc3Bhbj48L2Rpdj4KPGRpdj48c3BhbiBz dHlsZT0iRk9OVC1TSVpFOiA5cHQ7IExFVFRFUi1TUEFDSU5HOiAwLjVwdCI+SXQgZGVhbHMgd2l0 aCB0aGUgNmxvd3BhbiBNSUIgZGVmaW5pdGlvbi48L3NwYW4+PC9kaXY+CjxkaXY+PHNwYW4gc3R5 bGU9IkZPTlQtU0laRTogOXB0OyBMRVRURVItU1BBQ0lORzogMC41cHQiPjwvc3Bhbj4mbmJzcDs8 L2Rpdj4KPGRpdj48YnI+PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9x dW90ZSI+T24gMTEvMTAvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5HZW9mZiBNdWxs aWdhbjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpnZW9mZi1pZXRmQG11bGxpZ2FuLm9yZyI+Z2Vv ZmYtaWV0ZkBtdWxsaWdhbi5vcmc8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAw cHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPkZvbGtzLDxicj5FdmVu IHRob3VnaCB3ZSBkbyBub3QgaGF2ZSBhbiBhcHByb3ZlZCByZWNoYXJ0ZXIgdGV4dCB3ZSBoYXZl IGEgV0c8YnI+bWVldGluZyBzbG90IGF0IHRoZSBuZXh0IElFVEYgYW5kIHdlIG5lZWQgdG8gc2V0 IHRoZSBhZ2VuZGEuCjxicj48YnI+Jmd0O0Zyb20gdGhlIGxhc3QgSUVURiBtZWV0aW5nIEkgdGhp bmsgdGhhdCB3ZSByZWFjaGVkIGNvbnNlbnN1cyBvbiB0aGUgd29yazxicj5pdGVtcyBmb3IgdGhl IGdyb3VwOjxicj48YnI+MS4gQm9vdHN0cmFwcGluZyAvIE5laWdoYm9yIERpc2NvdmVyeTxicj4y LiBTdGF0ZWZ1bCBIZWFkZXIgQ29tcHJlc3Npb248YnI+My4gQXJjaGl0ZWN0dXJlPGJyPjQuIEFw cGxpY2F0aW9ucwo8YnI+NS4gU2VjdXJpdHkgQW5hbHlzaXM8YnI+PGJyPldlIGRlY2lkZWQgdGhh dCB3ZSB3b3VsZCBob2xkIG9mZiBvbiBNZXNoIFVuZGVyIChMYXllciAyIHJvdXRpbmcpIGF0PGJy PnRoaXMgdGltZSB1bnRpbCB0aGUgcGF0aCBiZWNvbWVzIG1vcmUgY2xlYXIgd2l0aCByZXNwZWN0 IHRvIHRoZSBSTDJOPGJyPnByb3Bvc2FsLjxicj48YnI+VGhpcyBncm91cCBoYXMgZ2VuZXJhdGVk IGEgbnVtYmVyIG9mIEktRHMsIHRob3VnaCBtYW55IGFyZSBub3cgZXhwaXJlZC4KPGJyPlNvbWUg b2YgdGhlIGFjdGl2ZSBhbmQgZXhwaXJlZCBJLURzIHNlZW0gY2xvc2VseSByZWxhdGVkIHRvIHRo ZSB3b3JrPGJyPml0ZW1zIGFib3ZlLjxicj48YnI+SSBoYXZlIGluY2x1ZGVkIGluIHRoaXMgbWVz c2FnZSBhIGxpc3Qgb2YgYm90aCB0aGUgQWN0aXZlIGFuZCBFeHBpcmVkPGJyPkktRHMgdGhhdCBo YXZlIGJlZW4gc3VibWl0dGVkIGFuZCB0aGVpciBhYnN0cmFjdHMgc28gdGhhdCB5b3UgZG9uJiMz OTt0IGhhdmUKPGJyPnRvIHNlYXJjaCBmb3IgdGhlIEktRCBpbmZvcm1hdGlvbi48YnI+PGJyPlRh a2luZyBpbnRvIGFjY291bnQgdGhlIGFib3ZlIHdvcmsgaXRlbXMsIGlmIGFueSBvZiB0aGUgYXV0 aG9ycyBhcmU8YnI+aW50ZXJlc3RlZCBpbiBwcmVzZW50aW5nIHRoZWlyIGRyYWZ0cyBhdCB0aGlz IG5leHQgSUVURiwgcGxlYXNlIGxldDxicj5DYXJzdGVuIG9yIEkga25vdyBzb29uLjxicj48YnI+ SSBkbyBob3BlIHRoYXQgd2Ugd2lsbCBkdXN0IG9mZiB0aGUgTkQgYW5kIHNlY3VyaXR5IGFuYWx5 c2lzIGRyYWZ0cy4KPGJyPjxicj5JZiBhbnlvbmUgZWxzZSBpcyBwbGFubmluZyBvbiBzdWJtaXR0 aW5nIGEgZHJhZnQsIHBsZWFzZSBsZXQgdXMga25vdzxicj5zb29uIGFuZCBhbHNvIGdldCBpdCBz dWJtaXR0ZWQgLSB0aGUgZGVhZGxpbmUgaXMgdGhlIDEydGguPGJyPjxicj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZ2VvZmY8YnI+PGJyPjxicj49PT09PT09PT09PT09PSBB Y3RpdmUgRHJhZnRzID09PT09PT09PT09PT09PTxicj4tLS0gZHJhZnQtZGFuaWVsLTZsb3dwYW4t Y29tbWlzc2lvbmluZy0wMAo8YnI+VGhlIGNvbW1pc2lvbmluZyBwcm9jZXNzIGRlZmluZXMgdGhl IHN0YXJ0dXAgcHJvY2VkdXJlIHRha2VuIGJ5IHRoZTxicj42TG9XUEFOIGRldmljZS4gVGhpcyBk b2N1bWVudCBkZWZpbmVzIHRoZSBzdGFydHVwIHByb2NlZHVyZSB0aGF0IGFsbDxicj5raW5kcyBv ZiBkZXZpY2VzIG11c3QgdGFrZSB0byBiZWNvbWUgcGFydCBvZiB0aGUgbmV0d29yay48YnI+PGJy Pi0tLSBkcmFmdC1kYW5pZWwtNmxvd3Bhbi1oaWxvdy1oaWVyYXJjaGljYWwtcm91dGluZy0wMQo8 YnI+VGhlIEVVSS02NCBpZGVudGlmaWVyIG9mIGEgNkxvV1BBTiBkZXZpY2UgY2FuIGJlIHVzZWQg YXMgdGhlIGludGVyZmFjZTxicj5pZGVudGlmaWVyIG9mIHRoZSBJUHY2IGFkZHJlc3MsIHdoaWNo IGNhbiBiZSB1c2VkIGZvciBmb3Igb24tZGVtYW5kPGJyPm11bHRpLWhvcCByb3V0aW5nIGluIDZM b1dQQU4uIE9uZSBvZiB0aGUgZGlzdGluY3RpdmUgZmVhdHVyZSBvZiA2TG9XUEFOPGJyPgppcyB0 aGUgY2FwYWJpbGl0eSBvZiB0aGUgZHluYW1pYyBhc3NpZ25tZW50IG9mIDE2LSBiaXQgc2hvcnQg YWRkcmVzc2VzLjxicj5CeSB1dGlsaXppbmcgdGhpcyBkeW5hbWljYWxseSBhc3NpZ25lZCBzaG9y dCBhZGRyZXNzLCBhIGhpZXJhcmNoaWNhbDxicj5yb3V0aW5nIHdoaWNoIGlzIHZlcnkgc2NhbGFi bGUgY2FuIGJlIGVtcGxveWVkLiBUaGlzIFRoaXMgZG9jdW1lbnQ8YnI+ZGVmaW5lcyBhIGR5bmFt aWMgYWRkcmVzcyBhc3NpZ25tZW50IHNjaGVtZSBhbmQgaGllcmFyY2hpY2FsIHJvdXRpbmcKPGJy PkhpTG93KSBiYXNlZCBvbiB0aGUgYXNzaWdubWVudC48YnI+PGJyPi0tLSBkcmFmdC1kYW5pZWwt Nmxvd3Bhbi1sb2FkLWFkaG9jLXJvdXRpbmctMDM8YnI+NkxvV1BBTiBBZCBIb2MgT24tRGVtYW5k IERpc3RhbmNlIFZlY3RvciBSb3V0aW5nIChMT0FEKSBpcyBpbnRlbmRlZCBmb3I8YnI+dXNlIGJ5 IElFRUUgODAyLjE1LjQgZGV2aWNlcyBpbiBhIDZMb1dQQU4uIEl0IGlzIGEgc2ltcGxpZmllZCBv bi1kZW1hbmQKPGJyPnJvdXRpbmcgcHJvdG9jb2wgYmFzZWQgb24gQU9EVi48YnI+PGJyPi0tLSBk cmFmdC1kYW5pZWwtNmxvd3Bhbi1zc2xwLTAxPGJyPlRoZSBTaW1wbGUgU2VydmljZSBMb2NhdGlv biBQcm90b2NvbCAoU1NMUCkgcHJvdmlkZXMgYSBmcmFtZXdvcmsgZm9yIHRoZTxicj5kaXNjb3Zl cnkgYW5kIHNlbGVjdGlvbiBvZiB0aGUgc2VydmljZXMgd29ya2luZyBvbiA2TG9XUEFOLiBUaGUg cHJvdG9jb2wKPGJyPmhhcyBhIHNpbXBsZSBzdHJ1Y3R1cmUgdGhhdCBpcyBlYXN5IHRvIGJlIGlt cGxlbWVudGVkIG9uIDZMb1dQQU4gZGV2aWNlczxicj50aGF0IGFyZSBjaGFyYWN0ZXJpemVkIGJ5 IHNob3J0IHJhbmdlLCBsb3cgYml0IHJhdGUgYW5kIGxvdyBwb3dlci4gVGhlPGJyPnByb3RvY29s IGFsc28gb2ZmZXJzIGEgbWVjaGFuaXNtIGZvciBpbnRlcm9wZXJhYmlsaXR5IHdpdGggdGhlIElQ PGJyPgpuZXR3b3JrcyB1bmRlciBTTFAuIEl0IGVuYWJsZXMgY29tbXVuaWNhdGlvbiBiZXR3ZWVu IDZMb1dQQU4gYW5kIG90aGVyPGJyPklQIG5ldHdvcmtzLjxicj48YnI+LS0tIGRyYWZ0LWRva2Fz cGFyLTZsb3dwYW4tcm91dHJlcS0wMjxicj5UaGlzIGRvY3VtZW50IHByb3ZpZGVzIHRoZSBwcm9i bGVtIHN0YXRlbWVudCBmb3IgbWVzaCByb3V0aW5nIGJlbG93IHRoZTxicj5JUCBsYXllciAoaW4g NkxvV1BBTiYjMzk7cyBhZGFwdGF0aW9uIGxheWVyKS4gSXQgYWxzbyBkZWZpbmVzIG1ham9yIGRl c2lnbgo8YnI+Z29hbHMgYW5kIHJlcXVpcmVtZW50cyBmb3IgNkxvV1BBTiBtZXNoIHJvdXRpbmcg Y29uc2lkZXJpbmcgdGhlPGJyPmxvdy1wb3dlciBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIG5ldHdv cmsgYW5kIGl0cyBkZXZpY2VzLjxicj48YnI+LS0tIGRyYWZ0LWVraW0tNmxvd3Bhbi1zY2VuYXJp b3MtMDA8YnI+VGhpcyBkb2N1bWVudCBpbnZlc3RpZ2F0ZXMgcG90ZW50aWFsIGFwcGxpY2F0aW9u IHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzCjxicj5mb3IgbG93LXBvd2VyIHdpcmVsZXNzIHBlcnNv bmFsIGFyZWEgbmV0d29ya3MgKExvV1BBTnMpLjxicj48YnI+LS0tIGRyYWZ0LWh1aS02bG93cGFu LWhjMWctMDA8YnI+VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzdGF0ZWxlc3MgSVAgaGVhZGVy IGNvbXByZXNzaW9uIHNjaGVtZSBmb3I8YnI+SVB2NiBwYWNrZXQgZGVsaXZlcnkgaW4gNkxvV1BB TiBzdWJuZXR3b3Jrcy4gVGhlIGNvbXByZXNzaW9uIHNjaGVtZQo8YnI+Zm9jdXNlcyBvbiBMb1dQ QU4gbm9kZXMgdGhhdCBtYXkgaGF2ZSBnbG9iYWwgdW5pY2FzdCBhZGRyZXNzZXMgYXNzaWduZWQ8 YnI+dG8gdGhlaXIgaW50ZXJmYWNlcy48YnI+PGJyPi0tLSBkcmFmdC1odWktNmxvd3Bhbi1pbnRl cm9wLTAwPGJyPlRoaXMgbWVtbyBkZWZpbmVzIGEgZmlyc3Qgc3RlcCBpbiB0ZXN0aW5nIGFuZCBk ZW1vbnN0cmF0aW5nIHRoZTxicj5pbnRlcm9wZXJhYmlsaXR5IG9mIGluZGVwZW5kZW50IDZMb1dQ QU4gaW1wbGVtZW50YXRpb25zLgo8YnI+PGJyPi0tLSBkcmFmdC1tb250ZW5lZ3JvLTZsb3dwYW4t ZHltby1sb3ctcm91dGluZy0wMzxicj5UaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdG8gdXNl IHRoZSBEeW5hbWljIE1BTkVUIE9uLWRlbWFuZCBSb3V0aW5nPGJyPlByb3RvY29sIG92ZXIgSUVF RTgwMi4xNS40IG5ldHdvcmtzLjxicj48YnI+LS0tIGRyYWZ0LW9oLTZsb3dwYW4tcGFja2V0YmIt ZHltb2FwcC0wMTxicj4KVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGFwcGxpY2FiaWxpdHkg b2YgdGhlIGdlbmVyYWxpemVkIE1BTkVUPGJyPnBhY2tldC9tZXNzYWdlIGZvcm1hdCAocGFja2V0 YmIpIGFuZCB0aGUgZHluYW1pYyBNQU5FVCBvbi1kZW1hbmQgKERZTU8pPGJyPnJvdXRpbmcgcHJv dG9jb2wgb3ZlciA2TG9XUEFOLiBJbiBvcmRlciB0byBhY2hpZXZlIGxvdyBtZW1vcnkgdXNhZ2Ug YW5kPGJyPmxvdyBwcm9jZXNzaW5nIG92ZXJoZWFkLCB0aGlzIGRvY3VtZW50IHN1Z2dlc3RzIHdo YXQgaXMgdG8gYmUgbW9kaWZpZWQKPGJyPmZyb20gdGhlIE1BTkVUIGJhc2Ugc3BlY2lmaWNhdGlv bnMuPGJyPjxicj4tLS0gZHJhZnQtc2hpbi02bG93cGFuLW1vYmlsaXR5LTAwPGJyPlRoaXMgZHJh ZnQgbGlzdHMgbW9iaWxpdHkgc2NlbmFyaW9zIGFuZCBzdWdnZXN0cyBzb2x1dGlvbnMgb2YgaG93 IHRvPGJyPnByb3ZpZGUgbW9iaWxpdHkgc3VwcG9ydCBpbiBJUHY2IGxvdy1wb3dlciBwZXJzb25h bCBhcmVhIG5ldHdvcmtzCjxicj4oNkxvV1BBTnMpLjxicj48YnI+LS0tIGRyYWZ0LXRodWJlcnQt bG93cGFuLWJhY2tib25lLXJvdXRlci0wMDxicj5JU0ExMDAuMTFhIGlzIGEgV29ya2luZyBHcm91 cCBhdCB0aGUgSVNBIFNQMTAwIHN0YW5kYXJkIGNvbW1pdHRlZSB0aGF0PGJyPmNvdmVycyBXaXJl bGVzcyBTeXN0ZW1zIGZvciBJbmR1c3RyaWFsIEF1dG9tYXRpb24gYW5kIFByb2Nlc3MgQ29udHJv bC48YnI+VGhlIFdHIGlzIG1hbmRhdGVkIHRvIGRlc2lnbiBhIHNjYWxhYmxlLCBpbmR1c3RyaWFs IGdyYWRlIExvd1BBTiBmb3IKPGJyPmRldmljZXMgc3VjaCBhcyBzZW5zb3JzLCB2YWx2ZXMsIGFu ZCBhY3R1YXRvcnMuIFRoZSB1cGNvbWluZyBzdGFuZGFyZDxicj51c2VzIHRoZSA2TG9XUEFOIGZv cm1hdCBmb3IgdGhlIG5ldHdvcmsgaGVhZGVyLiBJdCBhbHNvIGludHJvZHVjZXMgdGhlPGJyPmNv bmNlcHQgb2YgYSBCYWNrYm9uZSBSb3V0ZXIgdG8gbWVyZ2Ugc21hbGwgTG9XUEFOcyB2aWEgYSBo aWdoIHNwZWVkPGJyPgp0cmFuc2l0IGFuZCBzY2FsZSB0aGUgSVNBMTAwLjExYSBuZXR3b3JrLiBU aGlzIHBhcGVyIHByb3Bvc2VzIGFuIElQdjY8YnI+dmVyc2lvbiBvZiB0aGUgQmFja2JvbmUgUm91 dGVyIGNvbmNlcHQuPGJyPjxicj49PT09PT09PT09PT09PT0gRXhwaXJlZCBEcmFmdHMgPT09PT09 PT09PT09PT09PGJyPi0tLSBkcmFmdC1jaGFrcmFiYXJ0aS02bG93cGFuLWlwdjYtbmQtMDM8YnI+ SUVURiA2TG93UGFuIHdvcmtpbmcgZ3JvdXAgZGVmaW5lcyBJUHY2IG92ZXIgbG93LXBvd2VyIHBl cnNvbmFsIGFyZWEKPGJyPm5ldHdvcmsgKElFRUUgODAyLjE1LjQpLiBJRUVFIDgwMi4xNS40IGxp bmsgbGF5ZXIgZG9lcyBub3QgaGF2ZTxicj5tdWx0aWNhc3Qgc3VwcG9ydCwgYWx0aG91Z2ggaXQg c3VwcG9ydHMgYnJvYWRjYXN0LiBEdWUgdG8gdGhlIG5hdHVyZSBvZjxicj5Mb3dQYW4gbmV0d29y ayBvciBzZW5zb3IgbmV0d29ya3MsIGJyb2FkY2FzdCBtZXNzYWdlcyBzaG91bGQgYmU8YnI+bWlu aW1pemVkLiBUaGlzIGRvY3VtZW50IHN1Z2dlc3RzIHNvbWUgb3B0aW1pemF0aW9ucyB0byBJUHY2 IE5laWdoYm9yCjxicj5EaXNjb3ZlcnkgcmVsYXRlZCBtdWx0aWNhc3QgbWVzc2FnZXMgaW4gb3Jk ZXIgdG8gcmVkdWNlIHNpZ25hbGluZyBpbiB0aGU8YnI+bG93LWNvc3QgbG93LXBvd2VyZWQgbmV0 d29yay48YnI+PGJyPi0tLSBkcmFmdC1jaGFrcmFiYXJ0aS1tb2JvcHRzLWxvd3Bhbi1yZXEtMDE8 YnI+SUVURiBMb3dQYW4gd29ya2luZyBncm91cCBkZWZpbmVzIElQdjYgb3ZlciBsb3ctcG93ZXIg cGVyc29uYWwgYXJlYQo8YnI+bmV0d29yayAoSUVFRSA4MDIuMTUuNCkuIExvd3BhbiBhcmNoaXRl Y3R1cmUgYWxsb3dzIHJvdXRpbmcgdG8gdGFrZTxicj5wbGFjZSBhdCB0aGUgbGluayBsYXllciBp biBvcmRlciB0byBzYXZlIHBheWxvYWQgb3ZlcmhlYWQgb3ZlciB0aGUgSUVFRTxicj44MDIuMTUu NCBsaW5rIGFuZCB0aHVzIG1vcmUgZWZmaWNpZW50IHJvdXRpbmcgZm9yIGxvdyBwb3dlciwgbG93 PGJyPmRhdGEtcmF0ZSBuZXR3b3JrcyBzdWNoIGFzIHNlbnNvciBuZXR3b3Jrcy4gVGhpcyBkb2N1 bWVudCBkaXNjdXNzZXMgYQo8YnI+ZmV3IHNjZW5hcmlvcyBvZiBtb2JpbGl0eSBpbiBMb3dQYW4g bmV0d29yayBhbmQgc3RhdGVzIG1vYmlsaXR5PGJyPnJlcXVpcmVtZW50cyBhbmQgZ29hbHMgZm9y IExvd1BhbiBuZXR3b3Jrcy48YnI+PGJyPi0tLSBkcmFmdC1kYW5pZWwtNmxvd3Bhbi1pbnRlcm9w ZXJhYmlsaXR5LTAxPGJyPlRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBnYXRld2F5IGFyY2hp dGVjdHVyZSBmb3IgdGhlCjxicj5pbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gNkxvV1BBTiBhbmQg ZXh0ZXJuYWwgSVB2NiBuZXR3b3Jrcy4gVGhlIGdhdGV3YXk8YnI+ZG9lcyB0aGUgY29tcHJlc3Np b24gYW5kIGRlY29tcHJlc3Npb24gb2YgSVB2NiBwYWNrZXRzIGFuZCBwZXJmb3JtcyB0aGU8YnI+ bWFwcGluZyBiZXR3ZWVuIDE2IGJpdCBzaG9ydCBhZGRyZXNzZXMgYW5kIHRoZSBJUHY2IGFkZHJl c3NlcyBmb3IgYm90aAo8YnI+dGhlIGV4dGVybmFsIElQdjYgbmV0d29ya3MgYW5kIDZMb3dQQU4s IHJlc3BlY3RpdmVseS48YnI+PGJyPi0tLSBkcmFmdC1kYW5pZWwtNmxvd3Bhbi1zZWN1cml0eS1h bmFseXNpcy0wMTxicj5UaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBwb3NzaWJsZSB0aHJlYXRzIGFu ZCBzZWN1cml0eSBvcHRpb25zIGZvcjxicj5JUHY2LW92ZXItSUVFRTgwMi4xNS40IG5ldHdvcmtz LiBJdCBpcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50IHRvCjxicj5yYWlzZSBhd2FyZW5lc3Mg b2Ygc2VjdXJpdHkgaXNzdWVzIGluIElQdjYgbG93UGFuIG5ldHdvcmtzLjxicj48YnI+LS0tIGRy YWZ0LWd1aGEtbG93cGFuLW1vYmlsaXR5LXByb3RvY29sLXJlcS0wMDxicj5JbiB0aGlzIGRyYWZ0 LCB3ZSBwcm9wb3NlIHNvbWUgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIGZvciBtb2JpbGl0eSBpbjxi cj5Mb3dQQU4gbmV0d29ya3Mgd2l0aGluIHRoZSBjb250ZXh0IG9mIHRoZSBJRVRGIExvd1BBTiB3 b3JraW5nIGdyb3VwCjxicj4oSVB2NiBvdmVyIElFRUUgODAyLjE1LjQpLiBUbyBhY2hpZXZlIG1v YmlsaXR5IGluIExvd1BBTiBuZXR3b3JrcywgdGhlcmU8YnI+bWF5IGJlIGludGVyLWRvbWFpbiBt b3ZlbWVudCBvZiBuZXR3b3JrIGVsZW1lbnRzIGFjcm9zcyBkaWZmZXJlbnQgTG93UEFOPGJyPmRv bWFpbnMgb3IgYWNyb3NzIGRvbWFpbnMgdGhhdCBkbyBub3QgY29tcHJpc2UgTG93UEFOIGF1dG9u b21vdXM8YnI+CnN5c3RlbXMuIFRvIGFkZHJlc3Mgcm91dGluZyBpc3N1ZXMgaW4gaW50ZXItZG9t YWluIExvd1BBTiBuZXR3b3JrcyB0aGF0PGJyPmNvbmZvcm0gdG8gZml0dGluZyB3aXRoaW4gYSBz aW5nbGUgSUVFRSA4MDIuMTUuNCBmcmFtZSwgdGhlcmUgYXJlIG5lZWRzPGJyPmZvciBjb2xsYWJv cmF0aXZlIGFuZCBkaXN0cmlidXRlZCBtZXRob2RvbG9naWVzIGZvciByb3V0ZSBjb21wdXRhdGlv biw8YnI+CmluZm9ybWF0aW9uIHN0b3JhZ2UgYW5kIHJldHJpZXZhbCwgYW5kIHNlY3VyaXR5IGlz c3VlcyBpbiBwcm90b2NvbHM8YnI+dGFyZ2V0ZWQgdG8gTG93UEFOIG1vYmlsaXR5LiBUaGlzIGRy YWZ0IHByb3Bvc2VzIHNvbWUgcmVxdWlyZW1lbnRzIG9mPGJyPm1vYmlsaXR5IGluIExvd1BBTiBw cm90b2NvbHMgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Y8YnI+cHJvdG9jb2wtaW5kZXBlbmRlbnQg bWV0cmljcywgYWxnb3JpdGhtIGNvbXBsZXhpdGllcywgc2NhbGFiaWxpdHkgYW5kCjxicj5zZWN1 cml0eSBjcml0ZXJpYS48YnI+PGJyPi0tLSBkcmFmdC1tb250ZW5lZ3JvLWxvd3Bhbi1hb2R2LTAw PGJyPlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byB1c2UgdGhlIEFkIEhvYyBPbi1EZW1h bmQgVmVjdG9yIFByb3RvY29sPGJyPihBT0RWKSBpbiBJRUVFIDgwMi4xNS40IG5ldHdvcmtzLjxi cj48YnI+LS0tIGRyYWZ0LXNhcmlrYXlhLTZsb3dwYW4tZm9yd2FyZGluZy0wMAo8YnI+VGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBzaW1wbGUgYXBwcm9hY2ggdG8gaW50ZXJjb25uZWN0IElFRUUg ODAyLjE1LjQ8YnI+c2Vuc29yIG5vZGVzIHRvIElQdjYgSW50ZXJuZXQuIFRoZSB0ZWNobmlxdWUg cmVxdWlyZXMgYSBnYXRld2F5IG5vZGU8YnI+dGhhdCBpcyBjb25uZWN0ZWQgdG8gYm90aCB0aGUg c2Vuc29yIG5ldHdvcmsgYW5kIHRoZSBJUHY2IEludGVybmV0LiBUaGUKPGJyPmdhdGV3YXkgbm9k ZSBydW5zIHRoZSBzZXJpYWwgZm9yd2FyZGVyIG92ZXIgSVB2Ni4gU2Vuc29yIG5vZGVzIHJ1biB0 aGU8YnI+b3Blbi1zb3VyY2UgVGlueU9TIG9wZXJhdGluZyBzeXN0ZW0gYW5kIGdlbmVyYXRlIFRp bnlPUyBwYWNrZXRzLiBUaGU8YnI+c2Vuc29yIG5ldHdvcmsgY2FuIGJlIGFjY2Vzc2VkIGZyb20g SVB2NiBJbnRlcm5ldCB1c2luZyBhIFdlYiBpbnRlcmZhY2UKPGJyPmFuZCB0aGUgc2VyaWFsIGZv cndhcmRlciB0aGF0IHJ1bnMgaW4gdGhlIGFwcGxldHMgZW5hYmxlczxicj5yZWNlcHRpb24vdHJh bnNtaXNzaW9uIG9mIFRpbnlPUyBwYWNrZXRzIG92ZXIgSVB2Ni48YnI+PGJyPjxicj48YnI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Nmxvd3BhbiBt YWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOjZsb3dwYW5AaWV0Zi5vcmciPgo2bG93cGFu QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby82bG93cGFuIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby82 bG93cGFuPC9hPjxicj48YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+ PGJyPi0tIDxicj5LaS1IeXVuZyBLaW0gKLHoseLH/Cwg0N3Rw/r7KTxicj5Bc3NvY2lhdGUgUHJv ZmVzc29yCjxicj5EaXZpc2lvbiBvZiBJbmZvcm1hdGlvbiBhbmQgQ29tcHV0ZXIgRW5nLiwgQWpv dSBVbml2ZXJzaXR5LCBTdXdvbiwgS29yZWEgNDQyLTc0OTxicj5UZWw6ICs4Mi0zMS0yMTktMjQz MywgQ2VsOiArODItMTAtNDc2MC0yNTUxLCZuYnNwOyZuYnNwO0ZheDogKzgyLTMxLTIxOS0yNDMz IDxhIGhyZWY9Imh0dHA6Ly93d3cuNmxvd3Bhbi5vcmciPmh0dHA6Ly93d3cuNmxvd3Bhbi5vcmc8 L2E+IAo= ------=_Part_11134_27707592.1196343652770-- --===============2027352748== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============2027352748==-- From 6lowpan-bounces@ietf.org Thu Nov 29 08:42:33 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixjez-0002MJ-Bu; Thu, 29 Nov 2007 08:42:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixjex-0002L2-Qg for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 08:42:31 -0500 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixjew-0001RE-02 for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 08:42:31 -0500 Received: by py-out-1112.google.com with SMTP id u77so3561887pyb for <6lowpan@lists.ietf.org>; Thu, 29 Nov 2007 05:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=BDk6MHVolOFCVC66MGu/YIfNPauMStt4Og5xSMtLSwg=; b=UKER2SDNu3J3SXozYxxSiLTyyAsJ6Ovpx/jmfeA6Xf1/2Ld28XGlTWyf4QJseKk8g/ZH+K+Pj8pStze4Y9MExX72an4eyMLvzg8voMVeiIwaI07FYhYYrBOgxa1BTSvtJ+cdbo6lnAH3HIA3QvN/5808CUaR81cE8Qm/fbkfn6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YPdZIB9N5mf7c935hEuA6zwO9dmZLJvVP5z9L55bFaLnwr8biseUQJeZL3F0GVwEQsTWqy5U7l0BY0VOEi+r6jUKJRLKMHN9SXNo2RS9Lc32wpqBx9WmVnImwAdLUTS+98VxbHybFKvhimWjyct6Uqh3CRYQPKqo4Yx2p6qrUTI= Received: by 10.35.78.13 with SMTP id f13mr890509pyl.1196343749523; Thu, 29 Nov 2007 05:42:29 -0800 (PST) Received: by 10.35.124.6 with HTTP; Thu, 29 Nov 2007 05:42:29 -0800 (PST) Message-ID: Date: Thu, 29 Nov 2007 22:42:29 +0900 From: "Ki-Hyung Kim" To: "Geoff Mulligan" , "Carsten Bormann" Subject: Re: [6lowpan] working group drafts and agenda for next IETF In-Reply-To: <1194656137.5777.131.camel@dellx1> MIME-Version: 1.0 References: <1194656137.5777.131.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0881019386==" Errors-To: 6lowpan-bounces@ietf.org --===============0881019386== Content-Type: multipart/alternative; boundary="----=_Part_11139_24953962.1196343749514" ------=_Part_11139_24953962.1196343749514 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline R2VvZmYgYW5kIENhcnN0ZW4sCkNhbiBJIGFzayBhIHRpbWUgc2xvdCBpbiB0aGUgbmV4dCBJRVRG IG1lZXRpbmcgb24gcHJlc2VudGluZyB0aGUKY29tbWlzc2lvbmluZyBhbmQgYm9vdHN0cmFwcGlu ZyBpc3N1ZXMgaW4gNmxvd3Bhbj8KCgpPbiAxMS8xMC8wNywgR2VvZmYgTXVsbGlnYW4gPGdlb2Zm LWlldGZAbXVsbGlnYW4ub3JnPiB3cm90ZToKPgo+IEZvbGtzLAo+IEV2ZW4gdGhvdWdoIHdlIGRv IG5vdCBoYXZlIGFuIGFwcHJvdmVkIHJlY2hhcnRlciB0ZXh0IHdlIGhhdmUgYSBXRwo+IG1lZXRp bmcgc2xvdCBhdCB0aGUgbmV4dCBJRVRGIGFuZCB3ZSBuZWVkIHRvIHNldCB0aGUgYWdlbmRhLgo+ Cj4gPkZyb20gdGhlIGxhc3QgSUVURiBtZWV0aW5nIEkgdGhpbmsgdGhhdCB3ZSByZWFjaGVkIGNv bnNlbnN1cyBvbiB0aGUgd29yawo+IGl0ZW1zIGZvciB0aGUgZ3JvdXA6Cj4KPiAxLiBCb290c3Ry YXBwaW5nIC8gTmVpZ2hib3IgRGlzY292ZXJ5Cj4gMi4gU3RhdGVmdWwgSGVhZGVyIENvbXByZXNz aW9uCj4gMy4gQXJjaGl0ZWN0dXJlCj4gNC4gQXBwbGljYXRpb25zCj4gNS4gU2VjdXJpdHkgQW5h bHlzaXMKPgo+IFdlIGRlY2lkZWQgdGhhdCB3ZSB3b3VsZCBob2xkIG9mZiBvbiBNZXNoIFVuZGVy IChMYXllciAyIHJvdXRpbmcpIGF0Cj4gdGhpcyB0aW1lIHVudGlsIHRoZSBwYXRoIGJlY29tZXMg bW9yZSBjbGVhciB3aXRoIHJlc3BlY3QgdG8gdGhlIFJMMk4KPiBwcm9wb3NhbC4KPgo+IFRoaXMg Z3JvdXAgaGFzIGdlbmVyYXRlZCBhIG51bWJlciBvZiBJLURzLCB0aG91Z2ggbWFueSBhcmUgbm93 IGV4cGlyZWQuCj4gU29tZSBvZiB0aGUgYWN0aXZlIGFuZCBleHBpcmVkIEktRHMgc2VlbSBjbG9z ZWx5IHJlbGF0ZWQgdG8gdGhlIHdvcmsKPiBpdGVtcyBhYm92ZS4KPgo+IEkgaGF2ZSBpbmNsdWRl ZCBpbiB0aGlzIG1lc3NhZ2UgYSBsaXN0IG9mIGJvdGggdGhlIEFjdGl2ZSBhbmQgRXhwaXJlZAo+ IEktRHMgdGhhdCBoYXZlIGJlZW4gc3VibWl0dGVkIGFuZCB0aGVpciBhYnN0cmFjdHMgc28gdGhh dCB5b3UgZG9uJ3QgaGF2ZQo+IHRvIHNlYXJjaCBmb3IgdGhlIEktRCBpbmZvcm1hdGlvbi4KPgo+ IFRha2luZyBpbnRvIGFjY291bnQgdGhlIGFib3ZlIHdvcmsgaXRlbXMsIGlmIGFueSBvZiB0aGUg YXV0aG9ycyBhcmUKPiBpbnRlcmVzdGVkIGluIHByZXNlbnRpbmcgdGhlaXIgZHJhZnRzIGF0IHRo aXMgbmV4dCBJRVRGLCBwbGVhc2UgbGV0Cj4gQ2Fyc3RlbiBvciBJIGtub3cgc29vbi4KPgo+IEkg ZG8gaG9wZSB0aGF0IHdlIHdpbGwgZHVzdCBvZmYgdGhlIE5EIGFuZCBzZWN1cml0eSBhbmFseXNp cyBkcmFmdHMuCj4KPiBJZiBhbnlvbmUgZWxzZSBpcyBwbGFubmluZyBvbiBzdWJtaXR0aW5nIGEg ZHJhZnQsIHBsZWFzZSBsZXQgdXMga25vdwo+IHNvb24gYW5kIGFsc28gZ2V0IGl0IHN1Ym1pdHRl ZCAtIHRoZSBkZWFkbGluZSBpcyB0aGUgMTJ0aC4KPgo+ICAgICAgICBnZW9mZgo+Cj4KPiA9PT09 PT09PT09PT09PSBBY3RpdmUgRHJhZnRzID09PT09PT09PT09PT09PQo+IC0tLSBkcmFmdC1kYW5p ZWwtNmxvd3Bhbi1jb21taXNzaW9uaW5nLTAwCj4gVGhlIGNvbW1pc2lvbmluZyBwcm9jZXNzIGRl ZmluZXMgdGhlIHN0YXJ0dXAgcHJvY2VkdXJlIHRha2VuIGJ5IHRoZQo+IDZMb1dQQU4gZGV2aWNl LiBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIHN0YXJ0dXAgcHJvY2VkdXJlIHRoYXQgYWxsCj4g a2luZHMgb2YgZGV2aWNlcyBtdXN0IHRha2UgdG8gYmVjb21lIHBhcnQgb2YgdGhlIG5ldHdvcmsu Cj4KPiAtLS0gZHJhZnQtZGFuaWVsLTZsb3dwYW4taGlsb3ctaGllcmFyY2hpY2FsLXJvdXRpbmct MDEKPiBUaGUgRVVJLTY0IGlkZW50aWZpZXIgb2YgYSA2TG9XUEFOIGRldmljZSBjYW4gYmUgdXNl ZCBhcyB0aGUgaW50ZXJmYWNlCj4gaWRlbnRpZmllciBvZiB0aGUgSVB2NiBhZGRyZXNzLCB3aGlj aCBjYW4gYmUgdXNlZCBmb3IgZm9yIG9uLWRlbWFuZAo+IG11bHRpLWhvcCByb3V0aW5nIGluIDZM b1dQQU4uIE9uZSBvZiB0aGUgZGlzdGluY3RpdmUgZmVhdHVyZSBvZiA2TG9XUEFOCj4gaXMgdGhl IGNhcGFiaWxpdHkgb2YgdGhlIGR5bmFtaWMgYXNzaWdubWVudCBvZiAxNi0gYml0IHNob3J0IGFk ZHJlc3Nlcy4KPiBCeSB1dGlsaXppbmcgdGhpcyBkeW5hbWljYWxseSBhc3NpZ25lZCBzaG9ydCBh ZGRyZXNzLCBhIGhpZXJhcmNoaWNhbAo+IHJvdXRpbmcgd2hpY2ggaXMgdmVyeSBzY2FsYWJsZSBj YW4gYmUgZW1wbG95ZWQuIFRoaXMgVGhpcyBkb2N1bWVudAo+IGRlZmluZXMgYSBkeW5hbWljIGFk ZHJlc3MgYXNzaWdubWVudCBzY2hlbWUgYW5kIGhpZXJhcmNoaWNhbCByb3V0aW5nCj4gSGlMb3cp IGJhc2VkIG9uIHRoZSBhc3NpZ25tZW50Lgo+Cj4gLS0tIGRyYWZ0LWRhbmllbC02bG93cGFuLWxv YWQtYWRob2Mtcm91dGluZy0wMwo+IDZMb1dQQU4gQWQgSG9jIE9uLURlbWFuZCBEaXN0YW5jZSBW ZWN0b3IgUm91dGluZyAoTE9BRCkgaXMgaW50ZW5kZWQgZm9yCj4gdXNlIGJ5IElFRUUgODAyLjE1 LjQgZGV2aWNlcyBpbiBhIDZMb1dQQU4uIEl0IGlzIGEgc2ltcGxpZmllZCBvbi1kZW1hbmQKPiBy b3V0aW5nIHByb3RvY29sIGJhc2VkIG9uIEFPRFYuCj4KPiAtLS0gZHJhZnQtZGFuaWVsLTZsb3dw YW4tc3NscC0wMQo+IFRoZSBTaW1wbGUgU2VydmljZSBMb2NhdGlvbiBQcm90b2NvbCAoU1NMUCkg cHJvdmlkZXMgYSBmcmFtZXdvcmsgZm9yIHRoZQo+IGRpc2NvdmVyeSBhbmQgc2VsZWN0aW9uIG9m IHRoZSBzZXJ2aWNlcyB3b3JraW5nIG9uIDZMb1dQQU4uIFRoZSBwcm90b2NvbAo+IGhhcyBhIHNp bXBsZSBzdHJ1Y3R1cmUgdGhhdCBpcyBlYXN5IHRvIGJlIGltcGxlbWVudGVkIG9uIDZMb1dQQU4g ZGV2aWNlcwo+IHRoYXQgYXJlIGNoYXJhY3Rlcml6ZWQgYnkgc2hvcnQgcmFuZ2UsIGxvdyBiaXQg cmF0ZSBhbmQgbG93IHBvd2VyLiBUaGUKPiBwcm90b2NvbCBhbHNvIG9mZmVycyBhIG1lY2hhbmlz bSBmb3IgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHRoZSBJUAo+IG5ldHdvcmtzIHVuZGVyIFNMUC4g SXQgZW5hYmxlcyBjb21tdW5pY2F0aW9uIGJldHdlZW4gNkxvV1BBTiBhbmQgb3RoZXIKPiBJUCBu ZXR3b3Jrcy4KPgo+IC0tLSBkcmFmdC1kb2thc3Bhci02bG93cGFuLXJvdXRyZXEtMDIKPiBUaGlz IGRvY3VtZW50IHByb3ZpZGVzIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBmb3IgbWVzaCByb3V0aW5n IGJlbG93IHRoZQo+IElQIGxheWVyIChpbiA2TG9XUEFOJ3MgYWRhcHRhdGlvbiBsYXllcikuIEl0 IGFsc28gZGVmaW5lcyBtYWpvciBkZXNpZ24KPiBnb2FscyBhbmQgcmVxdWlyZW1lbnRzIGZvciA2 TG9XUEFOIG1lc2ggcm91dGluZyBjb25zaWRlcmluZyB0aGUKPiBsb3ctcG93ZXIgY2hhcmFjdGVy aXN0aWNzIG9mIHRoZSBuZXR3b3JrIGFuZCBpdHMgZGV2aWNlcy4KPgo+IC0tLSBkcmFmdC1la2lt LTZsb3dwYW4tc2NlbmFyaW9zLTAwCj4gVGhpcyBkb2N1bWVudCBpbnZlc3RpZ2F0ZXMgcG90ZW50 aWFsIGFwcGxpY2F0aW9uIHNjZW5hcmlvcyBhbmQgdXNlIGNhc2VzCj4gZm9yIGxvdy1wb3dlciB3 aXJlbGVzcyBwZXJzb25hbCBhcmVhIG5ldHdvcmtzIChMb1dQQU5zKS4KPgo+IC0tLSBkcmFmdC1o dWktNmxvd3Bhbi1oYzFnLTAwCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzdGF0ZWxlc3Mg SVAgaGVhZGVyIGNvbXByZXNzaW9uIHNjaGVtZSBmb3IKPiBJUHY2IHBhY2tldCBkZWxpdmVyeSBp biA2TG9XUEFOIHN1Ym5ldHdvcmtzLiBUaGUgY29tcHJlc3Npb24gc2NoZW1lCj4gZm9jdXNlcyBv biBMb1dQQU4gbm9kZXMgdGhhdCBtYXkgaGF2ZSBnbG9iYWwgdW5pY2FzdCBhZGRyZXNzZXMgYXNz aWduZWQKPiB0byB0aGVpciBpbnRlcmZhY2VzLgo+Cj4gLS0tIGRyYWZ0LWh1aS02bG93cGFuLWlu dGVyb3AtMDAKPiBUaGlzIG1lbW8gZGVmaW5lcyBhIGZpcnN0IHN0ZXAgaW4gdGVzdGluZyBhbmQg ZGVtb25zdHJhdGluZyB0aGUKPiBpbnRlcm9wZXJhYmlsaXR5IG9mIGluZGVwZW5kZW50IDZMb1dQ QU4gaW1wbGVtZW50YXRpb25zLgo+Cj4gLS0tIGRyYWZ0LW1vbnRlbmVncm8tNmxvd3Bhbi1keW1v LWxvdy1yb3V0aW5nLTAzCj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgaG93IHRvIHVzZSB0aGUg RHluYW1pYyBNQU5FVCBPbi1kZW1hbmQgUm91dGluZwo+IFByb3RvY29sIG92ZXIgSUVFRTgwMi4x NS40IG5ldHdvcmtzLgo+Cj4gLS0tIGRyYWZ0LW9oLTZsb3dwYW4tcGFja2V0YmItZHltb2FwcC0w MQo+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBnZW5l cmFsaXplZCBNQU5FVAo+IHBhY2tldC9tZXNzYWdlIGZvcm1hdCAocGFja2V0YmIpIGFuZCB0aGUg ZHluYW1pYyBNQU5FVCBvbi1kZW1hbmQgKERZTU8pCj4gcm91dGluZyBwcm90b2NvbCBvdmVyIDZM b1dQQU4uIEluIG9yZGVyIHRvIGFjaGlldmUgbG93IG1lbW9yeSB1c2FnZSBhbmQKPiBsb3cgcHJv Y2Vzc2luZyBvdmVyaGVhZCwgdGhpcyBkb2N1bWVudCBzdWdnZXN0cyB3aGF0IGlzIHRvIGJlIG1v ZGlmaWVkCj4gZnJvbSB0aGUgTUFORVQgYmFzZSBzcGVjaWZpY2F0aW9ucy4KPgo+IC0tLSBkcmFm dC1zaGluLTZsb3dwYW4tbW9iaWxpdHktMDAKPiBUaGlzIGRyYWZ0IGxpc3RzIG1vYmlsaXR5IHNj ZW5hcmlvcyBhbmQgc3VnZ2VzdHMgc29sdXRpb25zIG9mIGhvdyB0bwo+IHByb3ZpZGUgbW9iaWxp dHkgc3VwcG9ydCBpbiBJUHY2IGxvdy1wb3dlciBwZXJzb25hbCBhcmVhIG5ldHdvcmtzCj4gKDZM b1dQQU5zKS4KPgo+IC0tLSBkcmFmdC10aHViZXJ0LWxvd3Bhbi1iYWNrYm9uZS1yb3V0ZXItMDAK PiBJU0ExMDAuMTFhIGlzIGEgV29ya2luZyBHcm91cCBhdCB0aGUgSVNBIFNQMTAwIHN0YW5kYXJk IGNvbW1pdHRlZSB0aGF0Cj4gY292ZXJzIFdpcmVsZXNzIFN5c3RlbXMgZm9yIEluZHVzdHJpYWwg QXV0b21hdGlvbiBhbmQgUHJvY2VzcyBDb250cm9sLgo+IFRoZSBXRyBpcyBtYW5kYXRlZCB0byBk ZXNpZ24gYSBzY2FsYWJsZSwgaW5kdXN0cmlhbCBncmFkZSBMb3dQQU4gZm9yCj4gZGV2aWNlcyBz dWNoIGFzIHNlbnNvcnMsIHZhbHZlcywgYW5kIGFjdHVhdG9ycy4gVGhlIHVwY29taW5nIHN0YW5k YXJkCj4gdXNlcyB0aGUgNkxvV1BBTiBmb3JtYXQgZm9yIHRoZSBuZXR3b3JrIGhlYWRlci4gSXQg YWxzbyBpbnRyb2R1Y2VzIHRoZQo+IGNvbmNlcHQgb2YgYSBCYWNrYm9uZSBSb3V0ZXIgdG8gbWVy Z2Ugc21hbGwgTG9XUEFOcyB2aWEgYSBoaWdoIHNwZWVkCj4gdHJhbnNpdCBhbmQgc2NhbGUgdGhl IElTQTEwMC4xMWEgbmV0d29yay4gVGhpcyBwYXBlciBwcm9wb3NlcyBhbiBJUHY2Cj4gdmVyc2lv biBvZiB0aGUgQmFja2JvbmUgUm91dGVyIGNvbmNlcHQuCj4KPiA9PT09PT09PT09PT09PT0gRXhw aXJlZCBEcmFmdHMgPT09PT09PT09PT09PT09Cj4gLS0tIGRyYWZ0LWNoYWtyYWJhcnRpLTZsb3dw YW4taXB2Ni1uZC0wMwo+IElFVEYgNkxvd1BhbiB3b3JraW5nIGdyb3VwIGRlZmluZXMgSVB2NiBv dmVyIGxvdy1wb3dlciBwZXJzb25hbCBhcmVhCj4gbmV0d29yayAoSUVFRSA4MDIuMTUuNCkuIElF RUUgODAyLjE1LjQgbGluayBsYXllciBkb2VzIG5vdCBoYXZlCj4gbXVsdGljYXN0IHN1cHBvcnQs IGFsdGhvdWdoIGl0IHN1cHBvcnRzIGJyb2FkY2FzdC4gRHVlIHRvIHRoZSBuYXR1cmUgb2YKPiBM b3dQYW4gbmV0d29yayBvciBzZW5zb3IgbmV0d29ya3MsIGJyb2FkY2FzdCBtZXNzYWdlcyBzaG91 bGQgYmUKPiBtaW5pbWl6ZWQuIFRoaXMgZG9jdW1lbnQgc3VnZ2VzdHMgc29tZSBvcHRpbWl6YXRp b25zIHRvIElQdjYgTmVpZ2hib3IKPiBEaXNjb3ZlcnkgcmVsYXRlZCBtdWx0aWNhc3QgbWVzc2Fn ZXMgaW4gb3JkZXIgdG8gcmVkdWNlIHNpZ25hbGluZyBpbiB0aGUKPiBsb3ctY29zdCBsb3ctcG93 ZXJlZCBuZXR3b3JrLgo+Cj4gLS0tIGRyYWZ0LWNoYWtyYWJhcnRpLW1vYm9wdHMtbG93cGFuLXJl cS0wMQo+IElFVEYgTG93UGFuIHdvcmtpbmcgZ3JvdXAgZGVmaW5lcyBJUHY2IG92ZXIgbG93LXBv d2VyIHBlcnNvbmFsIGFyZWEKPiBuZXR3b3JrIChJRUVFIDgwMi4xNS40KS4gTG93cGFuIGFyY2hp dGVjdHVyZSBhbGxvd3Mgcm91dGluZyB0byB0YWtlCj4gcGxhY2UgYXQgdGhlIGxpbmsgbGF5ZXIg aW4gb3JkZXIgdG8gc2F2ZSBwYXlsb2FkIG92ZXJoZWFkIG92ZXIgdGhlIElFRUUKPiA4MDIuMTUu NCBsaW5rIGFuZCB0aHVzIG1vcmUgZWZmaWNpZW50IHJvdXRpbmcgZm9yIGxvdyBwb3dlciwgbG93 Cj4gZGF0YS1yYXRlIG5ldHdvcmtzIHN1Y2ggYXMgc2Vuc29yIG5ldHdvcmtzLiBUaGlzIGRvY3Vt ZW50IGRpc2N1c3NlcyBhCj4gZmV3IHNjZW5hcmlvcyBvZiBtb2JpbGl0eSBpbiBMb3dQYW4gbmV0 d29yayBhbmQgc3RhdGVzIG1vYmlsaXR5Cj4gcmVxdWlyZW1lbnRzIGFuZCBnb2FscyBmb3IgTG93 UGFuIG5ldHdvcmtzLgo+Cj4gLS0tIGRyYWZ0LWRhbmllbC02bG93cGFuLWludGVyb3BlcmFiaWxp dHktMDEKPiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgZ2F0ZXdheSBhcmNoaXRlY3R1cmUg Zm9yIHRoZQo+IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiA2TG9XUEFOIGFuZCBleHRlcm5hbCBJ UHY2IG5ldHdvcmtzLiBUaGUgZ2F0ZXdheQo+IGRvZXMgdGhlIGNvbXByZXNzaW9uIGFuZCBkZWNv bXByZXNzaW9uIG9mIElQdjYgcGFja2V0cyBhbmQgcGVyZm9ybXMgdGhlCj4gbWFwcGluZyBiZXR3 ZWVuIDE2IGJpdCBzaG9ydCBhZGRyZXNzZXMgYW5kIHRoZSBJUHY2IGFkZHJlc3NlcyBmb3IgYm90 aAo+IHRoZSBleHRlcm5hbCBJUHY2IG5ldHdvcmtzIGFuZCA2TG93UEFOLCByZXNwZWN0aXZlbHku Cj4KPiAtLS0gZHJhZnQtZGFuaWVsLTZsb3dwYW4tc2VjdXJpdHktYW5hbHlzaXMtMDEKPiBUaGlz IGRvY3VtZW50IGRpc2N1c3NlcyBwb3NzaWJsZSB0aHJlYXRzIGFuZCBzZWN1cml0eSBvcHRpb25z IGZvcgo+IElQdjYtb3Zlci1JRUVFODAyLjE1LjQgbmV0d29ya3MuIEl0IGlzIGFuIGluZm9ybWF0 aW9uYWwgZG9jdW1lbnQgdG8KPiByYWlzZSBhd2FyZW5lc3Mgb2Ygc2VjdXJpdHkgaXNzdWVzIGlu IElQdjYgbG93UGFuIG5ldHdvcmtzLgo+Cj4gLS0tIGRyYWZ0LWd1aGEtbG93cGFuLW1vYmlsaXR5 LXByb3RvY29sLXJlcS0wMAo+IEluIHRoaXMgZHJhZnQsIHdlIHByb3Bvc2Ugc29tZSBwcm90b2Nv bCByZXF1aXJlbWVudHMgZm9yIG1vYmlsaXR5IGluCj4gTG93UEFOIG5ldHdvcmtzIHdpdGhpbiB0 aGUgY29udGV4dCBvZiB0aGUgSUVURiBMb3dQQU4gd29ya2luZyBncm91cAo+IChJUHY2IG92ZXIg SUVFRSA4MDIuMTUuNCkuIFRvIGFjaGlldmUgbW9iaWxpdHkgaW4gTG93UEFOIG5ldHdvcmtzLCB0 aGVyZQo+IG1heSBiZSBpbnRlci1kb21haW4gbW92ZW1lbnQgb2YgbmV0d29yayBlbGVtZW50cyBh Y3Jvc3MgZGlmZmVyZW50IExvd1BBTgo+IGRvbWFpbnMgb3IgYWNyb3NzIGRvbWFpbnMgdGhhdCBk byBub3QgY29tcHJpc2UgTG93UEFOIGF1dG9ub21vdXMKPiBzeXN0ZW1zLiBUbyBhZGRyZXNzIHJv dXRpbmcgaXNzdWVzIGluIGludGVyLWRvbWFpbiBMb3dQQU4gbmV0d29ya3MgdGhhdAo+IGNvbmZv cm0gdG8gZml0dGluZyB3aXRoaW4gYSBzaW5nbGUgSUVFRSA4MDIuMTUuNCBmcmFtZSwgdGhlcmUg YXJlIG5lZWRzCj4gZm9yIGNvbGxhYm9yYXRpdmUgYW5kIGRpc3RyaWJ1dGVkIG1ldGhvZG9sb2dp ZXMgZm9yIHJvdXRlIGNvbXB1dGF0aW9uLAo+IGluZm9ybWF0aW9uIHN0b3JhZ2UgYW5kIHJldHJp ZXZhbCwgYW5kIHNlY3VyaXR5IGlzc3VlcyBpbiBwcm90b2NvbHMKPiB0YXJnZXRlZCB0byBMb3dQ QU4gbW9iaWxpdHkuIFRoaXMgZHJhZnQgcHJvcG9zZXMgc29tZSByZXF1aXJlbWVudHMgb2YKPiBt b2JpbGl0eSBpbiBMb3dQQU4gcHJvdG9jb2xzIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mCj4gcHJv dG9jb2wtaW5kZXBlbmRlbnQgbWV0cmljcywgYWxnb3JpdGhtIGNvbXBsZXhpdGllcywgc2NhbGFi aWxpdHkgYW5kCj4gc2VjdXJpdHkgY3JpdGVyaWEuCj4KPiAtLS0gZHJhZnQtbW9udGVuZWdyby1s b3dwYW4tYW9kdi0wMAo+IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGhvdyB0byB1c2UgdGhlIEFk IEhvYyBPbi1EZW1hbmQgVmVjdG9yIFByb3RvY29sCj4gKEFPRFYpIGluIElFRUUgODAyLjE1LjQg bmV0d29ya3MuCj4KPiAtLS0gZHJhZnQtc2FyaWtheWEtNmxvd3Bhbi1mb3J3YXJkaW5nLTAwCj4g VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBzaW1wbGUgYXBwcm9hY2ggdG8gaW50ZXJjb25uZWN0 IElFRUUgODAyLjE1LjQKPiBzZW5zb3Igbm9kZXMgdG8gSVB2NiBJbnRlcm5ldC4gVGhlIHRlY2hu aXF1ZSByZXF1aXJlcyBhIGdhdGV3YXkgbm9kZQo+IHRoYXQgaXMgY29ubmVjdGVkIHRvIGJvdGgg dGhlIHNlbnNvciBuZXR3b3JrIGFuZCB0aGUgSVB2NiBJbnRlcm5ldC4gVGhlCj4gZ2F0ZXdheSBu b2RlIHJ1bnMgdGhlIHNlcmlhbCBmb3J3YXJkZXIgb3ZlciBJUHY2LiBTZW5zb3Igbm9kZXMgcnVu IHRoZQo+IG9wZW4tc291cmNlIFRpbnlPUyBvcGVyYXRpbmcgc3lzdGVtIGFuZCBnZW5lcmF0ZSBU aW55T1MgcGFja2V0cy4gVGhlCj4gc2Vuc29yIG5ldHdvcmsgY2FuIGJlIGFjY2Vzc2VkIGZyb20g SVB2NiBJbnRlcm5ldCB1c2luZyBhIFdlYiBpbnRlcmZhY2UKPiBhbmQgdGhlIHNlcmlhbCBmb3J3 YXJkZXIgdGhhdCBydW5zIGluIHRoZSBhcHBsZXRzIGVuYWJsZXMKPiByZWNlcHRpb24vdHJhbnNt aXNzaW9uIG9mIFRpbnlPUyBwYWNrZXRzIG92ZXIgSVB2Ni4KPgo+Cj4KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IDZsb3dwYW4gbWFpbGluZyBsaXN0 Cj4gNmxvd3BhbkBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvLzZsb3dwYW4KPgo+CgoKLS0gCktpLUh5dW5nIEtpbSAoseix4sf8LCDQ3dHD+vspCkFzc29j aWF0ZSBQcm9mZXNzb3IKRGl2aXNpb24gb2YgSW5mb3JtYXRpb24gYW5kIENvbXB1dGVyIEVuZy4s IEFqb3UgVW5pdmVyc2l0eSwgU3V3b24sIEtvcmVhCjQ0Mi03NDkKVGVsOiArODItMzEtMjE5LTI0 MzMsIENlbDogKzgyLTEwLTQ3NjAtMjU1MSwgIEZheDogKzgyLTMxLTIxOS0yNDMzCmh0dHA6Ly93 d3cuNmxvd3Bhbi5vcmcK ------=_Part_11139_24953962.1196343749514 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5HZW9mZiBhbmQgQ2Fyc3Rlbiw8L2Rpdj4KPGRpdj5DYW4gSSZuYnNwO2FzayBhIHRpbWUg c2xvdCBpbiB0aGUgbmV4dCBJRVRGIG1lZXRpbmcgb24gcHJlc2VudGluZyB0aGUgY29tbWlzc2lv bmluZyBhbmQgYm9vdHN0cmFwcGluZyBpc3N1ZXMgaW4gNmxvd3Bhbj88L2Rpdj4KPGRpdj48YnI+ Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAxMS8xMC8wNywg PGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPkdlb2ZmIE11bGxpZ2FuPC9iPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdlb2ZmLWlldGZAbXVsbGlnYW4ub3JnIj5nZW9mZi1pZXRmQG11bGxpZ2FuLm9y ZzwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1BUkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRF Ui1MRUZUOiAjY2NjIDFweCBzb2xpZCI+Rm9sa3MsPGJyPkV2ZW4gdGhvdWdoIHdlIGRvIG5vdCBo YXZlIGFuIGFwcHJvdmVkIHJlY2hhcnRlciB0ZXh0IHdlIGhhdmUgYSBXRzxicj5tZWV0aW5nIHNs b3QgYXQgdGhlIG5leHQgSUVURiBhbmQgd2UgbmVlZCB0byBzZXQgdGhlIGFnZW5kYS4KPGJyPjxi cj4mZ3Q7RnJvbSB0aGUgbGFzdCBJRVRGIG1lZXRpbmcgSSB0aGluayB0aGF0IHdlIHJlYWNoZWQg Y29uc2Vuc3VzIG9uIHRoZSB3b3JrPGJyPml0ZW1zIGZvciB0aGUgZ3JvdXA6PGJyPjxicj4xLiBC b290c3RyYXBwaW5nIC8gTmVpZ2hib3IgRGlzY292ZXJ5PGJyPjIuIFN0YXRlZnVsIEhlYWRlciBD b21wcmVzc2lvbjxicj4zLiBBcmNoaXRlY3R1cmU8YnI+NC4gQXBwbGljYXRpb25zCjxicj41LiBT ZWN1cml0eSBBbmFseXNpczxicj48YnI+V2UgZGVjaWRlZCB0aGF0IHdlIHdvdWxkIGhvbGQgb2Zm IG9uIE1lc2ggVW5kZXIgKExheWVyIDIgcm91dGluZykgYXQ8YnI+dGhpcyB0aW1lIHVudGlsIHRo ZSBwYXRoIGJlY29tZXMgbW9yZSBjbGVhciB3aXRoIHJlc3BlY3QgdG8gdGhlIFJMMk48YnI+cHJv cG9zYWwuPGJyPjxicj5UaGlzIGdyb3VwIGhhcyBnZW5lcmF0ZWQgYSBudW1iZXIgb2YgSS1Ecywg dGhvdWdoIG1hbnkgYXJlIG5vdyBleHBpcmVkLgo8YnI+U29tZSBvZiB0aGUgYWN0aXZlIGFuZCBl eHBpcmVkIEktRHMgc2VlbSBjbG9zZWx5IHJlbGF0ZWQgdG8gdGhlIHdvcms8YnI+aXRlbXMgYWJv dmUuPGJyPjxicj5JIGhhdmUgaW5jbHVkZWQgaW4gdGhpcyBtZXNzYWdlIGEgbGlzdCBvZiBib3Ro IHRoZSBBY3RpdmUgYW5kIEV4cGlyZWQ8YnI+SS1EcyB0aGF0IGhhdmUgYmVlbiBzdWJtaXR0ZWQg YW5kIHRoZWlyIGFic3RyYWN0cyBzbyB0aGF0IHlvdSBkb24mIzM5O3QgaGF2ZQo8YnI+dG8gc2Vh cmNoIGZvciB0aGUgSS1EIGluZm9ybWF0aW9uLjxicj48YnI+VGFraW5nIGludG8gYWNjb3VudCB0 aGUgYWJvdmUgd29yayBpdGVtcywgaWYgYW55IG9mIHRoZSBhdXRob3JzIGFyZTxicj5pbnRlcmVz dGVkIGluIHByZXNlbnRpbmcgdGhlaXIgZHJhZnRzIGF0IHRoaXMgbmV4dCBJRVRGLCBwbGVhc2Ug bGV0PGJyPkNhcnN0ZW4gb3IgSSBrbm93IHNvb24uPGJyPjxicj5JIGRvIGhvcGUgdGhhdCB3ZSB3 aWxsIGR1c3Qgb2ZmIHRoZSBORCBhbmQgc2VjdXJpdHkgYW5hbHlzaXMgZHJhZnRzLgo8YnI+PGJy PklmIGFueW9uZSBlbHNlIGlzIHBsYW5uaW5nIG9uIHN1Ym1pdHRpbmcgYSBkcmFmdCwgcGxlYXNl IGxldCB1cyBrbm93PGJyPnNvb24gYW5kIGFsc28gZ2V0IGl0IHN1Ym1pdHRlZCAtIHRoZSBkZWFk bGluZSBpcyB0aGUgMTJ0aC48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBnZW9mZjxicj48YnI+PGJyPj09PT09PT09PT09PT09IEFjdGl2ZSBEcmFmdHMgPT09PT09 PT09PT09PT09PGJyPi0tLSBkcmFmdC1kYW5pZWwtNmxvd3Bhbi1jb21taXNzaW9uaW5nLTAwCjxi cj5UaGUgY29tbWlzaW9uaW5nIHByb2Nlc3MgZGVmaW5lcyB0aGUgc3RhcnR1cCBwcm9jZWR1cmUg dGFrZW4gYnkgdGhlPGJyPjZMb1dQQU4gZGV2aWNlLiBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhl IHN0YXJ0dXAgcHJvY2VkdXJlIHRoYXQgYWxsPGJyPmtpbmRzIG9mIGRldmljZXMgbXVzdCB0YWtl IHRvIGJlY29tZSBwYXJ0IG9mIHRoZSBuZXR3b3JrLjxicj48YnI+LS0tIGRyYWZ0LWRhbmllbC02 bG93cGFuLWhpbG93LWhpZXJhcmNoaWNhbC1yb3V0aW5nLTAxCjxicj5UaGUgRVVJLTY0IGlkZW50 aWZpZXIgb2YgYSA2TG9XUEFOIGRldmljZSBjYW4gYmUgdXNlZCBhcyB0aGUgaW50ZXJmYWNlPGJy PmlkZW50aWZpZXIgb2YgdGhlIElQdjYgYWRkcmVzcywgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIGZv ciBvbi1kZW1hbmQ8YnI+bXVsdGktaG9wIHJvdXRpbmcgaW4gNkxvV1BBTi4gT25lIG9mIHRoZSBk aXN0aW5jdGl2ZSBmZWF0dXJlIG9mIDZMb1dQQU48YnI+CmlzIHRoZSBjYXBhYmlsaXR5IG9mIHRo ZSBkeW5hbWljIGFzc2lnbm1lbnQgb2YgMTYtIGJpdCBzaG9ydCBhZGRyZXNzZXMuPGJyPkJ5IHV0 aWxpemluZyB0aGlzIGR5bmFtaWNhbGx5IGFzc2lnbmVkIHNob3J0IGFkZHJlc3MsIGEgaGllcmFy Y2hpY2FsPGJyPnJvdXRpbmcgd2hpY2ggaXMgdmVyeSBzY2FsYWJsZSBjYW4gYmUgZW1wbG95ZWQu IFRoaXMgVGhpcyBkb2N1bWVudDxicj5kZWZpbmVzIGEgZHluYW1pYyBhZGRyZXNzIGFzc2lnbm1l bnQgc2NoZW1lIGFuZCBoaWVyYXJjaGljYWwgcm91dGluZwo8YnI+SGlMb3cpIGJhc2VkIG9uIHRo ZSBhc3NpZ25tZW50Ljxicj48YnI+LS0tIGRyYWZ0LWRhbmllbC02bG93cGFuLWxvYWQtYWRob2Mt cm91dGluZy0wMzxicj42TG9XUEFOIEFkIEhvYyBPbi1EZW1hbmQgRGlzdGFuY2UgVmVjdG9yIFJv dXRpbmcgKExPQUQpIGlzIGludGVuZGVkIGZvcjxicj51c2UgYnkgSUVFRSA4MDIuMTUuNCBkZXZp Y2VzIGluIGEgNkxvV1BBTi4gSXQgaXMgYSBzaW1wbGlmaWVkIG9uLWRlbWFuZAo8YnI+cm91dGlu ZyBwcm90b2NvbCBiYXNlZCBvbiBBT0RWLjxicj48YnI+LS0tIGRyYWZ0LWRhbmllbC02bG93cGFu LXNzbHAtMDE8YnI+VGhlIFNpbXBsZSBTZXJ2aWNlIExvY2F0aW9uIFByb3RvY29sIChTU0xQKSBw cm92aWRlcyBhIGZyYW1ld29yayBmb3IgdGhlPGJyPmRpc2NvdmVyeSBhbmQgc2VsZWN0aW9uIG9m IHRoZSBzZXJ2aWNlcyB3b3JraW5nIG9uIDZMb1dQQU4uIFRoZSBwcm90b2NvbAo8YnI+aGFzIGEg c2ltcGxlIHN0cnVjdHVyZSB0aGF0IGlzIGVhc3kgdG8gYmUgaW1wbGVtZW50ZWQgb24gNkxvV1BB TiBkZXZpY2VzPGJyPnRoYXQgYXJlIGNoYXJhY3Rlcml6ZWQgYnkgc2hvcnQgcmFuZ2UsIGxvdyBi aXQgcmF0ZSBhbmQgbG93IHBvd2VyLiBUaGU8YnI+cHJvdG9jb2wgYWxzbyBvZmZlcnMgYSBtZWNo YW5pc20gZm9yIGludGVyb3BlcmFiaWxpdHkgd2l0aCB0aGUgSVA8YnI+Cm5ldHdvcmtzIHVuZGVy IFNMUC4gSXQgZW5hYmxlcyBjb21tdW5pY2F0aW9uIGJldHdlZW4gNkxvV1BBTiBhbmQgb3RoZXI8 YnI+SVAgbmV0d29ya3MuPGJyPjxicj4tLS0gZHJhZnQtZG9rYXNwYXItNmxvd3Bhbi1yb3V0cmVx LTAyPGJyPlRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgdGhlIHByb2JsZW0gc3RhdGVtZW50IGZvciBt ZXNoIHJvdXRpbmcgYmVsb3cgdGhlPGJyPklQIGxheWVyIChpbiA2TG9XUEFOJiMzOTtzIGFkYXB0 YXRpb24gbGF5ZXIpLiBJdCBhbHNvIGRlZmluZXMgbWFqb3IgZGVzaWduCjxicj5nb2FscyBhbmQg cmVxdWlyZW1lbnRzIGZvciA2TG9XUEFOIG1lc2ggcm91dGluZyBjb25zaWRlcmluZyB0aGU8YnI+ bG93LXBvd2VyIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgbmV0d29yayBhbmQgaXRzIGRldmljZXMu PGJyPjxicj4tLS0gZHJhZnQtZWtpbS02bG93cGFuLXNjZW5hcmlvcy0wMDxicj5UaGlzIGRvY3Vt ZW50IGludmVzdGlnYXRlcyBwb3RlbnRpYWwgYXBwbGljYXRpb24gc2NlbmFyaW9zIGFuZCB1c2Ug Y2FzZXMKPGJyPmZvciBsb3ctcG93ZXIgd2lyZWxlc3MgcGVyc29uYWwgYXJlYSBuZXR3b3JrcyAo TG9XUEFOcykuPGJyPjxicj4tLS0gZHJhZnQtaHVpLTZsb3dwYW4taGMxZy0wMDxicj5UaGlzIGRv Y3VtZW50IHNwZWNpZmllcyBhIHN0YXRlbGVzcyBJUCBoZWFkZXIgY29tcHJlc3Npb24gc2NoZW1l IGZvcjxicj5JUHY2IHBhY2tldCBkZWxpdmVyeSBpbiA2TG9XUEFOIHN1Ym5ldHdvcmtzLiBUaGUg Y29tcHJlc3Npb24gc2NoZW1lCjxicj5mb2N1c2VzIG9uIExvV1BBTiBub2RlcyB0aGF0IG1heSBo YXZlIGdsb2JhbCB1bmljYXN0IGFkZHJlc3NlcyBhc3NpZ25lZDxicj50byB0aGVpciBpbnRlcmZh Y2VzLjxicj48YnI+LS0tIGRyYWZ0LWh1aS02bG93cGFuLWludGVyb3AtMDA8YnI+VGhpcyBtZW1v IGRlZmluZXMgYSBmaXJzdCBzdGVwIGluIHRlc3RpbmcgYW5kIGRlbW9uc3RyYXRpbmcgdGhlPGJy PmludGVyb3BlcmFiaWxpdHkgb2YgaW5kZXBlbmRlbnQgNkxvV1BBTiBpbXBsZW1lbnRhdGlvbnMu Cjxicj48YnI+LS0tIGRyYWZ0LW1vbnRlbmVncm8tNmxvd3Bhbi1keW1vLWxvdy1yb3V0aW5nLTAz PGJyPlRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGhvdyB0byB1c2UgdGhlIER5bmFtaWMgTUFORVQg T24tZGVtYW5kIFJvdXRpbmc8YnI+UHJvdG9jb2wgb3ZlciBJRUVFODAyLjE1LjQgbmV0d29ya3Mu PGJyPjxicj4tLS0gZHJhZnQtb2gtNmxvd3Bhbi1wYWNrZXRiYi1keW1vYXBwLTAxPGJyPgpUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgZ2VuZXJhbGl6ZWQg TUFORVQ8YnI+cGFja2V0L21lc3NhZ2UgZm9ybWF0IChwYWNrZXRiYikgYW5kIHRoZSBkeW5hbWlj IE1BTkVUIG9uLWRlbWFuZCAoRFlNTyk8YnI+cm91dGluZyBwcm90b2NvbCBvdmVyIDZMb1dQQU4u IEluIG9yZGVyIHRvIGFjaGlldmUgbG93IG1lbW9yeSB1c2FnZSBhbmQ8YnI+bG93IHByb2Nlc3Np bmcgb3ZlcmhlYWQsIHRoaXMgZG9jdW1lbnQgc3VnZ2VzdHMgd2hhdCBpcyB0byBiZSBtb2RpZmll ZAo8YnI+ZnJvbSB0aGUgTUFORVQgYmFzZSBzcGVjaWZpY2F0aW9ucy48YnI+PGJyPi0tLSBkcmFm dC1zaGluLTZsb3dwYW4tbW9iaWxpdHktMDA8YnI+VGhpcyBkcmFmdCBsaXN0cyBtb2JpbGl0eSBz Y2VuYXJpb3MgYW5kIHN1Z2dlc3RzIHNvbHV0aW9ucyBvZiBob3cgdG88YnI+cHJvdmlkZSBtb2Jp bGl0eSBzdXBwb3J0IGluIElQdjYgbG93LXBvd2VyIHBlcnNvbmFsIGFyZWEgbmV0d29ya3MKPGJy Pig2TG9XUEFOcykuPGJyPjxicj4tLS0gZHJhZnQtdGh1YmVydC1sb3dwYW4tYmFja2JvbmUtcm91 dGVyLTAwPGJyPklTQTEwMC4xMWEgaXMgYSBXb3JraW5nIEdyb3VwIGF0IHRoZSBJU0EgU1AxMDAg c3RhbmRhcmQgY29tbWl0dGVlIHRoYXQ8YnI+Y292ZXJzIFdpcmVsZXNzIFN5c3RlbXMgZm9yIElu ZHVzdHJpYWwgQXV0b21hdGlvbiBhbmQgUHJvY2VzcyBDb250cm9sLjxicj5UaGUgV0cgaXMgbWFu ZGF0ZWQgdG8gZGVzaWduIGEgc2NhbGFibGUsIGluZHVzdHJpYWwgZ3JhZGUgTG93UEFOIGZvcgo8 YnI+ZGV2aWNlcyBzdWNoIGFzIHNlbnNvcnMsIHZhbHZlcywgYW5kIGFjdHVhdG9ycy4gVGhlIHVw Y29taW5nIHN0YW5kYXJkPGJyPnVzZXMgdGhlIDZMb1dQQU4gZm9ybWF0IGZvciB0aGUgbmV0d29y ayBoZWFkZXIuIEl0IGFsc28gaW50cm9kdWNlcyB0aGU8YnI+Y29uY2VwdCBvZiBhIEJhY2tib25l IFJvdXRlciB0byBtZXJnZSBzbWFsbCBMb1dQQU5zIHZpYSBhIGhpZ2ggc3BlZWQ8YnI+CnRyYW5z aXQgYW5kIHNjYWxlIHRoZSBJU0ExMDAuMTFhIG5ldHdvcmsuIFRoaXMgcGFwZXIgcHJvcG9zZXMg YW4gSVB2Njxicj52ZXJzaW9uIG9mIHRoZSBCYWNrYm9uZSBSb3V0ZXIgY29uY2VwdC48YnI+PGJy Pj09PT09PT09PT09PT09PSBFeHBpcmVkIERyYWZ0cyA9PT09PT09PT09PT09PT08YnI+LS0tIGRy YWZ0LWNoYWtyYWJhcnRpLTZsb3dwYW4taXB2Ni1uZC0wMzxicj5JRVRGIDZMb3dQYW4gd29ya2lu ZyBncm91cCBkZWZpbmVzIElQdjYgb3ZlciBsb3ctcG93ZXIgcGVyc29uYWwgYXJlYQo8YnI+bmV0 d29yayAoSUVFRSA4MDIuMTUuNCkuIElFRUUgODAyLjE1LjQgbGluayBsYXllciBkb2VzIG5vdCBo YXZlPGJyPm11bHRpY2FzdCBzdXBwb3J0LCBhbHRob3VnaCBpdCBzdXBwb3J0cyBicm9hZGNhc3Qu IER1ZSB0byB0aGUgbmF0dXJlIG9mPGJyPkxvd1BhbiBuZXR3b3JrIG9yIHNlbnNvciBuZXR3b3Jr cywgYnJvYWRjYXN0IG1lc3NhZ2VzIHNob3VsZCBiZTxicj5taW5pbWl6ZWQuIFRoaXMgZG9jdW1l bnQgc3VnZ2VzdHMgc29tZSBvcHRpbWl6YXRpb25zIHRvIElQdjYgTmVpZ2hib3IKPGJyPkRpc2Nv dmVyeSByZWxhdGVkIG11bHRpY2FzdCBtZXNzYWdlcyBpbiBvcmRlciB0byByZWR1Y2Ugc2lnbmFs aW5nIGluIHRoZTxicj5sb3ctY29zdCBsb3ctcG93ZXJlZCBuZXR3b3JrLjxicj48YnI+LS0tIGRy YWZ0LWNoYWtyYWJhcnRpLW1vYm9wdHMtbG93cGFuLXJlcS0wMTxicj5JRVRGIExvd1BhbiB3b3Jr aW5nIGdyb3VwIGRlZmluZXMgSVB2NiBvdmVyIGxvdy1wb3dlciBwZXJzb25hbCBhcmVhCjxicj5u ZXR3b3JrIChJRUVFIDgwMi4xNS40KS4gTG93cGFuIGFyY2hpdGVjdHVyZSBhbGxvd3Mgcm91dGlu ZyB0byB0YWtlPGJyPnBsYWNlIGF0IHRoZSBsaW5rIGxheWVyIGluIG9yZGVyIHRvIHNhdmUgcGF5 bG9hZCBvdmVyaGVhZCBvdmVyIHRoZSBJRUVFPGJyPjgwMi4xNS40IGxpbmsgYW5kIHRodXMgbW9y ZSBlZmZpY2llbnQgcm91dGluZyBmb3IgbG93IHBvd2VyLCBsb3c8YnI+ZGF0YS1yYXRlIG5ldHdv cmtzIHN1Y2ggYXMgc2Vuc29yIG5ldHdvcmtzLiBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBhCjxi cj5mZXcgc2NlbmFyaW9zIG9mIG1vYmlsaXR5IGluIExvd1BhbiBuZXR3b3JrIGFuZCBzdGF0ZXMg bW9iaWxpdHk8YnI+cmVxdWlyZW1lbnRzIGFuZCBnb2FscyBmb3IgTG93UGFuIG5ldHdvcmtzLjxi cj48YnI+LS0tIGRyYWZ0LWRhbmllbC02bG93cGFuLWludGVyb3BlcmFiaWxpdHktMDE8YnI+VGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGdhdGV3YXkgYXJjaGl0ZWN0dXJlIGZvciB0aGUKPGJy PmludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiA2TG9XUEFOIGFuZCBleHRlcm5hbCBJUHY2IG5ldHdv cmtzLiBUaGUgZ2F0ZXdheTxicj5kb2VzIHRoZSBjb21wcmVzc2lvbiBhbmQgZGVjb21wcmVzc2lv biBvZiBJUHY2IHBhY2tldHMgYW5kIHBlcmZvcm1zIHRoZTxicj5tYXBwaW5nIGJldHdlZW4gMTYg Yml0IHNob3J0IGFkZHJlc3NlcyBhbmQgdGhlIElQdjYgYWRkcmVzc2VzIGZvciBib3RoCjxicj50 aGUgZXh0ZXJuYWwgSVB2NiBuZXR3b3JrcyBhbmQgNkxvd1BBTiwgcmVzcGVjdGl2ZWx5Ljxicj48 YnI+LS0tIGRyYWZ0LWRhbmllbC02bG93cGFuLXNlY3VyaXR5LWFuYWx5c2lzLTAxPGJyPlRoaXMg ZG9jdW1lbnQgZGlzY3Vzc2VzIHBvc3NpYmxlIHRocmVhdHMgYW5kIHNlY3VyaXR5IG9wdGlvbnMg Zm9yPGJyPklQdjYtb3Zlci1JRUVFODAyLjE1LjQgbmV0d29ya3MuIEl0IGlzIGFuIGluZm9ybWF0 aW9uYWwgZG9jdW1lbnQgdG8KPGJyPnJhaXNlIGF3YXJlbmVzcyBvZiBzZWN1cml0eSBpc3N1ZXMg aW4gSVB2NiBsb3dQYW4gbmV0d29ya3MuPGJyPjxicj4tLS0gZHJhZnQtZ3VoYS1sb3dwYW4tbW9i aWxpdHktcHJvdG9jb2wtcmVxLTAwPGJyPkluIHRoaXMgZHJhZnQsIHdlIHByb3Bvc2Ugc29tZSBw cm90b2NvbCByZXF1aXJlbWVudHMgZm9yIG1vYmlsaXR5IGluPGJyPkxvd1BBTiBuZXR3b3JrcyB3 aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlIElFVEYgTG93UEFOIHdvcmtpbmcgZ3JvdXAKPGJyPihJ UHY2IG92ZXIgSUVFRSA4MDIuMTUuNCkuIFRvIGFjaGlldmUgbW9iaWxpdHkgaW4gTG93UEFOIG5l dHdvcmtzLCB0aGVyZTxicj5tYXkgYmUgaW50ZXItZG9tYWluIG1vdmVtZW50IG9mIG5ldHdvcmsg ZWxlbWVudHMgYWNyb3NzIGRpZmZlcmVudCBMb3dQQU48YnI+ZG9tYWlucyBvciBhY3Jvc3MgZG9t YWlucyB0aGF0IGRvIG5vdCBjb21wcmlzZSBMb3dQQU4gYXV0b25vbW91czxicj4Kc3lzdGVtcy4g VG8gYWRkcmVzcyByb3V0aW5nIGlzc3VlcyBpbiBpbnRlci1kb21haW4gTG93UEFOIG5ldHdvcmtz IHRoYXQ8YnI+Y29uZm9ybSB0byBmaXR0aW5nIHdpdGhpbiBhIHNpbmdsZSBJRUVFIDgwMi4xNS40 IGZyYW1lLCB0aGVyZSBhcmUgbmVlZHM8YnI+Zm9yIGNvbGxhYm9yYXRpdmUgYW5kIGRpc3RyaWJ1 dGVkIG1ldGhvZG9sb2dpZXMgZm9yIHJvdXRlIGNvbXB1dGF0aW9uLDxicj4KaW5mb3JtYXRpb24g c3RvcmFnZSBhbmQgcmV0cmlldmFsLCBhbmQgc2VjdXJpdHkgaXNzdWVzIGluIHByb3RvY29sczxi cj50YXJnZXRlZCB0byBMb3dQQU4gbW9iaWxpdHkuIFRoaXMgZHJhZnQgcHJvcG9zZXMgc29tZSBy ZXF1aXJlbWVudHMgb2Y8YnI+bW9iaWxpdHkgaW4gTG93UEFOIHByb3RvY29scyBmcm9tIHRoZSBw ZXJzcGVjdGl2ZSBvZjxicj5wcm90b2NvbC1pbmRlcGVuZGVudCBtZXRyaWNzLCBhbGdvcml0aG0g Y29tcGxleGl0aWVzLCBzY2FsYWJpbGl0eSBhbmQKPGJyPnNlY3VyaXR5IGNyaXRlcmlhLjxicj48 YnI+LS0tIGRyYWZ0LW1vbnRlbmVncm8tbG93cGFuLWFvZHYtMDA8YnI+VGhpcyBkb2N1bWVudCBk ZXNjcmliZXMgaG93IHRvIHVzZSB0aGUgQWQgSG9jIE9uLURlbWFuZCBWZWN0b3IgUHJvdG9jb2w8 YnI+KEFPRFYpIGluIElFRUUgODAyLjE1LjQgbmV0d29ya3MuPGJyPjxicj4tLS0gZHJhZnQtc2Fy aWtheWEtNmxvd3Bhbi1mb3J3YXJkaW5nLTAwCjxicj5UaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IHNpbXBsZSBhcHByb2FjaCB0byBpbnRlcmNvbm5lY3QgSUVFRSA4MDIuMTUuNDxicj5zZW5zb3Ig bm9kZXMgdG8gSVB2NiBJbnRlcm5ldC4gVGhlIHRlY2huaXF1ZSByZXF1aXJlcyBhIGdhdGV3YXkg bm9kZTxicj50aGF0IGlzIGNvbm5lY3RlZCB0byBib3RoIHRoZSBzZW5zb3IgbmV0d29yayBhbmQg dGhlIElQdjYgSW50ZXJuZXQuIFRoZQo8YnI+Z2F0ZXdheSBub2RlIHJ1bnMgdGhlIHNlcmlhbCBm b3J3YXJkZXIgb3ZlciBJUHY2LiBTZW5zb3Igbm9kZXMgcnVuIHRoZTxicj5vcGVuLXNvdXJjZSBU aW55T1Mgb3BlcmF0aW5nIHN5c3RlbSBhbmQgZ2VuZXJhdGUgVGlueU9TIHBhY2tldHMuIFRoZTxi cj5zZW5zb3IgbmV0d29yayBjYW4gYmUgYWNjZXNzZWQgZnJvbSBJUHY2IEludGVybmV0IHVzaW5n IGEgV2ViIGludGVyZmFjZQo8YnI+YW5kIHRoZSBzZXJpYWwgZm9yd2FyZGVyIHRoYXQgcnVucyBp biB0aGUgYXBwbGV0cyBlbmFibGVzPGJyPnJlY2VwdGlvbi90cmFuc21pc3Npb24gb2YgVGlueU9T IHBhY2tldHMgb3ZlciBJUHY2Ljxicj48YnI+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj42bG93cGFuIG1haWxpbmcgbGlzdDxicj48YSBo cmVmPSJtYWlsdG86Nmxvd3BhbkBpZXRmLm9yZyI+CjZsb3dwYW5AaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW4iPmh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzZsb3dwYW48L2E+PGJyPjxicj48 L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPktpLUh5dW5n IEtpbSAoseix4sf8LCDQ3dHD+vspPGJyPkFzc29jaWF0ZSBQcm9mZXNzb3IKPGJyPkRpdmlzaW9u IG9mIEluZm9ybWF0aW9uIGFuZCBDb21wdXRlciBFbmcuLCBBam91IFVuaXZlcnNpdHksIFN1d29u LCBLb3JlYSA0NDItNzQ5PGJyPlRlbDogKzgyLTMxLTIxOS0yNDMzLCBDZWw6ICs4Mi0xMC00NzYw LTI1NTEsJm5ic3A7Jm5ic3A7RmF4OiArODItMzEtMjE5LTI0MzMgPGEgaHJlZj0iaHR0cDovL3d3 dy42bG93cGFuLm9yZyI+aHR0cDovL3d3dy42bG93cGFuLm9yZzwvYT4gCg== ------=_Part_11139_24953962.1196343749514-- --===============0881019386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0881019386==-- From 6lowpan-bounces@ietf.org Thu Nov 29 10:10:25 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixl1y-0007AP-Ks; Thu, 29 Nov 2007 10:10:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixl1w-0007A0-LU for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 10:10:20 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixl1u-0005WR-7B for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 10:10:20 -0500 X-IronPort-AV: E=Sophos;i="4.23,229,1194217200"; d="scan'208";a="159139333" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Nov 2007 16:09:52 +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 lATF9qC5015740; Thu, 29 Nov 2007 16:09:52 +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 lATF9p3Z023149; Thu, 29 Nov 2007 15:09:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 16:09:51 +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 Date: Thu, 29 Nov 2007 16:09:49 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> In-Reply-To: <474DBB4A.2030605@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: Acgx8U3p294YVOJqSm6vpPkGt8Ii6AAqFMUg References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "Kris Pister" X-OriginalArrivalTime: 29 Nov 2007 15:09:51.0723 (UTC) FILETIME=[E408DBB0:01C83299] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8756; t=1196348992; x=1197212992; 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=u6Ek7HPDWx0Dvg4/nsoQvA9Cyi8LO1ZVQ2aPx9QijnA=; b=pj35omPC75HgPg/zzGHzEJuQaZ7HtZo+KNMjyAqzkRWNAe1xaf97b8iw2xMewxnb/PLuQUmB X7W9L3DqfM7ZOjcp5KYbk4MVECVGArbPol/XrZVlJQnW/q0NKTLiq5IB; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: 6lowpan <6lowpan@lists.ietf.org> Subject: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hum...=20 I had missed that; Seems that we have to make an exception :) If you = consider ISA100.11a, they already have security at L2 and L5, it makes = little sense to MUST IPSec on top of that. Pascal >-----Original Message----- >From: Kris Pister [mailto:pister@eecs.berkeley.edu] >Sent: Wednesday, November 28, 2007 8:03 PM >To: Pascal Thubert (pthubert) >Cc: 6lowpan >Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > >Hmm. From 4294: > >"However, while authentication and encryption can each be NULL, they >MUST NOT both be NULL." > >ksjp > >Pascal Thubert (pthubert) wrote: >> Hi Kris: >> >> For your question on ESP, AFAIK, RFC 4294 only mandates NULL = encryption and authentication for >interoperability reasons. >> >> On the general question of RFC 4294 itself: I'm not sure the work was = ever done. I hope someone >from the list can help? >> >> If the answer is unclear, and considering that we are re-chartering = the group, maybe we could have >a work item to specify the instantiation of RFC 4294 for LoWPAN nodes? >> >> Pascal >> ________________________________________ >> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >> Sent: Wednesday, November 28, 2007 5:42 PM >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan >> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >> >> Is there an email thread somewhere that discusses the impact on = 6LoWPAN of the security >requirements of 4294 and 4303? >> My first quick readthrough makes me very uncomfortable that some of = the mandates are going to be >ugly from a header standpoint. >> >> ksjp >> >> Pascal Thubert (pthubert) wrote: >> Hi JP: >> >> Thanks a bunch for this charter. I'll try not to rephrase what was = already discussed with Christian, >Anders, Philip and Misha. >> >> There's an additional item I'd wish to see either in ROLL or 6LoWPAN = and I do not know exactly >where it belongs, maybe both. The question is whether we need to and = can document how RFC 4294 >applies for sensors, and M2M devices in general, whether they act as = hosts or as routers. >> >> I've seen IPv6 presented as a Pandora box that drags just too much = stuff to be incorporated in a >sensory device. For instance, at the moment, SP100.11a endorses 6LoWPAN = formats but it's not so clear >at all that IPv6 itself is mandated. A clear spec with well-documented = implementation could be a >formidable tool to despond to Fear, Uncertainty and Defiance. >> >> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do = without multicast at all if ND is >supported some other way (such as suggested in: = http://www.ietf.org/internet-drafts/draft-thubert- >lowpan-backbone-router-00.txt). Maybe NULL encryption and = authentication is enough etc, etc... >> >> Being able to define one minimum set and maybe a few other profiles = for the use cases that we >selected could help tremendously. >> >> Otherwise I find the charter real well written and easy to digest. = >From the MANEMO experience, I >expect that some arguments about the relative applicability of existing = MANET protocols will be >difficult to prove without some good simulation work running = agreed-upon scenarios. >> >> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 = seem supported. Ipv4 comes with a >lot of overhead like DHCP. I suggest that when trouble comes and things = can not be done in a common >fashion for both IP protocols, hen we prioritize IPv6. >> >> Unfortunately, I can not make it to Vancouver, but I do feel that the = work is really needed so >please count my vote in for the adoption of the WG. >> >> Cheers, >> >> Pascal >> >> >> -----Original Message----- >> From: Jean Philippe Vasseur (jvasseur) >> Sent: Wednesday, November 21, 2007 9:19 PM >> To: rsn@ietf.org >> Subject: [RSN] Here is the new RL2N Proposed Working Charter >> >> Dear all, >> >> As promised, here is the new proposed Working Group, which reflects = the >> number of comments/suggestions that we received, the pre-WG = consensus, ... >> >> Thanks to Dave Ward (RTD AD) for his input. >> >> Proposed RL2N WG Charter >> >> Description of Working Group >> >> L2Ns (Low power and Lossy networks) are typically composed of many = embedded >> devices with limited power, memory, and processing resources = interconnected >> by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Low = Power >> WiFi. >> >> L2Ns are transitioning to an end-to-end IP-based solution to avoid = the >> problems of non-interoperable networks interconnected by protocol >> translation gateways and proxies. In addition, L2Ns have specific = routing >> requirements that are not currently met by existing routing = protocols, such >> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be designed = to take >> into consideration the specific power, capabilities, attributes and >> functional characteristics of the links and nodes in the network. >> >> >> There is a wide scope of application areas for L2Ns, including = industrial >> monitoring, building automation (HVAC, lighting/access control), = connected >> home, healthcare, environmental monitoring, agricultural, smart = cities, >> logistics, assets tracking, and refrigeration. The L2N WG will focus = on >> routing solutions for a subset of these deployment scenarios, namely >> industrial, connected home/building and urban applications. The = Working >> Group will determine the routing requirements for these scenarios. >> >> >> The Working Group will provide a routing framework for these = application >> scenarios that provides high reliability in the presence of time = varying >> loss characteristics and connectivity while permitting low-power = operation >> with very modest memory and CPU pressure. >> >> >> The Working Group will pay a particular attention to routing security = and >> manageability (e.g self managing/configuration) issues, which are >> particularly critical for L2Ns. >> >> Work Items: >> >> - Produce use cases documents for Industrial, Connected Home, = Building and >> urban application networks. Each document will describe the use case = and the >> associated routing protocol requirements. The documents will progress = in >> collaboration with the 6lowpan Working Group (INT area). >> >> >> - Survey the applicability of existing protocols to L2Ns. The aim of = this >> document will be to analyze the scaling and characteristics of = existing >> protocols and identify whether or not they meet the routing = requirements of >> the L2Ns applications identified above. Existing IGPs, MANET, NEMO, = DTN >> routing protocols will be part of evaluation. >> >> - Specification of routing metrics used in path calculation. This = includes >> static and dynamic link/nodes attributes required for routing in = L2Ns. >> >> - Provide an architectural framework for routing and path selection = at Layer >> 3 (Routing for L2N Architecture) >> * Decide whether the L2Ns routing protocol require a distributed, >> centralized path computation models or both. >> * Decide whether the L2N routing protocol requires a hierarchical = routing >> approach. >> >> - Produce a security framework for routing in L2Ns. >> >> Goals And Milestones: >> >> >> April 2008 Submit Use case/Routing requirements for Industrial, = Connected >> Home, Building and Urban networks applications to the IESG to be = considered >> as an Informational RFC. >> >> August 2008: Submit Routing metrics for L2Ns document to the IESG to = be >> considered as an Informational RFC. >> >> September 2008: Submit first draft of the Routing for L2Ns = Architecture >> document (summary of requirements, path computation model, >> flat/hierarchy,=A9). >> >> November 2008: Submit Protocol Survey to the IESG to be considered as = an >> Informational RFC. >> >> January 2009 Submit Security Framework for L2Ns to the IESG to be = considered >> as an Informational RFC >> >> February 2009: Submit the Routing for L2Ns Architecture document = (summary >> of requirements, metrics and attributes, path selection model) to the = IESG >> as an Informational RFC. >> >> March 2009: Recharter. >> >> >> Please comment/suggest/... >> >> See you in Vancouver. >> >> JP and David. >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> >> _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 10:52:31 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlgk-0000wH-P0; Thu, 29 Nov 2007 10:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlgj-0000vu-2E for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 10:52:29 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixlgg-0004Vl-79 for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 10:52:29 -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 lATFqEE5011028; Thu, 29 Nov 2007 08:52:14 -0700 (MST) Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter From: Geoff Mulligan To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=utf-8 Date: Thu, 29 Nov 2007 08:52:08 -0700 Message-Id: <1196351528.5692.0.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by grab.coslabs.com id lATFqEE5011028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org We have already received an exception from the IESG to IPsec on 6lowpan devices. geoff On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote: > Hum...=20 >=20 > I had missed that; Seems that we have to make an exception :) If you co= nsider ISA100.11a, they already have security at L2 and L5, it makes litt= le sense to MUST IPSec on top of that. >=20 > Pascal >=20 > >-----Original Message----- > >From: Kris Pister [mailto:pister@eecs.berkeley.edu] > >Sent: Wednesday, November 28, 2007 8:03 PM > >To: Pascal Thubert (pthubert) > >Cc: 6lowpan > >Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > > > >Hmm. From 4294: > > > >"However, while authentication and encryption can each be NULL, they > >MUST NOT both be NULL." > > > >ksjp > > > >Pascal Thubert (pthubert) wrote: > >> Hi Kris: > >> > >> For your question on ESP, AFAIK, RFC 4294 only mandates NULL encrypt= ion and authentication for > >interoperability reasons. > >> > >> On the general question of RFC 4294 itself: I'm not sure the work wa= s ever done. I hope someone > >from the list can help? > >> > >> If the answer is unclear, and considering that we are re-chartering = the group, maybe we could have > >a work item to specify the instantiation of RFC 4294 for LoWPAN nodes? > >> > >> Pascal > >> ________________________________________ > >> From: Kris Pister [mailto:pister@eecs.berkeley.edu] > >> Sent: Wednesday, November 28, 2007 5:42 PM > >> To: Pascal Thubert (pthubert) > >> Cc: 6lowpan > >> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > >> > >> Is there an email thread somewhere that discusses the impact on 6LoW= PAN of the security > >requirements of 4294 and 4303? > >> My first quick readthrough makes me very uncomfortable that some of = the mandates are going to be > >ugly from a header standpoint. > >> > >> ksjp > >> > >> Pascal Thubert (pthubert) wrote: > >> Hi JP: > >> > >> Thanks a bunch for this charter. I'll try not to rephrase what was a= lready discussed with Christian, > >Anders, Philip and Misha. > >> > >> There's an additional item I'd wish to see either in ROLL or 6LoWPAN= and I do not know exactly > >where it belongs, maybe both. The question is whether we need to and c= an document how RFC 4294 > >applies for sensors, and M2M devices in general, whether they act as h= osts or as routers. > >> > >> I've seen IPv6 presented as a Pandora box that drags just too much s= tuff to be incorporated in a > >sensory device. For instance, at the moment, SP100.11a endorses 6LoWPA= N 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 wi= thout multicast at all if ND is > >supported some other way (such as suggested in: http://www.ietf.org/in= ternet-drafts/draft-thubert- > >lowpan-backbone-router-00.txt). Maybe NULL encryption and authenticati= on is enough etc, etc... > >> > >> Being able to define one minimum set and maybe a few other profiles = for the use cases that we > >selected could help tremendously. > >> > >> Otherwise I find the charter real well written and easy to digest. >= >From the MANEMO experience, I > >expect that some arguments about the relative applicability of existin= g MANET protocols will be > >difficult to prove without some good simulation work running agreed-up= on scenarios. > >> > >> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 se= em supported. Ipv4 comes with a > >lot of overhead like DHCP. I suggest that when trouble comes and thing= s 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 th= e 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 consensu= s, ... > >> > >> 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 e= mbedded > >> devices with limited power, memory, and processing resources interco= nnected > >> by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Lo= w Power > >> WiFi. > >> > >> L2Ns are transitioning to an end-to-end IP-based solution to avoid t= he > >> problems of non-interoperable networks interconnected by protocol > >> translation gateways and proxies. In addition, L2Ns have specific ro= uting > >> requirements that are not currently met by existing routing protocol= s, 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 indus= trial > >> monitoring, building automation (HVAC, lighting/access control), con= nected > >> home, healthcare, environmental monitoring, agricultural, smart citi= es, > >> 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 Work= ing > >> Group will determine the routing requirements for these scenarios. > >> > >> > >> The Working Group will provide a routing framework for these applica= tion > >> scenarios that provides high reliability in the presence of time var= ying > >> loss characteristics and connectivity while permitting low-power ope= ration > >> with very modest memory and CPU pressure. > >> > >> > >> The Working Group will pay a particular attention to routing securit= y and > >> manageability (e.g self managing/configuration) issues, which are > >> particularly critical for L2Ns. > >> > >> Work Items: > >> > >> - Produce use cases documents for Industrial, Connected Home, Buildi= ng and > >> urban application networks. Each document will describe the use case= and the > >> associated routing protocol requirements. The documents will progres= s 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 exist= ing > >> protocols and identify whether or not they meet the routing requirem= ents 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 in= cludes > >> static and dynamic link/nodes attributes required for routing in L2N= s. > >> > >> - 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 ro= uting > >> approach. > >> > >> - Produce a security framework for routing in L2Ns. > >> > >> Goals And Milestones: > >> > >> > >> April 2008 Submit Use case/Routing requirements for Industrial, Conn= ected > >> Home, Building and Urban networks applications to the IESG to be con= sidered > >> 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 Architect= ure > >> document (summary of requirements, path computation model, > >> flat/hierarchy,=C5=A0). > >> > >> November 2008: Submit Protocol Survey to the IESG to be considered a= s an > >> Informational RFC. > >> > >> January 2009 Submit Security Framework for L2Ns to the IESG to be co= nsidered > >> as an Informational RFC > >> > >> February 2009: Submit the Routing for L2Ns Architecture document (s= ummary > >> of requirements, metrics and attributes, path selection model) to th= e IESG > >> as an Informational RFC. > >> > >> March 2009: Recharter. > >> > >> > >> Please comment/suggest/... > >> > >> See you in Vancouver. > >> > >> JP and David. > >> > >> > >> _______________________________________________ > >> RSN mailing list > >> RSN@ietf.org > >> https://www1.ietf.org/mailman/listinfo/rsn > >> > >> > >> > >> _______________________________________________ > >> RSN mailing list > >> RSN@ietf.org > >> https://www1.ietf.org/mailman/listinfo/rsn > >> > >> >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 11:32:01 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmIy-0001x3-TL; Thu, 29 Nov 2007 11:32:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmIx-0001we-P7 for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 11:31:59 -0500 Received: from piper.jhuapl.edu ([128.244.26.33] helo=jhuapl.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmIw-0002tX-Q0 for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 11:31:59 -0500 Received: from ([128.244.97.110]) by piper.jhuapl.edu with ESMTP id 5502121.55470464; Thu, 29 Nov 2007 11:31:37 -0500 Message-ID: <474EE969.3020102@innovationslab.net> Date: Thu, 29 Nov 2007 11:31:37 -0500 From: Brian Haberman User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Pascal, There will be a presentation in 6MAN on a possible update to 4294 to address other changes in the standards. I would encourage people interested in including sensor-like devices in such an update to bring the topic up either in the 6MAN meeting in Vancouver, on the 6MAN mailing list, or to the author of 4294 (John Loughney). Regards, Brian Pascal Thubert (pthubert) wrote: > Hi Kris: > > For your question on ESP, AFAIK, RFC 4294 only mandates NULL > encryption and authentication for interoperability reasons. > > On the general question of RFC 4294 itself: I'm not sure the work was > ever done. I hope someone from the list can help? > > If the answer is unclear, and considering that we are re-chartering > the group, maybe we could have a work item to specify the > instantiation of RFC 4294 for LoWPAN nodes? > > Pascal ________________________________________ From: Kris Pister > [mailto:pister@eecs.berkeley.edu] Sent: Wednesday, November 28, 2007 > 5:42 PM To: Pascal Thubert (pthubert) Cc: 6lowpan Subject: Re: [RSN] > Here is the new RL2N Proposed Working Charter > > Is there an email thread somewhere that discusses the impact on > 6LoWPAN of the security requirements of 4294 and 4303? My first quick > readthrough makes me very uncomfortable that some of the mandates are > going to be ugly from a header standpoint. > > ksjp > > Pascal Thubert (pthubert) wrote: Hi JP: > > Thanks a bunch for this charter. I'll try not to rephrase what was > already discussed with Christian, Anders, Philip and Misha. > > There's an additional item I'd wish to see either in ROLL or 6LoWPAN > and I do not know exactly where it belongs, maybe both. The question > is whether we need to and can document how RFC 4294 applies for > sensors, and M2M devices in general, whether they act as hosts or as > routers. > > I've seen IPv6 presented as a Pandora box that drags just too much > stuff to be incorporated in a sensory device. For instance, at the > moment, SP100.11a endorses 6LoWPAN formats but it's not so clear at > all that IPv6 itself is mandated. A clear spec with well-documented > implementation could be a formidable tool to despond to Fear, > Uncertainty and Defiance. > > So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do > without multicast at all if ND is supported some other way (such as > suggested in: > http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-00.txt). > Maybe NULL encryption and authentication is enough etc, etc... > > Being able to define one minimum set and maybe a few other profiles > for the use cases that we selected could help tremendously. > > Otherwise I find the charter real well written and easy to digest. > From the MANEMO experience, I expect that some arguments about the > relative applicability of existing MANET protocols will be difficult > to prove without some good simulation work running agreed-upon > scenarios. > > Finally, I'm a bit confused that it seems that both IPv4 and IPv6 > seem supported. Ipv4 comes with a lot of overhead like DHCP. I > suggest that when trouble comes and things can not be done in a > common fashion for both IP protocols, hen we prioritize IPv6. > > Unfortunately, I can not make it to Vancouver, but I do feel that the > work is really needed so please count my vote in for the adoption of > the WG. > > Cheers, > > Pascal > > > -----Original Message----- From: Jean Philippe Vasseur (jvasseur) > Sent: Wednesday, November 21, 2007 9:19 PM To: rsn@ietf.org Subject: > [RSN] Here is the new RL2N Proposed Working Charter > > Dear all, > > As promised, here is the new proposed Working Group, which reflects > the number of comments/suggestions that we received, the pre-WG > consensus, ... > > Thanks to Dave Ward (RTD AD) for his input. > > Proposed RL2N WG Charter > > Description of Working Group > > L2Ns (Low power and Lossy networks) are typically composed of many > embedded devices with limited power, memory, and processing resources > interconnected by a variety of wireless links, such as IEEE 802.15.4, > Bluetooth, Low Power WiFi. > > L2Ns are transitioning to an end-to-end IP-based solution to avoid > the problems of non-interoperable networks interconnected by protocol > translation gateways and proxies. In addition, L2Ns have specific > routing requirements that are not currently met by existing routing > protocols, such as OSPF, IS-IS, AODV, and OLSR. L2N path selection > must be designed to take into consideration the specific power, > capabilities, attributes and functional characteristics of the links > and nodes in the network. > > > There is a wide scope of application areas for L2Ns, including > industrial monitoring, building automation (HVAC, lighting/access > control), connected home, healthcare, environmental monitoring, > agricultural, smart cities, logistics, assets tracking, and > refrigeration. The L2N WG will focus on routing solutions for a > subset of these deployment scenarios, namely industrial, connected > home/building and urban applications. The Working Group will > determine the routing requirements for these scenarios. > > > The Working Group will provide a routing framework for these > application scenarios that provides high reliability in the presence > of time varying loss characteristics and connectivity while > permitting low-power operation with very modest memory and CPU > pressure. > > > The Working Group will pay a particular attention to routing security > and manageability (e.g self managing/configuration) issues, which are > particularly critical for L2Ns. > > Work Items: > > - Produce use cases documents for Industrial, Connected Home, > Building and urban application networks. Each document will describe > the use case and the associated routing protocol requirements. The > documents will progress in collaboration with the 6lowpan Working > Group (INT area). > > > - Survey the applicability of existing protocols to L2Ns. The aim of > this document will be to analyze the scaling and characteristics of > existing protocols and identify whether or not they meet the routing > requirements of the L2Ns applications identified above. Existing > IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation. > > - Specification of routing metrics used in path calculation. This > includes static and dynamic link/nodes attributes required for > routing in L2Ns. > > - Provide an architectural framework for routing and path selection > at Layer 3 (Routing for L2N Architecture) * Decide whether the L2Ns > routing protocol require a distributed, centralized path computation > models or both. * Decide whether the L2N routing protocol requires a > hierarchical routing approach. > > - Produce a security framework for routing in L2Ns. > > Goals And Milestones: > > > April 2008 Submit Use case/Routing requirements for Industrial, > Connected Home, Building and Urban networks applications to the IESG > to be considered as an Informational RFC. > > August 2008: Submit Routing metrics for L2Ns document to the IESG to > be considered as an Informational RFC. > > September 2008: Submit first draft of the Routing for L2Ns > Architecture document (summary of requirements, path computation > model, flat/hierarchy,©). > > November 2008: Submit Protocol Survey to the IESG to be considered as > an Informational RFC. > > January 2009 Submit Security Framework for L2Ns to the IESG to be > considered as an Informational RFC > > February 2009: Submit the Routing for L2Ns Architecture document > (summary of requirements, metrics and attributes, path selection > model) to the IESG as an Informational RFC. > > March 2009: Recharter. > > > Please comment/suggest/... > > See you in Vancouver. > > JP and David. > > > _______________________________________________ RSN mailing list > RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn > > > > _______________________________________________ RSN mailing list > RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn > > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 12:09:56 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixmtg-0007Ck-2b; Thu, 29 Nov 2007 12:09:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixmtd-0007BX-JZ for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 12:09:54 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixmtb-0000mY-4w for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 12:09:53 -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 lATH9mVY011564; Thu, 29 Nov 2007 10:09:48 -0700 (MST) Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter From: Geoff Mulligan To: Brian Haberman In-Reply-To: <474EE969.3020102@innovationslab.net> References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474EE969.3020102@innovationslab.net> Content-Type: text/plain; charset=utf-8 Date: Thu, 29 Nov 2007 10:09:43 -0700 Message-Id: <1196356183.5692.7.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by grab.coslabs.com id lATH9mVY011564 X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org So people don't need to look it up, 6man is meeting Wednesday morning Session 1. geoff On Thu, 2007-11-29 at 11:31 -0500, Brian Haberman wrote: > Pascal, > There will be a presentation in 6MAN on a possible update to 4294= =20 > to address other changes in the standards. I would encourage people=20 > interested in including sensor-like devices in such an update to bring=20 > the topic up either in the 6MAN meeting in Vancouver, on the 6MAN=20 > mailing list, or to the author of 4294 (John Loughney). >=20 > Regards, > Brian >=20 >=20 > Pascal Thubert (pthubert) wrote: > > Hi Kris: > >=20 > > For your question on ESP, AFAIK, RFC 4294 only mandates NULL > > encryption and authentication for interoperability reasons. > >=20 > > On the general question of RFC 4294 itself: I'm not sure the work was > > ever done. I hope someone from the list can help? > >=20 > > If the answer is unclear, and considering that we are re-chartering > > the group, maybe we could have a work item to specify the > > instantiation of RFC 4294 for LoWPAN nodes? > >=20 > > Pascal ________________________________________ From: Kris Pister > > [mailto:pister@eecs.berkeley.edu] Sent: Wednesday, November 28, 2007 > > 5:42 PM To: Pascal Thubert (pthubert) Cc: 6lowpan Subject: Re: [RSN] > > Here is the new RL2N Proposed Working Charter > >=20 > > Is there an email thread somewhere that discusses the impact on > > 6LoWPAN of the security requirements of 4294 and 4303? My first quick > > readthrough makes me very uncomfortable that some of the mandates are > > going to be ugly from a header standpoint. > >=20 > > ksjp > >=20 > > Pascal Thubert (pthubert) wrote: Hi JP: > >=20 > > 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. > >=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-rou= ter-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. > >=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 when trouble comes and things can not be done in a > > common fashion for both IP protocols, hen we prioritize IPv6. > >=20 > > Unfortunately, I can not make it to Vancouver, but I do feel that the > > work is really needed so please count my vote in for the adoption of > > the WG. > >=20 > > Cheers, > >=20 > > Pascal > >=20 > >=20 > > -----Original Message----- From: Jean Philippe Vasseur (jvasseur)=20 > > 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 > > 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. > >=20 > >=20 > > 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. > >=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 with 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 > > 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). > >=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 > > 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: > >=20 > >=20 > > 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,=C5=A0). > >=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 > > considered as an Informational RFC > >=20 > > 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 > >=20 > > Please comment/suggest/... > >=20 > > See you in Vancouver. > >=20 > > JP and David. > >=20 > >=20 > > _______________________________________________ RSN mailing list=20 > > RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn > >=20 > >=20 > >=20 > > _______________________________________________ RSN mailing list=20 > > RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn > >=20 > >=20 > > _______________________________________________ 6lowpan mailing list=20 > > 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 12:35:34 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnIR-0004GQ-K5; Thu, 29 Nov 2007 12:35:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnIQ-0004G9-9w for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 12:35:30 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxnIN-0005Zy-CE for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 12:35:30 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194217200"; d="scan'208";a="159156447" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Nov 2007 18:35: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 lATHZMQg027941; Thu, 29 Nov 2007 18:35:22 +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 lATHZ13t019121; Thu, 29 Nov 2007 17:35:21 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 18:35:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Subject: RE: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Thu, 29 Nov 2007 18:35:02 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D9DE9F@xmb-ams-337.emea.cisco.com> In-Reply-To: <474EE969.3020102@innovationslab.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: AcgypXAf3J6QNODuQKiwChOdH7010gACJ1yg References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu><7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474EE969.3020102@innovationslab.net> From: "Pascal Thubert (pthubert)" To: "Brian Haberman" , "6lowpan" <6lowpan@lists.ietf.org> X-OriginalArrivalTime: 29 Nov 2007 17:35:06.0175 (UTC) FILETIME=[2E40B4F0:01C832AE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9004; t=1196357722; x=1197221722; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20RE=3A=20[RSN]=20Here=20is=20the=20new=20R L2N=20Proposed=20Working=20Charter |Sender:=20; bh=YMfn1M0mPl9y2SN7UXzsQ6snfNndZHU4yk/MJU0bOag=; b=nwBSQe2VFzJxzKUWuWXAH1hoj0hJd2ruevXOGCQMt3Kn8IOd5mhbhRJnS/AKK6V1F9e7JEIU yIsOPqNkr0uBkVpq7mJF8JAZiJ2KXtoxDNNObKVS2sVABi2RYpuTPVbI; 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: a4a24b484706be629f915bfb1a3e4771 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Thanks a bunch Brian, 6MAN, then. Pascal >-----Original Message----- >From: Brian Haberman [mailto:brian@innovationslab.net] >Sent: Thursday, November 29, 2007 5:32 PM >To: 6lowpan >Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working = Charter > >Pascal, > There will be a presentation in 6MAN on a possible update to 4294 >to address other changes in the standards. I would encourage people >interested in including sensor-like devices in such an update to bring >the topic up either in the 6MAN meeting in Vancouver, on the 6MAN >mailing list, or to the author of 4294 (John Loughney). > >Regards, >Brian > > >Pascal Thubert (pthubert) wrote: >> Hi Kris: >> >> For your question on ESP, AFAIK, RFC 4294 only mandates NULL >> encryption and authentication for interoperability reasons. >> >> On the general question of RFC 4294 itself: I'm not sure the work was >> ever done. I hope someone from the list can help? >> >> If the answer is unclear, and considering that we are re-chartering >> the group, maybe we could have a work item to specify the >> instantiation of RFC 4294 for LoWPAN nodes? >> >> Pascal ________________________________________ From: Kris Pister >> [mailto:pister@eecs.berkeley.edu] Sent: Wednesday, November 28, 2007 >> 5:42 PM To: Pascal Thubert (pthubert) Cc: 6lowpan Subject: Re: [RSN] >> Here is the new RL2N Proposed Working Charter >> >> Is there an email thread somewhere that discusses the impact on >> 6LoWPAN of the security requirements of 4294 and 4303? My first quick >> readthrough makes me very uncomfortable that some of the mandates are >> going to be ugly from a header standpoint. >> >> ksjp >> >> Pascal Thubert (pthubert) wrote: Hi JP: >> >> Thanks a bunch for this charter. I'll try not to rephrase what was >> already discussed with Christian, Anders, Philip and Misha. >> >> There's an additional item I'd wish to see either in ROLL or 6LoWPAN >> and I do not know exactly where it belongs, maybe both. The question >> is whether we need to and can document how RFC 4294 applies for >> sensors, and M2M devices in general, whether they act as hosts or as >> routers. >> >> I've seen IPv6 presented as a Pandora box that drags just too much >> stuff to be incorporated in a sensory device. For instance, at the >> moment, SP100.11a endorses 6LoWPAN formats but it's not so clear at >> all that IPv6 itself is mandated. A clear spec with well-documented >> implementation could be a formidable tool to despond to Fear, >> Uncertainty and Defiance. >> >> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do >> without multicast at all if ND is supported some other way (such as >> suggested in: >> = http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-= 00.txt). >> Maybe NULL encryption and authentication is enough etc, etc... >> >> Being able to define one minimum set and maybe a few other profiles >> for the use cases that we selected could help tremendously. >> >> Otherwise I find the charter real well written and easy to digest. >> From the MANEMO experience, I expect that some arguments about the >> relative applicability of existing MANET protocols will be difficult >> to prove without some good simulation work running agreed-upon >> scenarios. >> >> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 >> seem supported. Ipv4 comes with a lot of overhead like DHCP. I >> suggest that when trouble comes and things can not be done in a >> common fashion for both IP protocols, hen we prioritize IPv6. >> >> Unfortunately, I can not make it to Vancouver, but I do feel that the >> work is really needed so please count my vote in for the adoption of >> the WG. >> >> Cheers, >> >> Pascal >> >> >> -----Original Message----- From: Jean Philippe Vasseur (jvasseur) >> Sent: Wednesday, November 21, 2007 9:19 PM To: rsn@ietf.org Subject: >> [RSN] Here is the new RL2N Proposed Working Charter >> >> Dear all, >> >> As promised, here is the new proposed Working Group, which reflects >> the number of comments/suggestions that we received, the pre-WG >> consensus, ... >> >> Thanks to Dave Ward (RTD AD) for his input. >> >> Proposed RL2N WG Charter >> >> Description of Working Group >> >> L2Ns (Low power and Lossy networks) are typically composed of many >> embedded devices with limited power, memory, and processing resources >> interconnected by a variety of wireless links, such as IEEE 802.15.4, >> Bluetooth, Low Power WiFi. >> >> L2Ns are transitioning to an end-to-end IP-based solution to avoid >> the problems of non-interoperable networks interconnected by protocol >> translation gateways and proxies. In addition, L2Ns have specific >> routing requirements that are not currently met by existing routing >> protocols, such as OSPF, IS-IS, AODV, and OLSR. L2N path selection >> must be designed to take into consideration the specific power, >> capabilities, attributes and functional characteristics of the links >> and nodes in the network. >> >> >> There is a wide scope of application areas for L2Ns, including >> industrial monitoring, building automation (HVAC, lighting/access >> control), connected home, healthcare, environmental monitoring, >> agricultural, smart cities, logistics, assets tracking, and >> refrigeration. The L2N WG will focus on routing solutions for a >> subset of these deployment scenarios, namely industrial, connected >> home/building and urban applications. The Working Group will >> determine the routing requirements for these scenarios. >> >> >> The Working Group will provide a routing framework for these >> application scenarios that provides high reliability in the presence >> of time varying loss characteristics and connectivity while >> permitting low-power operation with very modest memory and CPU >> pressure. >> >> >> The Working Group will pay a particular attention to routing security >> and manageability (e.g self managing/configuration) issues, which are >> particularly critical for L2Ns. >> >> Work Items: >> >> - Produce use cases documents for Industrial, Connected Home, >> Building and urban application networks. Each document will describe >> the use case and the associated routing protocol requirements. The >> documents will progress in collaboration with the 6lowpan Working >> Group (INT area). >> >> >> - Survey the applicability of existing protocols to L2Ns. The aim of >> this document will be to analyze the scaling and characteristics of >> existing protocols and identify whether or not they meet the routing >> requirements of the L2Ns applications identified above. Existing >> IGPs, MANET, NEMO, DTN routing protocols will be part of evaluation. >> >> - Specification of routing metrics used in path calculation. This >> includes static and dynamic link/nodes attributes required for >> routing in L2Ns. >> >> - Provide an architectural framework for routing and path selection >> at Layer 3 (Routing for L2N Architecture) * Decide whether the L2Ns >> routing protocol require a distributed, centralized path computation >> models or both. * Decide whether the L2N routing protocol requires a >> hierarchical routing approach. >> >> - Produce a security framework for routing in L2Ns. >> >> Goals And Milestones: >> >> >> April 2008 Submit Use case/Routing requirements for Industrial, >> Connected Home, Building and Urban networks applications to the IESG >> to be considered as an Informational RFC. >> >> August 2008: Submit Routing metrics for L2Ns document to the IESG to >> be considered as an Informational RFC. >> >> September 2008: Submit first draft of the Routing for L2Ns >> Architecture document (summary of requirements, path computation >> model, flat/hierarchy,=A9). >> >> November 2008: Submit Protocol Survey to the IESG to be considered as >> an Informational RFC. >> >> January 2009 Submit Security Framework for L2Ns to the IESG to be >> considered as an Informational RFC >> >> February 2009: Submit the Routing for L2Ns Architecture document >> (summary of requirements, metrics and attributes, path selection >> model) to the IESG as an Informational RFC. >> >> March 2009: Recharter. >> >> >> Please comment/suggest/... >> >> See you in Vancouver. >> >> JP and David. >> >> >> _______________________________________________ RSN mailing list >> RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn >> >> >> >> _______________________________________________ RSN mailing list >> RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn >> >> >> _______________________________________________ 6lowpan mailing list >> 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 13:59:55 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixoc5-0004M8-5I; Thu, 29 Nov 2007 13:59:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixoc3-0004La-EG for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 13:59:51 -0500 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixoc2-0004D3-6g for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 13:59:51 -0500 Received: from [192.168.1.140] (66.237.74.130.ptr.us.xo.net [66.237.74.130]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.2/8.13.5) with ESMTP id lATIxli1019416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Nov 2007 10:59:49 -0800 (PST) Message-ID: <474F0C23.5070008@eecs.berkeley.edu> Date: Thu, 29 Nov 2007 10:59:47 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Geoff Mulligan Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> In-Reply-To: <1196351528.5692.0.camel@dellx1> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by gateway0.EECS.Berkeley.EDU id lATIxli1019416 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Geoff - ooh, I like exceptions. Did we try to get an exception on the UDP checksum? It's painful to=20 leave that in the compressed header if we have L2 message integrity. ksjp Geoff Mulligan wrote: > We have already received an exception from the IESG to IPsec on 6lowpan > devices. > > geoff > > On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote: > =20 >> Hum...=20 >> >> I had missed that; Seems that we have to make an exception :) If you c= onsider ISA100.11a, they already have security at L2 and L5, it makes lit= tle sense to MUST IPSec on top of that. >> >> Pascal >> >> =20 >>> -----Original Message----- >>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>> Sent: Wednesday, November 28, 2007 8:03 PM >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan >>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>> >>> Hmm. From 4294: >>> >>> "However, while authentication and encryption can each be NULL, they >>> MUST NOT both be NULL." >>> >>> ksjp >>> >>> Pascal Thubert (pthubert) wrote: >>> =20 >>>> Hi Kris: >>>> >>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL encrypt= ion and authentication for >>>> =20 >>> interoperability reasons. >>> =20 >>>> On the general question of RFC 4294 itself: I'm not sure the work wa= s ever done. I hope someone >>>> =20 >> >from the list can help? >> =20 >>>> If the answer is unclear, and considering that we are re-chartering = the group, maybe we could have >>>> =20 >>> a work item to specify the instantiation of RFC 4294 for LoWPAN nodes= ? >>> =20 >>>> Pascal >>>> ________________________________________ >>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan >>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>> >>>> Is there an email thread somewhere that discusses the impact on 6LoW= PAN of the security >>>> =20 >>> requirements of 4294 and 4303? >>> =20 >>>> My first quick readthrough makes me very uncomfortable that some of = the mandates are going to be >>>> =20 >>> ugly from a header standpoint. >>> =20 >>>> ksjp >>>> >>>> Pascal Thubert (pthubert) wrote: >>>> Hi JP: >>>> >>>> Thanks a bunch for this charter. I'll try not to rephrase what was a= lready discussed with Christian, >>>> =20 >>> 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 >>>> =20 >>> 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 s= tuff to be incorporated in a >>>> =20 >>> sensory device. For instance, at the moment, SP100.11a endorses 6LoWP= AN formats but it's not so clear >>> at all that IPv6 itself is mandated. A clear spec with well-documente= d 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 wi= thout multicast at all if ND is >>>> =20 >>> supported some other way (such as suggested in: http://www.ietf.org/i= nternet-drafts/draft-thubert- >>> lowpan-backbone-router-00.txt). Maybe NULL encryption and authenticat= ion is enough etc, etc... >>> =20 >>>> Being able to define one minimum set and maybe a few other profiles = for the use cases that we >>>> =20 >>> selected could help tremendously. >>> =20 >>>> Otherwise I find the charter real well written and easy to digest. >= >From the MANEMO experience, I >>>> =20 >>> expect that some arguments about the relative applicability of existi= ng MANET protocols will be >>> difficult to prove without some good simulation work running agreed-u= pon scenarios. >>> =20 >>>> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 se= em supported. Ipv4 comes with a >>>> =20 >>> lot of overhead like DHCP. I suggest that when trouble comes and thin= gs can not be done in a common >>> fashion for both IP protocols, hen we prioritize IPv6. >>> =20 >>>> Unfortunately, I can not make it to Vancouver, but I do feel that th= e work is really needed so >>>> =20 >>> please count my vote in for the adoption of the WG. >>> =20 >>>> Cheers, >>>> >>>> Pascal >>>> >>>> >>>> -----Original Message----- >>>> From: Jean Philippe Vasseur (jvasseur) >>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>> To: rsn@ietf.org >>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>> >>>> Dear all, >>>> >>>> As promised, here is the new proposed Working Group, which reflects = the >>>> number of comments/suggestions that we received, the pre-WG consensu= s, ... >>>> >>>> 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 e= mbedded >>>> devices with limited power, memory, and processing resources interco= nnected >>>> by a variety of wireless links, such as IEEE 802.15.4, Bluetooth, Lo= w Power >>>> WiFi. >>>> >>>> L2Ns are transitioning to an end-to-end IP-based solution to avoid t= he >>>> problems of non-interoperable networks interconnected by protocol >>>> translation gateways and proxies. In addition, L2Ns have specific ro= uting >>>> requirements that are not currently met by existing routing protocol= s, 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 indus= trial >>>> monitoring, building automation (HVAC, lighting/access control), con= nected >>>> home, healthcare, environmental monitoring, agricultural, smart citi= es, >>>> 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 Work= ing >>>> Group will determine the routing requirements for these scenarios. >>>> >>>> >>>> The Working Group will provide a routing framework for these applica= tion >>>> scenarios that provides high reliability in the presence of time var= ying >>>> loss characteristics and connectivity while permitting low-power ope= ration >>>> with very modest memory and CPU pressure. >>>> >>>> >>>> The Working Group will pay a particular attention to routing securit= y and >>>> manageability (e.g self managing/configuration) issues, which are >>>> particularly critical for L2Ns. >>>> >>>> Work Items: >>>> >>>> - Produce use cases documents for Industrial, Connected Home, Buildi= ng and >>>> urban application networks. Each document will describe the use case= and the >>>> associated routing protocol requirements. The documents will progres= s 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 exist= ing >>>> protocols and identify whether or not they meet the routing requirem= ents 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 in= cludes >>>> static and dynamic link/nodes attributes required for routing in L2N= s. >>>> >>>> - 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 ro= uting >>>> approach. >>>> >>>> - Produce a security framework for routing in L2Ns. >>>> >>>> Goals And Milestones: >>>> >>>> >>>> April 2008 Submit Use case/Routing requirements for Industrial, Conn= ected >>>> Home, Building and Urban networks applications to the IESG to be con= sidered >>>> 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 Architect= ure >>>> document (summary of requirements, path computation model, >>>> flat/hierarchy,=C5=A0). >>>> >>>> November 2008: Submit Protocol Survey to the IESG to be considered a= s an >>>> Informational RFC. >>>> >>>> January 2009 Submit Security Framework for L2Ns to the IESG to be co= nsidered >>>> as an Informational RFC >>>> >>>> February 2009: Submit the Routing for L2Ns Architecture document (s= ummary >>>> of requirements, metrics and attributes, path selection model) to th= e IESG >>>> as an Informational RFC. >>>> >>>> March 2009: Recharter. >>>> >>>> >>>> Please comment/suggest/... >>>> >>>> See you in Vancouver. >>>> >>>> JP and David. >>>> >>>> >>>> _______________________________________________ >>>> RSN mailing list >>>> RSN@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/rsn >>>> >>>> >>>> >>>> _______________________________________________ >>>> RSN mailing list >>>> RSN@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/rsn >>>> >>>> >>>> =20 >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www1.ietf.org/mailman/listinfo/6lowpan >> =20 > > =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 14:06:41 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixoif-0006wv-6n; Thu, 29 Nov 2007 14:06:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixoie-0006wl-OC for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 14:06:40 -0500 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixoid-0005p0-EP for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 14:06:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 2D122A960B; Thu, 29 Nov 2007 11:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-10 required=6.6 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOLJDunAJEtA; Thu, 29 Nov 2007 11:06:36 -0800 (PST) Received: from [192.168.7.195] (69-12-164-136.sfo.archedrock.com [69.12.164.136]) by mail.sf.archrock.com (Postfix) with ESMTP id 44C89A95E9; Thu, 29 Nov 2007 11:06:36 -0800 (PST) Message-ID: <474F0DB8.6080706@archrock.com> Date: Thu, 29 Nov 2007 11:06:32 -0800 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Kris Pister Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> In-Reply-To: <474F0C23.5070008@eecs.berkeley.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Note that L2 message integrity doesn't provide end-to-end message=20 integrity, which L4 checksums (that cover the L3 header) provide. -- Jonathan Hui Kris Pister wrote: > Geoff - ooh, I like exceptions. > Did we try to get an exception on the UDP checksum? It's painful to=20 > leave that in the compressed header if we have L2 message integrity. >=20 > ksjp >=20 > Geoff Mulligan wrote: >> We have already received an exception from the IESG to IPsec on 6lowpa= n >> devices. >> >> geoff >> >> On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote: >> =20 >>> Hum... >>> I had missed that; Seems that we have to make an exception :) If you=20 >>> consider ISA100.11a, they already have security at L2 and L5, it=20 >>> makes little sense to MUST IPSec on top of that. >>> >>> Pascal >>> >>> =20 >>>> -----Original Message----- >>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>> Sent: Wednesday, November 28, 2007 8:03 PM >>>> To: Pascal Thubert (pthubert) >>>> Cc: 6lowpan >>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>> >>>> Hmm. From 4294: >>>> >>>> "However, while authentication and encryption can each be NULL, they >>>> MUST NOT both be NULL." >>>> >>>> ksjp >>>> >>>> Pascal Thubert (pthubert) wrote: >>>> =20 >>>>> Hi Kris: >>>>> >>>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL=20 >>>>> encryption and authentication for >>>>> =20 >>>> interoperability reasons. >>>> =20 >>>>> On the general question of RFC 4294 itself: I'm not sure the work=20 >>>>> was ever done. I hope someone >>>>> =20 >>> >from the list can help? >>> =20 >>>>> If the answer is unclear, and considering that we are re-chartering= =20 >>>>> the group, maybe we could have >>>>> =20 >>>> a work item to specify the instantiation of RFC 4294 for LoWPAN node= s? >>>> =20 >>>>> Pascal >>>>> ________________________________________ >>>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >>>>> Sent: Wednesday, November 28, 2007 5:42 PM >>>>> To: Pascal Thubert (pthubert) >>>>> Cc: 6lowpan >>>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter >>>>> >>>>> Is there an email thread somewhere that discusses the impact on=20 >>>>> 6LoWPAN of the security >>>>> =20 >>>> requirements of 4294 and 4303? >>>> =20 >>>>> My first quick readthrough makes me very uncomfortable that some of= =20 >>>>> the mandates are going to be >>>>> =20 >>>> ugly from a header standpoint. >>>> =20 >>>>> ksjp >>>>> >>>>> Pascal Thubert (pthubert) wrote: >>>>> Hi JP: >>>>> >>>>> Thanks a bunch for this charter. I'll try not to rephrase what was=20 >>>>> already discussed with Christian, >>>>> =20 >>>> Anders, Philip and Misha. >>>> =20 >>>>> There's an additional item I'd wish to see either in ROLL or=20 >>>>> 6LoWPAN and I do not know exactly >>>>> =20 >>>> where it belongs, maybe both. The question is whether we need to and= =20 >>>> can document how RFC 4294 >>>> applies for sensors, and M2M devices in general, whether they act as= =20 >>>> hosts or as routers. >>>> =20 >>>>> I've seen IPv6 presented as a Pandora box that drags just too much=20 >>>>> stuff to be incorporated in a >>>>> =20 >>>> sensory device. For instance, at the moment, SP100.11a endorses=20 >>>> 6LoWPAN formats but it's not so clear >>>> at all that IPv6 itself is mandated. A clear spec with=20 >>>> well-documented implementation could be a >>>> formidable tool to despond to Fear, Uncertainty and Defiance. >>>> =20 >>>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can do=20 >>>>> without multicast at all if ND is >>>>> =20 >>>> supported some other way (such as suggested in:=20 >>>> http://www.ietf.org/internet-drafts/draft-thubert- >>>> lowpan-backbone-router-00.txt). Maybe NULL encryption and=20 >>>> authentication is enough etc, etc... >>>> =20 >>>>> Being able to define one minimum set and maybe a few other profiles= =20 >>>>> for the use cases that we >>>>> =20 >>>> selected could help tremendously. >>>> =20 >>>>> Otherwise I find the charter real well written and easy to digest.=20 >>>>> >>From the MANEMO experience, I >>>>> =20 >>>> expect that some arguments about the relative applicability of=20 >>>> existing MANET protocols will be >>>> difficult to prove without some good simulation work running=20 >>>> agreed-upon scenarios. >>>> =20 >>>>> Finally, I'm a bit confused that it seems that both IPv4 and IPv6=20 >>>>> seem supported. Ipv4 comes with a >>>>> =20 >>>> lot of overhead like DHCP. I suggest that when trouble comes and=20 >>>> things can not be done in a common >>>> fashion for both IP protocols, hen we prioritize IPv6. >>>> =20 >>>>> Unfortunately, I can not make it to Vancouver, but I do feel that=20 >>>>> the work is really needed so >>>>> =20 >>>> please count my vote in for the adoption of the WG. >>>> =20 >>>>> Cheers, >>>>> >>>>> Pascal >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Jean Philippe Vasseur (jvasseur) >>>>> Sent: Wednesday, November 21, 2007 9:19 PM >>>>> To: rsn@ietf.org >>>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >>>>> >>>>> Dear all, >>>>> >>>>> As promised, here is the new proposed Working Group, which 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, namel= y >>>>> 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 L2= Ns. >>>>> >>>>> - Provide an architectural framework for routing and path selection= =20 >>>>> at Layer >>>>> 3 (Routing for L2N Architecture) >>>>> * Decide whether the L2Ns routing protocol require a distributed, >>>>> centralized path computation models or both. >>>>> * Decide whether the L2N routing protocol requires a hierarchical=20 >>>>> routing >>>>> approach. >>>>> >>>>> - Produce a security framework for routing in L2Ns. >>>>> >>>>> Goals And Milestones: >>>>> >>>>> >>>>> April 2008 Submit Use case/Routing requirements for Industrial,=20 >>>>> Connected >>>>> Home, Building and Urban networks applications to the IESG to be=20 >>>>> considered >>>>> as an Informational RFC. >>>>> >>>>> August 2008: Submit Routing metrics for L2Ns document to the IESG=20 >>>>> to be >>>>> considered as an Informational RFC. >>>>> >>>>> September 2008: Submit first draft of the Routing for L2Ns=20 >>>>> Architecture >>>>> document (summary of requirements, path computation model, >>>>> flat/hierarchy,=C5=A0). >>>>> >>>>> November 2008: Submit Protocol Survey to the IESG to be 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 >>>>> >>>>> >>>>> =20 >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www1.ietf.org/mailman/listinfo/6lowpan >>> =20 >> >> =20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 14:09:12 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixol6-000165-1X; Thu, 29 Nov 2007 14:09:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixol5-00015t-L8 for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 14:09:11 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixol3-0006WE-8R for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 14:09:11 -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 lATJ97fL012563; Thu, 29 Nov 2007 12:09:07 -0700 (MST) Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter From: Geoff Mulligan To: Kris Pister In-Reply-To: <474F0C23.5070008@eecs.berkeley.edu> References: <7892795E1A87F04CADFCCF41FADD00FC04D9D877@xmb-ams-337.emea.cisco.com> <474D9A60.3040808@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DA5A@xmb-ams-337.emea.cisco.com> <474DBB4A.2030605@eecs.berkeley.edu> <7892795E1A87F04CADFCCF41FADD00FC04D9DDD2@xmb-ams-337.emea.cisco.com> <1196351528.5692.0.camel@dellx1> <474F0C23.5070008@eecs.berkeley.edu> Content-Type: text/plain; charset=utf-8 Date: Thu, 29 Nov 2007 12:09:02 -0700 Message-Id: <1196363342.5692.52.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by grab.coslabs.com id lATJ97fL012563 X-Spam-Score: 0.0 (/) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org We did not try to get an exception to UDP checksums. geoff On Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote: > Geoff - ooh, I like exceptions. > Did we try to get an exception on the UDP checksum? It's painful to=20 > leave that in the compressed header if we have L2 message integrity. >=20 > ksjp >=20 > Geoff Mulligan wrote: > > We have already received an exception from the IESG to IPsec on 6lowp= an > > devices. > > > > geoff > > > > On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) wrote: > > =20 > >> Hum...=20 > >> > >> I had missed that; Seems that we have to make an exception :) If you= consider ISA100.11a, they already have security at L2 and L5, it makes l= ittle sense to MUST IPSec on top of that. > >> > >> Pascal > >> > >> =20 > >>> -----Original Message----- > >>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] > >>> Sent: Wednesday, November 28, 2007 8:03 PM > >>> To: Pascal Thubert (pthubert) > >>> Cc: 6lowpan > >>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > >>> > >>> Hmm. From 4294: > >>> > >>> "However, while authentication and encryption can each be NULL, the= y > >>> MUST NOT both be NULL." > >>> > >>> ksjp > >>> > >>> Pascal Thubert (pthubert) wrote: > >>> =20 > >>>> Hi Kris: > >>>> > >>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL encry= ption and authentication for > >>>> =20 > >>> interoperability reasons. > >>> =20 > >>>> On the general question of RFC 4294 itself: I'm not sure the work = was ever done. I hope someone > >>>> =20 > >> >from the list can help? > >> =20 > >>>> If the answer is unclear, and considering that we are re-charterin= g the group, maybe we could have > >>>> =20 > >>> a work item to specify the instantiation of RFC 4294 for LoWPAN nod= es? > >>> =20 > >>>> Pascal > >>>> ________________________________________ > >>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] > >>>> Sent: Wednesday, November 28, 2007 5:42 PM > >>>> To: Pascal Thubert (pthubert) > >>>> Cc: 6lowpan > >>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > >>>> > >>>> Is there an email thread somewhere that discusses the impact on 6L= oWPAN of the security > >>>> =20 > >>> requirements of 4294 and 4303? > >>> =20 > >>>> My first quick readthrough makes me very uncomfortable that some o= f the mandates are going to be > >>>> =20 > >>> ugly from a header standpoint. > >>> =20 > >>>> ksjp > >>>> > >>>> Pascal Thubert (pthubert) wrote: > >>>> Hi JP: > >>>> > >>>> Thanks a bunch for this charter. I'll try not to rephrase what was= already discussed with Christian, > >>>> =20 > >>> Anders, Philip and Misha. > >>> =20 > >>>> There's an additional item I'd wish to see either in ROLL or 6LoWP= AN and I do not know exactly > >>>> =20 > >>> where it belongs, maybe both. The question is whether we need to an= d can document how RFC 4294 > >>> applies for sensors, and M2M devices in general, whether they act a= s 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 > >>>> =20 > >>> sensory device. For instance, at the moment, SP100.11a endorses 6Lo= WPAN formats but it's not so clear > >>> at all that IPv6 itself is mandated. A clear spec with well-documen= ted 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 > >>>> =20 > >>> 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 authentic= ation is enough etc, etc... > >>> =20 > >>>> Being able to define one minimum set and maybe a few other profile= s for the use cases that we > >>>> =20 > >>> selected could help tremendously. > >>> =20 > >>>> Otherwise I find the charter real well written and easy to digest.= >>From the MANEMO experience, I > >>>> =20 > >>> expect that some arguments about the relative applicability of exis= ting MANET protocols will be > >>> difficult to prove without some good simulation work running agreed= -upon scenarios. > >>> =20 > >>>> Finally, I'm a bit confused that it seems that both IPv4 and IPv6 = seem supported. Ipv4 comes with a > >>>> =20 > >>> lot of overhead like DHCP. I suggest that when trouble comes and th= ings can not be done in a common > >>> fashion for both IP protocols, hen we prioritize IPv6. > >>> =20 > >>>> Unfortunately, I can not make it to Vancouver, but I do feel that = the work is really needed so > >>>> =20 > >>> please count my vote in for the adoption of the WG. > >>> =20 > >>>> Cheers, > >>>> > >>>> Pascal > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Jean Philippe Vasseur (jvasseur) > >>>> Sent: Wednesday, November 21, 2007 9:19 PM > >>>> To: rsn@ietf.org > >>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter > >>>> > >>>> Dear all, > >>>> > >>>> As promised, here is the new proposed Working Group, which reflect= s the > >>>> number of comments/suggestions that we received, the pre-WG consen= sus, ... > >>>> > >>>> 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 inter= connected > >>>> 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 protoc= ols, such > >>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be designe= d to take > >>>> into consideration the specific power, capabilities, attributes an= d > >>>> functional characteristics of the links and nodes in the network. > >>>> > >>>> > >>>> There is a wide scope of application areas for L2Ns, including ind= ustrial > >>>> monitoring, building automation (HVAC, lighting/access control), c= onnected > >>>> home, healthcare, environmental monitoring, agricultural, smart ci= ties, > >>>> logistics, assets tracking, and refrigeration. The L2N WG will foc= us on > >>>> routing solutions for a subset of these deployment scenarios, name= ly > >>>> industrial, connected home/building and urban applications. The Wo= rking > >>>> Group will determine the routing requirements for these scenarios. > >>>> > >>>> > >>>> The Working Group will provide a routing framework for these appli= cation > >>>> scenarios that provides high reliability in the presence of time v= arying > >>>> loss characteristics and connectivity while permitting low-power o= peration > >>>> with very modest memory and CPU pressure. > >>>> > >>>> > >>>> The Working Group will pay a particular attention to routing secur= ity and > >>>> manageability (e.g self managing/configuration) issues, which are > >>>> particularly critical for L2Ns. > >>>> > >>>> Work Items: > >>>> > >>>> - Produce use cases documents for Industrial, Connected Home, Buil= ding and > >>>> urban application networks. Each document will describe the use ca= se and the > >>>> associated routing protocol requirements. The documents will progr= ess 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 exi= sting > >>>> protocols and identify whether or not they meet the routing requir= ements 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 L= 2Ns. > >>>> > >>>> - Provide an architectural framework for routing and path selectio= n 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, Co= nnected > >>>> Home, Building and Urban networks applications to the IESG to be c= onsidered > >>>> 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 Archite= cture > >>>> document (summary of requirements, path computation model, > >>>> flat/hierarchy,=C5=A0). > >>>> > >>>> 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 > >>>> > >>>> > >>>> =20 > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www1.ietf.org/mailman/listinfo/6lowpan > >> =20 > > > > =20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Thu Nov 29 23:04:42 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixx7E-0005Y7-DV; Thu, 29 Nov 2007 23:04:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixx7C-0005Xg-FN for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 23:04:34 -0500 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixx7A-0004MN-Rq for 6lowpan@lists.ietf.org; Thu, 29 Nov 2007 23:04:34 -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 lAU41L1K015295; Thu, 29 Nov 2007 21:01:21 -0700 (MST) Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter From: Geoff Mulligan To: gabriel montenegro In-Reply-To: <750929.34078.qm@web81904.mail.mud.yahoo.com> References: <750929.34078.qm@web81904.mail.mud.yahoo.com> Content-Type: text/plain; charset=utf-8 Date: Thu, 29 Nov 2007 21:01:18 -0700 Message-Id: <1196395279.5692.78.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by grab.coslabs.com id lAU41L1K015295 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org I will search back, but m recollection was that we (you) did argue with the IESG that devices such as these (small 8bit micro sensors) would not be capable of IPsec and after a few emails back a forth we were told that 6lowpan devices did not need to support IPsec. Again I will look back and see if I can find the email exchange and I'll ask Russ. geoff On Thu, 2007-11-29 at 17:13 -0800, gabriel montenegro wrote: > Geoff,=20 >=20 > Could you please provide a pointer to the message or document with > that exception?=20 > This is an important item and it should be added to the group's Wiki > page. >=20 > My recollection is different, but I may have just forgotten. What I > recollect is that back when we=20 > were starting the working group and initiating work on the problem > statement draft, was that the recommendation > was to stay away from issuing our own IPv6 profile, precisely because > saying things like ("IPsec is not recommended in lowpan > environments") was a sure-fire way to invite controversy at the IESG. > E.g., IPv6 mandates IPsec, so how could > we ever claim to support IPv6.... This debate probably is better had > in 6man in terms of a revision of the hosts > requirements, rather than in any particular WG. >=20 > -gabriel >=20 > ----- Original Message ---- > From: Geoff Mulligan > To: Kris Pister > Cc: 6lowpan <6lowpan@lists.ietf.org> > Sent: Thursday, November 29, 2007 11:09:02 AM > Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working > Charter >=20 > We did not try to get an exception to UDP checksums. >=20 > geoff >=20 > On Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote: > > Geoff - ooh, I like exceptions. > > Did we try to get an exception on the UDP checksum? It's painful > to=20 > > leave that in the compressed header if we have L2 message integrity. > >=20 > > ksjp > >=20 > > Geoff Mulligan wrote: > > > We have already received an exception from the IESG to IPsec on > 6lowpan > > > devices. > > > > > > geoff > > > > > > On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) > wrote: > > > =20 > > >> Hum...=20 > > >> > > >> I had missed that; Seems that we have to make an exception :) If > you consider ISA100.11a, they already have security at L2 and L5, it > makes little sense to MUST IPSec on top of that. > > >> > > >> Pascal > > >> > > >> =20 > > >>> -----Original Message----- > > >>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] > > >>> Sent: Wednesday, November 28, 2007 8:03 PM > > >>> To: Pascal Thubert (pthubert) > > >>> Cc: 6lowpan > > >>> Subject: Re: [RSN] Here is the new RL2N Proposed Working Charter > > >>> > > >>> Hmm. From 4294: > > >>> > > >>> "However, while authentication and encryption can each be NULL, > they > > >>> MUST NOT both be NULL." > > >>> > > >>> ksjp > > >>> > > >>> Pascal Thubert (pthubert) wrote: > > >>> =20 > > >>>> Hi Kris: > > >>>> > > >>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL > encryption and authentication for > > >>>> =20 > > >>> interoperability reasons. > > >>> =20 > > >>>> On the general question of RFC 4294 itself: I'm not sure the > work was ever done. I hope someone > > >>>> =20 > > >> >from the list can help? > > >> =20 > > >>>> If the answer is unclear, and considering that we are > re-chartering the group, maybe we could have > > >>>> =20 > > >>> a work item to specify the instantiation of RFC 4294 for LoWPAN > nodes? > > >>> =20 > > >>>> Pascal > > >>>> ________________________________________ > > >>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] > > >>>> Sent: Wednesday, November 28, 2007 5:42 PM > > >>>> To: Pascal Thubert (pthubert) > > >>>> Cc: 6lowpan > > >>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working > Charter > > >>>> > > >>>> Is there an email thread somewhere that discusses the impact on > 6LoWPAN of the security > > >>>> =20 > > >>> requirements of 4294 and 4303? > > >>> =20 > > >>>> My first quick readthrough makes me very uncomfortable that > some of the mandates are going to be > > >>>> =20 > > >>> ugly from a header standpoint. > > >>> =20 > > >>>> ksjp > > >>>> > > >>>> Pascal Thubert (pthubert) wrote: > > >>>> Hi JP: > > >>>> > > >>>> Thanks a bunch for this charter. I'll try not to rephrase what > was already discussed with Christian, > > >>>> =20 > > >>> Anders, Philip and Misha. > > >>> =20 > > >>>> There's an additional item I'd wish to see either in ROLL or > 6LoWPAN and I do not know exactly > > >>>> =20 > > >>> 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 > > >>>> =20 > > >>> 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 > > >>>> =20 > > >>> 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 > > >>>> =20 > > >>> selected could help tremendously. > > >>> =20 > > >>>> Otherwise I find the charter real well written and easy to > digest. >>From the MANEMO experience, I > > >>>> =20 > > >>> 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. > > >>> =20 > > >>>> Finally, I'm a bit confused that it seems that both IPv4 and > IPv6 seem supported. Ipv4 comes with a > > >>>> =20 > > >>> 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. > > >>> =20 > > >>>> Unfortunately, I can not make it to Vancouver, but I do feel > that the work is really needed so > > >>>> =20 > > >>> please count my vote in for the adoption of the WG. > > >>> =20 > > >>>> Cheers, > > >>>> > > >>>> Pascal > > >>>> > > >>>> > > >>>> -----Original Message----- > > >>>> From: Jean Philippe Vasseur (jvasseur) > > >>>> Sent: Wednesday, November 21, 2007 9:19 PM > > >>>> To: rsn@ietf.org > > >>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter > > >>>> > > >>>> Dear all, > > >>>> > > >>>> As promised, here is the new proposed Working Group, which > 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,=C5=A0). > > >>>> > > >>>> 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 > > >>>> > > >>>> > > >>>> =20 > > >> _______________________________________________ > > >> 6lowpan mailing list > > >> 6lowpan@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/6lowpan > > >> =20 > > > > > > =20 >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan >=20 >=20 >=20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Nov 30 03:09:01 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy0vi-0006Su-Ac; Fri, 30 Nov 2007 03:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy0vh-0006SV-8J for 6lowpan@lists.ietf.org; Fri, 30 Nov 2007 03:08:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy0ve-0001XA-Fj for 6lowpan@lists.ietf.org; Fri, 30 Nov 2007 03:08:57 -0500 X-IronPort-AV: E=Sophos;i="4.23,233,1194217200"; d="scan'208";a="159188416" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 30 Nov 2007 09:08:54 +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 lAU88rET021777; Fri, 30 Nov 2007 09:08:53 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAU88n3Z009632; Fri, 30 Nov 2007 08:08:53 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 09:08:49 +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: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter Date: Fri, 30 Nov 2007 09:08:42 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04D9DFB1@xmb-ams-337.emea.cisco.com> In-Reply-To: <1196395279.5692.78.camel@dellx1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working Charter Thread-Index: AcgzBi0n0x52L/O4RsawAf10+FS0ZwAHzDHw References: <750929.34078.qm@web81904.mail.mud.yahoo.com> <1196395279.5692.78.camel@dellx1> From: "Pascal Thubert (pthubert)" To: "Geoff Mulligan" , "gabriel montenegro" X-OriginalArrivalTime: 30 Nov 2007 08:08:49.0081 (UTC) FILETIME=[3CBD5A90:01C83328] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14764; t=1196410133; x=1197274133; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[6lowpan]=20RE=3A=20[RSN]=20Here=20is=20the=20new=20R L2N=20Proposed=20Working=20Charter |Sender:=20; bh=04UEuQIqAc29BOgXKoG0vmFn33Kk2u6QMSjp5zeLLFY=; b=LXm/eYSYx29VQoWmNIhDekuMQFvCkgGNmBDxzphU34De4soFtZglg7mzAutHithN1FSbhNDR gaALcob5DcTxPhzggvSujbeSaiPD0Uf5urQQ0t33IBLTKPfdJT7bn+mK; 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: 75ac86d24bd0a3cd8a26e327ae61143e Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Geoff: It's not just about IPSec though: There are a number of companies out there designing and integrating = silicon for LoWPANs. IPv6 is not necessarily a target for them when it = does not mean immediate sales. Also, they do not necessarily know what = supporting IPv6 means for their devices and what the associated cost = will be. They could use some help and we can provide it in the form of = an RFC that summarizes a LoWPAN profile for IPv6.=20 That profile should not include IPSec; that profile should include = 6LoWPAN - RFC 4944 is not listed in RFC 4294 for obvious reasons-, and = the ND solution we will come up with. That profile should be designed to = enable very low end embedded systems (an 8-bit processor in my Mc D's = toy) to run IPv6. Once we have that published with IETF stamp of approval, it becomes = possible for people out there to: - guarantee interoperability - develop and distribute an opensource stack - publish actual numbers for footprint and performance on various = implementations - go to standard bodies such as ISA SP100 and present those numbers to = support IPv6 adoption. I do think it is worth the effort. If 6MAN is the place, so be it. Pascal >-----Original Message----- >From: Geoff Mulligan [mailto:geoff@mulligan.com] >Sent: Friday, November 30, 2007 5:01 AM >To: gabriel montenegro >Cc: 6lowpan >Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed Working = Charter > >I will search back, but m recollection was that we (you) did argue with >the IESG that devices such as these (small 8bit micro sensors) would = not >be capable of IPsec and after a few emails back a forth we were told >that 6lowpan devices did not need to support IPsec. > >Again I will look back and see if I can find the email exchange and = I'll >ask Russ. > > geoff > >On Thu, 2007-11-29 at 17:13 -0800, gabriel montenegro wrote: >> Geoff, >> >> Could you please provide a pointer to the message or document with >> that exception? >> This is an important item and it should be added to the group's Wiki >> page. >> >> My recollection is different, but I may have just forgotten. What I >> recollect is that back when we >> were starting the working group and initiating work on the problem >> statement draft, was that the recommendation >> was to stay away from issuing our own IPv6 profile, precisely because >> saying things like ("IPsec is not recommended in lowpan >> environments") was a sure-fire way to invite controversy at the IESG. >> E.g., IPv6 mandates IPsec, so how could >> we ever claim to support IPv6.... This debate probably is better had >> in 6man in terms of a revision of the hosts >> requirements, rather than in any particular WG. >> >> -gabriel >> >> ----- Original Message ---- >> From: Geoff Mulligan >> To: Kris Pister >> Cc: 6lowpan <6lowpan@lists.ietf.org> >> Sent: Thursday, November 29, 2007 11:09:02 AM >> Subject: Re: [6lowpan] RE: [RSN] Here is the new RL2N Proposed = Working >> Charter >> >> We did not try to get an exception to UDP checksums. >> >> geoff >> >> On Thu, 2007-11-29 at 10:59 -0800, Kris Pister wrote: >> > Geoff - ooh, I like exceptions. >> > Did we try to get an exception on the UDP checksum? It's painful >> to >> > leave that in the compressed header if we have L2 message = integrity. >> > >> > ksjp >> > >> > Geoff Mulligan wrote: >> > > We have already received an exception from the IESG to IPsec on >> 6lowpan >> > > devices. >> > > >> > > geoff >> > > >> > > On Thu, 2007-11-29 at 16:09 +0100, Pascal Thubert (pthubert) >> wrote: >> > > >> > >> Hum... >> > >> >> > >> I had missed that; Seems that we have to make an exception :) If >> you consider ISA100.11a, they already have security at L2 and L5, it >> makes little sense to MUST IPSec on top of that. >> > >> >> > >> Pascal >> > >> >> > >> >> > >>> -----Original Message----- >> > >>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >> > >>> Sent: Wednesday, November 28, 2007 8:03 PM >> > >>> To: Pascal Thubert (pthubert) >> > >>> Cc: 6lowpan >> > >>> Subject: Re: [RSN] Here is the new RL2N Proposed Working = Charter >> > >>> >> > >>> Hmm. From 4294: >> > >>> >> > >>> "However, while authentication and encryption can each be NULL, >> they >> > >>> MUST NOT both be NULL." >> > >>> >> > >>> ksjp >> > >>> >> > >>> Pascal Thubert (pthubert) wrote: >> > >>> >> > >>>> Hi Kris: >> > >>>> >> > >>>> For your question on ESP, AFAIK, RFC 4294 only mandates NULL >> encryption and authentication for >> > >>>> >> > >>> interoperability reasons. >> > >>> >> > >>>> On the general question of RFC 4294 itself: I'm not sure the >> work was ever done. I hope someone >> > >>>> >> > >> >from the list can help? >> > >> >> > >>>> If the answer is unclear, and considering that we are >> re-chartering the group, maybe we could have >> > >>>> >> > >>> a work item to specify the instantiation of RFC 4294 for LoWPAN >> nodes? >> > >>> >> > >>>> Pascal >> > >>>> ________________________________________ >> > >>>> From: Kris Pister [mailto:pister@eecs.berkeley.edu] >> > >>>> Sent: Wednesday, November 28, 2007 5:42 PM >> > >>>> To: Pascal Thubert (pthubert) >> > >>>> Cc: 6lowpan >> > >>>> Subject: Re: [RSN] Here is the new RL2N Proposed Working >> Charter >> > >>>> >> > >>>> Is there an email thread somewhere that discusses the impact = on >> 6LoWPAN of the security >> > >>>> >> > >>> requirements of 4294 and 4303? >> > >>> >> > >>>> My first quick readthrough makes me very uncomfortable that >> some of the mandates are going to be >> > >>>> >> > >>> ugly from a header standpoint. >> > >>> >> > >>>> ksjp >> > >>>> >> > >>>> Pascal Thubert (pthubert) wrote: >> > >>>> Hi JP: >> > >>>> >> > >>>> Thanks a bunch for this charter. I'll try not to rephrase what >> was already discussed with Christian, >> > >>>> >> > >>> Anders, Philip and Misha. >> > >>> >> > >>>> There's an additional item I'd wish to see either in ROLL or >> 6LoWPAN and I do not know exactly >> > >>>> >> > >>> where it belongs, maybe both. The question is whether we need = to >> and can document how RFC 4294 >> > >>> applies for sensors, and M2M devices in general, whether they >> act as hosts or as routers. >> > >>> >> > >>>> I've seen IPv6 presented as a Pandora box that drags just too >> much stuff to be incorporated in a >> > >>>> >> > >>> sensory device. For instance, at the moment, SP100.11a endorses >> 6LoWPAN formats but it's not so clear >> > >>> at all that IPv6 itself is mandated. A clear spec with >> well-documented implementation could be a >> > >>> formidable tool to despond to Fear, Uncertainty and Defiance. >> > >>> >> > >>>> So maybe we do not need DHCP (a MAY in RFC 4294) and maybe can >> do without multicast at all if ND is >> > >>>> >> > >>> supported some other way (such as suggested in: >> http://www.ietf.org/internet-drafts/draft-thubert- >> > >>> lowpan-backbone-router-00.txt). Maybe NULL encryption and >> authentication is enough etc, etc... >> > >>> >> > >>>> Being able to define one minimum set and maybe a few other >> profiles for the use cases that we >> > >>>> >> > >>> selected could help tremendously. >> > >>> >> > >>>> Otherwise I find the charter real well written and easy to >> digest. >>From the MANEMO experience, I >> > >>>> >> > >>> expect that some arguments about the relative applicability of >> existing MANET protocols will be >> > >>> difficult to prove without some good simulation work running >> agreed-upon scenarios. >> > >>> >> > >>>> Finally, I'm a bit confused that it seems that both IPv4 and >> IPv6 seem supported. Ipv4 comes with a >> > >>>> >> > >>> lot of overhead like DHCP. I suggest that when trouble comes = and >> things can not be done in a common >> > >>> fashion for both IP protocols, hen we prioritize IPv6. >> > >>> >> > >>>> Unfortunately, I can not make it to Vancouver, but I do feel >> that the work is really needed so >> > >>>> >> > >>> please count my vote in for the adoption of the WG. >> > >>> >> > >>>> Cheers, >> > >>>> >> > >>>> Pascal >> > >>>> >> > >>>> >> > >>>> -----Original Message----- >> > >>>> From: Jean Philippe Vasseur (jvasseur) >> > >>>> Sent: Wednesday, November 21, 2007 9:19 PM >> > >>>> To: rsn@ietf.org >> > >>>> Subject: [RSN] Here is the new RL2N Proposed Working Charter >> > >>>> >> > >>>> Dear all, >> > >>>> >> > >>>> As promised, here is the new proposed Working Group, which >> reflects the >> > >>>> number of comments/suggestions that we received, the pre-WG >> consensus, ... >> > >>>> >> > >>>> Thanks to Dave Ward (RTD AD) for his input. >> > >>>> >> > >>>> Proposed RL2N WG Charter >> > >>>> >> > >>>> Description of Working Group >> > >>>> >> > >>>> L2Ns (Low power and Lossy networks) are typically composed of >> many embedded >> > >>>> devices with limited power, memory, and processing resources >> interconnected >> > >>>> by a variety of wireless links, such as IEEE 802.15.4, >> Bluetooth, Low Power >> > >>>> WiFi. >> > >>>> >> > >>>> L2Ns are transitioning to an end-to-end IP-based solution to >> avoid the >> > >>>> problems of non-interoperable networks interconnected by >> protocol >> > >>>> translation gateways and proxies. In addition, L2Ns have >> specific routing >> > >>>> requirements that are not currently met by existing routing >> protocols, such >> > >>>> as OSPF, IS-IS, AODV, and OLSR. L2N path selection must be >> designed to take >> > >>>> into consideration the specific power, capabilities, = attributes >> and >> > >>>> functional characteristics of the links and nodes in the >> network. >> > >>>> >> > >>>> >> > >>>> There is a wide scope of application areas for L2Ns, including >> industrial >> > >>>> monitoring, building automation (HVAC, lighting/access >> control), connected >> > >>>> home, healthcare, environmental monitoring, agricultural, = smart >> cities, >> > >>>> logistics, assets tracking, and refrigeration. The L2N WG will >> focus on >> > >>>> routing solutions for a subset of these deployment scenarios, >> namely >> > >>>> industrial, connected home/building and urban applications. = The >> Working >> > >>>> Group will determine the routing requirements for these >> scenarios. >> > >>>> >> > >>>> >> > >>>> The Working Group will provide a routing framework for these >> application >> > >>>> scenarios that provides high reliability in the presence of >> time varying >> > >>>> loss characteristics and connectivity while permitting >> low-power operation >> > >>>> with very modest memory and CPU pressure. >> > >>>> >> > >>>> >> > >>>> The Working Group will pay a particular attention to routing >> security and >> > >>>> manageability (e.g self managing/configuration) issues, which >> are >> > >>>> particularly critical for L2Ns. >> > >>>> >> > >>>> Work Items: >> > >>>> >> > >>>> - Produce use cases documents for Industrial, Connected Home, >> Building and >> > >>>> urban application networks. Each document will describe the = use >> case and the >> > >>>> associated routing protocol requirements. The documents will >> progress in >> > >>>> collaboration with the 6lowpan Working Group (INT area). >> > >>>> >> > >>>> >> > >>>> - Survey the applicability of existing protocols to L2Ns. The >> aim of this >> > >>>> document will be to analyze the scaling and characteristics of >> existing >> > >>>> protocols and identify whether or not they meet the routing >> requirements of >> > >>>> the L2Ns applications identified above. Existing IGPs, MANET, >> NEMO, DTN >> > >>>> routing protocols will be part of evaluation. >> > >>>> >> > >>>> - Specification of routing metrics used in path calculation. >> This includes >> > >>>> static and dynamic link/nodes attributes required for routing >> in L2Ns. >> > >>>> >> > >>>> - Provide an architectural framework for routing and path >> selection at Layer >> > >>>> 3 (Routing for L2N Architecture) >> > >>>> * Decide whether the L2Ns routing protocol require a >> distributed, >> > >>>> centralized path computation models or both. >> > >>>> * Decide whether the L2N routing protocol requires a >> hierarchical routing >> > >>>> approach. >> > >>>> >> > >>>> - Produce a security framework for routing in L2Ns. >> > >>>> >> > >>>> Goals And Milestones: >> > >>>> >> > >>>> >> > >>>> April 2008 Submit Use case/Routing requirements for = Industrial, >> Connected >> > >>>> Home, Building and Urban networks applications to the IESG to >> be considered >> > >>>> as an Informational RFC. >> > >>>> >> > >>>> August 2008: Submit Routing metrics for L2Ns document to the >> IESG to be >> > >>>> considered as an Informational RFC. >> > >>>> >> > >>>> September 2008: Submit first draft of the Routing for L2Ns >> Architecture >> > >>>> document (summary of requirements, path computation model, >> > >>>> flat/hierarchy,=A9). >> > >>>> >> > >>>> November 2008: Submit Protocol Survey to the IESG to be >> considered as an >> > >>>> Informational RFC. >> > >>>> >> > >>>> January 2009 Submit Security Framework for L2Ns to the IESG to >> be considered >> > >>>> as an Informational RFC >> > >>>> >> > >>>> February 2009: Submit the Routing for L2Ns Architecture >> document (summary >> > >>>> of requirements, metrics and attributes, path selection model) >> to the IESG >> > >>>> as an Informational RFC. >> > >>>> >> > >>>> March 2009: Recharter. >> > >>>> >> > >>>> >> > >>>> Please comment/suggest/... >> > >>>> >> > >>>> See you in Vancouver. >> > >>>> >> > >>>> JP and David. >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> RSN mailing list >> > >>>> RSN@ietf.org >> > >>>> https://www1.ietf.org/mailman/listinfo/rsn >> > >>>> >> > >>>> >> > >>>> >> > >>>> _______________________________________________ >> > >>>> RSN mailing list >> > >>>> RSN@ietf.org >> > >>>> https://www1.ietf.org/mailman/listinfo/rsn >> > >>>> >> > >>>> >> > >>>> >> > >> _______________________________________________ >> > >> 6lowpan mailing list >> > >> 6lowpan@ietf.org >> > >> https://www1.ietf.org/mailman/listinfo/6lowpan >> > >> >> > > >> > > >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www1.ietf.org/mailman/listinfo/6lowpan >> >> >> > > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan