From rsn-bounces@ietf.org Fri Jun 01 11:15:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8qe-0000xF-M4; Fri, 01 Jun 2007 11:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu8qd-0000x9-Tr for rsn@ietf.org; Fri, 01 Jun 2007 11:15:27 -0400 Received: from relay3.ptmail.sapo.pt ([212.55.154.23] helo=sapo.pt) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hu8qb-0000MX-CZ for rsn@ietf.org; Fri, 01 Jun 2007 11:15:27 -0400 Received: (qmail 20527 invoked from network); 1 Jun 2007 15:15:23 -0000 Received: from unknown (HELO sapo.pt) (10.134.35.210) by relay3 with SMTP; 1 Jun 2007 15:15:23 -0000 Received: (qmail 13574 invoked from network); 1 Jun 2007 15:15:19 -0000 X-AntiVirus: PTMail-AV 0.3-0.90.1 X-Virus-Status: Clean (0.03939 seconds) Received: from unknown (HELO [192.168.2.101]) (tandre@sapo.pt@[84.91.24.208]) (envelope-sender ) by mta15 (qmail-ldap-1.03) with SMTP for ; 1 Jun 2007 15:15:19 -0000 Message-ID: <4660383D.2000304@dei.uc.pt> Date: Fri, 01 Jun 2007 16:16:13 +0100 From: Tiago Camilo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: JP Vasseur Subject: Re: [RSN] Next step for RSN ? References: <20070522232511.DD58016B0002@secure.archedrock.com><7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> <7892795E1A87F04CADFCCF41FADD00FC03FCE257@xmb-ams-337.emea.cisco.com> <55D78861-C538-4A6B-9B9D-9E30038A50AB@cisco.com> In-Reply-To: <55D78861-C538-4A6B-9B9D-9E30038A50AB@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi JP, > > I think you both agree: we do want to be able to have an IP routing > protocol not tied up with a specific layer 2 but it may be desirable to > get layer2 information used for routing, this is why I wrote in my > original email: > > "/ ... Thus the proposal is to design a IP routing solution > specifically for sensor networks, that would of course be independent > to the L1/L2 protocol in use (it may be desirable to take into account > link layer attributes when calculating a route but the routing process > would not be tied up with the link layer). ..."/ > I 100% agree with this approach, due to sensor nodes constrains it is necessary and advisable (whenever is possible) to use L2 information for routing. What I would like to raze here is, probably, a to-crazy-question-to-answer but here it goes: why not also adopting application layer requirements in routing protocols? I know that we, in parallel, are building requirement IDs specially to application scenarios such as home automation, however i do see the need to supply to RSN solutions, mechanisms such as service discovery, natively or as an extended option. In a near future I can see the integration of several platforms working in the same sensornet, becoming in sensor mesh networks, such supposition will make difficult to the network manager to track the service availability of his network, and IMO this can be applied to any kind of sensor application. In a previous mail you mention the need to support point to Multipoint (P2MP) communication, and maybe you are already answering my question, this could be supported by means of multicast-based solutions. Are you considering service discovery as a requirement in the ID draft-culler-rsn-routing-reqs ? Or this ID should be application agnostic? Thanks, Tiago Camilo University of Coimbra >> Pascal => For instance, I believe that an abstract notion of beacon can >> be useful to advertise L3 triggers that will help in peer selection, >> considering that the memory footprint will not enable to track all peers >> at all times. You can imagine that the L2 abstraction provides an >> optional timely broadcast on which L3 message can be passed, with a >> fallback solution of triggering a data frame broadcast if the beacon is >> not provided by one specific MAC. >> > > Agree, similarly to what is being done in today's network when > SONET/SDH/Optical parameters are used by the layer 3. > But still, we want a routing solution working above any type of > layer-2, we're in sync. > >>> Whether beacons or some other arbitration strategy is used should not >> be >>> relevant to the routing layer. What is important is which capabilites >> is >>> provided by the lower layer, such as: >>> >>> * Guaranteed delivery to another node (Yes/No) >>> * Worst-case time for delivery of a packet to another node (may depend >>> on target node capabilities) >>> * Power properties (AC / AC w. batt. Backup / Big battery / Button cell >>> battery / Environmental -sun or wind) >>> * Availability of another node (A sun-powered node may be available and >>> reliable for long periods, but not always...) >>> >> Pascal => Agreed but it's a different level. These are metrics and >> constraints that will enter in path selection. I was discussing a >> potential optimization of the flow of the PDUs that would depend on how >> well we can exploit L2 mechanisms. > > Yes. > > Thanks. > > JP. > >> >>> I see RSN as a strong initiative because it is targeting a sensor world >>> with just a good integration of technologies as classic IP provides >>> today: >>> I do not have to worry whether my IP traffic is running over GPRS, >> ADSL, >>> ATM, Ethernet, MPLS or WiFi. >>> >>> In exactly the same way, RSN should provide seamless operation between >>> sensor solutions running over Z-Wave, 802.15.4 and other wireless >>> low-power technologies. >>> >>> Br. >>> Anders >>> >>> ------------- >>> Anders Brandt >>> Senior Software Architect >>> >>> Zensys >>> Emdrupvej 26 >>> DK-2100 Copenhagen O >>> DENMARK >>> >>> phone: +45 70209940 >>> fax: +4570209950 >>> mail: abr@zen-sys.com >>> web: www.zen-sys.com >>> >>> _______________________________________________ >>> RSN mailing list >>> RSN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rsn >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn > > ------------------------------------------------------------------------ > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jun 01 19:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGR5-0006Pw-Dw; Fri, 01 Jun 2007 19:21:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuGR4-0006Pr-BD for rsn@ietf.org; Fri, 01 Jun 2007 19:21:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuGR2-0006IA-Sc for rsn@ietf.org; Fri, 01 Jun 2007 19:21:34 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Jun 2007 19:21:32 -0400 X-IronPort-AV: i="4.16,374,1175486400"; d="scan'208"; a="122609170:sNHT56658010" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l51NLW8j018265; Fri, 1 Jun 2007 19:21:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l51NLT5f001099; Fri, 1 Jun 2007 23:21:32 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 19:21:29 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 19:21:29 -0400 In-Reply-To: <4660383D.2000304@dei.uc.pt> References: <20070522232511.DD58016B0002@secure.archedrock.com><7892795E1A87F04CADFCCF41FADD00FC03FCDD2E@xmb-ams-337.emea.cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E77B297@zensys17.zensys.local> <7892795E1A87F04CADFCCF41FADD00FC03FCE257@xmb-ams-337.emea.cisco.com> <55D78861-C538-4A6B-9B9D-9E30038A50AB@cisco.com> <4660383D.2000304@dei.uc.pt> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Next step for RSN ? Date: Fri, 1 Jun 2007 19:21:17 -0400 To: Tiago Camilo X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 01 Jun 2007 23:21:29.0235 (UTC) FILETIME=[95273E30:01C7A4A3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6606; t=1180740092; x=1181604092; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Next=20step=20for=20RSN=20? |Sender:=20 |To:=20Tiago=20Camilo=20; bh=s1M2kGUCSPU3RTplLVpU4l0jQQqL6AiOvbvn2MwtosU=; b=jgLbGx44S8q9Fny5PxIR15zO38dj+amo2u6Pni/3egB3H2tqwnDp9WbscHZHcCbqlVase8p7 1rOEhNamlJHao1DRRncER6QOFckE2u6rWiSh2axedUjepsG+NucChCwi; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, On Jun 1, 2007, at 11:16 AM, Tiago Camilo wrote: > Hi JP, > >> >> I think you both agree: we do want to be able to have an IP >> routing protocol not tied up with a specific layer 2 but it may be >> desirable to >> get layer2 information used for routing, this is why I wrote in my >> original email: >> >> "/ ... Thus the proposal is to design a IP routing solution >> specifically for sensor networks, that would of course be >> independent to the L1/L2 protocol in use (it may be desirable to >> take into account link layer attributes when calculating a route >> but the routing process would not be tied up with the link >> layer). ..."/ >> > I 100% agree with this approach, due to sensor nodes constrains it > is necessary and advisable (whenever is possible) to use L2 > information for routing. > What I would like to raze here is, probably, a to-crazy-question-to- > answer but here it goes: why not also adopting application layer > requirements in routing protocols? > I know that we, in parallel, are building requirement IDs specially > to application scenarios such as home automation, however i do see > the need to supply > to RSN solutions, mechanisms such as service discovery, natively or > as an extended option. > In a near future I can see the integration of several platforms > working in the same sensornet, becoming in sensor mesh networks, > such supposition will > make difficult to the network manager to track the service > availability of his network, and IMO this can be applied to any > kind of sensor application. This is a pefectly reasonable question to ask. We've been struggling with that exact same issue for other IGPs consisting of off-loading the IGP to carry non routing information, but its flooding capability. So here is a proposal: we should definitely bear this in mind when designing the routing protocol without making it a MUST requirement. If it turns out that the routing protocol can also be used for application discovery w/o imposing too many constraints on it in term of bw usage, ... why not ? This may or may not be feasible depending on the final design. The case of OSPF/ISIS was quite straightforward because of their flooding nature (we just had to come up with prioritization mechanisms to avoid convergence impact because of the non-routing data): thus specifying a node capability TLV carried within a Router Information LSA or ISIS LSP is not that much expensive especially when such capability is fairly static (30mn refresh for OSPF and up to 18+ hours with ISIS). But we first need to study the routing design and see whether we could use it for such purpose or would need to rely on other discovery service protocols. > In a previous mail you mention the need to support point to > Multipoint (P2MP) communication, and maybe you are already > answering my question, > this could be supported by means of multicast-based solutions. > Are you considering service discovery as a requirement in the ID > draft-culler-rsn-routing-reqs ? Or this ID should be application > agnostic? > Although we should probably focus on the pure routing issues, I would very encourage further discussion on this topic: would you be willing to list such application-specific mechanism ? Thanks. JP. > Thanks, > Tiago Camilo > University of Coimbra >>> Pascal => For instance, I believe that an abstract notion of >>> beacon can >>> be useful to advertise L3 triggers that will help in peer selection, >>> considering that the memory footprint will not enable to track >>> all peers >>> at all times. You can imagine that the L2 abstraction provides an >>> optional timely broadcast on which L3 message can be passed, with a >>> fallback solution of triggering a data frame broadcast if the >>> beacon is >>> not provided by one specific MAC. >>> >> >> Agree, similarly to what is being done in today's network when >> SONET/SDH/Optical parameters are used by the layer 3. >> But still, we want a routing solution working above any type of >> layer-2, we're in sync. >> >>>> Whether beacons or some other arbitration strategy is used >>>> should not >>> be >>>> relevant to the routing layer. What is important is which >>>> capabilites >>> is >>>> provided by the lower layer, such as: >>>> >>>> * Guaranteed delivery to another node (Yes/No) >>>> * Worst-case time for delivery of a packet to another node (may >>>> depend >>>> on target node capabilities) >>>> * Power properties (AC / AC w. batt. Backup / Big battery / >>>> Button cell >>>> battery / Environmental -sun or wind) >>>> * Availability of another node (A sun-powered node may be >>>> available and >>>> reliable for long periods, but not always...) >>>> >>> Pascal => Agreed but it's a different level. These are metrics and >>> constraints that will enter in path selection. I was discussing a >>> potential optimization of the flow of the PDUs that would depend >>> on how >>> well we can exploit L2 mechanisms. >> >> Yes. >> >> Thanks. >> >> JP. >> >>> >>>> I see RSN as a strong initiative because it is targeting a >>>> sensor world >>>> with just a good integration of technologies as classic IP provides >>>> today: >>>> I do not have to worry whether my IP traffic is running over GPRS, >>> ADSL, >>>> ATM, Ethernet, MPLS or WiFi. >>>> >>>> In exactly the same way, RSN should provide seamless operation >>>> between >>>> sensor solutions running over Z-Wave, 802.15.4 and other wireless >>>> low-power technologies. >>>> >>>> Br. >>>> Anders >>>> >>>> ------------- >>>> Anders Brandt >>>> Senior Software Architect >>>> >>>> Zensys >>>> Emdrupvej 26 >>>> DK-2100 Copenhagen O >>>> DENMARK >>>> >>>> phone: +45 70209940 >>>> fax: +4570209950 >>>> mail: abr@zen-sys.com >>>> web: www.zen-sys.com >>>> >>>> _______________________________________________ >>>> RSN mailing list >>>> RSN@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/rsn >>> >>> _______________________________________________ >>> RSN mailing list >>> RSN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rsn >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jun 03 08:03:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuonW-0002Ei-Dw; Sun, 03 Jun 2007 08:03:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuonU-00024h-RD for rsn@ietf.org; Sun, 03 Jun 2007 08:03:00 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuonT-0002h9-Go for rsn@ietf.org; Sun, 03 Jun 2007 08:03:00 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 03 Jun 2007 05:02:59 -0700 X-IronPort-AV: i="4.16,377,1175497200"; d="scan'208"; a="160368036:sNHT41280066" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l53C2whj007482 for ; Sun, 3 Jun 2007 05:02:58 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l53C2wV1023397 for ; Sun, 3 Jun 2007 12:02:58 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 08:02:57 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 08:02:57 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: rsn@ietf.org From: JP Vasseur Date: Sun, 3 Jun 2007 08:02:45 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Jun 2007 12:02:57.0772 (UTC) FILETIME=[200E7AC0:01C7A5D7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1094; t=1180872178; x=1181736178; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Update |Sender:=20; bh=g3iUCbYDQh+D8CzZnTEYPdY2ojbyntcFtx15e/h8W98=; b=DE40X4NLFxqnGBSBM/UI2j5b39VNxgpriN5keR22f41l0pCsH033HhIfbkoThlYEe2CLlZPV HWMAKhfvSTLIUl1bybVkc7kOM90i/WatEyjjKmWnhPihyOi2wlMTuW11; Authentication-Results: sj-dkim-8; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [RSN] Update X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Dear all, Here is an update on where we stand: good progress ! 1) We've been having quite a bit of off-line and on-line discussions and there is apparently a good level of interest in this work. There are currently 5 IDs in the works: * The generic routing requirements: draft-culler-rsn-routing-reqs * Two application-specific routing requirements: - Home Networking - Industrial * A problem statement * An ID on routing metrics Of course, if you're interested to work on these IDs or other items, feel free ! 2) New name Although we called this initiative RSN: Routing for Sensor Networks, it does apply more generally to constrained nodes (Low Power) operating in Lossy Networks. Objects in general would typically be part of those networks. So from now on, let's rename this work R2LN: "Routing issues for Low Power, Lossy Networks", and use that acronym in all IDs. 3) Next IETF We asked for a presentation slot for the next IETF. Depending on the feedback, the next step would then to request a BOF in Vancouver. Thanks. JP and David. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jun 03 16:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuwlF-0002jb-JZ; Sun, 03 Jun 2007 16:33:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuwlD-0002YP-WE for rsn@ietf.org; Sun, 03 Jun 2007 16:33:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuwlC-0005XO-Ga for rsn@ietf.org; Sun, 03 Jun 2007 16:33:11 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Jun 2007 16:33:10 -0400 X-IronPort-AV: i="4.16,378,1175486400"; d="scan'208,217"; a="61831353:sNHT334339496" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l53KX9bB011153 for ; Sun, 3 Jun 2007 16:33:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l53KX15j013847 for ; Sun, 3 Jun 2007 20:33:09 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 16:33:03 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 16:33:03 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) To: rsn@ietf.org Message-Id: <28107EC3-7BBC-4299-BF9E-39A2BA298C11@cisco.com> References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> From: JP Vasseur Subject: Fwd: [RSN] Update Date: Sun, 3 Jun 2007 16:31:49 -0400 X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Jun 2007 20:33:03.0283 (UTC) FILETIME=[625CD830:01C7A61E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8790; t=1180902789; x=1181766789; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Fwd=3A=20[RSN]=20Update |Sender:=20 |To:=20rsn@ietf.org; bh=kSb94ibrYBPZa3CJQCBilYE8/8zPijbrE0yFvruvEi8=; b=VGMwz9Us8G2EHFUFcDOs+naMNcmmfP26oz7/lIvEitzocZtaq84a2EM7lXZcJHXGDY2y+chN wvLUf7binUEOexNreeuMMymP9xFfo1DOJ1IpdMbi7jAUJ3iEXljV5Ntx; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1144355250==" Errors-To: rsn-bounces@ietf.org --===============1144355250== Content-Type: multipart/alternative; boundary=Apple-Mail-459-732047041 --Apple-Mail-459-732047041 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Begin forwarded message: > From: JP Vasseur > Date: June 3, 2007 8:02:45 AM EDT > To: rsn@ietf.org > Subject: [RSN] Update > > Dear all, > > Here is an update on where we stand: good progress ! > > 1) We've been having quite a bit of off-line and on-line > discussions and there is apparently a good level of interest in > this work. > There are currently 5 IDs in the works: > * The generic routing requirements: draft-culler-rsn-routing-reqs > * Two application-specific routing requirements: > - Home Networking > - Industrial > * A problem statement > * An ID on routing metrics > > Of course, if you're interested to work on these IDs or other > items, feel free ! > > 2) New name > Although we called this initiative RSN: Routing for Sensor > Networks, it does apply more generally to constrained nodes (Low > Power) > operating in Lossy Networks. Objects in general would typically be > part of those networks. So from now on, let's rename this work > R2LN: "Routing issues for Low Power, Lossy Networks", It should actually read RL2N: "Routing issues for Low power, Lossy Networks" Thanks. JP. > and use that acronym in all IDs. > > 3) Next IETF > We asked for a presentation slot for the next IETF. Depending on > the feedback, the next step would then to request a BOF in Vancouver. > > Thanks. > > JP and David. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn --Apple-Mail-459-732047041 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = June 3, 2007 8:02:45 AM EDT
Subject: = [RSN] Update

Dear = all,

Here is an update on where we stand: good progress = !

1) We've been having quite a bit of off-line and = on-line discussions and there is apparently a good level of interest in = this work.
There are currently 5 IDs in the = works:
* The generic routing = requirements: draft-culler-rsn-routing-reqs
* Two = application-specific routing requirements:
- Home = Networking
- Industrial
* A problem statement
* An ID = on routing metrics
Of course, if you're interested = to work on these IDs or other items, feel free !

2) New = name
Although we called this = initiative RSN: Routing for Sensor Networks, it does apply more = generally to constrained nodes (Low Power)
R2LN: "Routing issues for Low Power, Lossy = Networks",

It should actually read = RL2N:=A0"Routing issues for Low power, Lossy Networks"

Thanks.

JP.

and use that acronym in all = IDs.

3) Next IETF
We asked for = a presentation slot for the next IETF. Depending on the feedback, the = next step would then to request a BOF in Vancouver.


JP and David.

RSN mailing list

= --Apple-Mail-459-732047041-- --===============1144355250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1144355250==-- From rsn-bounces@ietf.org Sun Jun 03 16:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hux22-0004sl-Py; Sun, 03 Jun 2007 16:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hux20-0004rU-LA for rsn@ietf.org; Sun, 03 Jun 2007 16:50:32 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hux1y-00074o-7V for rsn@ietf.org; Sun, 03 Jun 2007 16:50:32 -0400 Received: from [127.0.0.1] (saloits.com [208.42.140.127]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l53KoKep080418 for ; Sun, 3 Jun 2007 15:50:27 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <46632986.3000401@saloits.com> Date: Sun, 03 Jun 2007 15:50:14 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rsn@ietf.org Subject: Re: [RSN] Update References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> In-Reply-To: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org JP Vasseur wrote: > 2) New name > Although we called this initiative RSN: Routing for Sensor Networks, it > does apply more generally to constrained nodes (Low Power) > operating in Lossy Networks. Objects in general would typically be part > of those networks. So from now on, let's rename this work > R2LN: "Routing issues for Low Power, Lossy Networks", and use that > acronym in all IDs. I suggest that "Routing Issues in Low-Power Wireless Networks" might be more descriptive. "Wireless" implies "lossy". "Wireless" also implies a variety of other behaviors, such as a limited-range broadcast (usually), and a variety of others. I doubt that we will spend any time at all thinking about low power wired networks. "Low-Power" sounds better than "Resource-Constrained", although the latter might be more descriptive. And finally, to do the job well, this group must look at more than just routing issues (e.g., neighbor discovery and management in low-power wireless networks). We might consider: "Internetworking Issues in Low-Power Wireless Networks" or "Internetworking Issues in Resource-Constrained Wireless Networks" or even "Internetworking Issues in Resource-Constrained Networks" (I2RCN) One (non-trivial) advantage of "Internetworking" is that it helps answer the question: Why should the IETF (e.g., rather than the IEEE) be interested in this work? (Assuming that we think about how low-power wireless networks should be interconnected with the Internet.) -tjs _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jun 03 17:16:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuxRS-0004eQ-Td; Sun, 03 Jun 2007 17:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuxRR-0004Yo-4i; Sun, 03 Jun 2007 17:16:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuxRQ-0001xW-9d; Sun, 03 Jun 2007 17:16:49 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jun 2007 17:16:48 -0400 X-IronPort-AV: i="4.16,378,1175486400"; d="scan'208"; a="122679267:sNHT46819934" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l53LGlM1017769; Sun, 3 Jun 2007 17:16:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l53LGh5f018841; Sun, 3 Jun 2007 21:16:43 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 17:16:43 -0400 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 17:16:42 -0400 Message-ID: <46632FB9.6080705@cisco.com> Date: Sun, 03 Jun 2007 23:16:41 +0200 From: Mark Townsley User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: "Timothy J. Salo" Subject: Re: [RSN] Update References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> In-Reply-To: <46632986.3000401@saloits.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2007 21:16:43.0177 (UTC) FILETIME=[7BF0F190:01C7A624] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2126; t=1180905408; x=1181769408; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[RSN]=20Update |Sender:=20 |To:=20=22Timothy=20J.=20Salo=22=20; bh=qTwwHhviIRIG/qDj8bcSUlBDjuHrB7v8oWCaP4zQs7o=; b=U2F2JcCkq4aDz8bsh8LUnWZE/UY2WJ5R93v9mZyLj1CL2wClJY0V31vCP1upBFZe0vhh3W+8 cV6YEBBldOwcJeXO2RUzegnBGG3kBq5m0jm1fXnImGESIZOQQtMcA/MJ; Authentication-Results: rtp-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rsn@ietf.org, 6lowpan@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Timothy J. Salo wrote: > JP Vasseur wrote: >> 2) New name >> Although we called this initiative RSN: Routing for Sensor Networks, >> it does apply more generally to constrained nodes (Low Power) >> operating in Lossy Networks. Objects in general would typically be >> part of those networks. So from now on, let's rename this work >> R2LN: "Routing issues for Low Power, Lossy Networks", and use that >> acronym in all IDs. > > I suggest that "Routing Issues in Low-Power Wireless Networks" > might be more descriptive. > > "Wireless" implies "lossy". "Wireless" also implies a variety > of other behaviors, such as a limited-range broadcast (usually), > and a variety of others. > > I doubt that we will spend any time at all thinking about > low power wired networks. > > "Low-Power" sounds better than "Resource-Constrained", although > the latter might be more descriptive. > > And finally, to do the job well, this group must look at more > than just routing issues (e.g., neighbor discovery and management > in low-power wireless networks). We might consider: This part should be part of the 6lowpan recharter. The idea amongst the ADs has been to split off the routing portion of the work on low-power networks to the routing area, and continue forward with work on ND, bootstrapping, etc. within the int-area. > > "Internetworking Issues in Low-Power Wireless Networks" > > or > > "Internetworking Issues in Resource-Constrained Wireless Networks" > > or even > > "Internetworking Issues in Resource-Constrained Networks" (I2RCN) > > One (non-trivial) advantage of "Internetworking" is that it > helps answer the question: Why should the IETF (e.g., rather than > the IEEE) be interested in this work? (Assuming that we think > about how low-power wireless networks should be interconnected > with the Internet.) I agree that this is an important topic that should be part of both charters. - Mark > > -tjs > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jun 03 18:07:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuyE4-0003K0-0I; Sun, 03 Jun 2007 18:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuyE2-0003Js-7e; Sun, 03 Jun 2007 18:07:02 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuyE1-0007Xb-UL; Sun, 03 Jun 2007 18:07:02 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Jun 2007 18:07:00 -0400 X-IronPort-AV: i="4.16,378,1175486400"; d="scan'208"; a="122680616:sNHT49884948" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l53M6xtJ026791; Sun, 3 Jun 2007 18:06:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l53M6x5f025316; Sun, 3 Jun 2007 22:06:59 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 18:06:59 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 3 Jun 2007 18:06:58 -0400 In-Reply-To: <46632FB9.6080705@cisco.com> References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B8C1A92-0FC1-4627-8F08-AE189D00078C@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Update Date: Sun, 3 Jun 2007 18:06:26 -0400 To: Mark Townsley , "Timothy J. Salo" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Jun 2007 22:06:58.0969 (UTC) FILETIME=[817E4890:01C7A62B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2838; t=1180908419; x=1181772419; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20Update |Sender:=20 |To:=20Mark=20Townsley=20, =20=22Timothy=20J.=20Salo=2 2=20; bh=EghmwqmZ5lRcfca+J7Tqtuzd1tie/JDCEQx7xrpocNo=; b=j0+vJsj0kC5nFgGD5Z6cOL2+kCqidN46gEm3Ep96LUDK8RCP9gbPxl4u8p7XYzkuNW8DhzOE 0Ul+AElmwUnDj5SZ4OJ1lA9wIEFhyQku0dzoSQy6uCjkLe2V25jurLfJ; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: rsn@ietf.org, 6lowpan@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, On Jun 3, 2007, at 5:16 PM, Mark Townsley wrote: > Timothy J. Salo wrote: >> JP Vasseur wrote: >>> 2) New name >>> Although we called this initiative RSN: Routing for Sensor >>> Networks, it does apply more generally to constrained nodes (Low >>> Power) >>> operating in Lossy Networks. Objects in general would typically >>> be part of those networks. So from now on, let's rename this work >>> R2LN: "Routing issues for Low Power, Lossy Networks", and use >>> that acronym in all IDs. >> >> I suggest that "Routing Issues in Low-Power Wireless Networks" >> might be more descriptive. >> >> "Wireless" implies "lossy". "Wireless" also implies a variety >> of other behaviors, such as a limited-range broadcast (usually), >> and a variety of others. >> >> I doubt that we will spend any time at all thinking about >> low power wired networks. >> >> "Low-Power" sounds better than "Resource-Constrained", although >> the latter might be more descriptive. >> >> And finally, to do the job well, this group must look at more >> than just routing issues (e.g., neighbor discovery and management >> in low-power wireless networks). We might consider: > This part should be part of the 6lowpan recharter. The idea amongst > the ADs has been to split off the routing portion of the work on > low-power networks to the routing area, and continue forward with > work on ND, bootstrapping, etc. within the int-area. Indeed ... By the way this gives the opportunity to re-enforce the fact that this initiative deals with routing issues *only*. If we need additional specifications for the routing that do not deal with pure routing issues, then we need to ask to 6lowpan indeed. >> >> "Internetworking Issues in Low-Power Wireless Networks" >> >> or >> >> "Internetworking Issues in Resource-Constrained Wireless Networks" >> >> or even >> >> "Internetworking Issues in Resource-Constrained Networks" (I2RCN) >> >> One (non-trivial) advantage of "Internetworking" is that it >> helps answer the question: Why should the IETF (e.g., rather than >> the IEEE) be interested in this work? (Assuming that we think >> about how low-power wireless networks should be interconnected >> with the Internet.) Because I think that these devices will soon be part of the Internet ;-) Quite seriously. And we need to keep the word Routing here. > I agree that this is an important topic that should be part of both > charters. > Thanks. JP. > - Mark >> >> -tjs >> >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jun 04 00:43:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4Po-0004Uz-68; Mon, 04 Jun 2007 00:43:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv4Pj-0004HL-RM for rsn@ietf.org; Mon, 04 Jun 2007 00:43:32 -0400 Received: from mail.ajou.ac.kr ([202.30.0.18]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hv4Pg-0000V4-F9 for rsn@ietf.org; Mon, 04 Jun 2007 00:43:31 -0400 Received: from ajou.ac.kr (127.0.0.1) by mail.ajou.ac.kr with ESMTP imoxion SensMail SmtpServer 5.0 id <46639bb23fe593bc9ef9ce0a> for from ; Mon, 04 Jun 2007 13:43:41 +0900 Message-ID: <46639b153fc8@imoxion.com> Date: Mon, 4 Jun 2007 13:43:44 +0900 (KST) From: Zeeshan Hameed Mir To: manet@ietf.org, rsn@ietf.org, tccc@cs.columbia.edu, 6lowpan@lists.ietf.org, dbworld-request@cs.wisc.edu MIME-Version: 1.0 X-Priority: 3 X-Spam-Score: 1.3 (+) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: Subject: [RSN] USN 2007 Extended Deadline to June 15 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0399495044==" Errors-To: rsn-bounces@ietf.org --===============0399495044== Content-Type: multipart/alternative; boundary="----=_Part_2714156_24876845.1180932224144" ------=_Part_2714156_24876845.1180932224144 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 W1BsZWFzZSBhY2NlcHQgb3VyIGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBjb3Bp ZXMgb2YgdGhpcyBDRlBdIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIA0KQ0FMTCBGT1IgUEFQRVJTIGZvciBVU04gMjAwNyANCg0KVGhlIDNy ZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5kIFViaXF1aXRvdXMgU2Vuc29yIE5l dHdvcmtzIChVU04pIA0KDQpodHRwOi8vdW5zLmFqb3UuYWMua3IvfnVzbjIwMDcvLCBEZWNlbWJl ciAxNy0yMCwgMjAwNywgVGFpcGVpLCBUYWl3YW4pIA0KDQpUbyBiZSBoZWxkIGluIGNvbmp1bmN0 aW9uIHdpdGggRVVDIDIwMDcgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIA0KDQoNCkltcG9ydGFudCBEYXRlczogDQoNCiogU3VibWlzc2lvbiBE dWU6IEp1bmUgMTUsIDIwMDcgKGV4dGVuZGVkIGRlYWRsaW5lKSANCg0KKiBBY2NlcHRhbmNlIG5v dGlmaWNhdGlvbjogQXVndXN0IDYsIDIwMDcgDQoNCiogQ2FtZXJhLXJlYWR5IGR1ZTogU2VwdGVt YmVyIDQsIDIwMDcgDQoNCiAgDQpBYm91dCB0aGUgd29ya3Nob3A6IA0KDQpUaGUgcHVycG9zZSBv ZiBVU04gMjAwNyBpcyB0byBlc3RhYmxpc2ggYSBkaXNjdXNzaW9uIGZyYW1ld29yayBvbiBhbGwg dGhlIGNoYWxsZW5nZXMgcmFpc2VkIGZyb20gdGhlIGV2b2x1dGlvbiBvZiB0aGUgVWJpcXVpdG91 cyBTZW5zb3IgTmV0d29ya3MgYW5kIFJGSUQgdGVjaG5vbG9naWVzLiBBcyBhIHVuaXF1ZSBvcHBv cnR1bml0eSB0byBvYnRhaW4gYW4gaW5zaWdodCBvbiB0aGUgbGVhZGluZyB0ZWNobm9sb2dpZXMg b2YgdGhlIG5leHQgcGVydmFzaXZlIGVyYSwgVVNOIDIwMDcgd2FudHMgdG8gaW52aXRlIHJlc2Vh cmNoZXJzIHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgdGhlaXIgaWRlYXMuIA0KICANCg0KVG9waWNz IG9mIHRoaXMgd29ya3Nob3AgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bzogDQoNCqGk ICAgICAgICAgUkZJRCBTeXN0ZW1zIGFuZCBBcmNoaXRlY3R1cmUgDQoNCqGkICAgICAgICAgUkZJ RCBNaWRkbGV3YXJlIERlc2lnbiANCg0KoaQgICAgICAgICBBbnRpLWNvbGxpc2lvbiBhbGdvcml0 aG1zIA0KDQqhpCAgICAgICAgIE1vYmlsZSBSRklEIFN5c3RlbXMgYW5kIEFwcGxpY2F0aW9ucyAN Cg0KoaQgICAgICAgICBEYXRhIE1vZGVsaW5nIGFuZCBNYW5hZ2VtZW50IA0KDQqhpCAgICAgICAg IEVtYmVkZGVkIFJGSUQtZW5hYmxlZCBEZXZpY2UgVGVjaG5vbG9neSANCg0KoaQgICAgICAgICBT ZW5zb3IgTmV0d29yayBBcmNoaXRlY3R1cmVzIGFuZCBQcm90b2NvbHMgDQoNCqGkICAgICAgICAg TmV0d29yayBwcm90b2NvbHMsIGUuZy4sIE1BQyBhbmQgcm91dGluZyANCg0KoaQgICAgICAgICBE aXN0cmlidXRlZCBBbGdvcml0aG1zLCBlLmcuLCBMb2NhbGl6YXRpb24gYW5kIFN5bmNocm9uaXph dGlvbiANCg0KoaQgICAgICAgICBDcm9zcyBMYXllciBhbmQgRW5lcmd5IEVmZmljaWVudCBEZXNp Z24gDQoNCqGkICAgICAgICAgVVNOIE1pZGRsZXdhcmUgSXNzdWVzLCBlLmcuLCBPUyBhbmQgRGF0 YWJhc2UgDQoNCqGkICAgICAgICAgQ29leGlzdGVuY2Ugb2YgUkZJRCAmIFVTTiANCg0KoaQgICAg ICAgICBRb1MgYW5kIFJlYWwtVGltZSBJc3N1ZXMgDQoNCqGkICAgICAgICAgU2VjdXJpdHkgYW5k IHByaXZhY3kgaXNzdWVzIA0KDQqhpCAgICAgICAgIE5ldHdvcmsgTWFuYWdlbWVudCBpbiBMYXJn ZS1zY2FsZSBEZXBsb3ltZW50IA0KDQqhpCAgICAgICAgIENvZXhpc3RlbmNlIG9mIFJGSUQgJiBV U04gDQoNCqGkICAgICAgICAgTm92ZWwgUkZJRCBhbmQgVVNOIEFwcGxpY2F0aW9ucyANCiAgDQoN CldvcmtzaG9wIENoYWlycyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KDQpZb3VuZy1CYWUgS28s IEFqb3UgVW5pdmVyc2l0eSwgS29yZWEgDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRzb24g UmVzZWFyY2gsIFVTQSANCg0KICANCg0KU3RlZXJpbmcgQ29tbWl0dGVlIA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSANCg0KSm9uZ3N1ayBDaGFlLCBFVFJJLCBLb3JlYSANCg0KU2V1bmctV2hhIFlv bywgQWpvdSBVbml2ZXJzaXR5LCBLb3JlYSANCg0KWXUtQ2hlZSBUc2VuZywgTmF0aW9uYWwgQ2hp YW8gVHVuZyBVbml2LiwgVGFpd2FuIA0KDQpEYWV5b3VuZyBLaW0sIEluZm9ybWF0aW9uIGFuZCBD b21tdW5pY2F0aW9ucyBVbml2ZXJzaXR5LCBLb3JlYSANCg0KICANCg0KUHJvZ3JhbSBDb21taXR0 ZWUgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNCkJ5dW5naHVuIFNvbmcsIEtFVEksIEtv cmVhIA0KDQpDaGFuc3UgWXUsIENsZXZlbGFuZCBTdGF0ZSBVbml2ZXJzaXR5LCBVU0EgDQoNCkNo aWgtWXVuZyBDaGFuZywgVGFta2FuZyBVbml2ZXJzaXR5LCBUYWl3YW4gDQoNCkRvbmctS3l1biBL aW0sIEt5dW5ncG9vayBOYXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KSmFlLUh5dW4gS2lt LCBBam91IFVuaXZlcnNpdHksIEtvcmVhIA0KDQpKYXZpZXIgR29tZXosIE5hdGlvbmFsIFVuaXZl cnNpdHkgb2YgTWV4aWNvLCBNZXhpY28gDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRzb24g UmVzZWFyY2gsIFVTQSANCg0KS3VpIFd1LCBVbml2ZXJzaXR5IG9mIFZpY3RvcmlhLCBDYW5hZGEg DQoNCkxpbmctSnloIENoZW4sIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGlvbiBTY2llbmNlLCBUYWl3 YW4gDQoNCk1pbmVvIFRha2FpLCBVQ0xBLCBVU0EgDQoNCk1pbmctSmVyIFRzYWksIE5hdGlvbmFs IFRzaW5nLUh1YSBVbml2LiwgVGFpd2FuIA0KDQpNaXNjaGEgRG9obGVyLCBGcmFuY2UgVGVsZWNv bSwgRnJhbmNlIA0KDQpNb2hhbWVkIFlvdW5pcywgVW5pdmVyc2l0eSBvZiBNYXJ5bGFuZCwgVVNB IA0KDQpPemd1ciBFcmNldGluLCBTYWJhbmNpIFVuaXZlcnNpdHksIFR1cmtleSANCg0KU2FhZCBC aWF6LCBBdWJ1cm4gVW5pdmVyc2l0eSwgVVNBIA0KDQpUYWVreXVuZyBLd29uLCBTZW91bCBOYXRp b25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KVGFlLUppbiBMZWUsIFN1bmdreXVua3dhbiBVbml2 ZXJzaXR5LCBLb3JlYSANCg0KWXVoLVNoeWFuIENoZW4sIE5hdGlvbmFsIENodW5nIENoZW5nIFVu aXZlcnNpdHksIFRhaXdhbiANCg0KV2VpIExvdSwgSG9uZyBLb25nIFBvbHl0ZWNobmljIFVuaXZl cnNpdHksIENoaW5hIA0KDQpXZW4tQ2hpaCBQZW5nLCBOYXRpb25hbCBDaGlhbyBUdW5nIFVuaXYu LCBUYWl3YW4gDQoNCldvbmp1biBMZWUsIEtvcmVhIFVuaXZlcnNpdHksIEtvcmVhIA0KDQotLS0t LQ0KDQpaZWVzaGFuIEhhbWVlZCBNaXIsDQpBam91IFVuaXZlcnNpdHksIFNvdXRoIEtvcmVhDQoN Cg== ------=_Part_2714156_24876845.1180932224144 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9J3RleHQvY3NzJz4gUCB7cGFkZGluZzowcHg7IG1hcmdp bjoycHg7IGJvcmRlcjowcHg7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6J2FyaWFsJzt9ICBi b2R5IHtwYWRkaW5nOjVweDsgbWFyZ2luOjBweDsgYm9yZGVyOjBweDtmb250LXNpemU6MTNweDtm b250LWZhbWlseTonYXJpYWwnO30gPC9zdHlsZT48L2hlYWQ+PGJvZHk+PHRhYmxlIHdpZHRoPTk5 JSBhbGlnbj1jZW50ZXIgaGVpZ2h0PScxMDAnPjx0ciB2YWxpZ249dG9wPjx0ZD48Zm9udCBzaXpl PTI+PFA+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+W1BsZWFzZSBhY2NlcHQgb3VyIGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2 ZSBtdWx0aXBsZSBjb3BpZXMgb2YgdGhpcyBDRlBdPC9TUEFOPjxTUEFOIGxhbmc9RU4tVVM+IDxC Uj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZP TlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPkNBTEwgRk9SIFBBUEVSUyBmb3IgVVNOIDIwMDc8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+VGhlIDNyZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5kIFVi aXF1aXRvdXMgU2Vuc29yIE5ldHdvcmtzIChVU04pIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1F Ti1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxh bmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYi Pmh0dHA6Ly91bnMuYWpvdS5hYy5rci9+dXNuMjAwNy8sIERlY2VtYmVyIDE3LTIwLCAyMDA3LCBU YWlwZWksIFRhaXdhbik8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VG8gYmUgaGVsZCBpbiBj b25qdW5jdGlvbiB3aXRoIEVVQyAyMDA3PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZPTlQ+ PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+SW1wb3J0YW50IERhdGVzOjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNl cmlmIj4qIFN1Ym1pc3Npb24gRHVlOiBKdW5lIDE1LCAyMDA3IChleHRlbmRlZCBkZWFkbGluZSk8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+KiBBY2NlcHRhbmNlIG5vdGlmaWNhdGlvbjogQXVn dXN0IDYsIDIwMDcgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFO PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+KiBDYW1lcmEtcmVhZHkgZHVl OiBTZXB0ZW1iZXIgNCwgMjAwNyA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQ QU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5BYm91dCB0aGUgd29ya3Nob3A6PC9TUEFOPjwvRk9OVD48U1BB TiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPlRoZSBwdXJwb3NlIG9mIFVTTiAyMDA3IGlzIHRvIGVzdGFibGlzaCBhIGRpc2N1 c3Npb24gZnJhbWV3b3JrIG9uIGFsbCB0aGUgY2hhbGxlbmdlcyByYWlzZWQgZnJvbSB0aGUgZXZv bHV0aW9uIG9mIHRoZSBVYmlxdWl0b3VzIFNlbnNvciBOZXR3b3JrcyBhbmQgUkZJRCB0ZWNobm9s b2dpZXMuIEFzIGEgdW5pcXVlIG9wcG9ydHVuaXR5IHRvIG9idGFpbiBhbiBpbnNpZ2h0IG9uIHRo ZSBsZWFkaW5nIHRlY2hub2xvZ2llcyBvZiB0aGUgbmV4dCBwZXJ2YXNpdmUgZXJhLCBVU04gMjAw NyB3YW50cyB0byBpbnZpdGUgcmVzZWFyY2hlcnMgdG8gcHJlc2VudCBhbmQgZGlzY3VzcyB0aGVp ciBpZGVhcy4gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48L1NQQU4+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fu cy1zZXJpZiI+VG9waWNzIG9mIHRoaXMgd29ya3Nob3AgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGlt aXRlZCB0bzogPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFJGSUQgU3lzdGVtcyBhbmQgQXJjaGl0ZWN0dXJlIDwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSRklEIE1pZGRsZXdhcmUg RGVzaWduIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBBbnRpLWNvbGxpc2lvbiBhbGdvcml0aG1zIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2Vy aWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNb2JpbGUgUkZJRCBTeXN0ZW1zIGFu ZCBBcHBsaWNhdGlvbnMgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IERhdGEgTW9kZWxpbmcgYW5kIE1hbmFnZW1lbnQgPC9TUEFOPjwvRk9O VD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEVtYmVkZGVkIFJG SUQtZW5hYmxlZCBEZXZpY2UgVGVjaG5vbG9neSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4t VVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6h pCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2Vuc29yIE5ldHdvcmsgQXJjaGl0ZWN0dXJl cyBhbmQgUHJvdG9jb2xzIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBOZXR3b3JrIHByb3RvY29scywgZS5nLiwgTUFDIGFuZCByb3V0aW5n IDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBEaXN0cmlidXRlZCBBbGdvcml0aG1zLCBlLmcuLCBMb2NhbGl6YXRpb24gYW5kIFN5bmNocm9u aXphdGlvbiA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgQ3Jvc3MgTGF5ZXIgYW5kIEVuZXJneSBFZmZpY2llbnQgRGVzaWduIDwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBVU04gTWlk ZGxld2FyZSBJc3N1ZXMsIGUuZy4sIE9TIGFuZCBEYXRhYmFzZSA8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29leGlzdGVuY2Ugb2YgUkZJ RCAmYW1wOyBVU04gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFO PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFFvUyBhbmQgUmVhbC1UaW1lIElzc3VlcyA8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2VjdXJpdHkgYW5kIHByaXZh Y3kgaXNzdWVzIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBOZXR3b3JrIE1hbmFnZW1lbnQgaW4gTGFyZ2Utc2NhbGUgRGVwbG95bWVudCA8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1z YW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7 IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Q29leGlzdGVuY2Ugb2YgUkZJRCAmYW1wOyBVU04gPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVO LVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+ oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE5vdmVsIFJGSUQgYW5kIFVTTiBBcHBsaWNh dGlvbnMgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48L1NQQU4+PEZPTlQgZmFj ZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+V29ya3Nob3AgQ2hhaXJzPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+ PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0tLS0t LS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+WW91bmctQmFlIEtvLCBBam91IFVu aXZlcnNpdHksIEtvcmVhIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkthbmctV29uIExlZSwg SUJNIFQuSiBXYXRzb24gUmVzZWFyY2gsIFVTQTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1V Uz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4m bmJzcDs8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+U3RlZXJpbmcgQ29tbWl0dGVlIDwvU1BB Tj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9 Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBz YW5zLXNlcmlmIj5Kb25nc3VrIENoYWUsIEVUUkksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBs YW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMt c2VyaWYiPlNldW5nLVdoYSBZb28sIEFqb3UgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+WXUtQ2hlZSBUc2VuZywgTmF0aW9uYWwgQ2hpYW8gVHVuZyBVbml2Liwg VGFpd2FuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkRhZXlvdW5nIEtpbSwgSW5mb3JtYXRp b24gYW5kIENvbW11bmljYXRpb25zIFVuaXZlcnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BB TiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPiZuYnNwOzwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48 L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Qcm9ncmFtIENvbW1p dHRlZTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTwvU1BB Tj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5z LXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZP TlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5CeXVuZ2h1biBTb25nLCBLRVRJLCBLb3JlYTwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5DaGFuc3UgWXUsIENsZXZlbGFuZCBTdGF0ZSBVbml2ZXJzaXR5 LCBVU0E8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Q2hpaC1ZdW5nIENoYW5nLCBUYW1rYW5n IFVuaXZlcnNpdHksIFRhaXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Eb25nLUt5dW4g S2ltLCBLeXVuZ3Bvb2sgTmF0aW9uYWwgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+SmFlLUh5dW4gS2ltLCBBam91IFVuaXZlcnNpdHksIEtvcmVhPC9TUEFOPjwv Rk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPkphdmllciBHb21leiwgTmF0aW9uYWwgVW5pdmVyc2l0eSBvZiBN ZXhpY28sIE1leGljbzwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQ QU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5LYW5nLVdvbiBMZWUsIElC TSBULkogV2F0c29uIFJlc2VhcmNoLCBVU0E8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+ IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+S3Vp IFd1LCBVbml2ZXJzaXR5IG9mIFZpY3RvcmlhLCBDYW5hZGE8L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+TGluZy1KeWggQ2hlbiwgSW5zdGl0dXRlIG9mIEluZm9ybWF0aW9uIFNjaWVuY2UsIFRh aXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5NaW5lbyBUYWthaSwgVUNMQSwgVVNBPC9T UEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPk1pbmctSmVyIFRzYWksIE5hdGlvbmFsIFRzaW5nLUh1 YSBVbml2LiwgVGFpd2FuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPk1pc2NoYSBEb2hsZXIs IEZyYW5jZSBUZWxlY29tLCBGcmFuY2U8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxC Uj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+TW9oYW1l ZCBZb3VuaXMsIFVuaXZlcnNpdHkgb2YgTWFyeWxhbmQsIFVTQTwvU1BBTj48L0ZPTlQ+PFNQQU4g bGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj5Pemd1ciBFcmNldGluLCBTYWJhbmNpIFVuaXZlcnNpdHksIFR1cmtleTwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNl cmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQt RkFNSUxZOiBzYW5zLXNlcmlmIj5TYWFkIEJpYXosIEF1YnVybiBVbml2ZXJzaXR5LCBVU0E8L1NQ QU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fu cy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBG T05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VGFla3l1bmcgS3dvbiwgU2VvdWwgTmF0aW9uYWwgVW5p dmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9T UEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+VGFlLUppbiBMZWUsIFN1 bmdreXVua3dhbiBVbml2ZXJzaXR5LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1V Uz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5Z dWgtU2h5YW4gQ2hlbiwgTmF0aW9uYWwgQ2h1bmcgQ2hlbmcgVW5pdmVyc2l0eSwgVGFpd2FuPC9T UEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPldlaSBMb3UsIEhvbmcgS29uZyBQb2x5dGVjaG5pYyBV bml2ZXJzaXR5LCBDaGluYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48 L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxl PSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5XZW4tQ2hpaCBQZW5n LCBOYXRpb25hbCBDaGlhbyBUdW5nIFVuaXYuLCBUYWl3YW48L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+V29uanVuIExlZSwgS29yZWEgVW5pdmVyc2l0eSwgS29yZWE8L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUz4tLS0t LTwvU1BBTj48L1A+DQo8UD48U1BBTiBsYW5nPUVOLVVTPjwvU1BBTj4mbmJzcDs8L1A+DQo8UD48 U1BBTiBsYW5nPUVOLVVTPlplZXNoYW4gSGFtZWVkIE1pciw8L1NQQU4+PC9QPg0KPFA+PFNQQU4g bGFuZz1FTi1VUz5Bam91IFVuaXZlcnNpdHksIFNvdXRoIEtvcmVhPC9QPjwvU1BBTj48L2ZvbnQ+ PC90ZD48L3RyPjwvdGFibGU+PGJyPg0KPGltZyBpZD0nbWFpbGV4cCcgd2lkdGg9MCBoZWlnaD0w IGJvcmRlcj0wIHNyYz0naHR0cDovL21haWwuYWpvdS5hYy5rcjo4MC9tYWlsX3JlY2VpcHRfY2hl Y2suanNwP3VrZXk9NDY2MzliMTQzZmU5ODM3MjZmMWI1OThhJnVzZXJpZD16aG1pciZhaG9zdD1h am91X2FjX2tyJz48L2JvZHk+PC9odG1sPg== ------=_Part_2714156_24876845.1180932224144-- --===============0399495044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0399495044==-- From rsn-bounces@ietf.org Mon Jun 04 01:23:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv52W-00023X-MU; Mon, 04 Jun 2007 01:23:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv52V-00022M-65 for rsn@ietf.org; Mon, 04 Jun 2007 01:23:35 -0400 Received: from auth-smtp.nebula.fi ([217.30.180.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv52T-0004nI-M6 for rsn@ietf.org; Mon, 04 Jun 2007 01:23:35 -0400 Received: from s-cwc-pc199.local (addr-213-139-165-97.baananet.fi [213.139.165.97]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id l544tLLB008470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 4 Jun 2007 07:55:22 +0300 Message-ID: <4663A1D0.2000406@sensinode.com> Date: Mon, 04 Jun 2007 08:23:28 +0300 From: Zach Shelby User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: rsn@ietf.org Subject: Re: [RSN] Industrial References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> In-Reply-To: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, I would like to contribute to the Industrial application-specific ID. - Zach JP Vasseur wrote: > Dear all, > > Here is an update on where we stand: good progress ! > > 1) We've been having quite a bit of off-line and on-line discussions and > there is apparently a good level of interest in this work. > There are currently 5 IDs in the works: > * The generic routing requirements: draft-culler-rsn-routing-reqs > * Two application-specific routing requirements: > - Home Networking > - Industrial > * A problem statement > * An ID on routing metrics > > Of course, if you're interested to work on these IDs or other items, > feel free ! > > 2) New name > Although we called this initiative RSN: Routing for Sensor Networks, it > does apply more generally to constrained nodes (Low Power) > operating in Lossy Networks. Objects in general would typically be part > of those networks. So from now on, let's rename this work > R2LN: "Routing issues for Low Power, Lossy Networks", and use that > acronym in all IDs. > > 3) Next IETF > We asked for a presentation slot for the next IETF. Depending on the > feedback, the next step would then to request a BOF in Vancouver. > > Thanks. > > JP and David. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn -- Zach Shelby | Managing Director | +358 40 7796297 Sensinode Ltd. www.sensinode.com _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jun 04 06:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9Pv-0000jF-Hx; Mon, 04 Jun 2007 06:04:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hv9Pu-0000j9-Ek for rsn@ietf.org; Mon, 04 Jun 2007 06:04:02 -0400 Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hv9Pt-0007gZ-Rj for rsn@ietf.org; Mon, 04 Jun 2007 06:04:02 -0400 Received: from smtpscan-eur5.philips.com (smtpscan-eur5.mail.philips.com [130.144.57.168]) by gw-eur4.philips.com (Postfix) with ESMTP id 1D0D749712; Mon, 4 Jun 2007 10:04:01 +0000 (UTC) Received: from smtpscan-eur5.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id DDA68619; Mon, 4 Jun 2007 10:04:00 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur5.philips.com (Postfix) with ESMTP id B63E13EE; Mon, 4 Jun 2007 10:04:00 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 96E228E; Mon, 4 Jun 2007 10:04:00 +0000 (GMT) In-Reply-To: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> To: JP Vasseur Subject: Re: [RSN] Update MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Anthony Schoofs Date: Mon, 4 Jun 2007 12:06:04 +0200 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.5HF1002 | November 23, 2006) at 04/06/2007 12:06:05, Serialize complete at 04/06/2007 12:06:05 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0496628291==" Errors-To: rsn-bounces@ietf.org This is a multipart message in MIME format. --===============0496628291== Content-Type: multipart/alternative; boundary="=_alternative 00373EF1C12572F0_=" This is a multipart message in MIME format. --=_alternative 00373EF1C12572F0_= Content-Type: text/plain; charset="US-ASCII" We did some work to schedule a coordinate switching on and off of sensor nodes in order to reduce at maximum the energy consumption of the network. We came up with a routing protocol that allows us to route data throughout the network according to the ON/OFF state of the nodes. We would like to provide input for an ID on routing schemes that have energy consumption as the first focus. Best regards, Anthony. -- Anthony Schoofs Philips Research High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands Email: anthony.schoofs@philips.com JP Vasseur 03-06-2007 14:02 To rsn@ietf.org cc Subject [RSN] Update Classification Dear all, Here is an update on where we stand: good progress ! 1) We've been having quite a bit of off-line and on-line discussions and there is apparently a good level of interest in this work. There are currently 5 IDs in the works: * The generic routing requirements: draft-culler-rsn-routing-reqs * Two application-specific routing requirements: - Home Networking - Industrial * A problem statement * An ID on routing metrics Of course, if you're interested to work on these IDs or other items, feel free ! 2) New name Although we called this initiative RSN: Routing for Sensor Networks, it does apply more generally to constrained nodes (Low Power) operating in Lossy Networks. Objects in general would typically be part of those networks. So from now on, let's rename this work R2LN: "Routing issues for Low Power, Lossy Networks", and use that acronym in all IDs. 3) Next IETF We asked for a presentation slot for the next IETF. Depending on the feedback, the next step would then to request a BOF in Vancouver. Thanks. JP and David. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --=_alternative 00373EF1C12572F0_= Content-Type: text/html; charset="US-ASCII"
We did some work to schedule a coordinate switching on and off of sensor nodes in order to reduce at maximum the energy consumption of the network.
We came up with a routing protocol that allows us to route data throughout  the network according to the ON/OFF state of the nodes.

We would like to provide input for an ID on routing schemes that have energy consumption as the first focus.

Best regards,
Anthony.

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







JP Vasseur <jvasseur@cisco.com>

03-06-2007 14:02

To
rsn@ietf.org
cc
Subject
[RSN] Update
Classification





Dear all,

Here is an update on where we stand: good progress !

1) We've been having quite a bit of off-line and on-line discussions  
and there is apparently a good level of interest in this work.
There are currently 5 IDs in the works:
* The generic routing requirements: draft-culler-rsn-routing-reqs
* Two application-specific routing requirements:
                - Home Networking
                - Industrial
* A problem statement
* An ID on routing metrics

Of course, if you're interested to work on these IDs or other items,  
feel free !

2) New name
Although we called this initiative RSN: Routing for Sensor Networks,  
it does apply more generally to constrained nodes (Low Power)
operating in Lossy Networks. Objects in general would typically be  
part of those networks. So from now on, let's rename this work
R2LN: "Routing issues for Low Power, Lossy Networks", and use that  
acronym in all IDs.

3) Next IETF
We asked for a presentation slot for the next IETF. Depending on the  
feedback, the next step would then to request a BOF in Vancouver.

Thanks.

JP and David.

_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn
--=_alternative 00373EF1C12572F0_=-- --===============0496628291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0496628291==-- From rsn-bounces@ietf.org Mon Jun 04 11:37:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEcK-0004wy-KK; Mon, 04 Jun 2007 11:37:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEcJ-0004wp-GF; Mon, 04 Jun 2007 11:37:11 -0400 Received: from cs1.sf.archedrock.com ([64.147.171.181] helo=secure.archedrock.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEcI-00075n-35; Mon, 04 Jun 2007 11:37:11 -0400 Received: by secure.archedrock.com (Postfix, from userid 101) id 9527C16B0001; Mon, 4 Jun 2007 08:37:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on cs1.sf.archedrock.com X-Spam-Level: X-Spam-Status: No, score=-101.0 required=5.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_ID,TW_TJ,USER_IN_WHITELIST autolearn=no version=3.1.8 Received: from GoatRock (69-12-164-142.sfo.archedrock.com [69.12.164.142]) by secure.archedrock.com (Postfix) with ESMTP id E95E316B0001; Mon, 4 Jun 2007 08:37:08 -0700 (PDT) From: "dculler" To: "'Mark Townsley'" , "'Timothy J. Salo'" Subject: RE: [RSN] Update Date: Mon, 4 Jun 2007 08:36:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46632FB9.6080705@cisco.com> Thread-Index: AcemJIL8UMhVJoKYSJywjTNfZAep0wAmN+2Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Message-Id: <20070604153708.E95E316B0001@secure.archedrock.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: rsn@ietf.org, 6lowpan@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dculler@archrock.com List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org I think the simplification to "Routing Issues for Low Power Wireless Networks" is very good. It defines the scope implicitly in a number of useful ways. * There are a whole class of these devices where no routing is involved (game controllers, remote controls, wireless keyboard and mouse, ear pieces). * It includes portions of sensor networks, embedded networks, automation, but it not specifically limited to that. * It includes 802.15.4 and links in a similar class. * The technical challenges (loss, variation, multihop) are implied. * It allows for both light footprint (microcontroller) and more capable hosts. So now we just need to tweak it to get a good acronym, since RILPWM doesn't exactly role off the tongue. -----Original Message----- From: Mark Townsley [mailto:townsley@cisco.com] Sent: Sunday, June 03, 2007 2:17 PM To: Timothy J. Salo Cc: rsn@ietf.org; 6lowpan@ietf.org Subject: Re: [RSN] Update Timothy J. Salo wrote: > JP Vasseur wrote: >> 2) New name >> Although we called this initiative RSN: Routing for Sensor Networks, >> it does apply more generally to constrained nodes (Low Power) >> operating in Lossy Networks. Objects in general would typically be >> part of those networks. So from now on, let's rename this work >> R2LN: "Routing issues for Low Power, Lossy Networks", and use that >> acronym in all IDs. > > I suggest that "Routing Issues in Low-Power Wireless Networks" > might be more descriptive. > > "Wireless" implies "lossy". "Wireless" also implies a variety of > other behaviors, such as a limited-range broadcast (usually), and a > variety of others. > > I doubt that we will spend any time at all thinking about low power > wired networks. > > "Low-Power" sounds better than "Resource-Constrained", although the > latter might be more descriptive. > > And finally, to do the job well, this group must look at more than > just routing issues (e.g., neighbor discovery and management in > low-power wireless networks). We might consider: This part should be part of the 6lowpan recharter. The idea amongst the ADs has been to split off the routing portion of the work on low-power networks to the routing area, and continue forward with work on ND, bootstrapping, etc. within the int-area. > > "Internetworking Issues in Low-Power Wireless Networks" > > or > > "Internetworking Issues in Resource-Constrained Wireless Networks" > > or even > > "Internetworking Issues in Resource-Constrained Networks" (I2RCN) > > One (non-trivial) advantage of "Internetworking" is that it helps > answer the question: Why should the IETF (e.g., rather than the IEEE) > be interested in this work? (Assuming that we think about how > low-power wireless networks should be interconnected with the > Internet.) I agree that this is an important topic that should be part of both charters. - Mark > > -tjs > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jun 04 12:13:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFBL-0006Rt-Gz; Mon, 04 Jun 2007 12:13:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFBJ-0006RA-Iw; Mon, 04 Jun 2007 12:13:21 -0400 Received: from imap.univmed.fr ([2001:660:5402:800::126] helo=univmed.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFBE-00067X-L5; Mon, 04 Jun 2007 12:13:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by univmed.fr (Postfix) with ESMTP id 0BE7346A4B8; Mon, 4 Jun 2007 18:13:15 +0200 (CEST) X-Virus-Scanned: by amavisd-new at univmed.fr Received: from univmed.fr ([127.0.0.1]) by localhost (smtp.univmed.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAnsfNkuhE0U; Mon, 4 Jun 2007 18:13:12 +0200 (CEST) Received: from LapTM-G4.local (unknown [82.237.240.239]) by univmed.fr (Postfix) with ESMTP id 4719546A438; Mon, 4 Jun 2007 18:13:11 +0200 (CEST) Message-ID: <46643A15.9050204@univmed.fr> Date: Mon, 04 Jun 2007 18:13:09 +0200 From: Traian MUNTEAN Organization: Univ =?ISO-8859-1?Q?=22M=E9diterran=E9e=22_Marseille_-_?= =?ISO-8859-1?Q?France?= User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: dculler@archrock.com Subject: Re: [RSN] Update References: <20070604153708.E95E316B0001@secure.archedrock.com> In-Reply-To: <20070604153708.E95E316B0001@secure.archedrock.com> X-Spam-Score: 3.3 (+++) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: rsn@ietf.org, 6lowpan@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Traian.Muntean@univmed.fr List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0248906518==" Errors-To: rsn-bounces@ietf.org --===============0248906518== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,
I have not yet contributed to the discussion but David's last comments seem to me quite correct.
I would also insist on the dynamic "adaptiveness" of such networks and associated routing issues, and this not only because this would simplify "the role off the tongue"! (could provide an acronym like RIALPoWN which could be by extension read: "real pawn"!! ...yet tedious!)
Best,
Traian

dculler wrote: 
I think the simplification to "Routing Issues for Low Power Wireless
Networks" is very good.  It defines the scope implicitly in a number of
useful ways. 
* There are a whole class of these devices where no routing is involved
(game controllers, remote controls, wireless keyboard and mouse, ear
pieces).
* It includes portions of sensor networks, embedded networks, automation,
but it not specifically limited to that.
* It includes 802.15.4 and links in a similar class.
* The technical challenges (loss, variation, multihop) are implied.
* It allows for both light footprint (microcontroller) and more capable
hosts.

So now we just need to tweak it to get a good acronym, since RILPWM doesn't
exactly role off the tongue.

 

-----Original Message-----
From: Mark Townsley [mailto:townsley@cisco.com] 
Sent: Sunday, June 03, 2007 2:17 PM
To: Timothy J. Salo
Cc: rsn@ietf.org; 6lowpan@ietf.org
Subject: Re: [RSN] Update

Timothy J. Salo wrote:
  
JP Vasseur wrote:
    
2) New name
Although we called this initiative RSN: Routing for Sensor Networks, 
it does apply more generally to constrained nodes (Low Power) 
operating in Lossy Networks. Objects in general would typically be 
part of those networks. So from now on, let's rename this work
R2LN: "Routing issues for Low Power, Lossy Networks", and use that 
acronym in all IDs.
      
I suggest that "Routing Issues in Low-Power Wireless Networks"
might be more descriptive.

"Wireless" implies "lossy".  "Wireless" also implies a variety of 
other behaviors, such as a limited-range broadcast (usually), and a 
variety of others.

I doubt that we will spend any time at all thinking about low power 
wired networks.

"Low-Power" sounds better than "Resource-Constrained", although the 
latter might be more descriptive.

And finally, to do the job well, this group must look at more than 
just routing issues (e.g., neighbor discovery and management in 
low-power wireless networks).  We might consider:
    
This part should be part of the 6lowpan recharter. The idea amongst the ADs
has been to split off the routing portion of the work on low-power networks
to the routing area, and continue forward with work on ND, bootstrapping,
etc. within the int-area.
  
  "Internetworking Issues in Low-Power Wireless Networks"

or

  "Internetworking Issues in Resource-Constrained Wireless Networks"

or even

  "Internetworking Issues in Resource-Constrained Networks" (I2RCN)

One (non-trivial) advantage of "Internetworking" is that it helps 
answer the question: Why should the IETF (e.g., rather than the IEEE) 
be interested in this work?  (Assuming that we think about how 
low-power wireless networks should be interconnected with the 
Internet.)
    
I agree that this is an important topic that should be part of both
charters.

- Mark
  
-tjs


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

    

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



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

--===============0248906518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0248906518==-- From rsn-bounces@ietf.org Mon Jun 04 23:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPKY-0003Nc-PW; Mon, 04 Jun 2007 23:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvPKY-0003NO-2Y; Mon, 04 Jun 2007 23:03:34 -0400 Received: from saloits.com ([208.42.140.127] helo=newbsd.saloits.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvPKW-000484-GR; Mon, 04 Jun 2007 23:03:34 -0400 Received: from [127.0.0.1] (mpls.saloits.com [216.243.132.62]) by newbsd.saloits.com (8.13.1/8.13.1) with ESMTP id l553347s091193; Mon, 4 Jun 2007 22:03:24 -0500 (CDT) (envelope-from salo@saloits.com) Message-ID: <4664D24E.2000803@saloits.com> Date: Mon, 04 Jun 2007 22:02:38 -0500 From: "Timothy J. Salo" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rsn@ietf.org, 6lowpan@ietf.org Subject: Re: [RSN] Update References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> In-Reply-To: <46632FB9.6080705@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Mark Townsley wrote: >> And finally, to do the job well, this group must look at more >> than just routing issues (e.g., neighbor discovery and management >> in low-power wireless networks). We might consider: >> > This part should be part of the 6lowpan recharter. The idea amongst the > ADs has been to split off the routing portion of the work on low-power > networks to the routing area, and continue forward with work on ND, > bootstrapping, etc. within the int-area. I strongly recommend that serious consideration be given to creating a single working group that is responsible for both the routing and the non-routing aspects of low-power wireless networks. While it is important to apply the IETF's routing expertise to these issues, I believe that, in this arena, there is also a need for close coordination between the routing solutions and the non-routing solutions. o I believe that the IETF's low-power wireless network activity (both the routing and the non-routing portions) will benefit from (perhaps even require) outside experts and expertise. (i.e., people who don't traditionally attend IETF working group meetings). I also believe that it will be much easier for these people to attend working group meetings if there is a single working group, rather than two. Yes, we could have two working groups and promise that they will always meet on the same day. But, given the complexities of scheduling working group meetings, it seems much easier and much more reliable to simply have a single working group. Groups I would like to see attend include: - Wireless Sensor Network (WSN) Research Commmunity - The WSN research community has considerable domain expertise that would benefit the IETF. Furthermore, this community is developing routing protocols adapted to the unique needs of WSNs that are radically different than anything the IETF is thinking about (e.g., protocols that propagate _only_ a default route, and enable nodes to route packets to _only_ to an exit router or to immediately adjacent nodes; and protocols that enable at least some nodes to sleep most of the time). - Home Automation and Industrial Automation Vendors - These groups have strong ideas about their requirements and have developed some initial solutions. - Standards Bodies and Industry Consortiums - It is possible that some of these groups (e.g., ZigBee Alliance, IEEE etc.) might choose to send some representatives. o I believe that low-power wireless networks are, in many respects, radically different than the networks with which the IETF has experience. As a result, both those working on the routing and the non-routing aspects of this problem will need to collectively develop a detailed understanding of the of the unique characteristics of these environments. Some of these unique characteristics have strong implications for the routing solutions (e.g., some nodes may sleep much of the time; some nodes may be severely energy-constrained, while other nodes may be mains-powered; nodes may have [at least in academic discussions] thousands of neighbors]). It would be useful for the routing and non-routing participants to develop this domain expertise jointly, rather than have after-the-fact discussions of the form: But, you didn't tell us about _that_ requirement... o Finally, I believe that there must be much closer collaboration between the routing and the non-routing solutions than is common in the IETF. For example, some proposed WSN routing protocols assume that clocks are reasonably well synchronized (no, they don't run NTP). Some system-level design issues should be decided in close coordination with the routing protocol design, such as: - Should some nodes, such as power-rich or gateway nodes, act as proxies (for some functions) for power constrained node? - Should a link/subnet use both MAC addresses and network-addresses, or should only a single set of addresses be used for both purposes? - Should full IP (particularly IPv6) addresses _ever_ be transmitted over a low-power wireless link (except to request translation to a short, link-local address)? Having said all that, I do think that it is important for a single (or maybe "joint") low-power wireless networking working group to be associated with both the Internet Area and the Routing Area. Perhaps, it is possible for this working group to be associated with, and have oversight from, both Areas. Thoughts on whether this new working group should result from a rechartering of the 6lowpan working group, or whether a fresh start would be beneficial, is the topic of some future pontification^H^H^H^H^H^H e-mail. More unsolicited opinions from, -tjs _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jun 05 04:03:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvU0Y-0002Bx-FX; Tue, 05 Jun 2007 04:03:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvU0Y-0002Bp-4e for RSN@ietf.org; Tue, 05 Jun 2007 04:03:14 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvU0V-0003K4-M8 for RSN@ietf.org; Tue, 05 Jun 2007 04:03:14 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:03:10 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.227]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:03:10 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [RSN] Update Date: Tue, 5 Jun 2007 10:03:10 +0200 Message-ID: <9E577E61D0108D4F8CD482029B613F5C302A9B@PTPEVS108BA020.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Update thread-index: AcenPRvvGg0mjqs4Tzq1Kl3AuEdoPAAAMYCQAAI5CJg= References: <46643FFE.1040400@telecomitalia.it> <466445C0.9040307@telecomitalia.it> <9E577E61D0108D4F8CD482029B613F5C302A99@PTPEVS108BA020.idc.cww.telecomitalia.it> From: "Cuda Alberto" To: X-OriginalArrivalTime: 05 Jun 2007 08:03:10.0564 (UTC) FILETIME=[F5704240:01C7A747] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi all, This e-mail just to state that Telecom Italia welcomes a solution of the issues listed in the scope of this initiative. In particular Telecom Italia would like to see a smooth and fruitful integration of the IP layer with existing layer 2 protocols to enrich the IP devices' ecosystem once a suitable routing protocol has been developed. Telecom Italia welcomes a solution which is well harmonized with existing standards for Wireless Sensor Networks, in particular ZigBee. The solution should also envisage for a network comprising sleeping routers, i.e. nodes having routing facility and comprising a radio transceiver that is intermittently operating (typically battery powered). Cheers. Alberto. > Dear all, > > Here is an update on where we stand: good progress ! > > 1) We've been having quite a bit of off-line and on-line discussions=20 > and there is apparently a good level of interest in this work. > There are currently 5 IDs in the works: > * The generic routing requirements: draft-culler-rsn-routing-reqs > * Two application-specific routing requirements: > - Home Networking > - Industrial > * A problem statement > * An ID on routing metrics > > Of course, if you're interested to work on these IDs or other items,=20 > feel free ! > > 2) New name > Although we called this initiative RSN: Routing for Sensor Networks,=20 > it does apply more generally to constrained nodes (Low Power)=20 > operating in Lossy Networks. Objects in general would typically be=20 > part of those networks. So from now on, let's rename this work > R2LN: "Routing issues for Low Power, Lossy Networks", and use that=20 > acronym in all IDs. > > 3) Next IETF > We asked for a presentation slot for the next IETF. Depending on the=20 > feedback, the next step would then to request a BOF in Vancouver. > > Thanks. > > JP and David. -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jun 05 13:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcWb-0003qz-L4; Tue, 05 Jun 2007 13:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvcWa-0003qu-Eu for rsn@ietf.org; Tue, 05 Jun 2007 13:08:52 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvcWY-0001W0-Tq for rsn@ietf.org; Tue, 05 Jun 2007 13:08:52 -0400 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.1/8.13.5) with ESMTP id l55H8mZ0011446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Jun 2007 10:08:49 -0700 (PDT) Message-ID: <4665989B.9030301@eecs.berkeley.edu> Date: Tue, 05 Jun 2007 10:08:43 -0700 From: Kris Pister User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: rsn@ietf.org Subject: Re: [RSN] Next step for RSN ? References: <20070522232511.DD58016B0002@secure.archedrock.com> <465A6EBF.70600@sensinode.com> <465BE818.2020909@sensinode.com> <329074DA-D05C-4BDB-8DA4-0F5F5D243A21@cs.stanford.edu> <6D9687E95918C04A8B30A7D6DA805A3E77B2B7@zensys17.zensys.local> <465F198D.3080009@eecs.berkeley.edu> In-Reply-To: <465F198D.3080009@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: 7da5a831c477fb6ef97f379a05fb683c X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org oops. Here's at link to the attachment that didn't go through: http://www.eecs.berkeley.edu/~pister/tmp/Path24to17.gif ksjp Kris Pister wrote: > I don't know what CTP and ETX are, but I'm 100% supportive of the use > of L2 ACKs. > > In my experience, it is quite rare for links to go down in the 2.4GHz > band. However, it is quite common for the PER to go from 0 to 100% on > a given channel. If we have a requirement to support people who don't > channel hop (sigh) then L2 ACKs are even more critical, since a single > bad channel is perceived as a bad link. I do think that in an ideal > world the network layer would have some visibility into the radio > flexibility and the channel characteristics that the radio has to deal > with. In some cases the available information may be "I'm stuck at > 908.42MHz and don't move", or it may be "I can hop on 16 channels". > The link characteristics can always be represented at the very least > by some short term average of PER. > > I've included a plot below of a particular link in a mesh network > running on 15.4 radios. Each horizontal trace is the 15 minute > average PDR (=1-PER) on a particular 15.4 channel (channels are in > 15.4 order, with 2.405 on bottom). You can clearly see the work-week > in the periodicity of the data, for example all channels look great at > around Day 12 (Sunday) and come Day 13 (monday morning) many of them > go to hell. It's interesting that there are a couple of channels that > always look good, but that most would regularly be declared to be > "down links" in a single-channel network. Note also that other links > in the network look similar, but with different channels that are good > over the month-long test. (this data will be published soon at ICCCN) > > Routing algorithms for sensor networks need to comprehend and leverage > this kind of link behavior. > > ksjp > > > > Philip Levis wrote: >> On May 31, 2007, at 4:19 AM, Anders Brandt wrote: >> >>>> The goal should be to define a *minimal* set of primitives the routing >>> layer can depend on, in order to support as a broad a set >>>> of layer 2s as possible. Individual routing implementations for >>> specific layer 2s can always take advantage of special hardware, >>>> but they can't assume its presence for correct operation. For example, >>> a routing implementation might use physical layer >>>> indicators to guide its route selection, but it shouldn't be embedding >>> these indicators in its packets as other nodes might have >>>> different radios with different indicators. E.g., an XBee Pro-based >>> device might not know what to do with the soft chip decision >>>> indicator of a CC2420. >>> >>> I couldn't agree more. RSSI and ToA sounds very sexy but very HW >>> specific. >> >> Well, RSSI can definitely be useful, even if it is HW specific. For >> example, while different HW sensitivities (read: noise floors) means >> that trying to infer link quality from the RSSI value requires >> additional mechanisms, phenomena such as sudden changes in RSSI can >> be very valuable. For example, if a node observes that the RSSI of >> packets from another node just dropped 10 dB, this suggests that the >> link might have degraded. >> >>> >>> A more pragmatic approach might be some high-level L2 API indication of >>> the quality of the link to a given neighbour node. >>> The challenge is mapping the specific properties of different L2's into >>> that high-level L2 API. >>> RSN's finest goal should be a set of primitives that allows routing >>> across a broad range of RF platforms; >>> mesh-under or not, beacon or not, etc. >>> That high-level L2 API will give us a hard work before it satisfies all >>> our conflicting interests, but our success depends on it. >> >> 15.4 tried to do this with LQI, and it's of limited use. There are >> basically two things to consider: >> >> 1) Unless you require an underlying protocol, neighborhood table >> management, or other state in the link layer, this measurement will >> be for *incoming* connectivity only. That is, it measures the quality >> of the packet you received, not the quality of packets you will >> transmit. As soon as you have link asymmetries from hardware (e.g., >> calibration) or from local interference (e.g., a microwave), then >> this simple value is insufficient. >> >> 2) Settling on a value that is truly interoperable is very hard. >> Again, 15.4 tried to specify LQI, but if you look how manufacturers >> suggest you compute LQI from their hardware, they basically say "it's >> up to you." Even given how vague the LQI specification is, it's still >> hard to meet. >> >> Based on these difficulties, the conclusion the TinyOS networking >> group was that trying to specify this L2 information was a lost >> cause. Rather, network protocols shouldn't assume any such >> information, and should be able to operate in its absence. In CTP, >> for example, the periodic routing beacons have sequence numbers in >> them so nodes can estimate PRRs at layer 3. Now, a particular >> implementation may have hardware resources that it can use to >> estimate more quickly or accurately, but the protocol does not assume >> them. For example, when seeding a routing table a node with a CC2420 >> radio can use the soft chip decision indicator (sort of a bit error >> rate) to come up with an estimate that is a lot faster and usually >> but not always more accurate than packet sequence numbers. >> >>> >>> One final note on RF connection reliability: >>> Having statistics for a given path is fine, but in RF, an apparently >>> fine connection may quickly turn out to be weak because of some new >>> noise generator in the neighbourhood. Therefore, being able to quickly >>> choose another alternative link is at least as important as knowing the >>> link quality upfront. >> >> Very true. Most beacon-based routing protocols run into a problem >> here, in that the link quality is updated by periodic beacons, whose >> transmission is independent of data traffic. If a link goes down, the >> time it takes to recover is defined by the beacons and is independent >> of data traffic. The current CTP implementation in TinyOS deals with >> this problem by directly using acknowledgements to estimate link >> quality. CTP uses an ETX metric for routing, and there's no better >> measure of ETX than how many data packets you have to transmit before >> you get an ack... >> >> Phil >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jun 06 04:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvqkC-0002oV-7v; Wed, 06 Jun 2007 04:19:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvqkB-0002oQ-Qk for rsn@ietf.org; Wed, 06 Jun 2007 04:19:51 -0400 Received: from mail.zen-sys.com ([195.215.56.170] helo=zensys17.zensys.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvqkA-0005LQ-GO for rsn@ietf.org; Wed, 06 Jun 2007 04:19:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RSN] Update Date: Wed, 6 Jun 2007 10:19:49 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E77B2D1@zensys17.zensys.local> In-Reply-To: <4664D24E.2000803@saloits.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] Update thread-index: AcenHh9V3G2VjjRGSnetjqigWVkMpQA8fJ5A References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com><46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> <4664D24E.2000803@saloits.com> From: "Anders Brandt" To: "Timothy J. Salo" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org -----Original Message----- From: Timothy J. Salo [mailto:salo@saloits.com]=20 Sent: 5. juni 2007 05:03 > (e.g., some nodes may sleep much of the time; ... > Should some nodes, such as power-rich or gateway nodes, act as > proxies (for some functions) for power constrained node? ... > - Should a link/subnet use both MAC addresses and network-addresses, or should only a single set of addresses be used for both purposes? Operating nodes running on small batteries in very low bandwidth environments is at the heart of this initiative. While awareness of sleeping nodes and the use of certain nodes as proxies is very much inside the scope of this group, I am a bit uncertain whether header and/or data compression is relevant on the routing layer. It might be specific to the individual L2 implementations? Concerning the proxy node topic, there are (at least) two situations to consider: A: Certain transmission mechanisms are asymmetrical, so that sending to a 99% sleeping requires a transmission activity from the sending part than from the node waking up a short while to detect traffic. This case may be considered a _POWER_PROXY_. Latency for the node response may not be higher than a few 100 milliseconds. B: Water sensing nodes and other nodes may wake up extremely rarely, say every 5 minutes. They send a measurement report to a local proxy, that confirms the receival. Then the node goes back to sleep for the next 5 minutes. The only way to change settings, e.g. the measument interval or the target proxy for such a node, is to provide a mailbox service, where instructions are queued up, waiting for the next time, the node makes contact. We could call this a _TIME_PROXY_. Anders Brandt _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jun 06 07:59:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuAV-00030t-KZ; Wed, 06 Jun 2007 07:59:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvuAU-00030n-MK for rsn@ietf.org; Wed, 06 Jun 2007 07:59:14 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvuAU-0005VA-D0 for rsn@ietf.org; Wed, 06 Jun 2007 07:59:14 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Jun 2007 07:59:14 -0400 X-IronPort-AV: i="4.16,389,1175486400"; d="scan'208"; a="62083483:sNHT51210982" 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 l56BxE86006026; Wed, 6 Jun 2007 07:59:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l56BxD5f019032; Wed, 6 Jun 2007 11:59:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 07:59:13 -0400 Received: from [10.86.104.179] ([10.86.104.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 07:59:12 -0400 In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E77B2D1@zensys17.zensys.local> References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com><46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> <4664D24E.2000803@saloits.com> <6D9687E95918C04A8B30A7D6DA805A3E77B2D1@zensys17.zensys.local> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] Update Date: Wed, 6 Jun 2007 07:58:53 -0400 To: Anders Brandt X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Jun 2007 11:59:12.0794 (UTC) FILETIME=[1932CFA0:01C7A832] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2435; t=1181131154; x=1181995154; 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]=20Update |Sender:=20 |To:=20Anders=20Brandt=20; bh=OAdHdgzpPdSpZLtI7gYmzRax/KU7Oi7oEufYYuoEbQg=; b=WN50UJxwJeK2t0rwSM5fnM2WGqfepUw/LPJh9TNQqAjnZrwadDx9flH4yfn5lE1g/unE33T1 2Q1DcXly1UcA2ZNQHOdaAuDSo/EZ5SMAatKcyZsPCDuIFPCBG/pw+KhC; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Jun 6, 2007, at 4:19 AM, Anders Brandt wrote: > -----Original Message----- > From: Timothy J. Salo [mailto:salo@saloits.com] > Sent: 5. juni 2007 05:03 > >> (e.g., some nodes may sleep much of the time; > > ... > >> Should some nodes, such as power-rich or gateway nodes, act as >> proxies (for some functions) for power constrained node? > > ... > >> - Should a link/subnet use both MAC addresses and network-addresses, > or should only a single set of addresses be used for both > purposes? > > Operating nodes running on small batteries in very low bandwidth > environments > is at the heart of this initiative. > > While awareness of sleeping nodes and the use of certain nodes as > proxies > is very much inside the scope of this group, Absolutely. > I am a bit uncertain > whether > header and/or data compression is relevant on the routing layer. > It might be specific to the individual L2 implementations? > Header compression is clearly handled by 6lowpan. As far as data compression/fusion/..., if the technique and potential protocol extensions are within the scope of 6lowpan, the knowledge of some node capabilities may be used to route the traffic and are consequently part of RL2N. Again, a simple line of demarcation. JP. > Concerning the proxy node topic, there are (at least) two > situations to > consider: > > A: Certain transmission mechanisms are asymmetrical, so that > sending to > a 99% sleeping > requires a transmission activity from the sending part than from the > node waking up a > short while to detect traffic. This case may be considered a > _POWER_PROXY_. > Latency for the node response may not be higher than a few 100 > milliseconds. > > B: Water sensing nodes and other nodes may wake up extremely > rarely, say > every 5 minutes. > They send a measurement report to a local proxy, that confirms the > receival. > Then the node goes back to sleep for the next 5 minutes. > The only way to change settings, e.g. the measument interval or the > target proxy > for such a node, is to provide a mailbox service, where > instructions are > queued up, > waiting for the next time, the node makes contact. > We could call this a _TIME_PROXY_. > > Anders Brandt > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jun 06 10:23:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwQ8-0004nM-0k; Wed, 06 Jun 2007 10:23:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwQ6-0004n7-Gs for rsn@ietf.org; Wed, 06 Jun 2007 10:23:30 -0400 Received: from gw-eur4.philips.com ([161.85.125.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvwQ5-0005tg-Qb for rsn@ietf.org; Wed, 06 Jun 2007 10:23:30 -0400 Received: from smtpscan-eur8.philips.com (smtpscan-eur8.mail.philips.com [130.144.57.173]) by gw-eur4.philips.com (Postfix) with ESMTP id A774649730; Wed, 6 Jun 2007 14:23:28 +0000 (UTC) Received: from smtpscan-eur8.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 2D6836D4; Wed, 6 Jun 2007 14:23:28 +0000 (GMT) Received: from smtprelay-eur2.philips.com (smtprelay-eur2.philips.com [130.144.57.171]) by smtpscan-eur8.philips.com (Postfix) with ESMTP id 129596CC; Wed, 6 Jun 2007 14:23:28 +0000 (GMT) Received: from ehvrmh02.diamond.philips.com (ehvrmh02-srv.diamond.philips.com [130.139.27.125]) by smtprelay-eur2.philips.com (Postfix) with ESMTP id 55586A9; Wed, 6 Jun 2007 14:23:27 +0000 (GMT) In-Reply-To: To: Anthony Schoofs Subject: Re: [RSN] Update MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.3 September 26, 2003 Message-ID: From: Anthony Schoofs Date: Wed, 6 Jun 2007 16:21:05 +0200 X-MIMETrack: Serialize by Router on ehvrmh02/H/SERVER/PHILIPS(Release 6.5.5HF1002 | November 23, 2006) at 06/06/2007 16:25:34, Serialize complete at 06/06/2007 16:25:34 X-Spam-Score: 0.1 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1105545604==" Errors-To: rsn-bounces@ietf.org This is a multipart message in MIME format. --===============1105545604== Content-Type: multipart/alternative; boundary="=_alternative 004EA41EC12572F2_=" This is a multipart message in MIME format. --=_alternative 004EA41EC12572F2_= Content-Type: text/plain; charset="US-ASCII" JP, I agree when you said in a previous email: > "the proposal is to design a IP routing solution > specifically for sensor networks, that would of course be independent > to the L1/L2 protocol in use (it may be desirable to take into account > link layer attributes when calculating a route but the routing process > would not be tied up with the link layer). In addition, our routing scheme should know when the PAN coordinator/Gateway location has changed to lower and balance the network energy consumption. Then new timezones can be assigned and data routed accordingly. I am looking forward to seeing this new WG formed, Best regards, Anthony. -- Anthony Schoofs Philips Research WY 7-038 High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands Email: anthony.schoofs@philips.com Anthony Schoofs 04-06-2007 12:06 To JP Vasseur cc rsn@ietf.org Subject Re: [RSN] Update Classification We did some work to schedule a coordinate switching on and off of sensor nodes in order to reduce at maximum the energy consumption of the network. We came up with a routing protocol that allows us to route data throughout the network according to the ON/OFF state of the nodes. We would like to provide input for an ID on routing schemes that have energy consumption as the first focus. Best regards, Anthony. -- Anthony Schoofs Philips Research High Tech Campus 37 , 5656 AE Eindhoven, The Netherlands Email: anthony.schoofs@philips.com JP Vasseur 03-06-2007 14:02 To rsn@ietf.org cc Subject [RSN] Update Classification Dear all, Here is an update on where we stand: good progress ! 1) We've been having quite a bit of off-line and on-line discussions and there is apparently a good level of interest in this work. There are currently 5 IDs in the works: * The generic routing requirements: draft-culler-rsn-routing-reqs * Two application-specific routing requirements: - Home Networking - Industrial * A problem statement * An ID on routing metrics Of course, if you're interested to work on these IDs or other items, feel free ! 2) New name Although we called this initiative RSN: Routing for Sensor Networks, it does apply more generally to constrained nodes (Low Power) operating in Lossy Networks. Objects in general would typically be part of those networks. So from now on, let's rename this work R2LN: "Routing issues for Low Power, Lossy Networks", and use that acronym in all IDs. 3) Next IETF We asked for a presentation slot for the next IETF. Depending on the feedback, the next step would then to request a BOF in Vancouver. Thanks. JP and David. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --=_alternative 004EA41EC12572F2_= Content-Type: text/html; charset="US-ASCII"
JP, I agree when you said in a previous email:

> "the proposal is to design a IP routing solution
> specifically for sensor networks, that would of course be independent
> to the L1/L2 protocol in use (it may be desirable to take into account
> link layer attributes when calculating a route but the routing process
> would not be tied up with the link layer).

In addition, our routing scheme should know when the PAN coordinator/Gateway location has changed to lower and balance the network energy consumption.
Then new timezones can be assigned and data routed accordingly.

I am looking forward to seeing this new WG formed,
Best regards,
Anthony.


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







Anthony Schoofs

04-06-2007 12:06

To
JP Vasseur <jvasseur@cisco.com>
cc
rsn@ietf.org
Subject
Re: [RSN] Update
Classification






We did some work to schedule a coordinate switching on and off of sensor nodes in order to reduce at maximum the energy consumption of the network.
We came up with a routing protocol that allows us to route data throughout  the network according to the ON/OFF state of the nodes.

We would like to provide input for an ID on routing schemes that have energy consumption as the first focus.

Best regards,
Anthony.

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





JP Vasseur <jvasseur@cisco.com>

03-06-2007 14:02


To
rsn@ietf.org
cc
Subject
[RSN] Update
Classification







Dear all,

Here is an update on where we stand: good progress !

1) We've been having quite a bit of off-line and on-line discussions  
and there is apparently a good level of interest in this work.
There are currently 5 IDs in the works:
* The generic routing requirements: draft-culler-rsn-routing-reqs
* Two application-specific routing requirements:
               - Home Networking
               - Industrial
* A problem statement
* An ID on routing metrics

Of course, if you're interested to work on these IDs or other items,  
feel free !

2) New name
Although we called this initiative RSN: Routing for Sensor Networks,  
it does apply more generally to constrained nodes (Low Power)
operating in Lossy Networks. Objects in general would typically be  
part of those networks. So from now on, let's rename this work
R2LN: "Routing issues for Low Power, Lossy Networks", and use that  
acronym in all IDs.

3) Next IETF
We asked for a presentation slot for the next IETF. Depending on the  
feedback, the next step would then to request a BOF in Vancouver.

Thanks.

JP and David.

_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________
RSN mailing list
RSN@ietf.org
https://www1.ietf.org/mailman/listinfo/rsn
--=_alternative 004EA41EC12572F2_=-- --===============1105545604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============1105545604==-- From rsn-bounces@ietf.org Thu Jun 07 16:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwP39-0003xa-SG; Thu, 07 Jun 2007 16:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwP38-0003wy-4h for rsn@ietf.org; Thu, 07 Jun 2007 16:57:42 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwP36-0007Dl-Qf for rsn@ietf.org; Thu, 07 Jun 2007 16:57:42 -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 l57KvQmF001156; Thu, 7 Jun 2007 14:57:26 -0600 (MDT) From: Geoff Mulligan To: JP Vasseur In-Reply-To: References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> <4664D24E.2000803@saloits.com> <6D9687E95918C04A8B30A7D6DA805A3E77B2D1@zensys17.zensys.local> Content-Type: text/plain Date: Thu, 07 Jun 2007 14:57:41 -0600 Message-Id: <1181249862.5731.132.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: rsn@ietf.org Subject: [RSN] The need for RSN X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org I would like to reiterate that I think that the work RSN group has suggested taking on is very important to my working group - 6lowpan. Our working group is looking to recharter and the scope of the work will be focused on issues related to interoperability for 6lowpan networks. This include things like MIC identifiers, alternative mesh headers, security, ... What is not in the scope is routing. I think the RSN concept is important in that the devices we are anticipating have significant constraints (power, memory, processing) and as such the current set of protocols and development is probably not appropriate for these types of devices. geoff _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jun 11 00:17:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxbL8-0004Jm-Fh; Mon, 11 Jun 2007 00:17:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxbL7-0004Jc-7O for rsn@ietf.org; Mon, 11 Jun 2007 00:17:13 -0400 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxbL5-0000Rw-Tv for rsn@ietf.org; Mon, 11 Jun 2007 00:17:13 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1072138nzd for ; Sun, 10 Jun 2007 21:17:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pp9vk+KZ+t+DE9SXUYWuOPlFH/I/wHTNlQqJZjmsyev/lyVLlS1JdHQdcNwEClNnktd/94diuqFq593689+0dQojPq3v5/vtK+nYoB338Wfu0LmtzMgPiINVqJswt5WYSkZ3EGqlQiKCvO+fPrciecOfpQBbTj+FtV5Fr2/qp68= 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=Q6omx+Eyhq9TIaRL7CpHImywyK7cukkB7Ecq4+6czIDaJUOQpu/S34YVM+5gFutsgH+CB9H6fKXnhsvEd4WKL4q2ETMw24qUTxWDH3W3H43vjPDN8iZV/M6riAMxtDbfSU3IZlXQOvVTRET9f1Q7bt9S+PYUqxf8hNpu8TGEJhw= Received: by 10.114.184.16 with SMTP id h16mr935652waf.1181535431272; Sun, 10 Jun 2007 21:17:11 -0700 (PDT) Received: by 10.141.162.11 with HTTP; Sun, 10 Jun 2007 21:17:11 -0700 (PDT) Message-ID: <2a3692de0706102117m19d9cca3s4aa3e7535ef8d8a1@mail.gmail.com> Date: Mon, 11 Jun 2007 13:17:11 +0900 From: "Dominik Kaspar" To: "Geoff Mulligan" Subject: Re: [RSN] The need for RSN In-Reply-To: <1181249862.5731.132.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <023E7560-E91C-4805-9EA0-90F8EA3874EA@cisco.com> <46632986.3000401@saloits.com> <46632FB9.6080705@cisco.com> <4664D24E.2000803@saloits.com> <6D9687E95918C04A8B30A7D6DA805A3E77B2D1@zensys17.zensys.local> <1181249862.5731.132.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Geoff, As far as I know, there has not been any consensus yet to what is in the scope of 6lowpan and what is not. But concering the RSN/R2LN efforts, it would be favorable to find consensus as soon as possible, so that it's clear where to dedicate new work to. Dominik On 6/8/07, Geoff Mulligan wrote: > I would like to reiterate that I think that the work RSN group has > suggested taking on is very important to my working group - 6lowpan. > > Our working group is looking to recharter and the scope of the work will > be focused on issues related to interoperability for 6lowpan networks. > This include things like MIC identifiers, alternative mesh headers, > security, ... > > What is not in the scope is routing. I think the RSN concept is > important in that the devices we are anticipating have significant > constraints (power, memory, processing) and as such the current set of > protocols and development is probably not appropriate for these types of > devices. > > geoff > > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 14 22:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz1Db-0005n7-8k; Thu, 14 Jun 2007 22:07:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz1Da-0005mn-9W for rsn@ietf.org; Thu, 14 Jun 2007 22:07:18 -0400 Received: from seowon.ajou.ac.kr ([202.30.0.18] helo=mail.ajou.ac.kr) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hz1DX-0002rn-Hh for rsn@ietf.org; Thu, 14 Jun 2007 22:07:18 -0400 Received: from ajou.ac.kr (127.0.0.1) by mail.ajou.ac.kr with ESMTP imoxion SensMail SmtpServer 5.0 id <4671f4c33feee6b840abb2f4> for from ; Fri, 15 Jun 2007 11:07:15 +0900 Message-ID: <4671f6583fe0@imoxion.com> Date: Fri, 15 Jun 2007 11:07:15 +0900 (KST) From: Zeeshan Hameed Mir To: rsn@ietf.org, tccc@cs.columbia.edu, 6lowpan@lists.ietf.org MIME-Version: 1.0 X-Priority: 3 X-Spam-Score: 1.3 (+) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b Cc: Subject: [RSN] USN 2007 Extended Deadline to June 15 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0988595418==" Errors-To: rsn-bounces@ietf.org --===============0988595418== Content-Type: multipart/alternative; boundary="----=_Part_364596_5750024.1181873235261" ------=_Part_364596_5750024.1181873235261 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 IA0KW1BsZWFzZSBhY2NlcHQgb3VyIGFwb2xvZ2llcyBpZiB5b3UgcmVjZWl2ZSBtdWx0aXBsZSBj b3BpZXMgb2YgdGhpcyBDRlBdIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KQ0FMTCBGT1IgUEFQRVJTIGZvciBVU04gMjAwNyANCg0KVGhl IDNyZCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9wIG9uIFJGSUQgYW5kIFViaXF1aXRvdXMgU2Vuc29y IE5ldHdvcmtzIChVU04pIA0KDQpodHRwOi8vdW5zLmFqb3UuYWMua3IvfnVzbjIwMDcvLCBEZWNl bWJlciAxNy0yMCwgMjAwNywgVGFpcGVpLCBUYWl3YW4pIA0KDQpUbyBiZSBoZWxkIGluIGNvbmp1 bmN0aW9uIHdpdGggRVVDIDIwMDcgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KDQoNCkltcG9ydGFudCBEYXRlczogDQoNCiogU3VibWlzc2lv biBEdWU6IEp1bmUgMTUsIDIwMDcgKGV4dGVuZGVkIGRlYWRsaW5lKSANCg0KKiBBY2NlcHRhbmNl IG5vdGlmaWNhdGlvbjogQXVndXN0IDYsIDIwMDcgDQoNCiogQ2FtZXJhLXJlYWR5IGR1ZTogU2Vw dGVtYmVyIDQsIDIwMDcgDQoNCiAgDQpBYm91dCB0aGUgd29ya3Nob3A6IA0KDQpUaGUgcHVycG9z ZSBvZiBVU04gMjAwNyBpcyB0byBlc3RhYmxpc2ggYSBkaXNjdXNzaW9uIGZyYW1ld29yayBvbiBh bGwgdGhlIGNoYWxsZW5nZXMgcmFpc2VkIGZyb20gdGhlIGV2b2x1dGlvbiBvZiB0aGUgVWJpcXVp dG91cyBTZW5zb3IgTmV0d29ya3MgYW5kIFJGSUQgdGVjaG5vbG9naWVzLiBBcyBhIHVuaXF1ZSBv cHBvcnR1bml0eSB0byBvYnRhaW4gYW4gaW5zaWdodCBvbiB0aGUgbGVhZGluZyB0ZWNobm9sb2dp ZXMgb2YgdGhlIG5leHQgcGVydmFzaXZlIGVyYSwgVVNOIDIwMDcgd2FudHMgdG8gaW52aXRlIHJl c2VhcmNoZXJzIHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgdGhlaXIgaWRlYXMuIA0KICANCg0KVG9w aWNzIG9mIHRoaXMgd29ya3Nob3AgaW5jbHVkZSwgYnV0IGFyZSBub3QgbGltaXRlZCB0bzogDQoN CqGkICAgICAgICAgUkZJRCBTeXN0ZW1zIGFuZCBBcmNoaXRlY3R1cmUgDQoNCqGkICAgICAgICAg UkZJRCBNaWRkbGV3YXJlIERlc2lnbiANCg0KoaQgICAgICAgICBBbnRpLWNvbGxpc2lvbiBhbGdv cml0aG1zIA0KDQqhpCAgICAgICAgIE1vYmlsZSBSRklEIFN5c3RlbXMgYW5kIEFwcGxpY2F0aW9u cyANCg0KoaQgICAgICAgICBEYXRhIE1vZGVsaW5nIGFuZCBNYW5hZ2VtZW50IA0KDQqhpCAgICAg ICAgIEVtYmVkZGVkIFJGSUQtZW5hYmxlZCBEZXZpY2UgVGVjaG5vbG9neSANCg0KoaQgICAgICAg ICBTZW5zb3IgTmV0d29yayBBcmNoaXRlY3R1cmVzIGFuZCBQcm90b2NvbHMgDQoNCqGkICAgICAg ICAgTmV0d29yayBwcm90b2NvbHMsIGUuZy4sIE1BQyBhbmQgcm91dGluZyANCg0KoaQgICAgICAg ICBEaXN0cmlidXRlZCBBbGdvcml0aG1zLCBlLmcuLCBMb2NhbGl6YXRpb24gYW5kIFN5bmNocm9u aXphdGlvbiANCg0KoaQgICAgICAgICBDcm9zcyBMYXllciBhbmQgRW5lcmd5IEVmZmljaWVudCBE ZXNpZ24gDQoNCqGkICAgICAgICAgVVNOIE1pZGRsZXdhcmUgSXNzdWVzLCBlLmcuLCBPUyBhbmQg RGF0YWJhc2UgDQoNCqGkICAgICAgICAgQ29leGlzdGVuY2Ugb2YgUkZJRCAmIFVTTiANCg0KoaQg ICAgICAgICBRb1MgYW5kIFJlYWwtVGltZSBJc3N1ZXMgDQoNCqGkICAgICAgICAgU2VjdXJpdHkg YW5kIHByaXZhY3kgaXNzdWVzIA0KDQqhpCAgICAgICAgIE5ldHdvcmsgTWFuYWdlbWVudCBpbiBM YXJnZS1zY2FsZSBEZXBsb3ltZW50IA0KDQqhpCAgICAgICAgIENvZXhpc3RlbmNlIG9mIFJGSUQg JiBVU04gDQoNCqGkICAgICAgICAgTm92ZWwgUkZJRCBhbmQgVVNOIEFwcGxpY2F0aW9ucyANCiAg DQoNCldvcmtzaG9wIENoYWlycyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KDQpZb3VuZy1CYWUg S28sIEFqb3UgVW5pdmVyc2l0eSwgS29yZWEgDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRz b24gUmVzZWFyY2gsIFVTQSANCg0KICANCg0KU3RlZXJpbmcgQ29tbWl0dGVlIA0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSANCg0KSm9uZ3N1ayBDaGFlLCBFVFJJLCBLb3JlYSANCg0KU2V1bmctV2hh IFlvbywgQWpvdSBVbml2ZXJzaXR5LCBLb3JlYSANCg0KWXUtQ2hlZSBUc2VuZywgTmF0aW9uYWwg Q2hpYW8gVHVuZyBVbml2LiwgVGFpd2FuIA0KDQpEYWV5b3VuZyBLaW0sIEluZm9ybWF0aW9uIGFu ZCBDb21tdW5pY2F0aW9ucyBVbml2ZXJzaXR5LCBLb3JlYSANCg0KICANCg0KUHJvZ3JhbSBDb21t aXR0ZWUgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNCkJ5dW5naHVuIFNvbmcsIEtFVEks IEtvcmVhIA0KDQpDaGFuc3UgWXUsIENsZXZlbGFuZCBTdGF0ZSBVbml2ZXJzaXR5LCBVU0EgDQoN CkNoaWgtWXVuZyBDaGFuZywgVGFta2FuZyBVbml2ZXJzaXR5LCBUYWl3YW4gDQoNCkRvbmctS3l1 biBLaW0sIEt5dW5ncG9vayBOYXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KSmFlLUh5dW4g S2ltLCBBam91IFVuaXZlcnNpdHksIEtvcmVhIA0KDQpKYXZpZXIgR29tZXosIE5hdGlvbmFsIFVu aXZlcnNpdHkgb2YgTWV4aWNvLCBNZXhpY28gDQoNCkthbmctV29uIExlZSwgSUJNIFQuSiBXYXRz b24gUmVzZWFyY2gsIFVTQSANCg0KS3VpIFd1LCBVbml2ZXJzaXR5IG9mIFZpY3RvcmlhLCBDYW5h ZGEgDQoNCkxpbmctSnloIENoZW4sIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGlvbiBTY2llbmNlLCBU YWl3YW4gDQoNCk1pbmVvIFRha2FpLCBVQ0xBLCBVU0EgDQoNCk1pbmctSmVyIFRzYWksIE5hdGlv bmFsIFRzaW5nLUh1YSBVbml2LiwgVGFpd2FuIA0KDQpNaXNjaGEgRG9obGVyLCBGcmFuY2UgVGVs ZWNvbSwgRnJhbmNlIA0KDQpNb2hhbWVkIFlvdW5pcywgVW5pdmVyc2l0eSBvZiBNYXJ5bGFuZCwg VVNBIA0KDQpPemd1ciBFcmNldGluLCBTYWJhbmNpIFVuaXZlcnNpdHksIFR1cmtleSANCg0KU2Fh ZCBCaWF6LCBBdWJ1cm4gVW5pdmVyc2l0eSwgVVNBIA0KDQpUYWVreXVuZyBLd29uLCBTZW91bCBO YXRpb25hbCBVbml2ZXJzaXR5LCBLb3JlYSANCg0KVGFlLUppbiBMZWUsIFN1bmdreXVua3dhbiBV bml2ZXJzaXR5LCBLb3JlYSANCg0KWXVoLVNoeWFuIENoZW4sIE5hdGlvbmFsIENodW5nIENoZW5n IFVuaXZlcnNpdHksIFRhaXdhbiANCg0KV2VpIExvdSwgSG9uZyBLb25nIFBvbHl0ZWNobmljIFVu aXZlcnNpdHksIENoaW5hIA0KDQpXZW4tQ2hpaCBQZW5nLCBOYXRpb25hbCBDaGlhbyBUdW5nIFVu aXYuLCBUYWl3YW4gDQoNCldvbmp1biBMZWUsIEtvcmVhIFVuaXZlcnNpdHksIEtvcmVhIA0KDQot LS0tLQ0KDQpaZWVzaGFuIEhhbWVlZCBNaXIsDQpBam91IFVuaXZlcnNpdHksIFNvdXRoIEtvcmVh DQoNCg== ------=_Part_364596_5750024.1181873235261 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9J3RleHQvY3NzJz4gUCB7cGFkZGluZzowcHg7IG1hcmdp bjoycHg7IGJvcmRlcjowcHg7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6J2FyaWFsJzt9ICBi b2R5IHtwYWRkaW5nOjVweDsgbWFyZ2luOjBweDsgYm9yZGVyOjBweDtmb250LXNpemU6MTNweDtm b250LWZhbWlseTonYXJpYWwnO30gPC9zdHlsZT48L2hlYWQ+PGJvZHk+PHRhYmxlIHdpZHRoPTk5 JSBhbGlnbj1jZW50ZXIgaGVpZ2h0PScxMDAnPjx0ciB2YWxpZ249dG9wPjx0ZD48Zm9udCBzaXpl PTI+PEZPTlQgc2l6ZT0yPiZuYnNwOzwvRk9OVD4NCjxQPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPltQbGVhc2UgYWNjZXB0 IG91ciBhcG9sb2dpZXMgaWYgeW91IHJlY2VpdmUgbXVsdGlwbGUgY29waWVzIG9mIHRoaXMgQ0ZQ XTwvU1BBTj48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMt c2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48L1NQ QU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5DQUxMIEZPUiBQQVBFUlMg Zm9yIFVTTiAyMDA3PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BB Tj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPlRoZSAzcmQgSW50ZXJuYXRp b25hbCBXb3Jrc2hvcCBvbiBSRklEIGFuZCBVYmlxdWl0b3VzIFNlbnNvciBOZXR3b3JrcyAoVVNO KSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFj ZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5odHRwOi8vdW5zLmFqb3UuYWMua3IvfnVzbjIw MDcvLCBEZWNlbWJlciAxNy0yMCwgMjAwNywgVGFpcGVpLCBUYWl3YW4pPC9TUEFOPjwvRk9OVD48 U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPlRvIGJlIGhlbGQgaW4gY29uanVuY3Rpb24gd2l0aCBFVUMgMjAwNzwvU1BB Tj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2Vy aWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1G QU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PEJS PjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkltcG9ydGFudCBE YXRlczo8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05U IGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpF OiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+KiBTdWJtaXNzaW9uIER1ZTogSnVuZSAx NSwgMjAwNyAoZXh0ZW5kZWQgZGVhZGxpbmUpPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVT PiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9 RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPiog QWNjZXB0YW5jZSBub3RpZmljYXRpb246IEF1Z3VzdCA2LCAyMDA3IDwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPiogQ2FtZXJhLXJlYWR5IGR1ZTogU2VwdGVtYmVyIDQsIDIwMDcgPC9TUEFOPjwv Rk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+QWJvdXQgdGhl IHdvcmtzaG9wOjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5UaGUgcHVycG9zZSBvZiBVU04g MjAwNyBpcyB0byBlc3RhYmxpc2ggYSBkaXNjdXNzaW9uIGZyYW1ld29yayBvbiBhbGwgdGhlIGNo YWxsZW5nZXMgcmFpc2VkIGZyb20gdGhlIGV2b2x1dGlvbiBvZiB0aGUgVWJpcXVpdG91cyBTZW5z b3IgTmV0d29ya3MgYW5kIFJGSUQgdGVjaG5vbG9naWVzLiBBcyBhIHVuaXF1ZSBvcHBvcnR1bml0 eSB0byBvYnRhaW4gYW4gaW5zaWdodCBvbiB0aGUgbGVhZGluZyB0ZWNobm9sb2dpZXMgb2YgdGhl IG5leHQgcGVydmFzaXZlIGVyYSwgVVNOIDIwMDcgd2FudHMgdG8gaW52aXRlIHJlc2VhcmNoZXJz IHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgdGhlaXIgaWRlYXMuIDwvU1BBTj48L0ZPTlQ+PFNQQU4g bGFuZz1FTi1VUz48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJp ZiI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48 Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQt U0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPlRvcGljcyBvZiB0aGlzIHdvcmtz aG9wIGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86IDwvU1BBTj48L0ZPTlQ+PFNQQU4g bGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMt c2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSRklEIFN5c3RlbXMgYW5kIEFy Y2hpdGVjdHVyZSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgUkZJRCBNaWRkbGV3YXJlIERlc2lnbiA8L1NQQU4+PC9GT05UPjxTUEFOIGxh bmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNl cmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQW50aS1jb2xsaXNpb24gYWxnb3Jp dGhtcyA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQg ZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6 IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgTW9iaWxlIFJGSUQgU3lzdGVtcyBhbmQgQXBwbGljYXRpb25zIDwvU1BBTj48L0ZPTlQ+ PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRhIE1vZGVsaW5n IGFuZCBNYW5hZ2VtZW50IDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBFbWJlZGRlZCBSRklELWVuYWJsZWQgRGV2aWNlIFRlY2hub2xvZ3kg PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFNlbnNvciBOZXR3b3JrIEFyY2hpdGVjdHVyZXMgYW5kIFByb3RvY29scyA8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTmV0d29yayBwcm90 b2NvbHMsIGUuZy4sIE1BQyBhbmQgcm91dGluZyA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4t VVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6h pCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGlzdHJpYnV0ZWQgQWxnb3JpdGhtcywgZS5n LiwgTG9jYWxpemF0aW9uIGFuZCBTeW5jaHJvbml6YXRpb24gPC9TUEFOPjwvRk9OVD48U1BBTiBs YW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQ QU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1z ZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENyb3NzIExheWVyIGFuZCBFbmVy Z3kgRWZmaWNpZW50IERlc2lnbiA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj6hpCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVVNOIE1pZGRsZXdhcmUgSXNzdWVzLCBlLmcuLCBPUyBhbmQg RGF0YWJhc2UgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IENvZXhpc3RlbmNlIG9mIFJGSUQgJmFtcDsgVVNOIDwvU1BBTj48L0ZPTlQ+PFNQ QU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0y PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNh bnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBRb1MgYW5kIFJlYWwtVGlt ZSBJc3N1ZXMgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPjxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFNlY3VyaXR5IGFuZCBwcml2YWN5IGlzc3VlcyA8L1NQQU4+PC9GT05UPjxTUEFO IGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48 U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5z LXNlcmlmIj6hpCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTmV0d29yayBNYW5hZ2VtZW50 IGluIExhcmdlLXNjYWxlIERlcGxveW1lbnQgPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVT PjxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1F Ti1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+oaQg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENvZXhpc3RlbmNlIG9mIFJGSUQgJmFtcDsgVVNO IDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz48QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNl PXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPqGkICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBOb3ZlbCBSRklEIGFuZCBVU04gQXBwbGljYXRpb25zIDwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFu Zz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+ Jm5ic3A7PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPldvcmtzaG9wIENoYWlyczwvU1BBTj48 L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYg c2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1J TFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tPC9TUEFOPjwvRk9OVD48U1BBTiBs YW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxT UEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMt c2VyaWYiPllvdW5nLUJhZSBLbywgQWpvdSBVbml2ZXJzaXR5LCBLb3JlYSA8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBzYW5zLXNlcmlmIj5LYW5nLVdvbiBMZWUsIElCTSBULkogV2F0c29uIFJlc2VhcmNoLCBVU0E8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Jm5ic3A7PC9TUEFOPjwvRk9OVD48U1BBTiBsYW5n PUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2Vy aWYiPlN0ZWVyaW5nIENvbW1pdHRlZSA8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+PEJS PjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPi0tLS0tLS0tLS0t LS0tLS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFO PjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9O VC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Sm9uZ3N1ayBDaGFlLCBFVFJJ LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5TZXVuZy1XaGEgWW9vLCBBam91IFVu aXZlcnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwv U1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPll1LUNoZWUgVHNlbmcs IE5hdGlvbmFsIENoaWFvIFR1bmcgVW5pdi4sIFRhaXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFu Zz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BB TiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNl cmlmIj5EYWV5b3VuZyBLaW0sIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBVbml2ZXJz aXR5LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+ PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05U LVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4mbmJzcDs8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+UHJvZ3JhbSBDb21taXR0ZWU8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9 RU4tVVM+IDxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5n PUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxC Uj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1V UyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Qnl1bmdo dW4gU29uZywgS0VUSSwgS29yZWE8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+Q2hhbnN1IFl1 LCBDbGV2ZWxhbmQgU3RhdGUgVW5pdmVyc2l0eSwgVVNBPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5n PUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFO IGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2Vy aWYiPkNoaWgtWXVuZyBDaGFuZywgVGFta2FuZyBVbml2ZXJzaXR5LCBUYWl3YW48L1NQQU4+PC9G T05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJp ZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZB TUlMWTogc2Fucy1zZXJpZiI+RG9uZy1LeXVuIEtpbSwgS3l1bmdwb29rIE5hdGlvbmFsIFVuaXZl cnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BB Tj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkphZS1IeXVuIEtpbSwgQWpv dSBVbml2ZXJzaXR5LCBLb3JlYTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxC Uj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5KYXZpZXIgR29t ZXosIE5hdGlvbmFsIFVuaXZlcnNpdHkgb2YgTWV4aWNvLCBNZXhpY288L1NQQU4+PC9GT05UPjxT UEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXpl PTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTog c2Fucy1zZXJpZiI+S2FuZy1Xb24gTGVlLCBJQk0gVC5KIFdhdHNvbiBSZXNlYXJjaCwgVVNBPC9T UEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNh bnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsg Rk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkt1aSBXdSwgVW5pdmVyc2l0eSBvZiBWaWN0b3JpYSwg Q2FuYWRhPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPkxpbmctSnloIENoZW4sIEluc3RpdHV0 ZSBvZiBJbmZvcm1hdGlvbiBTY2llbmNlLCBUYWl3YW48L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9 RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4g bGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJp ZiI+TWluZW8gVGFrYWksIFVDTEEsIFVTQTwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4g PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5NaW5n LUplciBUc2FpLCBOYXRpb25hbCBUc2luZy1IdWEgVW5pdi4sIFRhaXdhbjwvU1BBTj48L0ZPTlQ+ PFNQQU4gbGFuZz1FTi1VUz4gPEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNp emU9Mj48U1BBTiBsYW5nPUVOLVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZ OiBzYW5zLXNlcmlmIj5NaXNjaGEgRG9obGVyLCBGcmFuY2UgVGVsZWNvbSwgRnJhbmNlPC9TUEFO PjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMt c2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IHNhbnMtc2VyaWYiPk1vaGFtZWQgWW91bmlzLCBVbml2ZXJzaXR5IG9mIE1hcnls YW5kLCBVU0E8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxG T05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+T3pndXIgRXJjZXRpbiwgU2FiYW5j aSBVbml2ZXJzaXR5LCBUdXJrZXk8L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48 QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+U2FhZCBCaWF6 LCBBdWJ1cm4gVW5pdmVyc2l0eSwgVVNBPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8 QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4t VVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPlRhZWt5 dW5nIEt3b24sIFNlb3VsIE5hdGlvbmFsIFVuaXZlcnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48 U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9OVCBmYWNlPXNhbnMtc2VyaWYgc2l6 ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6 IHNhbnMtc2VyaWYiPlRhZS1KaW4gTGVlLCBTdW5na3l1bmt3YW4gVW5pdmVyc2l0eSwgS29yZWE8 L1NQQU4+PC9GT05UPjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9 c2Fucy1zZXJpZiBzaXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0 OyBGT05ULUZBTUlMWTogc2Fucy1zZXJpZiI+WXVoLVNoeWFuIENoZW4sIE5hdGlvbmFsIENodW5n IENoZW5nIFVuaXZlcnNpdHksIFRhaXdhbjwvU1BBTj48L0ZPTlQ+PFNQQU4gbGFuZz1FTi1VUz4g PEJSPjxCUj48L1NQQU4+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9Mj48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBzYW5zLXNlcmlmIj5XZWkg TG91LCBIb25nIEtvbmcgUG9seXRlY2huaWMgVW5pdmVyc2l0eSwgQ2hpbmE8L1NQQU4+PC9GT05U PjxTUEFOIGxhbmc9RU4tVVM+IDxCUj48QlI+PC9TUEFOPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBz aXplPTI+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlM WTogc2Fucy1zZXJpZiI+V2VuLUNoaWggUGVuZywgTmF0aW9uYWwgQ2hpYW8gVHVuZyBVbml2Liwg VGFpd2FuPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PEJSPjwvU1BBTj48Rk9O VCBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0yPjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtU0la RTogMTBwdDsgRk9OVC1GQU1JTFk6IHNhbnMtc2VyaWYiPldvbmp1biBMZWUsIEtvcmVhIFVuaXZl cnNpdHksIEtvcmVhPC9TUEFOPjwvRk9OVD48U1BBTiBsYW5nPUVOLVVTPiA8QlI+PC9TUEFOPjwv UD4NCjxQPjxTUEFOIGxhbmc9RU4tVVM+LS0tLS08L1NQQU4+PC9QPg0KPFA+PFNQQU4gbGFuZz1F Ti1VUz48L1NQQU4+Jm5ic3A7PC9QPg0KPFA+PFNQQU4gbGFuZz1FTi1VUz5aZWVzaGFuIEhhbWVl ZCBNaXIsPC9TUEFOPjwvUD4NCjxQPjxTUEFOIGxhbmc9RU4tVVM+QWpvdSBVbml2ZXJzaXR5LCBT b3V0aCBLb3JlYTwvUD48L1NQQU4+PC9mb250PjwvdGQ+PC90cj48L3RhYmxlPjxicj4NCjxpbWcg aWQ9J21haWxleHAnIHdpZHRoPTAgaGVpZ2g9MCBib3JkZXI9MCBzcmM9J2h0dHA6Ly9tYWlsLmFq b3UuYWMua3I6ODAvbWFpbF9yZWNlaXB0X2NoZWNrLmpzcD91a2V5PTQ2NzFmNjU3M2ZiNDQxODEz NDY2NDY4OCZ1c2VyaWQ9emhtaXImYWhvc3Q9YWpvdV9hY19rcic+PC9ib2R5PjwvaHRtbD4= ------=_Part_364596_5750024.1181873235261-- --===============0988595418== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0988595418==-- From rsn-bounces@ietf.org Fri Jun 15 02:59:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5mJ-0005rq-PC; Fri, 15 Jun 2007 02:59:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5mI-0005rd-3n for rsn@ietf.org; Fri, 15 Jun 2007 02:59:26 -0400 Received: from web81902.mail.mud.yahoo.com ([68.142.207.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hz5mH-0000jH-6a for rsn@ietf.org; Fri, 15 Jun 2007 02:59:26 -0400 Received: (qmail 82648 invoked by uid 60001); 15 Jun 2007 06:59:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=mb9MJGbL2uO+UAGjASBAVuceesZjUsuWj7QHiC2HRjESPK1ojQ4QY3yUJi3e95WgPRMstl6HfEcA/aUKsGjM5dz6S4zg7UTacMKrw0KZIG5jtq3MSwVZvQ/7SnaCr/bqbEdSdnV38p2PgAL7m6ceM7mhyDIyP6sa17er9qOd6R4=; X-YMail-OSG: Bp0B3gMVM1lt8nmS9q_VmDV1qffI4bNvW4jgZPOLP3axqgpKMzbZ4tG1Y2HyOpj47Z.vQWn2p_Up6i9nULbkbaaf9BHhLKISeu4CCnU2Z4SI4uc- Received: from [24.16.90.95] by web81902.mail.mud.yahoo.com via HTTP; Thu, 14 Jun 2007 23:59:24 PDT X-Mailer: YahooMailRC/478 YahooMailWebService/0.7.41.14 Date: Thu, 14 Jun 2007 23:59:24 -0700 (PDT) From: g_e_montenegro@yahoo.com Subject: Re: [RSN] The need for RSN To: Dominik Kaspar , Geoff Mulligan MIME-Version: 1.0 Message-ID: <675024.81537.qm@web81902.mail.mud.yahoo.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0054509357==" Errors-To: rsn-bounces@ietf.org --===============0054509357== Content-Type: multipart/alternative; boundary="0-1123154084-1181890764=:81537" --0-1123154084-1181890764=:81537 Content-Type: text/plain; charset=ascii Well, the list of items has been pretty stable since IETF66 (if that's not consensus at the IETF, I don't know what is). And mesh routing is included, of course. This is acknowledged in the minutes on the rechartering discussion in IETF68: http://tools.ietf.org/wg/6lowpan/minutes?item=minutes68.html http://www3.ietf.org/proceedings/07mar/slides/6lowpan-0.pdf The slide (see the pdf above) is pretty clear about the scope of the "mesh routing" item: in 6lowpan we are not chartered to develop a new routing protocol (as in the algorithm, or the engine to generate routing tables). We have something that looks like consensus (just need the chairs to declare it so) on *adapting* routing protocols developed elsewhere. 6lowpan cannot develop protocols cuz it's not in the routing area. We've been primarily assuming we'd be adapting protocols from MANET, and there are individual submissions already on AODV, DyMO as well as non-IETF protocols (e.g., HILO). We've also been assured by MANET chairs (i.e., Ian) that they will heed our requirements and make sure their protocols also work for us. Of course, their protocols will never work "as is". We have to adapt them to work under IP, instead of over IP as assumed by MANET. As I understand it, RSN operates at layer 3, and it is arguing that there is room for another multi-hop routing WG in the routing area. Perhaps MANET can't really satisfy requirements for wireless sensors. Whether this is solved by integrating the RSN charter/deliverables into a re-chartered MANET, or by starting a new WG, from 6lowpan's point of view, 6lowpan can benefit from the resultant protocols. Of course, adaptation from layer 3 to sub-IP operation will be required, along the lines of the existing independent submissions in 6lowpan. My 2 motes (hopefully one day those will cost 1 cent each...) -gabriel ----- Original Message ---- From: Dominik Kaspar To: Geoff Mulligan Cc: rsn@ietf.org Sent: Sunday, June 10, 2007 9:17:11 PM Subject: Re: [RSN] The need for RSN Geoff, As far as I know, there has not been any consensus yet to what is in the scope of 6lowpan and what is not. But concering the RSN/R2LN efforts, it would be favorable to find consensus as soon as possible, so that it's clear where to dedicate new work to. Dominik On 6/8/07, Geoff Mulligan wrote: > I would like to reiterate that I think that the work RSN group has > suggested taking on is very important to my working group - 6lowpan. > > Our working group is looking to recharter and the scope of the work will > be focused on issues related to interoperability for 6lowpan networks. > This include things like MIC identifiers, alternative mesh headers, > security, ... > > What is not in the scope is routing. I think the RSN concept is > important in that the devices we are anticipating have significant > constraints (power, memory, processing) and as such the current set of > protocols and development is probably not appropriate for these types of > devices. > > geoff > > > > _______________________________________________ > 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 --0-1123154084-1181890764=:81537 Content-Type: text/html; charset=ascii
Well, the list of items has been pretty stable since IETF66 (if that's not consensus at the IETF, I don't know what is).
And mesh routing is included, of course. This is acknowledged in the minutes on the rechartering discussion in IETF68:

   http://tools.ietf.org/wg/6lowpan/minutes?item=minutes68.html
   http://www3.ietf.org/proceedings/07mar/slides/6lowpan-0.pdf

The slide (see the pdf above) is pretty clear about the scope of the "mesh routing" item: in 6lowpan we are not chartered
to develop a new routing protocol (as in the algorithm, or the engine to generate routing tables). We have something
that looks like consensus (just need the chairs to declare it so) on *adapting* routing protocols developed
elsewhere. 6lowpan cannot develop protocols cuz it's not in the routing area.

We've been primarily assuming we'd be adapting protocols from MANET, and there are individual
submissions already on AODV, DyMO as well as non-IETF protocols (e.g., HILO). We've also
been assured by MANET chairs (i.e., Ian) that they will heed our requirements and make sure
their protocols also work for us. Of course, their protocols will never work "as is". We have to
adapt them to work under IP, instead of over IP as assumed by MANET.

As I understand it, RSN operates at layer 3, and it is arguing that there is room for another multi-hop routing WG in the
routing area. Perhaps MANET can't really satisfy requirements for wireless sensors. Whether this is solved by
integrating the RSN charter/deliverables into a re-chartered MANET, or  by starting a new WG,
from 6lowpan's point of view, 6lowpan can benefit from the resultant protocols.
Of course, adaptation from layer 3 to sub-IP operation will be required, along the lines of the
existing independent submissions in 6lowpan.

My 2 motes (hopefully one day those will cost 1 cent each...)

-gabriel

----- Original Message ----
From: Dominik Kaspar <dokaspar.ietf@gmail.com>
To: Geoff Mulligan <geoff-ietf@mulligan.org>
Cc: rsn@ietf.org
Sent: Sunday, June 10, 2007 9:17:11 PM
Subject: Re: [RSN] The need for RSN

Geoff,

As far as I know, there has not been any consensus yet to what is in
the scope of 6lowpan and what is not. But concering the RSN/R2LN
efforts, it would be favorable to find consensus as soon as possible,
so that it's clear where to dedicate new work to.

Dominik

On 6/8/07, Geoff Mulligan <geoff-ietf@mulligan.org> wrote:
> I would like to reiterate that I think that the work RSN group has
> suggested taking on is very important to my working group - 6lowpan.
>
> Our working group is looking to recharter and the scope of the work will
> be focused on issues related to interoperability for 6lowpan networks.
> This include things like MIC identifiers, alternative mesh headers,
> security, ...
>
> What is not in the scope is routing.  I think the RSN concept is
> important in that the devices we are anticipating have significant
> constraints (power, memory, processing) and as such the current set of
> protocols and development is probably not appropriate for these types of
> devices.
>
>        geoff
>
>
>
> _______________________________________________
> 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

--0-1123154084-1181890764=:81537-- --===============0054509357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0054509357==-- From rsn-bounces@ietf.org Fri Jun 15 09:11:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBZr-0002c6-6m; Fri, 15 Jun 2007 09:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBZp-0002Wx-OD for rsn@ietf.org; Fri, 15 Jun 2007 09:10:57 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBZo-0007sf-C1 for rsn@ietf.org; Fri, 15 Jun 2007 09:10:57 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Jun 2007 15:10:54 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5FDArGI022151; Fri, 15 Jun 2007 15:10:53 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5FDASDR007118; Fri, 15 Jun 2007 13:10:32 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 15:10:28 +0200 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 Date: Fri, 15 Jun 2007 15:10:22 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC0416E9B4@xmb-ams-337.emea.cisco.com> In-Reply-To: <5vmlru$656cu@sj-inbound-f.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: L3 mesh requirements Thread-Index: Acd9QHg48W7LyQglRGiKW8JBcY5pBwAAJC6wABbT8AALHVRykAAgmicgASfdUVA= References: <006b01c7aa17$48592540$0202a8c0@Teco> <5vmlru$656cu@sj-inbound-f.cisco.com> From: "Pascal Thubert \(pthubert\)" To: "Ben McCarthy" , "Teco Boot" , "Ryuji Wakikawa" , "Bound, Jim" , "Jean Philippe Vasseur \(jvasseur\)" X-OriginalArrivalTime: 15 Jun 2007 13:10:28.0322 (UTC) FILETIME=[8B545C20:01C7AF4E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3307; t=1181913053; x=1182777053; 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:=20L3=20mesh=20requirements |Sender:=20; bh=H7Z0W0r3FspcnDrvfKcM91X8vAlAc8+sBS8Bjl4JsWU=; b=rUs4B5kpS6lWFBdGRRkCrOazP+27BTwqlM7BRFZVTOfDajusK9bN7J8QHBINvVhIEec340yz SfH3/ZvnuGry4hga9RjOzbbOHe/s0ytxUY/oPs/BXGFb9c8e6cts2ygH; 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: 02ec665d00de228c50c93ed6b5e4fc1a Cc: rsn@ietf.org, manemo@mobileip.jp Subject: [RSN] L3 mesh requirements X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi: There is a common need in MANEMO and RSN to define the specific needs for establishing a Layer 3 mesh network. In both MLs, we have pending work on listing these requirements, and then explaining how existing MANET techniques apply or not. >From there, we can derive what work is needed and how that could be split between existing and newly created WG(s). There have been many talks in both ML about these issues. I'm trying here to summarize what I read so far as mesh characteristics in the form of simple one-liners.=20 R1) A mesh network is a radio network connected to an infrastructure such as the Internet, and aimed at providing Routability between mesh nodes and that infrastructure, back and forth and at most times; still, the mesh should be able to operate for local communications when disconnected from the infrastructure. R2) Mesh nodes are not all equal. There are wired sinks which connect to the infrastructure, fully functional devices (FFD), and reduced functional devices (RFD). RFD are characterized by severely limited CPU, memory and battery capacity; they should not be involved in routing and forwarding but to the bare minimum. Because radio and battery are limited resources everywhere, the amount of control messages should be reduced to a minimum and optimized by compression, piggy backing etc... R3) The most common use case is to connect mesh nodes with middleware, applications servers and peer nodes located over the infrastructure, via mesh sinks. Routing should proactively maintain the path between the mesh nodes and the sinks, back and forth. It should be possible to avoid incremental cost linked to routing to other destinations. Also, the mesh protocol should be compatible with NEMO and enable mobile nodes to attach to their Home Agents over the mesh without the need of an additional MANET protocol. R4) Routing within the mesh also appears in a number of use cases. The routing requirements might vary depending on the application and might also depend on the way the mesh is built. For instance, it could possible to interconnect mesh nodes from the inside of a mesh over a MANET routing protocol, or via the infrastructure over the mesh protocol and NEMO. The mesh routing protocol should be interoperable with the standard MANET routing protocols in terms of external routes redistributions and so on, but should not depend on a specific instance of a MANET protocol being deployed. R5) A mesh network is self-forming and self-healing. This means that the mesh links are not preexisting like in the wired world and peer selection must occur to form those links before routing takes place over them. The list of selected peers must be reevaluated as the conditions change (movement, interferences, low battery, etc...).=20 R6) Peer selection and routing occur with the objective to reach a sink; this is based on Layer 3 information (peer type, reachability, path metrics to the sink...) as well as Layer 2 information (RSSI to peer, bandwidth, etc...). Because a scanning process might be involved at layer 2 to sustain the peer selection mechanism, it is desirable that the initial peer list be established in pure listening (monitor) mode. What did I miss? Fire at will... Pascal _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jun 15 12:14:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzER9-0001mz-KL; Fri, 15 Jun 2007 12:14:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzER8-0001mt-7n for rsn@ietf.org; Fri, 15 Jun 2007 12:14:10 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzER5-0004Dt-Mv for rsn@ietf.org; Fri, 15 Jun 2007 12:14:10 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5FGDklW007485; Fri, 15 Jun 2007 19:14:03 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 19:13:53 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:13:52 -0500 Received: from [10.243.7.87] ([10.243.7.87]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:13:51 -0500 Message-ID: <4672BABD.6000904@nokia.com> Date: Fri, 15 Jun 2007 09:13:49 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "ext Pascal Thubert (pthubert)" Subject: Re: [RSN] L3 mesh requirements References: <006b01c7aa17$48592540$0202a8c0@Teco> <5vmlru$656cu@sj-inbound-f.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0416E9B4@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC0416E9B4@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2007 16:13:51.0654 (UTC) FILETIME=[29D39460:01C7AF68] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: rsn@ietf.org, manemo@mobileip.jp X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hello Pascal, A few comments -- please excuse if I missed the relevant discussion since I am far behind on [rsn] and not even on the [manemo] mailing list at all. ext Pascal Thubert (pthubert) wrote: > R1) A mesh network is a radio network connected to an infrastructure > such as the Internet, and aimed at providing Routability between mesh > nodes and that infrastructure, back and forth and at most times; still, > the mesh should be able to operate for local communications when > disconnected from the infrastructure. > I don't think a mesh has to be connected to the Internet. Instead, as you mention, the mesh can work well as a self-contained network, and yet offer Internet connectivity whenever it is available. This may be viewed as intermittent or perhaps even seldom. So, I would not want to say that the mesh has to be "aimed at providing Routability between mesh nodes and that infrastructure". > R2) Mesh nodes are not all equal. There are wired sinks which connect to > the infrastructure, fully functional devices (FFD), and reduced > functional devices (RFD). RFD are characterized by severely limited CPU, > memory and battery capacity; they should not be involved in routing and > forwarding but to the bare minimum. This can be done if the metric is appropriate and the measurements are done properly. So, for instance, a node could indicate that it is unwilling to route, but able to do so in a pinch. > Because radio and battery are > limited resources everywhere, the amount of control messages should be > reduced to a minimum and optimized by compression, piggy backing etc... > Is [rsn] going to tackle compression? That would be a great area for development, and I don't think any other group even has it in their sights. Unfortunately, it seems to attract controversy over patent rights. > R3) The most common use case is to connect mesh nodes with middleware, > applications servers and peer nodes located over the infrastructure, via > mesh sinks. I am puzzling over the actual content of this sentence. It seems to apply to every network in the Internet, if we consider a host to be a "sensor". > Routing should proactively maintain the path between the > mesh nodes and the sinks, back and forth. Doesn't this remain to be seen? What about mesh nodes that are tired and want to sleep? > It should be possible to avoid > incremental cost linked to routing to other destinations. Also, the mesh > protocol should be compatible with NEMO and enable mobile nodes to > attach to their Home Agents over the mesh without the need of an > additional MANET protocol. > Check. Except, that we might want to fiddle with the Agent Advertisements. > R4) ... The mesh routing protocol should be interoperable with the > standard MANET routing protocols in terms of external routes > redistributions and so on, but should not depend on a specific instance > of a MANET protocol being deployed. > This is debatable. Especially, if it turns out that a "standard" MANET protocol (hmm... two should be here this year, we think) can be engineered into a good choice for mesh routing. > R6) Peer selection and routing occur with the objective to reach a sink; > this is based on Layer 3 information (peer type, reachability, path > metrics to the sink...) as well as Layer 2 information (RSSI to peer, > bandwidth, etc...). Because a scanning process might be involved at > layer 2 to sustain the peer selection mechanism, it is desirable that > the initial peer list be established in pure listening (monitor) mode. > What if two non-sensors, that are currently deployed in the field, want to use the sensor mesh to communicate with each other? Surely you would not like to burden the mesh with a whole new set of protocols just because a couple of people happened to want to make use of it while they are in the area... Or, did you want the sinks to be required intermediate nodes in every peer-to-peer communications? That could make connectivity even more expensive in a lot of cases. Regards, Charlie P. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jun 15 12:36:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzEly-000366-CW; Fri, 15 Jun 2007 12:35:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzElw-00032k-2F for rsn@ietf.org; Fri, 15 Jun 2007 12:35:40 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzElu-0008VD-K4 for rsn@ietf.org; Fri, 15 Jun 2007 12:35:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5FGZTIm024498; Fri, 15 Jun 2007 19:35:36 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 19:35:33 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:35:32 -0500 Received: from [10.243.7.87] ([10.243.7.87]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:35:31 -0500 Message-ID: <4672BFD1.5050509@nokia.com> Date: Fri, 15 Jun 2007 09:35:29 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Gabriel.Montenegro@microsoft.com Subject: Re: [RSN] The need for RSN References: <675024.81537.qm@web81902.mail.mud.yahoo.com> In-Reply-To: <675024.81537.qm@web81902.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2007 16:35:31.0795 (UTC) FILETIME=[30C55A30:01C7AF6B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hello Gabriel, ext rsn-bounces@ietf.org wrote: > We've been primarily assuming we'd be adapting protocols from MANET, > and there are individual > submissions already on AODV, DyMO as well as non-IETF protocols (e.g., > HILO). We've also > been assured by MANET chairs (i.e., Ian) that they will heed our > requirements and make sure > their protocols also work for us. Of course, their protocols will > never work "as is". We have to > adapt them to work under IP, instead of over IP as assumed by MANET. Of course, I have hoped that the "Of course" in your paragraph is not so self-evident. Is there really no hope? [PS. Your mail to the mailing list shows as bouncing?] > > As I understand it, RSN operates at layer 3, and it is arguing that > there is room for another multi-hop routing WG in the > routing area. Perhaps MANET can't really satisfy requirements for > wireless sensors. Whether this is solved by > integrating the RSN charter/deliverables into a re-chartered MANET, > or by starting a new WG, > from 6lowpan's point of view, 6lowpan can benefit from the resultant > protocols. I think it is more likely that [rsn] can be viewed as a spin-off from [manet], in much the same way that [mipshop] and others were spun off from the old [mobileip] group. In fact, I think the argument for [rsn] is much stronger than the argument for [mipshop] because [rsn] has a clear need for looking at: - compression, - power-saving techniques, - new extensions to DYMO or whatever, - new/better metrics, - clustering - multicast - perhaps also geographic routing techniques. > Of course, adaptation from layer 3 to sub-IP operation will be > required, along the lines of the > existing independent submissions in 6lowpan. There's that "Of course" again :-) Regards, Charlie P. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jun 19 04:39:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZEu-0003Ig-QR; Tue, 19 Jun 2007 04:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ZEt-0003IR-UH for rsn@ietf.org; Tue, 19 Jun 2007 04:39:03 -0400 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ZEt-0006xr-Ju for rsn@ietf.org; Tue, 19 Jun 2007 04:39:03 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1573354nzd for ; Tue, 19 Jun 2007 01:39:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=i7p4CknVPfiOuOa6chbT8PGvtyJqU6KplOb08lUOzwmWc8sF4d+uV9hbqnTlgV52trUov9kqIkEBP8XrlWpEUW3SyeU47jvaPMKGBBrdVVzAwr8s0jQRFRYh9bpLmGPLdmfwHPljQIAZP/kFb8oUGcwxFRQVrRG+NtikMPpWtJU= 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=VVq4FuNWWm88ehx+/M26/3MTOjTJmdrFO5mScMYgNaHwnQH4Be/kSY23IunZ3jUCZg0lgnpURxL8pXSlYgEb4WALEOzWodURDtwiwmHYTtu+hoVLOAD9GlA0+yi6xp4y/rJQ+NcEmcETMuI9/dpZUTx3GFETI0bMCqlx5qICTMc= Received: by 10.142.112.5 with SMTP id k5mr345245wfc.1182242342949; Tue, 19 Jun 2007 01:39:02 -0700 (PDT) Received: by 10.143.28.13 with HTTP; Tue, 19 Jun 2007 01:39:02 -0700 (PDT) Message-ID: <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> Date: Tue, 19 Jun 2007 17:39:02 +0900 From: "Eunsook \"Eunah\" Kim" To: "g_e_montenegro@yahoo.com" Subject: Re: [RSN] The need for RSN In-Reply-To: <675024.81537.qm@web81902.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <675024.81537.qm@web81902.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org My 2 cents are in line; > The slide (see the pdf above) is pretty clear about the scope of the "mesh > routing" item: in 6lowpan we are not chartered > to develop a new routing protocol (as in the algorithm, or the engine to > generate routing tables). We have something > that looks like consensus (just need the chairs to declare it so) on > *adapting* routing protocols developed > elsewhere. 6lowpan cannot develop protocols cuz it's not in the routing > area. > /snip/ In my understanding, we had some concerns to work routing solutions at 6lowpan, as you said it's not in the routing area. However, it doesn't mean that 6lowpan doesn't need to consider routing related issues for 6lowpan. IMHO, to make a solution and to handle routing related issues are different. If RSN successfully stages in the IETF, surely, RSN would be a good place to discuss routing issues for sensor networks. However, as you said below, for 6lowpan, sub-IP operations for multi-hop delivery should be considered, as RSN considers L3 routing. In my understanding, 6lowpan can be one of the applications for RSN. One way to consider 6lowpan routing issues is to put 6lowpan specific mesh-under routing requirements to RSN, as RSN is now gathering various requirements based on different applications. 6lowpan can discuss its own requirements with RSN, or input the requirements to RSN. -eunsook > As I understand it, RSN operates at layer 3, and it is arguing that there is > room for another multi-hop routing WG in the > routing area. Perhaps MANET can't really satisfy requirements for wireless > sensors. Whether this is solved by > integrating the RSN charter/deliverables into a re-chartered MANET, or by > starting a new WG, > from 6lowpan's point of view, 6lowpan can benefit from the resultant > protocols. > Of course, adaptation from layer 3 to sub-IP operation will be required, > along the lines of the > existing independent submissions in 6lowpan. > My 2 motes (hopefully one day those will cost 1 cent each...) > > -gabriel > > > ----- Original Message ---- > From: Dominik Kaspar > To: Geoff Mulligan > Cc: rsn@ietf.org > Sent: Sunday, June 10, 2007 9:17:11 PM > Subject: Re: [RSN] The need for RSN > > Geoff, > > As far as I know, there has not been any consensus yet to what is in > the scope of 6lowpan and what is not. But concering the RSN/R2LN > efforts, it would be favorable to find consensus as soon as possible, > so that it's clear where to dedicate new work to. > > Dominik > > On 6/8/07, Geoff Mulligan wrote: > > I would like to reiterate that I think that the work RSN group has > > suggested taking on is very important to my working group - 6lowpan. > > > > Our working group is looking to recharter and the scope of the work will > > be focused on issues related to interoperability for 6lowpan networks. > > This include things like MIC identifiers, alternative mesh headers, > > security, ... > > > > What is not in the scope is routing. I think the RSN concept is > > important in that the devices we are anticipating have significant > > constraints (power, memory, processing) and as such the current set of > > protocols and development is probably not appropriate for these types of > > devices. > > > > geoff > > > > > > > > _______________________________________________ > > RSN mailing list > > RSN@ietf.org > > https://www1.ietf.org/mailman/listinfo/rsn > > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jun 19 12:45:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gq4-0003Mm-Qf; Tue, 19 Jun 2007 12:45:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0gq3-0003KA-5A for rsn@ietf.org; Tue, 19 Jun 2007 12:45:55 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0gq2-0000OQ-G2 for rsn@ietf.org; Tue, 19 Jun 2007 12:45:55 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 19 Jun 2007 18:45:53 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5JGjriu031807; Tue, 19 Jun 2007 18:45:53 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5JGjWDR021740; Tue, 19 Jun 2007 16:45:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 18:45:32 +0200 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] L3 mesh requirements Date: Tue, 19 Jun 2007 18:45:27 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC041D1CCA@xmb-ams-337.emea.cisco.com> In-Reply-To: <4672BABD.6000904@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RSN] L3 mesh requirements Thread-Index: AcevaDlUzs8dAK8rS9Wp3eaU4SECzQC/qoKQ References: <006b01c7aa17$48592540$0202a8c0@Teco> <5vmlru$656cu@sj-inbound-f.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0416E9B4@xmb-ams-337.emea.cisco.com> <4672BABD.6000904@nokia.com> From: "Pascal Thubert \(pthubert\)" To: "Charles E. Perkins" X-OriginalArrivalTime: 19 Jun 2007 16:45:32.0031 (UTC) FILETIME=[403118F0:01C7B291] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7782; t=1182271553; x=1183135553; 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]=20L3=20mesh=20requirements |Sender:=20; bh=MD+gc2V5eGrHAdlt/nNWubwwo3TPrwmRS2AU9sP0Rk8=; b=Ye9UeOvU+6dTKs0YEllQe1igAFX6aJeoqDC4CUkN8NbMzMeG1BAzqac6gtJSj3oT3rZah7IH aBP7Ju2GA3uG6m/C2IJddqzSnC88K3KpN0EyLeSIJD0dAwL1cB5k2L+Y; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: rsn@ietf.org, manemo@mobileip.jp X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hello Charlie, It's just too easy to drag me into solution space. I'll (try to) resist! Please see inline >A few comments -- please excuse if I missed the relevant >discussion since I am far behind on [rsn] and not even on the >[manemo] mailing list at all. [Pascal] There's MANEMO history for sure, but also a lot of background, specifically from 802.11s (which involves AODV for inner routes :) and 802.16J, and 802.15.5, and ISA SP100, and wireless HART, and 6LoWPAN and RSN at IETF... > >ext Pascal Thubert (pthubert) wrote: >> R1) A mesh network is a radio network connected to an infrastructure >> such as the Internet, and aimed at providing Routability between mesh >> nodes and that infrastructure, back and forth and at most times; still, >> the mesh should be able to operate for local communications when >> disconnected from the infrastructure. >> > I don't think a mesh has to be connected to the Internet. Instead, as you >mention, the mesh can work well as a self-contained network, and yet offer >Internet connectivity whenever it is available. This may be viewed as >intermittent or perhaps even seldom. So, I would not want to say that >the mesh has to be "aimed at providing Routability between mesh >nodes and that infrastructure". [Pascal] I'd say it depends on which problem you're trying to solve, and we're specifying just that.=20 I based this requirement on mesh and sensor networks as they exist today or seem to come up in the near future. If you consider a municipal wifi mesh network or a factory sensor network, both are connected to an infrastructure and aim specifically at giving connectivity to that infrastructure. One common goal for RSN and MANEMO is to structure that access in a standard L3 way as opposed to leaving it to L2 specific or proprietary solution as they exist today. Now, what you say makes perfect sense to me and the requirement here is already opened to the disconnected case. It could be good to apply the same technology to build disconnected WLCs (Very Very Large Clusters :) and enable some hierarchical routing. But we need a focus for choosing the way we optimize things in short term and this seems to be related with the concept of sink, which in our case interconnects with the infrastructure. > >> R2) Mesh nodes are not all equal. There are wired sinks which connect to >> the infrastructure, fully functional devices (FFD), and reduced >> functional devices (RFD). RFD are characterized by severely limited CPU, >> memory and battery capacity; they should not be involved in routing and >> forwarding but to the bare minimum. > > This can be done if the metric is appropriate and the measurements are >done properly. So, for instance, a node could indicate that it is unwilling >to route, but able to do so in a pinch. > [Pascal] Yes, that metric is one of the big items to work on. Teco calls it UPM. Also the concept of being either a router, a relay (forwarder) or a mere terminator, and changing roles upon needs. Oups, no solution, I promised. >> Because radio and battery are >> limited resources everywhere, the amount of control messages should be >> reduced to a minimum and optimized by compression, piggy backing etc... >> > >Is [rsn] going to tackle compression? That would be a great >area for development, and I don't think any other group even >has it in their sights. Unfortunately, it seems to attract >controversy over patent rights. > [Pascal] Ouch! This is a good question for RSN. Could that be a service that 6LoWPAN provides and RSN uses in LoWPANs but MANEMO doesn't?=20 >> R3) The most common use case is to connect mesh nodes with middleware, >> applications servers and peer nodes located over the infrastructure, via >> mesh sinks. > > I am puzzling over the actual content of this sentence. It seems to apply >to every network in the Internet, if we consider a host to be a "sensor". > [Pascal] I mean as opposed to intra mesh communication. In a city mesh, people go to their web site. Same as Starbucks in fact: people'd rather start their VPN before a friendly neighbor invades their system. >> Routing should proactively maintain the path between the >> mesh nodes and the sinks, back and forth. > > Doesn't this remain to be seen? What about mesh nodes that are >tired and want to sleep? > [Pascal] In RSN, we might very well introduce synchronization between the nodes to let them sleep. Does not prevent from keeping proactive routes, mostly when (most of) the sleepers are not doing their routing themselves, does it? >> It should be possible to avoid >> incremental cost linked to routing to other destinations. Also, the mesh >> protocol should be compatible with NEMO and enable mobile nodes to >> attach to their Home Agents over the mesh without the need of an >> additional MANET protocol. >> > >Check. Except, that we might want to fiddle with the Agent Advertisements. [Pascal] That's more on the MANEMO side now :) Maybe the BU frequency can be aware of the mesh frequency? Hopefully MANEMO does not nee to change NEMO. But maybe it does? > >> R4) ... The mesh routing protocol should be interoperable with the >> standard MANET routing protocols in terms of external routes >> redistributions and so on, but should not depend on a specific instance >> of a MANET protocol being deployed. >> > > This is debatable. Especially, if it turns out that a "standard" MANET >protocol >(hmm... two should be here this year, we think) can be engineered into a >good >choice for mesh routing. [Pascal] That's fine :) I could not find a wording to mean 'another protocol than the mesh protocol itself'. This does not preclude an elected (modified?) standard MANET protocol to become the mesh protocol... Also, I hardly believe that there can be 2 mesh protocols. But maybe there can be a common minimum backplane that does the minimum trick and which both MANET protocols could benefit from for scaling and interconnecting via the infrastructure? > >> R6) Peer selection and routing occur with the objective to reach a sink; >> this is based on Layer 3 information (peer type, reachability, path >> metrics to the sink...) as well as Layer 2 information (RSSI to peer, >> bandwidth, etc...). Because a scanning process might be involved at >> layer 2 to sustain the peer selection mechanism, it is desirable that >> the initial peer list be established in pure listening (monitor) mode. >> > > What if two non-sensors, that are currently deployed in the field, want to >use the sensor mesh to communicate with each other? Surely you would >not like to burden the mesh with a whole new set of protocols just because >a couple of people happened to want to make use of it while they are >in the area... Or, did you want the sinks to be required intermediate nodes >in every peer-to-peer communications? That could make connectivity even >more expensive in a lot of cases. > [Pascal] 802.11s does that reactively. The idea is to recognize that inner routes are not as traveled and should not be always maintained at all cost, because most traffic is to the outside anyway. I can see your smile :) This is not a sure win for reactive, though. We could use Least Overhead Routing Approach as well. This is how MANEMO presents it at least. I like the idea to have a somewhere to forward a packet, even if that's not the best somewhere. That helps separate routing and forwarding. Also, I'm still confused with aggregation in reactive protocols, and how we can lookup a prefix, though DYMO has provision to carry a prefix length. Good debates ahead! >Regards, >Charlie P. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jun 19 18:07:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lrD-00026G-6e; Tue, 19 Jun 2007 18:07:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0lrC-000262-58; Tue, 19 Jun 2007 18:07:26 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0lrB-0002Pf-La; Tue, 19 Jun 2007 18:07:26 -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 l5JM7NHk000528; Tue, 19 Jun 2007 16:07:24 -0600 (MDT) Subject: Re: [RSN] The need for RSN From: Geoff Mulligan To: "Eunsook \"Eunah\" Kim" In-Reply-To: <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> References: <675024.81537.qm@web81902.mail.mud.yahoo.com> <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> Content-Type: text/plain Date: Tue, 19 Jun 2007 16:07:20 -0600 Message-Id: <1182290840.6218.32.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org It was my understanding that while 6lowpan may consider "mesh under" alternatives (layer 2 routing), it would rely upon a group like RSN to deal with "route over" (layer 3 routing) and that 6lowpan would provide requirements to RSN. geoff On Tue, 2007-06-19 at 17:39 +0900, Eunsook "Eunah" Kim wrote: > My 2 cents are in line; > > > The slide (see the pdf above) is pretty clear about the scope of the "mesh > > routing" item: in 6lowpan we are not chartered > > to develop a new routing protocol (as in the algorithm, or the engine to > > generate routing tables). We have something > > that looks like consensus (just need the chairs to declare it so) on > > *adapting* routing protocols developed > > elsewhere. 6lowpan cannot develop protocols cuz it's not in the routing > > area. > > /snip/ > > In my understanding, we had some concerns to work routing solutions at > 6lowpan, as you said it's not in the routing area. However, it doesn't > mean that 6lowpan doesn't need to consider routing related issues for > 6lowpan. IMHO, to make a solution and to handle routing related issues > are different. > > If RSN successfully stages in the IETF, surely, RSN would be a good > place to discuss routing issues for sensor networks. However, as you > said below, for 6lowpan, sub-IP operations for multi-hop delivery > should be considered, as RSN considers L3 routing. > > In my understanding, 6lowpan can be one of the applications for RSN. > One way to consider 6lowpan routing issues is to put 6lowpan specific > mesh-under routing requirements to RSN, as RSN is now gathering > various requirements based on different applications. 6lowpan can > discuss its own requirements with RSN, or input the requirements to > RSN. > > -eunsook > > > As I understand it, RSN operates at layer 3, and it is arguing that there is > > room for another multi-hop routing WG in the > > routing area. Perhaps MANET can't really satisfy requirements for wireless > > sensors. Whether this is solved by > > integrating the RSN charter/deliverables into a re-chartered MANET, or by > > starting a new WG, > > from 6lowpan's point of view, 6lowpan can benefit from the resultant > > protocols. > > Of course, adaptation from layer 3 to sub-IP operation will be required, > > along the lines of the > > existing independent submissions in 6lowpan. > > My 2 motes (hopefully one day those will cost 1 cent each...) > > > > -gabriel > > > > > > ----- Original Message ---- > > From: Dominik Kaspar > > To: Geoff Mulligan > > Cc: rsn@ietf.org > > Sent: Sunday, June 10, 2007 9:17:11 PM > > Subject: Re: [RSN] The need for RSN > > > > Geoff, > > > > As far as I know, there has not been any consensus yet to what is in > > the scope of 6lowpan and what is not. But concering the RSN/R2LN > > efforts, it would be favorable to find consensus as soon as possible, > > so that it's clear where to dedicate new work to. > > > > Dominik > > > > On 6/8/07, Geoff Mulligan wrote: > > > I would like to reiterate that I think that the work RSN group has > > > suggested taking on is very important to my working group - 6lowpan. > > > > > > Our working group is looking to recharter and the scope of the work will > > > be focused on issues related to interoperability for 6lowpan networks. > > > This include things like MIC identifiers, alternative mesh headers, > > > security, ... > > > > > > What is not in the scope is routing. I think the RSN concept is > > > important in that the devices we are anticipating have significant > > > constraints (power, memory, processing) and as such the current set of > > > protocols and development is probably not appropriate for these types of > > > devices. > > > > > > geoff > > > > > > > > > > > > _______________________________________________ > > > RSN mailing list > > > RSN@ietf.org > > > https://www1.ietf.org/mailman/listinfo/rsn > > > > > > > _______________________________________________ > > RSN mailing list > > RSN@ietf.org > > https://www1.ietf.org/mailman/listinfo/rsn > > > > > > _______________________________________________ > > RSN mailing list > > RSN@ietf.org > > https://www1.ietf.org/mailman/listinfo/rsn > > > > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jun 19 20:58:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oWR-0000eH-IH; Tue, 19 Jun 2007 20:58:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0oWP-0000dw-Iv for rsn@ietf.org; Tue, 19 Jun 2007 20:58:09 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0oWO-0003uj-Cr for rsn@ietf.org; Tue, 19 Jun 2007 20:58:09 -0400 Received: by wr-out-0506.google.com with SMTP id 36so22438wra for ; Tue, 19 Jun 2007 17:58:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aHgbgr7nZ0+yt5SP8ZfI3Hj3rI+mG0A1HTMKsqA2FVex+bwsSQkFFZDezDOZW1moMAGa8jLDII7OVLogrZMNYUdJcX7XJSMH71XDHO7iw8e3Vf5VsLGKQROb9+vf43iRMv7j6tJIkfKkA+uocMQBn8ghspSCYHWsy9Xs+GLqVQU= 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=upwROhuNgQj7+uVG8L+1eDnsZ8CA6IA40l/0y4RhfA8ajwtqAue6YzHra3qlVhxmSW0Do1qhZZVQBPtz0W2DTD2jofWWXvxQnIF3eQSqyPZO+8LRHYbtPLZvYWfoQ9fdhTc42NCBFf3aQQfqCuQPkf2JNA/E2N2GsE9RB8GCRZA= Received: by 10.142.107.1 with SMTP id f1mr2205wfc.1182301087394; Tue, 19 Jun 2007 17:58:07 -0700 (PDT) Received: by 10.143.28.13 with HTTP; Tue, 19 Jun 2007 17:58:07 -0700 (PDT) Message-ID: <77f1dba80706191758k39da5774r34051ab22f295f64@mail.gmail.com> Date: Wed, 20 Jun 2007 09:58:07 +0900 From: "Eunsook \"Eunah\" Kim" To: "Geoff Mulligan" Subject: Re: [RSN] The need for RSN In-Reply-To: <1182290840.6218.32.camel@dellx1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <675024.81537.qm@web81902.mail.mud.yahoo.com> <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> <1182290840.6218.32.camel@dellx1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Geoff, I'm glad that it seems like we are talking in the same language. :) -eunsook On 6/20/07, Geoff Mulligan wrote: > It was my understanding that while 6lowpan may consider "mesh under" > alternatives (layer 2 routing), it would rely upon a group like RSN to > deal with "route over" (layer 3 routing) and that 6lowpan would provide > requirements to RSN. > > geoff _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Wed Jun 20 12:27:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I131c-00037s-4R; Wed, 20 Jun 2007 12:27:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kU0-0007m6-Ts for rsn@ietf.org; Tue, 19 Jun 2007 16:39:24 -0400 Received: from smtp1-g19.free.fr ([212.27.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kTz-00042Z-LR for rsn@ietf.org; Tue, 19 Jun 2007 16:39:24 -0400 Received: from [192.168.0.1] (mir01-2-82-245-104-81.fbx.proxad.net [82.245.104.81]) by smtp1-g19.free.fr (Postfix) with ESMTP id 02DB01AB32E for ; Tue, 19 Jun 2007 22:39:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <505C7499-1AF3-45E0-875B-B5B73C25F4FE@free.fr> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: rsn@ietf.org From: Bernard Tourancheau Subject: RE: [RSN] L3 mesh requirements Date: Tue, 19 Jun 2007 22:39:13 +0200 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-Mailman-Approved-At: Wed, 20 Jun 2007 12:27:18 -0400 X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hello all, A few comments, probably very naive, I did not read entirely the archive. Other wireless networks do not have the strong energy constraint, memory constraint, ... that sensors have. Thus lowpan deserves a different perspective to reflect its physical reality. Routing will be hierarchical because of the different capabilities of each nodes. We may "classify them by their routing resources ?: Type | Capability Fonctional Device ------------------------------------------------------------------------ ------------------------ leaf nodes, | send/recv veryRFD? hop nodes, | send/recv/fwd+treatment? RFD? bridge nodes. | send/recv/fwd/multi-cast/treatment FFD? gateway nodes| send/recv/fwd/multi-cast/treatment + "always" up veryFFD? We may associate L3 to only FFDs ? The L2 forwarding is not mandatory, automatic and blind, somehow it defines a cluster, representing the first stage of the hierarchy. About mobility or slow mobility: Are we sure this is a requirement for our targets ? As long a connection exist no problem, its physical strength or the forwarding path can vary due to slow mobility, energy level or environment movements. When some connection is lost, let call it broken link. A new connection in another forwarding cluster needs dhcp style renegociation. My 2motes, Bernard. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 17:00:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tlr-0004vk-0z; Thu, 21 Jun 2007 17:00:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tlp-0004va-V3 for rsn@ietf.org; Thu, 21 Jun 2007 17:00:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Tlp-00016q-Ba for rsn@ietf.org; Thu, 21 Jun 2007 17:00:49 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 17:00:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPqCekZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175486400"; d="scan'208"; a="63392970:sNHT50535988" 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 l5LL0mZN007033; Thu, 21 Jun 2007 17:00:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LL06M9026721; Thu, 21 Jun 2007 21:00:46 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:34 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:33 -0400 In-Reply-To: <4672BABD.6000904@nokia.com> References: <006b01c7aa17$48592540$0202a8c0@Teco> <5vmlru$656cu@sj-inbound-f.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0416E9B4@xmb-ams-337.emea.cisco.com> <4672BABD.6000904@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] L3 mesh requirements Date: Thu, 21 Jun 2007 17:00:10 -0400 To: "Charles E. Perkins" , "ext Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Jun 2007 21:00:33.0377 (UTC) FILETIME=[3554B510:01C7B447] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6928; t=1182459648; x=1183323648; 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]=20L3=20mesh=20requirements |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20, =0A=20= 20=20=20=20=20=20=20=22ext=20Pascal=20Thubert=20(pthubert)=22=20; bh=C8onqoeYnG1wXVx0CRjxCgwhiD9TigQS1ZDxi50oOm0=; b=OnUsgc6Y1NZz53zWTrWg3rbfJ5YpdcD+4FIIJBQ6EWwOXEXk8GiJJIvAeKN62vkFkXCBicF2 JzFivf8Z6HoYITD16GMP0CdFaL1AZ5yPwRBWmk1Iph6SND+PR3NsTh0N; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: rsn@ietf.org, manemo@mobileip.jp X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi, On Jun 15, 2007, at 12:13 PM, Charles E. Perkins wrote: > > Hello Pascal, > > A few comments -- please excuse if I missed the relevant > discussion since I am far behind on [rsn] and not even on the > [manemo] mailing list at all. > > ext Pascal Thubert (pthubert) wrote: >> R1) A mesh network is a radio network connected to an infrastructure >> such as the Internet, and aimed at providing Routability between mesh >> nodes and that infrastructure, back and forth and at most times; >> still, >> the mesh should be able to operate for local communications when >> disconnected from the infrastructure. >> > I don't think a mesh has to be connected to the Internet. Instead, > as you > mention, the mesh can work well as a self-contained network, and > yet offer > Internet connectivity whenever it is available. This may be viewed as > intermittent or perhaps even seldom. So, I would not want to say that > the mesh has to be "aimed at providing Routability between mesh > nodes and that infrastructure". Eventually there might even not be any distinction between such infrastructure and the current Internet. I personally think that in a few years from now, we will consider things as regular Internet hosts. From a routing standpoint such L2N (Low Power and Lossy Networks) will be running different IGPs than the usual core routing protocols but this is perfectly fine. > >> R2) Mesh nodes are not all equal. There are wired sinks which >> connect to >> the infrastructure, fully functional devices (FFD), and reduced >> functional devices (RFD). RFD are characterized by severely >> limited CPU, >> memory and battery capacity; they should not be involved in >> routing and >> forwarding but to the bare minimum. > > This can be done if the metric is appropriate and the measurements are > done properly. So, for instance, a node could indicate that it is > unwilling > to route, but able to do so in a pinch. I think that we must make the distinction between nodes constraint and node attributes. Current IGPs do not handle node constraints when computing the shortest path. As you pointed out, we may manipulate the cost of the links attached to a node for example to avoid the routing of packets through that node. Now the ability to consider some node attributes to influence the routing decision (for example, route packets to D through node X because it performs data aggregation) although X may not be on the shortest path to the D is a different issue, not supported by the current routing with the exception of constrained-based routing (e.g. MPLS). > >> Because radio and battery are >> limited resources everywhere, the amount of control messages >> should be >> reduced to a minimum and optimized by compression, piggy backing >> etc... >> > Is [rsn] going to tackle compression? That would be a great > area for development, and I don't think any other group even > has it in their sights. Yes I do think that we need to deal with this issue. Input welcome of course. > Unfortunately, it seems to attract > controversy over patent rights. Patent rights ? > >> R3) The most common use case is to connect mesh nodes with >> middleware, >> applications servers and peer nodes located over the >> infrastructure, via >> mesh sinks. > > I am puzzling over the actual content of this sentence. It seems > to apply > to every network in the Internet, if we consider a host to be a > "sensor". > Pascal's point was I think related to the Point to Multipoint and Multipoint to Point traffic pattern nature of most of the sensor networks, as opposed to the "more" any to any nature of the traffic pattern in the Internet (more common with peer to peer). >> Routing should proactively maintain the path between the >> mesh nodes and the sinks, back and forth. > > Doesn't this remain to be seen? What about mesh nodes that are > tired and want to sleep? > Requires sync up. >> It should be possible to avoid >> incremental cost linked to routing to other destinations. Also, >> the mesh >> protocol should be compatible with NEMO and enable mobile nodes to >> attach to their Home Agents over the mesh without the need of an >> additional MANET protocol. >> > Check. Except, that we might want to fiddle with the Agent > Advertisements. > Pascal, why "compatible" with NEMO ? >> R4) ... The mesh routing protocol should be interoperable with the >> standard MANET routing protocols in terms of external routes >> redistributions and so on, but should not depend on a specific >> instance >> of a MANET protocol being deployed. >> > > This is debatable. Especially, if it turns out that a "standard" > MANET protocol > (hmm... two should be here this year, we think) can be engineered > into a good > choice for mesh routing. I also think that this is debatable. Should we need to define a new routing protocol, we should not try to take into account existing protocols. It is a good idea to keep them in mind but without trying to constraint the design to existing protocols. Of course, we may have to then define route redistribution schemes. > >> R6) Peer selection and routing occur with the objective to reach a >> sink; >> this is based on Layer 3 information (peer type, reachability, path >> metrics to the sink...) as well as Layer 2 information (RSSI to peer, >> bandwidth, etc...). Pascal, as discussed (thus I know that we are on the same page), we should define ways to translate the Layer2 information into new routing metrics rather than having to have inter-layer dependencies. For the list, Pascal and I are working on a new ID. >> Because a scanning process might be involved at >> layer 2 to sustain the peer selection mechanism, it is desirable that >> the initial peer list be established in pure listening (monitor) >> mode. >> > > What if two non-sensors, that are currently deployed in the field, > want to > use the sensor mesh to communicate with each other? Surely you would > not like to burden the mesh with a whole new set of protocols just > because > a couple of people happened to want to make use of it while they are > in the area... Or, did you want the sinks to be required > intermediate nodes > in every peer-to-peer communications? That could make connectivity > even > more expensive in a lot of cases. Yes and I think that although the routing protocols should be optimized for P2MP and MP2P, this MUST also support any to any since L2Ns are not just Sensor Networks. Cheers. JP. > > Regards, > Charlie P. > > > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 17:00:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tlt-0004x4-Hd; Thu, 21 Jun 2007 17:00:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tlq-0004vh-RK for rsn@ietf.org; Thu, 21 Jun 2007 17:00:50 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Tlp-00016r-Ea for rsn@ietf.org; Thu, 21 Jun 2007 17:00:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Jun 2007 17:00:49 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPqCekZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175486400"; d="scan'208"; a="124269120:sNHT29242162" 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 l5LL0mCq007039; Thu, 21 Jun 2007 17:00:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LL06MB026721; Thu, 21 Jun 2007 21:00:48 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:43 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:42 -0400 In-Reply-To: <4672BFD1.5050509@nokia.com> References: <675024.81537.qm@web81902.mail.mud.yahoo.com> <4672BFD1.5050509@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <540AF90E-C087-416A-8B68-33E1DED2F589@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] The need for RSN Date: Thu, 21 Jun 2007 17:00:19 -0400 To: "Charles E. Perkins" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Jun 2007 21:00:42.0924 (UTC) FILETIME=[3B0576C0:01C7B447] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2203; t=1182459648; x=1183323648; 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]=20The=20need=20for=20RSN |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20; bh=buAiEZuyY+eYaPvovsmVIGDphtmt0ZWwsUCEFiHQMSU=; b=uyeWaiWRdJ9npmQwplaUZEwWfGH1tT8JSbPa9eJ23aM7YJyeA2FUJaWN1Js/2+ZS3zLXHr/2 vhBf28QrO6IiCmfXeI6C8ivwHoDIYkx7demxHDVqMx+p30v4L3Mef8be; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: rsn@ietf.org, Gabriel.Montenegro@microsoft.com X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Jun 15, 2007, at 12:35 PM, Charles E. Perkins wrote: > > Hello Gabriel, > > ext rsn-bounces@ietf.org wrote: >> We've been primarily assuming we'd be adapting protocols from >> MANET, and there are individual >> submissions already on AODV, DyMO as well as non-IETF protocols >> (e.g., HILO). We've also >> been assured by MANET chairs (i.e., Ian) that they will heed our >> requirements and make sure >> their protocols also work for us. Of course, their protocols will >> never work "as is". We have to >> adapt them to work under IP, instead of over IP as assumed by MANET. > Of course, I have hoped that the "Of course" in your paragraph > is not so self-evident. Is there really no hope? > [PS. Your mail to the mailing list shows as bouncing?] >> >> As I understand it, RSN operates at layer 3, and it is arguing >> that there is room for another multi-hop routing WG in the >> routing area. Perhaps MANET can't really satisfy requirements for >> wireless sensors. Whether this is solved by >> integrating the RSN charter/deliverables into a re-chartered >> MANET, or by starting a new WG, >> from 6lowpan's point of view, 6lowpan can benefit from the >> resultant protocols. > I think it is more likely that [rsn] can be viewed as a spin-off > from [manet], > in much the same way that [mipshop] and others were spun off from the > old [mobileip] group. In fact, I think the argument for [rsn] is > much stronger > than the argument for [mipshop] because [rsn] has a clear need for > looking at: > - compression, > - power-saving techniques, > - new extensions to DYMO or whatever, > - new/better metrics, > - clustering > - multicast > - perhaps also geographic routing techniques. Fully agree. We can also add data-ware routing to the list. Cheers. JP. >> Of course, adaptation from layer 3 to sub-IP operation will be >> required, along the lines of the >> existing independent submissions in 6lowpan. > There's that "Of course" again :-) > > Regards, > Charlie P. > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 17:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tlx-00050g-1s; Thu, 21 Jun 2007 17:00:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tlv-0004y9-Gd for rsn@ietf.org; Thu, 21 Jun 2007 17:00:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Tlt-00016q-VI for rsn@ietf.org; Thu, 21 Jun 2007 17:00:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 17:00:53 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPqCekZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175486400"; d="scan'208"; a="63392984:sNHT95634716" 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 l5LL0rc8007071; Thu, 21 Jun 2007 17:00:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LL06MF026721; Thu, 21 Jun 2007 21:00:53 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:52 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:51 -0400 In-Reply-To: <1182290840.6218.32.camel@dellx1> References: <675024.81537.qm@web81902.mail.mud.yahoo.com> <77f1dba80706190139t661114f9q90d1c3e2140652ce@mail.gmail.com> <1182290840.6218.32.camel@dellx1> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [6lowpan] Re: [RSN] The need for RSN Date: Thu, 21 Jun 2007 17:00:29 -0400 To: Geoff Mulligan X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Jun 2007 21:00:51.0502 (UTC) FILETIME=[40225CE0:01C7B447] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4745; t=1182459653; x=1183323653; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20Re=3A=20[RSN]=20The=20need=20for=20RSN |Sender:=20 |To:=20Geoff=20Mulligan=20; bh=zj+s7m3mqAITg49J0OXKNh6935ZUE63P2s0XnQ3qgZc=; b=HOhlL/qbPrnmMVbwjPzg3K68K3QEXTsAC3pQ4iFeeWrOA1MRIYeJxS9sEfOVztk5vCw/KlKM Ae8rNH/mptsS/i8uAAqAw675m0XSZBc/oVaN804fpgjeq5f7F2kkn5jE; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Sounds like we are all in sync then ... JP. On Jun 19, 2007, at 6:07 PM, Geoff Mulligan wrote: > It was my understanding that while 6lowpan may consider "mesh under" > alternatives (layer 2 routing), it would rely upon a group like RSN to > deal with "route over" (layer 3 routing) and that 6lowpan would > provide > requirements to RSN. > > geoff > > On Tue, 2007-06-19 at 17:39 +0900, Eunsook "Eunah" Kim wrote: >> My 2 cents are in line; >> >>> The slide (see the pdf above) is pretty clear about the scope of >>> the "mesh >>> routing" item: in 6lowpan we are not chartered >>> to develop a new routing protocol (as in the algorithm, or the >>> engine to >>> generate routing tables). We have something >>> that looks like consensus (just need the chairs to declare it so) on >>> *adapting* routing protocols developed >>> elsewhere. 6lowpan cannot develop protocols cuz it's not in the >>> routing >>> area. >>> /snip/ >> >> In my understanding, we had some concerns to work routing >> solutions at >> 6lowpan, as you said it's not in the routing area. However, it >> doesn't >> mean that 6lowpan doesn't need to consider routing related issues for >> 6lowpan. IMHO, to make a solution and to handle routing related >> issues >> are different. >> >> If RSN successfully stages in the IETF, surely, RSN would be a good >> place to discuss routing issues for sensor networks. However, as you >> said below, for 6lowpan, sub-IP operations for multi-hop delivery >> should be considered, as RSN considers L3 routing. >> >> In my understanding, 6lowpan can be one of the applications for RSN. >> One way to consider 6lowpan routing issues is to put 6lowpan specific >> mesh-under routing requirements to RSN, as RSN is now gathering >> various requirements based on different applications. 6lowpan can >> discuss its own requirements with RSN, or input the requirements to >> RSN. >> >> -eunsook >> >>> As I understand it, RSN operates at layer 3, and it is arguing >>> that there is >>> room for another multi-hop routing WG in the >>> routing area. Perhaps MANET can't really satisfy requirements for >>> wireless >>> sensors. Whether this is solved by >>> integrating the RSN charter/deliverables into a re-chartered >>> MANET, or by >>> starting a new WG, >>> from 6lowpan's point of view, 6lowpan can benefit from the resultant >>> protocols. >>> Of course, adaptation from layer 3 to sub-IP operation will be >>> required, >>> along the lines of the >>> existing independent submissions in 6lowpan. >>> My 2 motes (hopefully one day those will cost 1 cent each...) >>> >>> -gabriel >>> >>> >>> ----- Original Message ---- >>> From: Dominik Kaspar >>> To: Geoff Mulligan >>> Cc: rsn@ietf.org >>> Sent: Sunday, June 10, 2007 9:17:11 PM >>> Subject: Re: [RSN] The need for RSN >>> >>> Geoff, >>> >>> As far as I know, there has not been any consensus yet to what is in >>> the scope of 6lowpan and what is not. But concering the RSN/R2LN >>> efforts, it would be favorable to find consensus as soon as >>> possible, >>> so that it's clear where to dedicate new work to. >>> >>> Dominik >>> >>> On 6/8/07, Geoff Mulligan wrote: >>>> I would like to reiterate that I think that the work RSN group has >>>> suggested taking on is very important to my working group - >>>> 6lowpan. >>>> >>>> Our working group is looking to recharter and the scope of the >>>> work will >>>> be focused on issues related to interoperability for 6lowpan >>>> networks. >>>> This include things like MIC identifiers, alternative mesh headers, >>>> security, ... >>>> >>>> What is not in the scope is routing. I think the RSN concept is >>>> important in that the devices we are anticipating have significant >>>> constraints (power, memory, processing) and as such the current >>>> set of >>>> protocols and development is probably not appropriate for these >>>> types of >>>> devices. >>>> >>>> geoff >>>> >>>> >>>> >>>> _______________________________________________ >>>> RSN mailing list >>>> RSN@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/rsn >>>> >>> >>> _______________________________________________ >>> RSN mailing list >>> RSN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rsn >>> >>> >>> _______________________________________________ >>> RSN mailing list >>> RSN@ietf.org >>> https://www1.ietf.org/mailman/listinfo/rsn >>> >>> > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 17:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tm2-000567-FX; Thu, 21 Jun 2007 17:01:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Tm0-00055v-Km for rsn@ietf.org; Thu, 21 Jun 2007 17:01:00 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1Tlz-00016q-6b for rsn@ietf.org; Thu, 21 Jun 2007 17:01:00 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 17:00:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPqCekZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175486400"; d="scan'208"; a="63392999:sNHT30234916" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5LL0wHK022641; Thu, 21 Jun 2007 17:00:58 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5LL0rM1027014; Thu, 21 Jun 2007 21:00:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:58 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:00:58 -0400 In-Reply-To: <505C7499-1AF3-45E0-875B-B5B73C25F4FE@free.fr> References: <505C7499-1AF3-45E0-875B-B5B73C25F4FE@free.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AA40622-DC1C-4120-9702-BD738EFA1E0B@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] L3 mesh requirements Date: Thu, 21 Jun 2007 17:00:36 -0400 To: Bernard Tourancheau X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Jun 2007 21:00:58.0174 (UTC) FILETIME=[441C6DE0:01C7B447] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3429; t=1182459658; x=1183323658; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[RSN]=20L3=20mesh=20requirements |Sender:=20 |To:=20Bernard=20Tourancheau=20; bh=NKaORZf8rw6U1tS3fBh2hC9QSbINzXxwS1kuGXmkDoM=; b=jUxbap1VCqxAYWDGFdkfXShgWm4iWWIf6e4gKNYEcTVQY56Wl8mu1c1LL3+tBTx5yxxjjwH/ DZvogoq0ULvrqbWYF0pc4QtVyo7/9vdD/BkkOSOk5GuDc7o7fQZcFjZZ; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Bernard, On Jun 19, 2007, at 4:39 PM, Bernard Tourancheau wrote: > Hello all, > A few comments, probably very naive, I did not read entirely the > archive. > > Other wireless networks do not have the strong energy constraint, > memory constraint, ... that sensors have. Thus lowpan deserves a > different perspective to reflect its physical reality. Routing will > be hierarchical because of the different capabilities of each nodes. > We may "classify them by their routing resources ?: > > Type | Capability Fonctional Device > ---------------------------------------------------------------------- > -------------------------- > leaf nodes, | send/recv veryRFD? > hop nodes, | send/recv/fwd+treatment? RFD? > bridge nodes. | send/recv/fwd/multi-cast/treatment FFD? > gateway nodes| send/recv/fwd/multi-cast/treatment + "always" up > veryFFD? > > We may associate L3 to only FFDs ? The L2 forwarding is not > mandatory, automatic and blind, somehow it defines a cluster, > representing the first stage of the hierarchy. > At this stage, we've been working on the requirements. As pointed out in a previous email, it may not be a good idea to take the superset of all the requirements of L2Ns (again let's try to use that terminology to refer to Low Power and Lossy Networks, which includes Sensor Networks but is not restricted to it). Why ? Because they drastically differ ... thus this may lead to trying to design a routing protocols satisfying conflicting requirements if we want to indeed design a network for light footprint nodes. Thus the proposed approach is to have (in addition to the generic ID above), several applications specific requirements documents and define the protocol as a set of loadable components. I know that two IDs are in the works: (1) Home Automation (2) Industrial application We would probably need to have another one for healthcare. Back to your point, in a second step, we may decide to classify nodes by category although I personally prefer to use nodes attributes to provide a better granularity, to be discussed with the group of course. Then the routing design will follow. At this point, I think that it is crucial to carefully analyze the requirements ... although I know that we are all tempted to jump into the protocol design discussion. Would you want to provide comments to http://www.ietf.org/internet- drafts/draft-culler-rsn-routing-reqs-00.txt? As I said other related IDs will be soon follow. > About mobility or slow mobility: > Are we sure this is a requirement for our targets ? As long a > connection exist no problem, its physical strength or the > forwarding path can vary due to slow mobility, energy level or > environment movements. When some connection is lost, let call it > broken link. A new connection in another forwarding cluster needs > dhcp style renegociation. See this is why we need application specific IDs. If it turns out that mobility is not a strong requirements it would be good to know it before making the assumption that it is required, although in this particular case I think it is ;-) Thanks. JP. > > My 2motes, > Bernard. > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 17:01:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TmH-0005Cf-Tn; Thu, 21 Jun 2007 17:01:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1TmH-0005CW-2Z for rsn@ietf.org; Thu, 21 Jun 2007 17:01:17 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1TmG-0005HZ-Ek for rsn@ietf.org; Thu, 21 Jun 2007 17:01:17 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 17:01:16 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPqCekZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,448,1175486400"; d="scan'208"; a="63393024:sNHT38005928" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5LL1G63007306; Thu, 21 Jun 2007 17:01:16 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5LL12ZH025898; Thu, 21 Jun 2007 21:01:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:01:06 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 17:01:06 -0400 In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC041D1CCA@xmb-ams-337.emea.cisco.com> References: <006b01c7aa17$48592540$0202a8c0@Teco> <5vmlru$656cu@sj-inbound-f.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC0416E9B4@xmb-ams-337.emea.cisco.com> <4672BABD.6000904@nokia.com> <7892795E1A87F04CADFCCF41FADD00FC041D1CCA@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7EFF5032-7994-478D-A7A4-FA5A16B529FB@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [RSN] L3 mesh requirements Date: Thu, 21 Jun 2007 17:00:44 -0400 To: Pascal Thubert ((pthubert)) X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 21 Jun 2007 21:01:06.0111 (UTC) FILETIME=[48D784F0:01C7B447] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9281; t=1182459676; x=1183323676; 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]=20L3=20mesh=20requirements |Sender:=20 |To:=20Pascal=20Thubert=20((pthubert))=20; bh=/kgCCxeImbfOSNMCSkYQwxlK9u+x2rM31UD5nSOQuIY=; b=WogCYpuYEJZO4cmugC4mSqk4Hp7wpaXr6dsBSo/1r8nI6J1KSeJDE1oCDrcqMACBuILd6tQA 7QkUuq87AgrGUofrSUTAd14GllBkQB9KGpsvESDUaSjpXJ4NHX1G3TSN; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: "Charles E. Perkins" , rsn@ietf.org, manemo@mobileip.jp X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hi Pascal, On Jun 19, 2007, at 12:45 PM, Pascal Thubert ((pthubert)) wrote: > Hello Charlie, > > It's just too easy to drag me into solution space. I'll (try to) > resist! > Please see inline > >> A few comments -- please excuse if I missed the relevant >> discussion since I am far behind on [rsn] and not even on the >> [manemo] mailing list at all. > > [Pascal] There's MANEMO history for sure, but also a lot of > background, > specifically from 802.11s (which involves AODV for inner routes :) and > 802.16J, and 802.15.5, and ISA SP100, and wireless HART, and > 6LoWPAN and > RSN at IETF... > >> >> ext Pascal Thubert (pthubert) wrote: >>> R1) A mesh network is a radio network connected to an infrastructure >>> such as the Internet, and aimed at providing Routability between >>> mesh >>> nodes and that infrastructure, back and forth and at most times; > still, >>> the mesh should be able to operate for local communications when >>> disconnected from the infrastructure. >>> >> I don't think a mesh has to be connected to the Internet. >> Instead, as > you >> mention, the mesh can work well as a self-contained network, and yet > offer >> Internet connectivity whenever it is available. This may be >> viewed as >> intermittent or perhaps even seldom. So, I would not want to say >> that >> the mesh has to be "aimed at providing Routability between mesh >> nodes and that infrastructure". > > [Pascal] I'd say it depends on which problem you're trying to > solve, and > we're specifying just that. > I based this requirement on mesh and sensor networks as they exist > today > or seem to come up in the near future. If you consider a municipal > wifi > mesh network or a factory sensor network, both are connected to an > infrastructure and aim specifically at giving connectivity to that > infrastructure. One common goal for RSN and MANEMO is to structure > that > access in a standard L3 way as opposed to leaving it to L2 specific or > proprietary solution as they exist today. Can't agree more. No need to argue here that we do not want see the explosion of protocol translation gateways ... we went through that path several times during the last 2 decades. > Now, what you say makes perfect sense to me and the requirement > here is > already opened to the disconnected case. It could be good to apply the > same technology to build disconnected WLCs (Very Very Large > Clusters :) > and enable some hierarchical routing. But we need a focus for choosing > the way we optimize things in short term and this seems to be related > with the concept of sink, which in our case interconnects with the > infrastructure. Yes I would just slight soften this statement. Optimize for P2MP/MP2P (leaf <-> sink) with a support for any to any (not all to all). > >> >>> R2) Mesh nodes are not all equal. There are wired sinks which >>> connect > to >>> the infrastructure, fully functional devices (FFD), and reduced >>> functional devices (RFD). RFD are characterized by severely limited > CPU, >>> memory and battery capacity; they should not be involved in routing > and >>> forwarding but to the bare minimum. >> >> This can be done if the metric is appropriate and the measurements >> are >> done properly. So, for instance, a node could indicate that it is > unwilling >> to route, but able to do so in a pinch. >> > [Pascal] Yes, that metric is one of the big items to work on. Teco > calls > it UPM. Also the concept of being either a router, a relay (forwarder) > or a mere terminator, and changing roles upon needs. Oups, no > solution, > I promised. > > >>> Because radio and battery are >>> limited resources everywhere, the amount of control messages should > be >>> reduced to a minimum and optimized by compression, piggy backing > etc... >>> >> >> Is [rsn] going to tackle compression? That would be a great >> area for development, and I don't think any other group even >> has it in their sights. Unfortunately, it seems to attract >> controversy over patent rights. >> > [Pascal] Ouch! This is a good question for RSN. Could that be a > service > that 6LoWPAN provides and RSN uses in LoWPANs but MANEMO doesn't? I think so although there will certainly be a need for some sort of compression at the routing layer. > >>> R3) The most common use case is to connect mesh nodes with > middleware, >>> applications servers and peer nodes located over the infrastructure, > via >>> mesh sinks. >> >> I am puzzling over the actual content of this sentence. It seems to > apply >> to every network in the Internet, if we consider a host to be a > "sensor". >> > [Pascal] I mean as opposed to intra mesh communication. In a city > mesh, > people go to their web site. Same as Starbucks in fact: people'd > rather > start their VPN before a friendly neighbor invades their system. > >>> Routing should proactively maintain the path between the >>> mesh nodes and the sinks, back and forth. >> >> Doesn't this remain to be seen? What about mesh nodes that are >> tired and want to sleep? >> > [Pascal] In RSN, we might very well introduce synchronization between > the nodes to let them sleep. Does not prevent from keeping proactive > routes, mostly when (most of) the sleepers are not doing their routing > themselves, does it? That was also my point in my previous answer. > >>> It should be possible to avoid >>> incremental cost linked to routing to other destinations. Also, the > mesh >>> protocol should be compatible with NEMO and enable mobile nodes to >>> attach to their Home Agents over the mesh without the need of an >>> additional MANET protocol. >>> >> >> Check. Except, that we might want to fiddle with the Agent > Advertisements. > [Pascal] That's more on the MANEMO side now :) Maybe the BU frequency > can be aware of the mesh frequency? Hopefully MANEMO does not nee to > change NEMO. But maybe it does? >> >>> R4) ... The mesh routing protocol should be interoperable with the >>> standard MANET routing protocols in terms of external routes >>> redistributions and so on, but should not depend on a specific > instance >>> of a MANET protocol being deployed. >>> >> >> This is debatable. Especially, if it turns out that a "standard" > MANET >> protocol >> (hmm... two should be here this year, we think) can be engineered >> into > a >> good >> choice for mesh routing. > [Pascal] That's fine :) I could not find a wording to mean 'another > protocol than the mesh protocol itself'. This does not preclude an > elected (modified?) standard MANET protocol to become the mesh > protocol... Also, I hardly believe that there can be 2 mesh protocols. I really hope not ... that would defeat our goal to design a simple solution. We have to bear in mind that in most deployment scenarios these networks will be self- managed. The level of complexity of having to deal with N>1 routing mesh protocols would certainly be an issue. > But maybe there can be a common minimum backplane that does the > minimum > trick and which both MANET protocols could benefit from for scaling > and > interconnecting via the infrastructure? > >> >>> R6) Peer selection and routing occur with the objective to reach a > sink; >>> this is based on Layer 3 information (peer type, reachability, path >>> metrics to the sink...) as well as Layer 2 information (RSSI to >>> peer, >>> bandwidth, etc...). Because a scanning process might be involved at >>> layer 2 to sustain the peer selection mechanism, it is desirable >>> that >>> the initial peer list be established in pure listening (monitor) > mode. >>> >> >> What if two non-sensors, that are currently deployed in the field, > want to >> use the sensor mesh to communicate with each other? Surely you would >> not like to burden the mesh with a whole new set of protocols just > because >> a couple of people happened to want to make use of it while they are >> in the area... Or, did you want the sinks to be required >> intermediate > nodes >> in every peer-to-peer communications? That could make connectivity > even >> more expensive in a lot of cases. >> > [Pascal] 802.11s does that reactively. The idea is to recognize that > inner routes are not as traveled and should not be always > maintained at > all cost, because most traffic is to the outside anyway. I can see > your > smile :) This is not a sure win for reactive, though. We could use > Least > Overhead Routing Approach as well. This is how MANEMO presents it at > least. I like the idea to have a somewhere to forward a packet, > even if > that's not the best somewhere. That helps separate routing and > forwarding. Also, I'm still confused with aggregation in reactive > protocols, and how we can lookup a prefix, though DYMO has > provision to > carry a prefix length. > > Good debates ahead! Surely. Cheers. JP. >> Regards, >> Charlie P. > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 20:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WbD-0006uk-CB; Thu, 21 Jun 2007 20:02:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1WbC-0006uZ-PA for rsn@ietf.org; Thu, 21 Jun 2007 20:02:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1WbC-0004tb-FT for rsn@ietf.org; Thu, 21 Jun 2007 20:02:02 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Jun 2007 20:02:02 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKOtekZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,449,1175486400"; d="scan'208"; a="63405855:sNHT26365878" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5M022ot020883; Thu, 21 Jun 2007 20:02:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5M01WLj005356; Fri, 22 Jun 2007 00:01:53 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 20:01:39 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 20:01:38 -0400 In-Reply-To: <0JK000KRBDJRJV@mmp1.samsung.com> References: <0JK000KRBDJRJV@mmp1.samsung.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [6lowpan] Re: [RSN] The need for RSN Date: Thu, 21 Jun 2007 20:01:14 -0400 To: Daniel Park X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Jun 2007 00:01:38.0948 (UTC) FILETIME=[81B74440:01C7B460] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1077; t=1182470522; x=1183334522; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20Re=3A=20[RSN]=20The=20need=20for=20RSN |Sender:=20 |To:=20Daniel=20Park=20; bh=/ttBaBx/f4LDZO7lT3FaHNOmAGBiuC/cYKCgyVKjnyU=; b=UvRpZLFS/jozcv9VFE4ObSn5vgtCf4hscghLjFy8AIyhl2KZOmkXX5K1XnNeUt7CSLXfIYsk 73qIyRHljLzlqHxulGZUd3K31ZZICRhbeaK1XQcZ0jh7FXcSLhL1BeTK; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: rsn@ietf.org, 6lowpan@lists.ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Jun 21, 2007, at 7:06 PM, Daniel Park wrote: >> It was my understanding that while 6lowpan may consider "mesh under" >> alternatives (layer 2 routing), it would rely upon a group >> like RSN to deal with "route over" (layer 3 routing) and that >> 6lowpan would provide requirements to RSN. > > I don't think so Geoff. Originally, this deliverable was for > Proposed Standard Document. Are you saying 6lowpan > mesh-routing requirement might be Proposed Standard ? > Absolutely, NO. There is no such deliverables ... > > I don't care if you as chair are leaning to RSN for this > matter based on AD's agreement, but just wanted to > clarify your mis-interpretation from 6lowpan perspevtive. > Daniel, as you know 6lowpan is about to recharter ... > Also, IEEE 802.15.5 is already developing L2 mesh > routing for IEEE 802.15.4. What alternative means > in your mention ? > > -- Daniel Park > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 20:40:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XCl-0004m5-LP; Thu, 21 Jun 2007 20:40:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XCl-0004l4-4Z; Thu, 21 Jun 2007 20:40:51 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1XCj-0004et-Ns; Thu, 21 Jun 2007 20:40:51 -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 l5M0ee2D021642; Thu, 21 Jun 2007 18:40:40 -0600 (MDT) Subject: RE: [6lowpan] Re: [RSN] The need for RSN From: Geoff Mulligan To: Daniel Park In-Reply-To: <0JK000KRBDJRJV@mmp1.samsung.com> References: <0JK000KRBDJRJV@mmp1.samsung.com> Content-Type: text/plain Date: Thu, 21 Jun 2007 18:40:50 -0600 Message-Id: <1182472850.6218.126.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Daniel, I don't understand what you are saying. On Fri, 2007-06-22 at 08:06 +0900, Daniel Park wrote: > > It was my understanding that while 6lowpan may consider "mesh under" > > alternatives (layer 2 routing), it would rely upon a group > > like RSN to deal with "route over" (layer 3 routing) and that > > 6lowpan would provide requirements to RSN. > > I don't think so Geoff. Originally, this deliverable was for > Proposed Standard Document. Are you saying 6lowpan > mesh-routing requirement might be Proposed Standard ? > Absolutely, NO. What do you mean "this deliverable"? What deliverable, "layer 2 mesh"? Never were we chartered to define a Proposed Standard for layer 2 meshing". If that is what you are saying, then I agree. As originally chartered we were not to write a proposed standard for layer 2 mesh. I stated in my message, as stated in the original charter, that the WG might look at layer 2 routing (mesh under) alternatives, such as those available from manet or 802.15.5. > > I don't care if you as chair are leaning to RSN for this > matter based on AD's agreement, but just wanted to > clarify your mis-interpretation from 6lowpan perspevtive. I don't think that I mis-interpreted our original charter. If you read the WG documents they represent the concept of mesh under (layer 2 routing) and not routing over IP, but either way, it was very clear that routing protocols were never intended to be a part of 6lowpan work. > > Also, IEEE 802.15.5 is already developing L2 mesh > routing for IEEE 802.15.4. What alternative means > in your mention ? I know that 15.5 is working on Layer 2 meshing and the working group should look at that as well as the other proposals that are consistent with MANET. > > -- Daniel Park _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 20:49:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XLU-0006Sg-GO; Thu, 21 Jun 2007 20:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XLS-0006SG-B4; Thu, 21 Jun 2007 20:49:50 -0400 Received: from grab.coslabs.com ([199.233.92.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1XLI-0006xD-FR; Thu, 21 Jun 2007 20:49:50 -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 l5M0nVpA021679; Thu, 21 Jun 2007 18:49:31 -0600 (MDT) Subject: RE: [6lowpan] Re: [RSN] The need for RSN From: Geoff Mulligan To: Daniel Park In-Reply-To: <0JK000879HR3P0@mmp2.samsung.com> References: <0JK000879HR3P0@mmp2.samsung.com> Content-Type: text/plain Date: Thu, 21 Jun 2007 18:49:41 -0600 Message-Id: <1182473381.6218.137.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: rsn@ietf.org, 6lowpan@lists.ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Daniel, I still don't understand your question. Do you not think that 6lowpan should generate a PS document on L2 routing? This has been in the re-charter proposal for months. I think that there may be networks that will not use L2 mesh and will instead opt for L3 routing. There might well be other networks that will use L3 routing between L2 mesh networks. geoff On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: > > >> It was my understanding that while 6lowpan may consider > > "mesh under" > > >> alternatives (layer 2 routing), it would rely upon a group > > >> like RSN to deal with "route over" (layer 3 routing) and that > > >> 6lowpan would provide requirements to RSN. > > > > > > I don't think so Geoff. Originally, this deliverable was for > > > Proposed Standard Document. Are you saying 6lowpan > > > mesh-routing requirement might be Proposed Standard ? > > > Absolutely, NO. > > There is no such deliverables ... > > I said: > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing > protocols for use within 6lowpans. While most routing protocols are > defined above the IP layer, 6lowpan requires a mesh routing protocol > below the IP layer. "6lowpan Mesh Routing" may be several proposed > standard documents. > > So, are you thinking we need both solutions as layer 2 routing > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? > Or, 6lowpan only work for RSN requirement ? > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Thu Jun 21 22:00:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1YRP-0003N6-PN; Thu, 21 Jun 2007 22:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1YRN-0003Gg-Qn; Thu, 21 Jun 2007 22:00:01 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1YRM-0005ur-IX; Thu, 21 Jun 2007 22:00:01 -0400 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1I1YRL-0000cs-1E; Thu, 21 Jun 2007 18:59:59 -0700 In-Reply-To: <20070604153708.E95E316B0001@secure.archedrock.com> References: <20070604153708.E95E316B0001@secure.archedrock.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DC8E411-0B38-4ABD-8EE6-46065A993316@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [RSN] Update Date: Thu, 21 Jun 2007 18:10:36 -0700 To: dculler@archrock.com X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: d568c20fab0e2ccae07d583947984559 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: rsn@ietf.org, 6lowpan@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Jun 4, 2007, at 8:36 AM, dculler wrote: > > I think the simplification to "Routing Issues for Low Power Wireless > Networks" is very good. It defines the scope implicitly in a > number of > useful ways. > * There are a whole class of these devices where no routing is > involved > (game controllers, remote controls, wireless keyboard and mouse, ear > pieces). > * It includes portions of sensor networks, embedded networks, > automation, > but it not specifically limited to that. > * It includes 802.15.4 and links in a similar class. > * The technical challenges (loss, variation, multihop) are implied. > * It allows for both light footprint (microcontroller) and more > capable > hosts. > > So now we just need to tweak it to get a good acronym, since RILPWM > doesn't > exactly role off the tongue. How about RLANE Routing in Lossy low power Ad-hoc wireless NEtworks. Phil _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jun 22 02:24:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cYp-0007GJ-9k; Fri, 22 Jun 2007 02:23:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1cYo-0007G6-5N for rsn@ietf.org; Fri, 22 Jun 2007 02:23:58 -0400 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1cYn-0005NY-Ls for rsn@ietf.org; Fri, 22 Jun 2007 02:23:58 -0400 Received: by nz-out-0506.google.com with SMTP id z31so762121nzd for ; Thu, 21 Jun 2007 23:23:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JHoY3arXYHuHyjKIUPDvzOLITHQ8ll3/aoLl+sMJ88f/hfcseHpBH5WlEcPdpIRElyIWWJsRfVw0/XvlRJ6Kj+Mj5EJsV99mCgp/bB9xVxqg5z/bybqEMhjzZ6/u6qCmPyRFqQLrbsTwAwsGPEfrOdi3ZdCK5BkfMtkeLxKgLFM= 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=Ya/0ESOBiRqAAc5pXijlLlPbEnM34pnz/MvH3/aM1CDEPoGxCqDr30mnjzZ2fTTpZLWdXh0hMXZZ/th+hPNE5Em+Lq4QSTvxvMdG2kYeyYlktzB//sPkdaeWDONdCKvKSieAjLuFNHVM1TMp1wFSINLIB8hSKUAy6+OyVEQy/Qo= Received: by 10.142.251.9 with SMTP id y9mr60746wfh.1182493437044; Thu, 21 Jun 2007 23:23:57 -0700 (PDT) Received: by 10.143.28.13 with HTTP; Thu, 21 Jun 2007 23:23:57 -0700 (PDT) Message-ID: <77f1dba80706212323l77364169y6438cb86a81b44f0@mail.gmail.com> Date: Fri, 22 Jun 2007 15:23:57 +0900 From: "Eunsook \"Eunah\" Kim" To: "Daniel Park" Subject: Re: [6lowpan] Re: [RSN] The need for RSN In-Reply-To: <0JK000F4NOL629@mmp2.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1182473381.6218.137.camel@dellx1> <0JK000F4NOL629@mmp2.samsung.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: rsn@ietf.org, 6lowpan@lists.ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Hmm.. I'm a bit confused by your discussion. >From Geoff's proposed recharter text, It seemed to be clear for me that so-called "mesh-under routing" is 6lowpan's concern, while L3 routing is RSN's concern. We need to find out if we CAN take exisiting solutions or if we NEED to design a new one. Clearly for me, to find out this answer is 6lowpan's work. -eunsook On 6/22/07, Daniel Park wrote: > Geoff, > > Clarification to me. > > L2 mesh routing is made by 6lowpan taking > 802.15.5 into consideration, and L3 mesh routing > is perhaps made by another WG regardless of > MANET WG deliverables such as DYMO/AODV > based on 6lowpan L3 mesh routing requirement. > > -- Daniel Park > > > -----Original Message----- > > From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org] > > Sent: Friday, June 22, 2007 9:50 AM > > To: Daniel Park > > Cc: 'JP Vasseur'; 'Eunsook "Eunah" Kim'; > > 6lowpan@lists.ietf.org; rsn@ietf.org; > > g_e_montenegro@yahoo.com; 'Mark Townsley' > > Subject: RE: [6lowpan] Re: [RSN] The need for RSN > > > > Daniel, > > I still don't understand your question. Do you not think > > that 6lowpan > > should generate a PS document on L2 routing? This has been in the > > re-charter proposal for months. > > > > I think that there may be networks that will not use L2 mesh and will > > instead opt for L3 routing. There might well be other networks that > > will use L3 routing between L2 mesh networks. > > > > geoff > > > > On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: > > > > >> It was my understanding that while 6lowpan may consider > > > > "mesh under" > > > > >> alternatives (layer 2 routing), it would rely upon a group > > > > >> like RSN to deal with "route over" (layer 3 routing) and that > > > > >> 6lowpan would provide requirements to RSN. > > > > > > > > > > I don't think so Geoff. Originally, this deliverable was for > > > > > Proposed Standard Document. Are you saying 6lowpan > > > > > mesh-routing requirement might be Proposed Standard ? > > > > > Absolutely, NO. > > > > There is no such deliverables ... > > > > > > I said: > > > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing > > > protocols for use within 6lowpans. While most routing protocols are > > > defined above the IP layer, 6lowpan requires a mesh routing protocol > > > below the IP layer. "6lowpan Mesh Routing" may be several proposed > > > standard documents. > > > > > > So, are you thinking we need both solutions as layer 2 routing > > > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? > > > Or, 6lowpan only work for RSN requirement ? > > > > > > > > > > > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Fri Jun 22 11:20:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kve-0007tA-Bd; Fri, 22 Jun 2007 11:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kvd-0007sv-42 for rsn@ietf.org; Fri, 22 Jun 2007 11:20:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1kvc-0007g4-Fm for rsn@ietf.org; Fri, 22 Jun 2007 11:20:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Jun 2007 11:20:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH6Fe0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,452,1175486400"; d="scan'208"; a="124326800:sNHT32424512" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5MFK4Hi003012; Fri, 22 Jun 2007 11:20:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5MFJoLv015044; Fri, 22 Jun 2007 15:19:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 11:19:50 -0400 Received: from [10.86.104.181] ([10.86.104.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 11:19:49 -0400 In-Reply-To: <77f1dba80706212323l77364169y6438cb86a81b44f0@mail.gmail.com> References: <1182473381.6218.137.camel@dellx1> <0JK000F4NOL629@mmp2.samsung.com> <77f1dba80706212323l77364169y6438cb86a81b44f0@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3AA57709-C2AB-477F-B398-813649DF97AE@cisco.com> Content-Transfer-Encoding: 7bit From: JP Vasseur Subject: Re: [6lowpan] Re: [RSN] The need for RSN Date: Fri, 22 Jun 2007 11:17:36 -0400 To: "Eunsook \"Eunah\" Kim" X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 22 Jun 2007 15:19:49.0810 (UTC) FILETIME=[C66DB120:01C7B4E0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3128; t=1182525604; x=1183389604; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20Re=3A=20[RSN]=20The=20need=20for=20RSN |Sender:=20 |To:=20=22Eunsook=20\=22Eunah\=22=20Kim=22=20; bh=uHn+jcdMdU2xo4DuqT3UEXF/SUQR3curZIac7vmbICA=; b=KFKMRJ0SPebUk3gkIEHYf5qbe2OE1J2x5t3hZgMeHlsVVrvJpsm2NzphN9edskXR/vrt7k7K 2NA4V0VHunfQZ0cZzY6TvIpqKnWmuytPBJZhzeBvwn2vaBpvyI6cVQpb; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: rsn@ietf.org, Daniel Park , 6lowpan@lists.ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org On Jun 22, 2007, at 2:23 AM, Eunsook "Eunah" Kim wrote: > Hmm.. > I'm a bit confused by your discussion. > From Geoff's proposed recharter text, It seemed to be clear for me > that so-called "mesh-under routing" is 6lowpan's concern, while L3 > routing is RSN's concern. Quite right. > > We need to find out if we CAN take exisiting solutions or if we NEED > to design a new one. Clearly for me, to find out this answer is > 6lowpan's work. > As far as L3 routing is concerned, that task WOULD be the one of the POTENTIAL new WG work. If everybody agrees, it would be nice to go back to the technical work. Cheers. JP. > -eunsook > > > On 6/22/07, Daniel Park wrote: >> Geoff, >> >> Clarification to me. >> >> L2 mesh routing is made by 6lowpan taking >> 802.15.5 into consideration, and L3 mesh routing >> is perhaps made by another WG regardless of >> MANET WG deliverables such as DYMO/AODV >> based on 6lowpan L3 mesh routing requirement. >> >> -- Daniel Park >> >> > -----Original Message----- >> > From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org] >> > Sent: Friday, June 22, 2007 9:50 AM >> > To: Daniel Park >> > Cc: 'JP Vasseur'; 'Eunsook "Eunah" Kim'; >> > 6lowpan@lists.ietf.org; rsn@ietf.org; >> > g_e_montenegro@yahoo.com; 'Mark Townsley' >> > Subject: RE: [6lowpan] Re: [RSN] The need for RSN >> > >> > Daniel, >> > I still don't understand your question. Do you not think >> > that 6lowpan >> > should generate a PS document on L2 routing? This has been in the >> > re-charter proposal for months. >> > >> > I think that there may be networks that will not use L2 mesh and >> will >> > instead opt for L3 routing. There might well be other networks >> that >> > will use L3 routing between L2 mesh networks. >> > >> > geoff >> > >> > On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: >> > > > >> It was my understanding that while 6lowpan may consider >> > > > "mesh under" >> > > > >> alternatives (layer 2 routing), it would rely upon a group >> > > > >> like RSN to deal with "route over" (layer 3 routing) and >> that >> > > > >> 6lowpan would provide requirements to RSN. >> > > > > >> > > > > I don't think so Geoff. Originally, this deliverable was for >> > > > > Proposed Standard Document. Are you saying 6lowpan >> > > > > mesh-routing requirement might be Proposed Standard ? >> > > > > Absolutely, NO. >> > > > There is no such deliverables ... >> > > >> > > I said: >> > > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh >> routing >> > > protocols for use within 6lowpans. While most routing >> protocols are >> > > defined above the IP layer, 6lowpan requires a mesh routing >> protocol >> > > below the IP layer. "6lowpan Mesh Routing" may be several >> proposed >> > > standard documents. >> > > >> > > So, are you thinking we need both solutions as layer 2 routing >> > > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? >> > > Or, 6lowpan only work for RSN requirement ? >> > > >> > >> > >> > >> >> _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Sun Jun 24 19:51:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2brb-0005z0-Q7; Sun, 24 Jun 2007 19:51:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2brZ-0005yl-Rr for rsn@ietf.org; Sun, 24 Jun 2007 19:51:25 -0400 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2brY-00013Y-KN for rsn@ietf.org; Sun, 24 Jun 2007 19:51:25 -0400 Received: by wa-out-1112.google.com with SMTP id k17so1031724waf for ; Sun, 24 Jun 2007 16:51:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cJGY7HEW4ZD1XRCj5uGySsiYhYOsV5pgZkTfy7QhLZRsA4ELvy81kaHCATedMpbSpXU0FEGlNB+ZnDtIWO3IUQOY9XwWaH/2SvgKCaw9jvkNGtOIjpeUAI+UY6eS5NA6vIYWXa2cd+xUoXVxsPa54oZa9Q/vXRceyEkepSzwGGo= 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=Ouac64lGzE+60YSctnSt5YghWj7UGeyreKXmJ86RWqM2JYuWLSeaZ5iz+KAdiJtSPV6uLbY73QdJ5B9ItdDFmUwPo1sRMB7TmeO2r6rjqCL2Rrfq6ILKlu6jDfYAOK8a9ndVFMzZ59nRnlxg6s47x3T2P2IeNqJmqbtmZnAcJ6E= Received: by 10.115.49.16 with SMTP id b16mr4931506wak.1182729083896; Sun, 24 Jun 2007 16:51:23 -0700 (PDT) Received: by 10.115.94.7 with HTTP; Sun, 24 Jun 2007 16:51:23 -0700 (PDT) Message-ID: Date: Mon, 25 Jun 2007 08:51:23 +0900 From: "Daniel Park" To: "JP Vasseur" Subject: Re: [6lowpan] Re: [RSN] The need for RSN In-Reply-To: <3AA57709-C2AB-477F-B398-813649DF97AE@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1182473381.6218.137.camel@dellx1> <0JK000F4NOL629@mmp2.samsung.com> <77f1dba80706212323l77364169y6438cb86a81b44f0@mail.gmail.com> <3AA57709-C2AB-477F-B398-813649DF97AE@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org, Daniel Park X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org > > We need to find out if we CAN take exisiting solutions or if we NEED > > to design a new one. Clearly for me, to find out this answer is > > 6lowpan's work. > > > > As far as L3 routing is concerned, that task WOULD be the one of the > POTENTIAL > new WG work. Well, those kinds of work can be taken place at the relevant WG in advance. For example, one of MANET WG sessions for this issue. Than, IETF can move it on if we can see any EXPLICIT _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jun 25 01:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2hDx-0005QB-Ss; Mon, 25 Jun 2007 01:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1X9u-0000lo-DQ for rsn@ietf.org; Thu, 21 Jun 2007 20:37:54 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1X9t-0003ic-0Y for rsn@ietf.org; Thu, 21 Jun 2007 20:37:54 -0400 Received: from epmmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JK0001EGHR3SE@mailout1.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 09:37:51 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JK000878HR2P0@mmp2.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 09:37:51 +0900 (KST) Date: Fri, 22 Jun 2007 09:37:36 +0900 From: Daniel Park Subject: RE: [6lowpan] Re: [RSN] The need for RSN In-reply-to: To: 'JP Vasseur' Message-id: <0JK000879HR3P0@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace0YJCl5WE2n68jSyG6XtXY58nnEwABABcw X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Mon, 25 Jun 2007 01:34:52 -0400 Cc: rsn@ietf.org, 6lowpan@lists.ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org > >> It was my understanding that while 6lowpan may consider > "mesh under" > >> alternatives (layer 2 routing), it would rely upon a group > >> like RSN to deal with "route over" (layer 3 routing) and that > >> 6lowpan would provide requirements to RSN. > > > > I don't think so Geoff. Originally, this deliverable was for > > Proposed Standard Document. Are you saying 6lowpan > > mesh-routing requirement might be Proposed Standard ? > > Absolutely, NO. > There is no such deliverables ... I said: 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing protocols for use within 6lowpans. While most routing protocols are defined above the IP layer, 6lowpan requires a mesh routing protocol below the IP layer. "6lowpan Mesh Routing" may be several proposed standard documents. So, are you thinking we need both solutions as layer 2 routing by 6lowpan WG and layer 3 routing by RSN for mesh routing ? Or, 6lowpan only work for RSN requirement ? _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jun 25 01:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2hDy-0005QI-5m; Mon, 25 Jun 2007 01:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ZSn-00072R-GG for rsn@ietf.org; Thu, 21 Jun 2007 23:05:33 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ZSl-0000md-W3 for rsn@ietf.org; Thu, 21 Jun 2007 23:05:33 -0400 Received: from epmmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (buFrom rsn-bounces@ietf.org Mon Jun 25 01:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2hDx-0005QB-Ss; Mon, 25 Jun 2007 01:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1X9u-0000lo-DQ for rsn@ietf.org; Thu, 21 Jun 2007 20:37:54 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1X9t-0003ic-0Y for rsn@ietf.org; Thu, 21 Jun 2007 20:37:54 -0400 Received: from epmmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JK0001EGHR3SE@mailout1.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 09:37:51 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JK000878HR2P0@mmp2.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 09:37:51 +0900 (KST) Date: Fri, 22 Jun 2007 09:37:36 +0900 From: Daniel Park Subject: RE: [6lowpan] Re: [RSN] The need for RSN In-reply-to: To: 'JP Vasseur' Message-id: <0JK000879HR3P0@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace0YJCl5WE2n68jSyG6XtXY58nnEwABABcw X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Mon, 25 Jun 2007 01:34:52 -0400 Cc: rsn@ietf.org, 6lowpan@lists.ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org > >> It was my understanding that while 6lowpan may consider > "mesh under" > >> alternatives (layer 2 routing), it would rely upon a group > >> like RSN to deal with "route over" (layer 3 routing) and that > >> 6lowpan would provide requirements to RSN. > > > > I don't think so Geoff. Originally, this deliverable was for > > Proposed Standard Document. Are you saying 6lowpan > > mesh-routing requirement might be Proposed Standard ? > > Absolutely, NO. > There is no such deliverables ... I said: 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing protocols for use within 6lowpans. While most routing protocols are defined above the IP layer, 6lowpan requires a mesh routing protocol below the IP layer. "6lowpan Mesh Routing" may be several proposed standard documents. So, are you thinking we need both solutions as layer 2 routing by 6lowpan WG and layer 3 routing by RSN for mesh routing ? Or, 6lowpan only work for RSN requirement ? _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jun 25 01:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2hDy-0005QI-5m; Mon, 25 Jun 2007 01:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1ZSn-00072R-GG for rsn@ietf.org; Thu, 21 Jun 2007 23:05:33 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1ZSl-0000md-W3 for rsn@ietf.org; Thu, 21 Jun 2007 23:05:33 -0400 Received: from epmmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JK00017VOL64K@mailout1.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 12:05:30 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JK000F4LOL529@mmp2.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 12:05:30 +0900 (KST) Date: Fri, 22 Jun 2007 12:05:15 +0900 From: Daniel Park Subject: RE: [6lowpan] Re: [RSN] The need for RSN In-reply-to: <1182473381.6218.137.camel@dellx1> To: 'Geoff Mulligan' Message-id: <0JK000F4NOL629@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace0Zz2Dds7YugYMR9K0PeleWhhZbgAEXExQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-Mailman-Approved-At: Mon, 25 Jun 2007 01:34:52 -0400 Cc: rsn@ietf.org, 6lowpan@lists.ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Geoff, Clarification to me. L2 mesh routing is made by 6lowpan taking 802.15.5 into consideration, and L3 mesh routing is perhaps made by another WG regardless of MANET WG deliverables such as DYMO/AODV based on 6lowpan L3 mesh routing requirement. -- Daniel Park > -----Original Message----- > From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org] > Sent: Friday, June 22, 2007 9:50 AM > To: Daniel Park > Cc: 'JP Vasseur'; 'Eunsook "Eunah" Kim'; > 6lowpan@lists.ietf.org; rsn@ietf.org; > g_e_montenegro@yahoo.com; 'Mark Townsley' > Subject: RE: [6lowpan] Re: [RSN] The need for RSN > > Daniel, > I still don't understand your question. Do you not think > that 6lowpan > should generate a PS document on L2 routing? This has been in the > re-charter proposal for months. > > I think that there may be networks that will not use L2 mesh and will > instead opt for L3 routing. There might well be other networks that > will use L3 routing between L2 mesh networks. > > geoff > > On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: > > > >> It was my understanding that while 6lowpan may consider > > > "mesh under" > > > >> alternatives (layer 2 routing), it would rely upon a group > > > >> like RSN to deal with "route over" (layer 3 routing) and that > > > >> 6lowpan would provide requirements to RSN. > > > > > > > > I don't think so Geoff. Originally, this deliverable was for > > > > Proposed Standard Document. Are you saying 6lowpan > > > > mesh-routing requirement might be Proposed Standard ? > > > > Absolutely, NO. > > > There is no such deliverables ... > > > > I said: > > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing > > protocols for use within 6lowpans. While most routing protocols are > > defined above the IP layer, 6lowpan requires a mesh routing protocol > > below the IP layer. "6lowpan Mesh Routing" may be several proposed > > standard documents. > > > > So, are you thinking we need both solutions as layer 2 routing > > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? > > Or, 6lowpan only work for RSN requirement ? > > > > > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn ilt Jul 14 2004)) with ESMTP id <0JK00017VOL64K@mailout1.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 12:05:30 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JK000F4LOL529@mmp2.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 12:05:30 +0900 (KST) Date: Fri, 22 Jun 2007 12:05:15 +0900 From: Daniel Park Subject: RE: [6lowpan] Re: [RSN] The need for RSN In-reply-to: <1182473381.6218.137.camel@dellx1> To: 'Geoff Mulligan' Message-id: <0JK000F4NOL629@mmp2.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace0Zz2Dds7YugYMR9K0PeleWhhZbgAEXExQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-Mailman-Approved-At: Mon, 25 Jun 2007 01:34:52 -0400 Cc: rsn@ietf.org, 6lowpan@lists.ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org Geoff, Clarification to me. L2 mesh routing is made by 6lowpan taking 802.15.5 into consideration, and L3 mesh routing is perhaps made by another WG regardless of MANET WG deliverables such as DYMO/AODV based on 6lowpan L3 mesh routing requirement. -- Daniel Park > -----Original Message----- > From: Geoff Mulligan [mailto:geoff-ietf@mulligan.org] > Sent: Friday, June 22, 2007 9:50 AM > To: Daniel Park > Cc: 'JP Vasseur'; 'Eunsook "Eunah" Kim'; > 6lowpan@lists.ietf.org; rsn@ietf.org; > g_e_montenegro@yahoo.com; 'Mark Townsley' > Subject: RE: [6lowpan] Re: [RSN] The need for RSN > > Daniel, > I still don't understand your question. Do you not think > that 6lowpan > should generate a PS document on L2 routing? This has been in the > re-charter proposal for months. > > I think that there may be networks that will not use L2 mesh and will > instead opt for L3 routing. There might well be other networks that > will use L3 routing between L2 mesh networks. > > geoff > > On Fri, 2007-06-22 at 09:37 +0900, Daniel Park wrote: > > > >> It was my understanding that while 6lowpan may consider > > > "mesh under" > > > >> alternatives (layer 2 routing), it would rely upon a group > > > >> like RSN to deal with "route over" (layer 3 routing) and that > > > >> 6lowpan would provide requirements to RSN. > > > > > > > > I don't think so Geoff. Originally, this deliverable was for > > > > Proposed Standard Document. Are you saying 6lowpan > > > > mesh-routing requirement might be Proposed Standard ? > > > > Absolutely, NO. > > > There is no such deliverables ... > > > > I said: > > 4. Produce "6lowpan Mesh Routing" to evaluate different mesh routing > > protocols for use within 6lowpans. While most routing protocols are > > defined above the IP layer, 6lowpan requires a mesh routing protocol > > below the IP layer. "6lowpan Mesh Routing" may be several proposed > > standard documents. > > > > So, are you thinking we need both solutions as layer 2 routing > > by 6lowpan WG and layer 3 routing by RSN for mesh routing ? > > Or, 6lowpan only work for RSN requirement ? > > > > > _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Mon Jun 25 01:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2hDx-0005Q3-Og; Mon, 25 Jun 2007 01:34:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Vk3-00020L-6Y for rsn@ietf.org; Thu, 21 Jun 2007 19:07:07 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Vk1-0002sD-0w for rsn@ietf.org; Thu, 21 Jun 2007 19:07:07 -0400 Received: from epmmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JK000G7CDJRBC@mailout3.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 08:07:03 +0900 (KST) Received: from daniel ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0JK000KRADJRJV@mmp1.samsung.com> for rsn@ietf.org; Fri, 22 Jun 2007 08:07:03 +0900 (KST) Date: Fri, 22 Jun 2007 08:06:48 +0900 From: Daniel Park Subject: RE: [6lowpan] Re: [RSN] The need for RSN In-reply-to: <1182290840.6218.32.camel@dellx1> To: 'Geoff Mulligan' , "'Eunsook \"Eunah\" Kim'" Message-id: <0JK000KRBDJRJV@mmp1.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcezQ9dR/IvB/xJERtGPx4Iv+S+K3QBFBNbQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 25 Jun 2007 01:34:52 -0400 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rsn-bounces@ietf.org > It was my understanding that while 6lowpan may consider "mesh under" > alternatives (layer 2 routing), it would rely upon a group > like RSN to deal with "route over" (layer 3 routing) and that > 6lowpan would provide requirements to RSN. I don't think so Geoff. Originally, this deliverable was for Proposed Standard Document. Are you saying 6lowpan mesh-routing requirement might be Proposed Standard ? Absolutely, NO. I don't care if you as chair are leaning to RSN for this matter based on AD's agreement, but just wanted to clarify your mis-interpretation from 6lowpan perspevtive. Also, IEEE 802.15.5 is already developing L2 mesh routing for IEEE 802.15.4. What alternative means in your mention ? -- Daniel Park _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn From rsn-bounces@ietf.org Tue Jun 26 13:48:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3F9K-00034r-4G; Tue, 26 Jun 2007 13:48:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3F9J-00034m-Ar for rsn@ietf.org; Tue, 26 Jun 2007 13:48:21 -0400 Received: from web81903.mail.mud.yahoo.com ([68.142.207.182]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3F8W-00086F-1o for rsn@ietf.org; Tue, 26 Jun 2007 13:48:21 -0400 Received: (qmail 51664 invoked by uid 60001); 26 Jun 2007 17:47:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=BRZIjBiNRb8OgIrSniWAc3wT5YE57CTW2pZYEegegSEMvgex0sfZM90XaBnvl04Qa81+hKta8xKP3Qf3STbW1rqCwvVxDvApzwynybF9jtnoy1qQ5MfFql8q1xI2QNq6DLwC+E9yRvYR527tx/xPY8mVrziqEtf8r/SLtO6JkUI=; X-YMail-OSG: 7aJ_wtkVM1n5NVRsgkqsVEdBCYsY3po5XhJi1ot35unGysDoE_huxzXJNYGbaJeZVOOwBLoPcEAYH3T8MyLmN8HuNVnF5KBWAIvPtN5I9renPeim3HM- Received: from [131.107.0.71] by web81903.mail.mud.yahoo.com via HTTP; Tue, 26 Jun 2007 10:47:31 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Tue, 26 Jun 2007 10:47:31 -0700 (PDT) From: g_e_montenegro@yahoo.com Subject: Re: [RSN] The need for RSN To: "Charles E. Perkins" MIME-Version: 1.0 Message-ID: <443744.51616.qm@web81903.mail.mud.yahoo.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: rsn@ietf.org X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0554662179==" Errors-To: rsn-bounces@ietf.org --===============0554662179== Content-Type: multipart/alternative; boundary="0-477594665-1182880051=:51616" --0-477594665-1182880051=:51616 Content-Type: text/plain; charset=ascii I did get it the first time, not sure why the messages appear as bouncing. At any rate, I thought initially your question was rhetorical, I guess it isn't. The "of course" refers to the fact that any layer 3 protocol works on layer 3 identifiers (IPv4 and IPv6 addresses). Before one can use that at a different layer, there is the adaptation work of at least, (1) a slight modification to make it work on identifiers relevant at that layer. In the 6lowpan case, those identifiers are either 16 or 64 bit MAC addresses. There may be (2) other adaptations or simplifications that may make sense in order to make packets smaller, reduce options, etc. I refer you to the individual submissions in 6lowpan. In the case of MANET protocols, both 1 and 2 may be in order. If RSN does things correctly, perhaps only #1 will be necessary for RSN protocols to be usable in 6lowpan. Either way, the bulk of the work, the path computation algorithms, the neighbor list maintenance procedures, etc, would be done in those groups within the routing area. Hope this is clear. -gabriel ----- Original Message ---- From: Charles E. Perkins To: Gabriel.Montenegro@microsoft.com Cc: rsn@ietf.org Sent: Friday, June 15, 2007 6:35:29 PM Subject: Re: [RSN] The need for RSN Hello Gabriel, ext rsn-bounces@ietf.org wrote: > We've been primarily assuming we'd be adapting protocols from MANET, > and there are individual > submissions already on AODV, DyMO as well as non-IETF protocols (e.g., > HILO). We've also > been assured by MANET chairs (i.e., Ian) that they will heed our > requirements and make sure > their protocols also work for us. Of course, their protocols will > never work "as is". We have to > adapt them to work under IP, instead of over IP as assumed by MANET. Of course, I have hoped that the "Of course" in your paragraph is not so self-evident. Is there really no hope? [PS. Your mail to the mailing list shows as bouncing?] > > As I understand it, RSN operates at layer 3, and it is arguing that > there is room for another multi-hop routing WG in the > routing area. Perhaps MANET can't really satisfy requirements for > wireless sensors. Whether this is solved by > integrating the RSN charter/deliverables into a re-chartered MANET, > or by starting a new WG, > from 6lowpan's point of view, 6lowpan can benefit from the resultant > protocols. I think it is more likely that [rsn] can be viewed as a spin-off from [manet], in much the same way that [mipshop] and others were spun off from the old [mobileip] group. In fact, I think the argument for [rsn] is much stronger than the argument for [mipshop] because [rsn] has a clear need for looking at: - compression, - power-saving techniques, - new extensions to DYMO or whatever, - new/better metrics, - clustering - multicast - perhaps also geographic routing techniques. > Of course, adaptation from layer 3 to sub-IP operation will be > required, along the lines of the > existing independent submissions in 6lowpan. There's that "Of course" again :-) Regards, Charlie P. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --0-477594665-1182880051=:51616 Content-Type: text/html; charset=ascii
I did get it the first time, not sure why the messages appear as bouncing.

At any rate, I thought initially your question was rhetorical, I guess it isn't.

The "of course" refers to the fact that
any layer 3 protocol works on layer 3 identifiers (IPv4 and IPv6 addresses). Before one can use that
at a different layer, there is the adaptation work of at least, (1) a slight modification to make it work on
identifiers relevant at that layer. In the 6lowpan case, those identifiers are either 16 or 64 bit MAC
addresses. There may be (2) other adaptations or simplifications that may make sense in order to
make packets smaller, reduce options, etc. I refer you to the individual submissions in 6lowpan.

In the case of MANET protocols, both 1 and 2 may be
in order. If RSN does things correctly, perhaps only #1 will be necessary for RSN protocols to
be usable in 6lowpan. Either way, the bulk of the work, the path computation algorithms, the
neighbor list maintenance procedures, etc, would be done in those groups within the routing area.

Hope this is clear.

-gabriel

----- Original Message ----
From: Charles E. Perkins <charles.perkins@nokia.com>
To: Gabriel.Montenegro@microsoft.com
Cc: rsn@ietf.org
Sent: Friday, June 15, 2007 6:35:29 PM
Subject: Re: [RSN] The need for RSN


Hello Gabriel,

ext rsn-bounces@ietf.org wrote:
> We've been primarily assuming we'd be adapting protocols from MANET,
> and there are individual
> submissions already on AODV, DyMO as well as non-IETF protocols (e.g.,
> HILO). We've also
> been assured by MANET chairs (i.e., Ian) that they will heed our
> requirements and make sure
> their protocols also work for us. Of course, their protocols will
> never work "as is". We have to
> adapt them to work under IP, instead of over IP as assumed by MANET.
Of course, I have hoped that the "Of course" in your paragraph
is not so self-evident.  Is there really no hope?
[PS. Your mail to the mailing list shows as bouncing?]
>
> As I understand it, RSN operates at layer 3, and it is arguing that
> there is room for another multi-hop routing WG in the
> routing area. Perhaps MANET can't really satisfy requirements for
> wireless sensors. Whether this is solved by
> integrating the RSN charter/deliverables into a re-chartered MANET,
> or  by starting a new WG,
> from 6lowpan's point of view, 6lowpan can benefit from the resultant
> protocols.
I think it is more likely that [rsn] can be viewed as a spin-off from
[manet],
in much the same way that [mipshop] and others were spun off from the
old [mobileip] group.  In fact, I think the argument for [rsn] is much
stronger
than the argument for [mipshop] because [rsn] has a clear need for
looking at:
- compression,
- power-saving techniques,
- new extensions to DYMO or whatever,
- new/better metrics,
- clustering
- multicast
- perhaps also geographic routing techniques.
> Of course, adaptation from layer 3 to sub-IP operation will be
> required, along the lines of the
> existing independent submissions in 6lowpan.
There's that "Of course" again :-)

Regards,
Charlie P.


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

--0-477594665-1182880051=:51616-- --===============0554662179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0554662179==-- From rsn-bounces@ietf.org Tue Jun 26 13:57:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3FIX-0003ho-0j; Tue, 26 Jun 2007 13:57:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3FIV-0003he-Fd for rsn@ietf.org; Tue, 26 Jun 2007 13:57:51 -0400 Received: from web81913.mail.mud.yahoo.com ([68.142.207.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3FHo-000197-MM for rsn@ietf.org; Tue, 26 Jun 2007 13:57:51 -0400 Received: (qmail 33816 invoked by uid 60001); 26 Jun 2007 17:57:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=J4A7fXnCatdGHCjwMAmDy2xWY7uEhH7pTCiIHS9OePekHaWi9X9qJgSoLgMgB9hWTi16JrKPO+DlVmBbOso7jVMFTqm8vBJ0heQuPQkRUJeK0Eh4ri2RGQaxiUYTJkCuwBu/Xaq2WOMP5V91i/O2eESDfAkIqVdvUdLwKTXtLPI=; X-YMail-OSG: ZVD9fpwVM1nKst_xQsp1RgbjzYCsP3AOSZQyjPLqhjWi1wPNEVil7e8ES832hw0MzufT5dWd5py.u77CY0As7L2v7hUMcEdeAjTz9XTXVhuTecI- Received: from [131.107.0.71] by web81913.mail.mud.yahoo.com via HTTP; Tue, 26 Jun 2007 10:57:08 PDT X-Mailer: YahooMailRC/651.29 YahooMailWebService/0.7.41.16 Date: Tue, 26 Jun 2007 10:57:07 -0700 (PDT) From: g_e_montenegro@yahoo.com Subject: Re: [RSN] L3 mesh requirements To: "Charles E. Perkins" , "ext Pascal Thubert \(pthubert\)" MIME-Version: 1.0 Message-ID: <162713.33568.qm@web81913.mail.mud.yahoo.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: rsn@ietf.org, manemo@mobileip.jp X-BeenThere: rsn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Sensor Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0810094970==" Errors-To: rsn-bounces@ietf.org --===============0810094970== Content-Type: multipart/alternative; boundary="0-720174780-1182880627=:33568" --0-720174780-1182880627=:33568 Content-Type: text/plain; charset=ascii Quick comment on something you said, Charlie: Is [rsn] going to tackle compression? That would be a great area for development, and I don't think any other group even has it in their sights. Unfortunately, it seems to attract controversy over patent rights. FYI, 6lowpan does have provisions for simple header compression in the mesh: http://tools.ietf.org/html/draft-ietf-6lowpan-format-13#section-10 -gabriel ----- Original Message ---- From: Charles E. Perkins To: ext Pascal Thubert (pthubert) Cc: rsn@ietf.org; manemo@mobileip.jp Sent: Friday, June 15, 2007 6:13:49 PM Subject: Re: [RSN] L3 mesh requirements Hello Pascal, A few comments -- please excuse if I missed the relevant discussion since I am far behind on [rsn] and not even on the [manemo] mailing list at all. ext Pascal Thubert (pthubert) wrote: > R1) A mesh network is a radio network connected to an infrastructure > such as the Internet, and aimed at providing Routability between mesh > nodes and that infrastructure, back and forth and at most times; still, > the mesh should be able to operate for local communications when > disconnected from the infrastructure. > I don't think a mesh has to be connected to the Internet. Instead, as you mention, the mesh can work well as a self-contained network, and yet offer Internet connectivity whenever it is available. This may be viewed as intermittent or perhaps even seldom. So, I would not want to say that the mesh has to be "aimed at providing Routability between mesh nodes and that infrastructure". > R2) Mesh nodes are not all equal. There are wired sinks which connect to > the infrastructure, fully functional devices (FFD), and reduced > functional devices (RFD). RFD are characterized by severely limited CPU, > memory and battery capacity; they should not be involved in routing and > forwarding but to the bare minimum. This can be done if the metric is appropriate and the measurements are done properly. So, for instance, a node could indicate that it is unwilling to route, but able to do so in a pinch. > Because radio and battery are > limited resources everywhere, the amount of control messages should be > reduced to a minimum and optimized by compression, piggy backing etc... > Is [rsn] going to tackle compression? That would be a great area for development, and I don't think any other group even has it in their sights. Unfortunately, it seems to attract controversy over patent rights. > R3) The most common use case is to connect mesh nodes with middleware, > applications servers and peer nodes located over the infrastructure, via > mesh sinks. I am puzzling over the actual content of this sentence. It seems to apply to every network in the Internet, if we consider a host to be a "sensor". > Routing should proactively maintain the path between the > mesh nodes and the sinks, back and forth. Doesn't this remain to be seen? What about mesh nodes that are tired and want to sleep? > It should be possible to avoid > incremental cost linked to routing to other destinations. Also, the mesh > protocol should be compatible with NEMO and enable mobile nodes to > attach to their Home Agents over the mesh without the need of an > additional MANET protocol. > Check. Except, that we might want to fiddle with the Agent Advertisements. > R4) ... The mesh routing protocol should be interoperable with the > standard MANET routing protocols in terms of external routes > redistributions and so on, but should not depend on a specific instance > of a MANET protocol being deployed. > This is debatable. Especially, if it turns out that a "standard" MANET protocol (hmm... two should be here this year, we think) can be engineered into a good choice for mesh routing. > R6) Peer selection and routing occur with the objective to reach a sink; > this is based on Layer 3 information (peer type, reachability, path > metrics to the sink...) as well as Layer 2 information (RSSI to peer, > bandwidth, etc...). Because a scanning process might be involved at > layer 2 to sustain the peer selection mechanism, it is desirable that > the initial peer list be established in pure listening (monitor) mode. > What if two non-sensors, that are currently deployed in the field, want to use the sensor mesh to communicate with each other? Surely you would not like to burden the mesh with a whole new set of protocols just because a couple of people happened to want to make use of it while they are in the area... Or, did you want the sinks to be required intermediate nodes in every peer-to-peer communications? That could make connectivity even more expensive in a lot of cases. Regards, Charlie P. _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --0-720174780-1182880627=:33568 Content-Type: text/html; charset=ascii
Quick comment on something you said, Charlie:

Is [rsn] going to tackle compression?  That would be a great
area for development, and I don't think any other group even
has it in their sights.  Unfortunately, it seems to attract
controversy over patent rights.

FYI, 6lowpan does have provisions for simple header compression in the mesh:

       http://tools.ietf.org/html/draft-ietf-6lowpan-format-13#section-10

-gabriel

----- Original Message ----
From: Charles E. Perkins <charles.perkins@nokia.com>
To: ext Pascal Thubert (pthubert) <pthubert@cisco.com>
Cc: rsn@ietf.org; manemo@mobileip.jp
Sent: Friday, June 15, 2007 6:13:49 PM
Subject: Re: [RSN] L3 mesh requirements


Hello Pascal,

A few comments -- please excuse if I missed the relevant
discussion since I am far behind on [rsn] and not even on the
[manemo] mailing list at all.

ext Pascal Thubert (pthubert) wrote:
> R1) A mesh network is a radio network connected to an infrastructure
> such as the Internet, and aimed at providing Routability between mesh
> nodes and that infrastructure, back and forth and at most times; still,
> the mesh should be able to operate for local communications when
> disconnected from the infrastructure.
>  
I don't think a mesh has to be connected to the Internet.  Instead, as you
mention, the mesh can work well as a self-contained network, and yet offer
Internet connectivity whenever it is available.  This may be viewed as
intermittent or perhaps even seldom.  So, I would not want to say that
the mesh has to be "aimed at providing Routability between mesh
nodes and that infrastructure".

> R2) Mesh nodes are not all equal. There are wired sinks which connect to
> the infrastructure, fully functional devices (FFD), and reduced
> functional devices (RFD). RFD are characterized by severely limited CPU,
> memory and battery capacity; they should not be involved in routing and
> forwarding but to the bare minimum.

This can be done if the metric is appropriate and the measurements are
done properly.  So, for instance, a node could indicate that it is unwilling
to route, but able to do so in a pinch.

>  Because radio and battery are
> limited resources everywhere, the amount of control messages should be
> reduced to a minimum and optimized by compression, piggy backing etc...
>  

Is [rsn] going to tackle compression?  That would be a great
area for development, and I don't think any other group even
has it in their sights.  Unfortunately, it seems to attract
controversy over patent rights.

> R3) The most common use case is to connect mesh nodes with middleware,
> applications servers and peer nodes located over the infrastructure, via
> mesh sinks.

I am puzzling over the actual content of this sentence.  It seems to apply
to every network in the Internet, if we consider a host to be a "sensor".

>  Routing should proactively maintain the path between the
> mesh nodes and the sinks, back and forth.

Doesn't this remain to be seen?  What about mesh nodes that are
tired and want to sleep?

>  It should be possible to avoid
> incremental cost linked to routing to other destinations. Also, the mesh
> protocol should be compatible with NEMO and enable mobile nodes to
> attach to their Home Agents over the mesh without the need of an
> additional MANET protocol.
>  

Check.  Except, that we might want to fiddle with the Agent Advertisements.

> R4) ... The mesh routing protocol should be interoperable with the
> standard MANET routing protocols in terms of external routes
> redistributions and so on, but should not depend on a specific instance
> of a MANET protocol being deployed.
>  

This is debatable.  Especially, if it turns out that a "standard" MANET
protocol
(hmm... two should be here this year, we think) can be engineered into a
good
choice for mesh routing.

> R6) Peer selection and routing occur with the objective to reach a sink;
> this is based on Layer 3 information (peer type, reachability, path
> metrics to the sink...) as well as Layer 2 information (RSSI to peer,
> bandwidth, etc...). Because a scanning process might be involved at
> layer 2 to sustain the peer selection mechanism, it is desirable that
> the initial peer list be established in pure listening (monitor) mode.
>  

What if two non-sensors, that are currently deployed in the field, want to
use the sensor mesh to communicate with each other?  Surely you would
not like to burden the mesh with a whole new set of protocols just because
a couple of people happened to want to make use of it while they are
in the area...  Or, did you want the sinks to be required intermediate nodes
in every peer-to-peer communications?  That could make connectivity even
more expensive in a lot of cases.

Regards,
Charlie P.




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

--0-720174780-1182880627=:33568-- --===============0810094970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RSN mailing list RSN@ietf.org https://www1.ietf.org/mailman/listinfo/rsn --===============0810094970==--