From 6lowpan-bounces@ietf.org Fri Aug 10 13:47:23 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYa1-00050z-R9; Fri, 10 Aug 2007 13:47:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYa0-0004yP-Ck for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 13:47:20 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYZz-0003OJ-2n for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 13:47:20 -0400 Received: from [192.168.1.211] (66.237.74.130.ptr.us.xo.net [66.237.74.130]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l7AHlCD4016830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2007 10:47:13 -0700 (PDT) Message-ID: <46BCA49F.2060304@eecs.berkeley.edu> Date: Fri, 10 Aug 2007 10:47:11 -0700 From: Kris Pister User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: JP Vasseur References: <20070725155919.9D8316E39@mail2.nict.go.jp> <15EE681D-EC8A-4EBB-8189-E7B5A89A289B@cisco.com> In-Reply-To: <15EE681D-EC8A-4EBB-8189-E7B5A89A289B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org Subject: [6lowpan] Re: [RSN] Re: Routing in L2N presentation file X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org JP - great presentation. I hope that it was well received. I'm very supportive of everything in that document, with one exception. There is one assumption that I believe is potentially fatal to the entire 6lowpan/rsn effort in ietf. On slide 11 you state "Research has focused on near-optimal solutions to specific problems", and then in bold "IP is maximizing interoperability, not aiming at finding a local optimum ;-)". I agree with the second statement, but the first one is flat out wrong. Very few people in sensor network research seem to care about near-optimal solutions. Consider one of the best-received papers [Kim07] at the recent IPSN conference. Note that the authors are leaders in the field, this is a respected conference, one of the better papers, and this is the dissertation work culminating four years of research on this project. The paper presents the best academic work to date on reliable multi-hop data collection, MP2P. The payload goodput in this network was 1.4% of the channel bandwidth, at 100% radio duty cycle. This is not "near-optimal" in any sense that I know. If we start with 1.4%, and then degrade that so that we can maximize interoperability, we'll be left with something that no one will use. We have an opportunity to do this right - let's not fall victim to the Zigbee-esque assumption that all we need to do is define *something* and adoption will be automatic. ksjp [Kim07] Kim, Pakzad, Culler, Demmel, Fenves, Glaser, Turon, "Health Monitoring of Civil Infrastructures Using Wireless Sensor Networks", IPSN07. JP Vasseur wrote: > Hi Ved, > > On Jul 25, 2007, at 10:59 AM, Ved Kafle wrote: > >> Hi JP, >> >> Is it possible to get the presentation file you used in the routing area >> meeting? >> I could find it on the web. >> > > I was about to do so, here it is: > We'll soon have a Web Page to point to for RSN related work. > > Thanks. > > JP. > >> Ved Kafle > ------------------------------------------------------------------------ > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Aug 10 13:50:33 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYd6-0001Nx-BL; Fri, 10 Aug 2007 13:50:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYd4-0001MM-TU for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 13:50:30 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYd3-0003TK-HV for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 13:50:30 -0400 Received: from [192.168.1.211] (66.237.74.130.ptr.us.xo.net [66.237.74.130]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l7AHoIHM016870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2007 10:50:27 -0700 (PDT) Message-ID: <46BCA55A.9010303@eecs.berkeley.edu> Date: Fri, 10 Aug 2007 10:50:18 -0700 From: Kris Pister User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Geoff Mulligan References: <20070718135323.587AA1DDC3B9@secure.archedrock.com> <1184781809.28557.35.camel@dellx1> In-Reply-To: <1184781809.28557.35.camel@dellx1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae Cc: '6lowpan' <6lowpan@lists.ietf.org>, rsn@ietf.org Subject: [6lowpan] Re: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Geoff - what would you call the 802.11s approach? Is that mesh under or router over, or something in between? David - >> In the vast majority of wireless sensor networks in existance the >> dominant communication pattern is data collection (from nodes in the >> PAN to IP-based computers external to the PAN) I'm curious what data you have to support this assertion. While I do believe that this may happen at some point in the future, I don't think that it's true today except in academic deployments. Data collection yes, but not to IP-based computers. When I look for commercial deployments in production, I see Eaton (Home Heartbeat) and Control 4 in home automation, and Emerson (Smart Wireless) in industrial. Very few if any of these systems are hooked up to IP-based computers. >> History suggests that once IP routing is available for a particular >> kind of link, sub-IP routing tends to dissappear. I don't know this history as well as you do, but I'm willing to bet that IP routing only gets successfully adopted on top of link technologies that actually work. My concern with this group is that it seems to be based on the premise that the only reason why WSN isn't taking off quickly is that we haven't had IP addresses for our motes yet. Do we really believe that Zigbee has had zero traction because it's not IP? Do we really believe that there are no real TinyOS products because it's not IP? Because that's not what customers and end users tell me. They say that those technologies simply don't satisfy their requirements (typically reliability and power). I'm looking forward to a world with IP-based motes and wsn routing. But I don't think that it's going to happen unless we acknowledge that our success depends on more than just defining the right header compression and routing protocols. We are intimately tied to L2 protocols in this space, and everyone to date who has ignored that has failed. ksjp Prof. EECS, UC Berkeley Founder & CTO, Dust Networks Geoff Mulligan wrote: > Very interesting and provocative question you pose at the end of your > message - "do we need mesh under?" I think and hope that this will > generate some discussion on the list. > > I suspect that there are people on the list that will argue that mesh > under is fact (it is deployed today) and that of course we need mesh > under and will use standard layer 3 routing between 6lowpan subnets. > Currently this is the thinking within SP100 for industrial wireless. > > 802.15.5 is certainly looking at and, I think, plans to standardize on a > two different mesh under designs/protocols. > > Utilizing trill is an interesting thought. I don't yet know enough > about trill to comment on it's applicability. > > Certainly the manet protocols might be applicable. > > What is critical to this discussion is that if 6lowpan does not select > or generate a mesh under protocol (if one is necessary and used) then > there will not be interoperability between multi-hoping nodes. If > mesh-under is not used (but router over is used for multi-hopping) then > all 6lowpan nodes can exchange packets and forward packets (but we need > to understand the implications of one node per subnet). > > geoff > > On Wed, 2007-07-18 at 06:53 -0700, dculler wrote: > >> The argument for route-over is pretty simple. >> >> 1. In the vast majority of wireless sensor networks in existance the >> dominant communication pattern is data collection (from nodes in the >> PAN to IP-based computers external to the PAN) and control actions >> (from controllers external to the PAN to devices within the PAN). >> There are cases where data collection point and/or the controller is a >> gateway device on the PAN, but this physical collocation is rather >> artificial. If is far more typical that where a gateway is deployed >> it is used to bridge communication to other networks. >> >> This is true not only for wireless instrumentation, but wired >> instrumentation as well. See for example >> >> BACNET: http://www.bacnet.org/Tutorial/HMN-Overview/sld028.htm and >> http://www.bacnet.org/Tutorial/HMN-Overview/sld029.htm >> >> and >> >> HART: >> http://www.hartcomm2.org/hart_protocol/tech_info/eval_networks/compnet.html >> >> and Wireless HART >> >> http://www.hartcomm2.org/hart_protocol/wireless_hart/architecture.html >> >> Routing onto or off the PAN utilizes a routable IP address for the >> device within the PAN. It is important for this address to be >> compressible, just as when both endpoints are within the PAN. No >> matter how effective is the L2 mesh routing within the PAN, you still >> need to deal with IP routing off the PAN. This is, of course, the >> purpose of IP routing. Whatever mesh-under is done, there will also >> be route-over. The mesh-under path is, at least, one of the >> route-over hops. Possibly more of the IP hops may occur over 802.15.4 >> links. >> >> 2. It is very common that devices route between distinct networks that >> use the same media, ie. distinct Ethernet subnets or distinct WiFi >> subnets. This will happen in 802.15.4 networks where the networks use >> the same physical link, but different PAN_IDs, different channels (or >> different sets of channels or different channel schedules), different >> MAC layers, etc. Even different meshing protocols. They will be >> stiched together by IP routing. >> >> 3. The Mesh-under protocol is currently undefined. 6lowpan is >> sufficient to describe single hop communication. It also identifies >> the endpoints (original and final) of multihop mesh-routed >> communication, but it does not define how the intervening hops are >> determined or what information is exchanged to establish >> routes. Clearly it anticipates that such L2 protocols will be >> developed and standardized. However, if a single 802.15.4 hop is >> performed per IP hop, any L3 routing algorithm can be used to set up >> the routing tables and forwarding occurs according to the routing >> tables. (Worst come to worst, you can hammer the tables in place by >> external means.) If mesh routing does become defined, IP routing can >> be applied per L2 mesh path. Thus, IP routing applies whether or not >> mesh routing is defined. All of the IP visibility and management >> tools apply to the IP hops. None of them apply to the mesh hops >> within an IP hop. >> >> 4. Many IP routing protocols are defined and a diversity of protocols >> has become the norm. One of the key elements of IP is that it >> separates routing from forwarding. We tolerate the use of different >> routing protocols in different settings. These protocols set up the >> tables and forwarding works across them. We have had multiple >> competing routing protocols apply to the same setting (e.g., RIP vs >> OSPF in the campus area) and their relative strengths have become >> clear over time. >> >> This has not been the case with link-level "meshing"; so far it has >> been approached as a winner-take-all and unfortunately this means that >> everybody must agree on the protocol before they have much experience >> with the use of the protocol. For example, in Zigbee we have seen >> that after several years of development, but no broad usage, Zigbee >> 1.0 is obsoleted in favor of Zigbee 2006, which is incompatible and >> also incompatible with Zigbee 2007, which is not yet fully defined. >> We have seen numerous proprietary protocols, proprietary extensions to >> standard protocols, and open research protocols for meshing that are >> all incompatible. In some cases they optimize for different aspects, >> in some cases they integrate aspects of all layers of the stack. In >> any case, they don't play well together. So, one of the key virtues of >> route-over is that we have an established framework and long history >> of stiching together a variety of routing protocols to establish the >> tables such that forwarding works across them and where we can gain >> experience over time. Call it "rough consensus and running code". >> >> One might argue these aspects are sociological, rather than technical. >> Well, the separation of topology formation, path selection, and route >> table maintainance from forwarding is awfully important. So are the >> vast set of tools to gain visibility into IP routing. At the very >> least, source routing, exploration, etc. will need to be developed for >> the PAN for mesh-under to mature. It is an interesting question >> whether you need to be within the PAN to utilize the equivalent of >> traceroute. >> >> 5. History suggests that once IP routing is available for a particular >> kind of link, sub-IP routing tends to dissappear. Remember x.25 and >> frame relay. Of course, we do some form of "mesh" routing in switched >> ethernets and mesh wifi, but generally it is transparent. The link >> looks like the unswitched counterpart. >> >> So I think it is very clear that IP routing will occur over IEEE >> 802.15.4 links. It is already there. For every single hop 15.4 >> network it is done. For deeper networks, there are many ways to set >> up the tables. >> >> So route-over is a fact. The question should be "Do you need >> mesh-under in addition to route-over?" Why? >> >> >> >> ______________________________________________________________ >> From: JP Vasseur [mailto:jvasseur@cisco.com] >> Sent: Tuesday, July 17, 2007 4:28 PM >> To: Dominik Kaspar >> Cc: 6lowpan; rsn@ietf.org >> Subject: [RSN] Comments on draft-dokaspar-6lowpan-routreq-02 >> >> >> >> Dear Coauthors, >> >> >> Few Comments on draft-dokaspar-6lowpan-routreq-02. >> >> >> First of all, I think that we will need to have that debate on >> whether we indeed need both a "Mesh-under" and a "Route over" >> solutions. If the answer turns out to be "yes, we need both" I >> would volunteer to write the ID capturing the pros and >> cons ... >> >> >> In the meantime, here are a few comments: >> >> >> 1) I would suggest to use a consistent terminology for the >> "Mesh-under" routing. Not trying to quibble on the terminology >> here but this is quite important to avoid confusion with the >> RSN initiative. "Lowpan mesh routing" looks more like Route >> over. >> >> >> 2) Section 2 >> >> >> These fundamental features of LoWPANs can affect the design of >> routing solutions, so that existing routing specifications >> should be >> simplified and modified to the smallest extent possible, in >> order to >> fit the low-power requirements of LoWPANs. >> >> >> >> >> We had that discussion before ... Yes, if one can find an >> existing protocol that meets >> the requirement and that can be adapted, then great. But >> whether any of the current >> protocols can be adapted to meet these requirements is not a >> given. >> >> >> 3) Section 2 >> >> >> In order to find energy-optimal routing paths, LoWPAN mesh >> routing >> protocols should minimize power consumption by utilizing a >> combination of the link quality indication (LQI) provided by >> the MAC >> layer and other measures, such as hop count. Route repair and >> route >> error messages should be avoided for minimizing the overall >> number of >> control messages and the required energy for sending them. >> >> >> Two comments: >> * This is a difference with Route-over where we will define IP >> metric to reflect >> the link characteristics to be used by the routing engine but >> we do want to >> remain layer 2 agnostic, thus the need for a minimal >> abstraction layer. >> * Should we avoid "Route Repair" ? mmm ... I'm not so sure >> since there are >> applications that require fast rerouting to forward sensitive >> data. A cheap >> alternative is to compute disjoint paths but this comes at the >> path quality >> cost. >> >> >> 3) Section 3 >> >> >> Transparent IP routing between LoWPAN domains and higher layer >> networks must be provided bidirectionally. A LoWPAN mesh >> routing >> protocol must allow for gateways to forward packets out of the >> local >> domain and it must be possible to query a LoWPAN device from >> outside >> of the local domain. Strategies must be considered to avoid >> battery >> depletion of nodes by too many queries from higher level >> networks. >> End-to-end communication is not a design goal of LoWPAN. >> >> >> This is one on my main motivations of a Route-over strategy. >> >> >> 4) Section 3.2 >> >> >> Because network layer routing imposes too much overhead for >> LoWPANs >> >> >> JP> Which Routing protocol ? >> >> >> and link layer techniques are out of scope of IETF, LoWPAN >> mesh >> routing should be performed within the adaptation layer >> defined in >> [3]. Both addressing modes provided by the IEEE 802.15.4 >> standard, >> 16-bit short addresses and 64-bit extended addresses, must be >> considered by LoWPAN mesh routing protocols. It is also >> assumed that >> nodes participating in LoWPAN mesh routing are assigned only a >> single >> address/identifier and do not support multiple interfaces. >> >> >> Just a note here to mention that L2Ns will more than likely >> support multiple >> interfaces thanks to multiple non overlapping frequencies. >> >> >> Thanks. >> >> >> JP. >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn >> > > > > _______________________________________________ > RSN mailing list > RSN@ietf.org > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Aug 10 14:12:08 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYxw-0004UQ-QA; Fri, 10 Aug 2007 14:12:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYxw-0004U7-1N for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 14:12:04 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYxu-0003vP-Iv for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 14:12:04 -0400 Received: from dnab4221c9.stanford.edu ([171.66.33.201]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1IJYxs-0000I1-Mm; Fri, 10 Aug 2007 11:12:01 -0700 In-Reply-To: <46BCA49F.2060304@eecs.berkeley.edu> References: <20070725155919.9D8316E39@mail2.nict.go.jp> <15EE681D-EC8A-4EBB-8189-E7B5A89A289B@cisco.com> <46BCA49F.2060304@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Fri, 10 Aug 2007 11:12:00 -0700 To: Kris Pister X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 47150f6aa31409442f7db1cf5c00e98a X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org Subject: [6lowpan] Re: [RSN] Re: Routing in L2N presentation file X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Aug 10, 2007, at 10:47 AM, Kris Pister wrote: > JP - great presentation. I hope that it was well received. I'm > very supportive of everything in that document, with one > exception. There is one assumption that I believe is potentially > fatal to the entire 6lowpan/rsn effort in ietf. On slide 11 you > state "Research has focused on near-optimal solutions to specific > problems", and then in bold "IP is maximizing interoperability, not > aiming at finding a local optimum ;-)". I agree with the second > statement, but the first one is flat out wrong. > Very few people in sensor network research seem to care about near- > optimal solutions. Consider one of the best-received papers > [Kim07] at the recent IPSN conference. Note that the authors are > leaders in the field, this is a respected conference, one of the > better papers, and this is the dissertation work culminating four > years of research on this project. The paper presents the best > academic work to date on reliable multi-hop data collection, MP2P. > The payload goodput in this network was 1.4% of the channel > bandwidth, at 100% radio duty cycle. This is not "near-optimal" in > any sense that I know. > > If we start with 1.4%, and then degrade that so that we can > maximize interoperability, we'll be left with something that no one > will use. We have an opportunity to do this right - let's not fall > victim to the Zigbee-esque assumption that all we need to do is > define *something* and adoption will be automatic. > > ksjp > > [Kim07] Kim, Pakzad, Culler, Demmel, Fenves, Glaser, Turon, "Health > Monitoring of Civil Infrastructures Using Wireless Sensor > Networks", IPSN07. You're right, Kris, but it's a bit deeper than that. There's a big debate in the research community right now about layered vs. cross- layer design, and there are more of the latter than the former. The protocol briefly mentioned in the paper you cite has a full paper about it that will be appearing in SenSys. It's clear that a cross- layer design could lead to higher performance (hence JP's comment about optimal point solutions), and some reviewers made this point. But you can't easily compose cross-layer protocols into larger systems. hence the morass many research systems enter when they try to incorporate protocols X, Y, and Z together. So the community is slowly shifting from "how good can we get if we throw out all layering" and moving towards "what have we learned from that and how can we apply it to the layers?" That shift is one reason why R2LN's timing is very auspicious. The 1.4% is a bit misleading. As 6.2 discusses, the transport protocol in the paper achieves 94.8% of the layer 3 protocol's throughput (when considering the 1/3rd effect you get from multihop). The big inefficiencies are the layer 3 and 2 protocols the particular implementation builds on, neither of which were optimized for throughput. It would be great to see how well the e2e transport protocol works on top of a layer 2 and a layer 3 with this metric in mind. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Aug 10 20:08:20 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJeWh-0000qK-EP; Fri, 10 Aug 2007 20:08:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJeWg-0000q6-Jh for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 20:08:18 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJeWf-0002MT-9k for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 20:08:18 -0400 Received: from [192.168.1.211] (66.237.74.130.ptr.us.xo.net [66.237.74.130]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.1/8.13.5) with ESMTP id l7B08BxU022356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Aug 2007 17:08:12 -0700 (PDT) Message-ID: <46BCFDEB.4050601@eecs.berkeley.edu> Date: Fri, 10 Aug 2007 17:08:11 -0700 From: Kris Pister User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Philip Levis References: <20070725155919.9D8316E39@mail2.nict.go.jp> <15EE681D-EC8A-4EBB-8189-E7B5A89A289B@cisco.com> <46BCA49F.2060304@eecs.berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 6lowpan@lists.ietf.org, rsn@ietf.org Subject: [6lowpan] Re: [RSN] Re: Routing in L2N presentation file X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org >> The 1.4% is a bit misleading. As 6.2 discusses, the transport >> protocol in the paper achieves 94.8% of the layer 3 protocol's >> throughput (when considering the 1/3rd effect you get from multihop). Phil - this is exactly the sort of thing that drives me nuts about papers in this community. First off, section 6.2 discusses details of single-hop transmission using a 14.4kbps radio, and claims 33% efficiency. The actual deployment is multi-hop, and uses 250kbps radios, and achieves 1.4%. The "1/3rd effect" that you allude to is a constraint imposed by single-channel operation. If you use a channel-hopping protocol the theoretical limit is 1, not 1/3. Try telling an end user that his measured 1.4% throughput is misleading, and that he should really take into account all of the artificial constraints that you have come up with to explain it. ksjp Philip Levis wrote: > On Aug 10, 2007, at 10:47 AM, Kris Pister wrote: > >> JP - great presentation. I hope that it was well received. I'm >> very supportive of everything in that document, with one exception. >> There is one assumption that I believe is potentially fatal to the >> entire 6lowpan/rsn effort in ietf. On slide 11 you state "Research >> has focused on near-optimal solutions to specific problems", and then >> in bold "IP is maximizing interoperability, not aiming at finding a >> local optimum ;-)". I agree with the second statement, but the first >> one is flat out wrong. >> Very few people in sensor network research seem to care about >> near-optimal solutions. Consider one of the best-received papers >> [Kim07] at the recent IPSN conference. Note that the authors are >> leaders in the field, this is a respected conference, one of the >> better papers, and this is the dissertation work culminating four >> years of research on this project. The paper presents the best >> academic work to date on reliable multi-hop data collection, MP2P. >> The payload goodput in this network was 1.4% of the channel >> bandwidth, at 100% radio duty cycle. This is not "near-optimal" in >> any sense that I know. >> >> If we start with 1.4%, and then degrade that so that we can maximize >> interoperability, we'll be left with something that no one will use. >> We have an opportunity to do this right - let's not fall victim to >> the Zigbee-esque assumption that all we need to do is define >> *something* and adoption will be automatic. >> >> ksjp >> >> [Kim07] Kim, Pakzad, Culler, Demmel, Fenves, Glaser, Turon, "Health >> Monitoring of Civil Infrastructures Using Wireless Sensor Networks", >> IPSN07. > > You're right, Kris, but it's a bit deeper than that. There's a big > debate in the research community right now about layered vs. > cross-layer design, and there are more of the latter than the former. > The protocol briefly mentioned in the paper you cite has a full paper > about it that will be appearing in SenSys. It's clear that a > cross-layer design could lead to higher performance (hence JP's > comment about optimal point solutions), and some reviewers made this > point. But you can't easily compose cross-layer protocols into larger > systems. hence the morass many research systems enter when they try to > incorporate protocols X, Y, and Z together. So the community is slowly > shifting from "how good can we get if we throw out all layering" and > moving towards "what have we learned from that and how can we apply it > to the layers?" That shift is one reason why R2LN's timing is very > auspicious. > > The 1.4% is a bit misleading. As 6.2 discusses, the transport protocol > in the paper achieves 94.8% of the layer 3 protocol's throughput (when > considering the 1/3rd effect you get from multihop). The big > inefficiencies are the layer 3 and 2 protocols the particular > implementation builds on, neither of which were optimized for > throughput. It would be great to see how well the e2e transport > protocol works on top of a layer 2 and a layer 3 with this metric in > mind. > > Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Fri Aug 10 20:16:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJeeL-0000PA-GT; Fri, 10 Aug 2007 20:16:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJeeJ-0000OE-I1 for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 20:16:11 -0400 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJeeI-0002T2-8Q for 6lowpan@lists.ietf.org; Fri, 10 Aug 2007 20:16:11 -0400 Received: from dnab4221c9.stanford.edu ([171.66.33.201]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1IJeeH-0001XX-H5; Fri, 10 Aug 2007 17:16:09 -0700 In-Reply-To: <46BCFDEB.4050601@eecs.berkeley.edu> References: <20070725155919.9D8316E39@mail2.nict.go.jp> <15EE681D-EC8A-4EBB-8189-E7B5A89A289B@cisco.com> <46BCA49F.2060304@eecs.berkeley.edu> <46BCFDEB.4050601@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16681DD3-1A9F-434C-8D12-ADB548DFFBDA@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Fri, 10 Aug 2007 17:16:08 -0700 To: Kris Pister X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -102.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org Subject: [6lowpan] Re: [RSN] Re: Routing in L2N presentation file X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Aug 10, 2007, at 5:08 PM, Kris Pister wrote: > >> The 1.4% is a bit misleading. As 6.2 discusses, the transport > >> protocol in the paper achieves 94.8% of the layer 3 protocol's > >> throughput (when considering the 1/3rd effect you get from > multihop). > > Phil - this is exactly the sort of thing that drives me nuts about > papers in this community. First off, section 6.2 discusses details > of single-hop transmission using a 14.4kbps radio, and claims 33% > efficiency. The actual deployment is multi-hop, and uses 250kbps > radios, and achieves 1.4%. :) > The "1/3rd effect" that you allude to is a constraint imposed by > single-channel operation. If you use a channel-hopping protocol > the theoretical limit is 1, not 1/3. Absolutely -- it's the 1/3 imposed by having a single-channel CSMA. > Try telling an end user that his measured 1.4% throughput is > misleading, and that he should really take into account all of the > artificial constraints that you have come up with to explain it. Agreed -- from a complete system standpoint, 1.4% is 1.4%. The TinyOS 15.4 MAC is notoriously inefficient for throughput, as it uses really big backoff interval. All I was trying to say is that if you improved the MAC in this regard, then the protocol described there would benefit from it. We should be focusing on optimizing individual layers, as they benefit everything above and below, rather than just exploring cross-layer approaches. Of course, as I said earlier, cross- layer efforts have helped figure out *what* those layers need: your comments a few months ago about schedule information is a great example. This is one reason I think 6lowpan has real potential to shake out the space and lead to technical excellence. Phil _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Sat Aug 11 13:54:22 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJvAI-0004oj-Fl; Sat, 11 Aug 2007 13:54:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJvAG-0004od-NM for 6lowpan@ietf.org; Sat, 11 Aug 2007 13:54:16 -0400 Received: from mv-osn-hcb003.ocn.ad.jp ([60.37.51.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJvAF-0004Pr-QK for 6lowpan@ietf.org; Sat, 11 Aug 2007 13:54:16 -0400 Received: from vcpure.ocn.ne.jp (mv-osn-hcb003 [60.37.51.8]) by mv-osn-hcb003.ocn.ad.jp (Postfix) with ESMTP id 7E13834008 for <6lowpan@ietf.org>; Sun, 12 Aug 2007 02:54:13 +0900 (JST) Received: from dell4500c (p5089-ipad11fukuokachu.fukuoka.ocn.ne.jp [219.162.193.89]) by vcpure.ocn.ne.jp (Postfix) with SMTP for <6lowpan@ietf.org>; Sun, 12 Aug 2007 02:54:13 +0900 (JST) Message-ID: <001a01c7dc40$a9280b60$0200a8c0@dell4500c> From: =?iso-2022-jp?B?GyRCJSohPCVKITwbKEI=?= To: <6lowpan@ietf.org> Date: Sun, 12 Aug 2007 02:54:25 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [6lowpan] (no subject) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1267461130==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1267461130== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C7DC8C.177A6D60" This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C7DC8C.177A6D60 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0016_01C7DC8C.177A6D60 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0016_01C7DC8C.177A6D60-- --===============1267461130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1267461130==-- From 6lowpan-bounces@ietf.org Tue Aug 14 09:29:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwSt-0003cg-43; Tue, 14 Aug 2007 09:29:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKwSr-0003cN-Ul for 6lowpan@lists.ietf.org; Tue, 14 Aug 2007 09:29:41 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKwSq-0001TH-NX for 6lowpan@lists.ietf.org; Tue, 14 Aug 2007 09:29:41 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Aug 2007 09:29:40 -0400 X-IronPort-AV: i="4.19,259,1183348800"; d="scan'208"; a="67951846:sNHT52346626" 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 l7EDTefu003125; Tue, 14 Aug 2007 09:29:40 -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 l7EDTejI024291; Tue, 14 Aug 2007 13:29:40 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); Tue, 14 Aug 2007 09:29:40 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 09:29:39 -0400 In-Reply-To: <46BCA49F.2060304@eecs.berkeley.edu> References: <20070725155919.9D8316E39@mail2.nict.go.jp> <15EE681D-EC8A-4EBB-8189-E7B5A89A289B@cisco.com> <46BCA49F.2060304@eecs.berkeley.edu> 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 Date: Tue, 14 Aug 2007 09:29:09 -0400 To: Kris Pister X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 14 Aug 2007 13:29:39.0646 (UTC) FILETIME=[2A5B75E0:01C7DE77] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3671; t=1187098180; x=1187962180; 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]=20Re=3A=20Routing=20in=20L2N=20presentation=20f ile |Sender:=20 |To:=20Kris=20Pister=20; bh=E/oFQEIdELdC7YHzPWrogJ0hXnMkqLdj//oa73T+Zpg=; b=y6gyJK18X6NZi6WDdc482rE9vRf1/kbtU9xbkzsHndCzRqbQCVL49bzNEUEnb9abwfD8fa3j XAw/Ke2jfpR5EKBBoCT+cC1vqDeLbUTWajO2RWJA3AuVjJpqCQ3qKFDA; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 6lowpan@lists.ietf.org, rsn@ietf.org Subject: [6lowpan] Re: [RSN] Re: Routing in L2N presentation file X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Kris, On Aug 10, 2007, at 1:47 PM, Kris Pister wrote: > JP - great presentation. I hope that it was well received. I'm > very supportive of everything in that document, Thanks. > with one exception. Ah ;-) > There is one assumption that I believe is potentially fatal to the > entire 6lowpan/rsn effort in ietf. On slide 11 you state "Research > has focused on near-optimal solutions to specific problems", and > then in bold "IP is maximizing interoperability, not aiming at > finding a local optimum ;-)". I agree with the second statement, > but the first one is flat out wrong. > Very few people in sensor network research seem to care about near- > optimal solutions. OK let me first clarify something: first the statement was not negative by all means but having reviewed quite a few paper on WSN, there is a plethora of papers the aim of which is indeed to find a near-optimal solutions to a very specific problem. But you're right that this is not a generality. But more importantly the point that I was trying to stress is the following: the space of Sensor Networks or L2Ns to be a bit more generic is highly fragmented and the set of issues and constraints can vary significantly from one application to another. Thus, trying to find a near optimal to any specific problem would unavoidably lead to either N solutions (which we want to avoid !). And indeed, one of the greatest thing about IP is interoperability. I heard many people in the past telling me that they HAD to define a proprietary solution to get something optimal for a specific environment. Not only this is quite arguable, but our goal is to define a common set of IP-based solutions that would address most of the problem space (not all, sorry). > Consider one of the best-received papers [Kim07] at the recent IPSN > conference. Note that the authors are leaders in the field, this > is a respected conference, one of the better papers, and this is > the dissertation work culminating four years of research on this > project. The paper presents the best academic work to date on > reliable multi-hop data collection, MP2P. The payload goodput in > this network was 1.4% of the channel bandwidth, at 100% radio duty > cycle. This is not "near-optimal" in any sense that I know. > > If we start with 1.4%, and then degrade that so that we can > maximize interoperability, we'll be left with something that no one > will use. We have an opportunity to do this right - let's not fall > victim to the Zigbee-esque assumption that all we need to do is > define *something* and adoption will be automatic. Note that I did not say that interoperability implied sub-sub- optimality ;-) but I guess that I clarified my statement. Thanks for your support. JP. > > ksjp > > [Kim07] Kim, Pakzad, Culler, Demmel, Fenves, Glaser, Turon, "Health > Monitoring of Civil Infrastructures Using Wireless Sensor > Networks", IPSN07. > > JP Vasseur wrote: >> Hi Ved, >> >> On Jul 25, 2007, at 10:59 AM, Ved Kafle wrote: >> >>> Hi JP, >>> >>> Is it possible to get the presentation file you used in the >>> routing area >>> meeting? >>> I could find it on the web. >>> >> >> I was about to do so, here it is: >> We'll soon have a Web Page to point to for RSN related work. >> >> Thanks. >> >> JP. >> >>> Ved Kafle >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> RSN mailing list >> RSN@ietf.org >> https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Aug 27 11:27:15 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgUj-0000jB-2v; Mon, 27 Aug 2007 11:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgUh-0000iw-OD for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 11:27:11 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPgUg-00046l-Do for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 11:27:11 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Aug 2007 17:27:08 +0200 X-IronPort-AV: i="4.19,311,1183327200"; d="scan'208"; a="151580190:sNHT54152080" 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 l7RFR7i7026131; Mon, 27 Aug 2007 17:27:07 +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 l7RFR74F011711; Mon, 27 Aug 2007 15:27:07 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); Mon, 27 Aug 2007 17:27:07 +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: [6lowpan] Rechartering consensus... Date: Mon, 27 Aug 2007 17:27:00 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> In-Reply-To: <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Rechartering consensus... Thread-Index: AcfGH+2cZuaD89UtTq22UodRBKHgyQinNrnQ References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> From: "Pascal Thubert \(pthubert\)" To: "Jean Philippe Vasseur \(jvasseur\)" , "Mark Townsley \(townsley\)" , "Geoff Mulligan" X-OriginalArrivalTime: 27 Aug 2007 15:27:07.0042 (UTC) FILETIME=[BA4D8020:01C7E8BE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1262; t=1188228427; x=1189092427; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Rechartering=20consensus... |Sender:=20; bh=iXC4TPoixn+DFu+7Keu0uag352Jo7hwSrnXzOFDesE0=; b=v15NwJsZqAefMH+dm99chsMTMKBhiBZEZPepHxUmT8vYTUd0U2fGR+grTrtQPvxeGSvb18Vh afpaxnjdT3R8vMPz+4JHJaf14blLd1gqYn/aGy6I3YCimOhKRs1bu4kK; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > >"6lowpan Mesh Routing" > >JP> One of these "hot" topic. And of course, the main question will >to be >discuss whether Mesh-under routing is required if Route over is >available. >In particular, open questions are "If we claim a need for a mesh >under routing, >does that mean that we'll see a plethora of IDs showing how to adapt all >protocols (e.g. MANET) used in a 802.15.4 environment ?" > [Pascal] Hi JP: "While most routing protocols are defined above the IP layer, 6lowpan requires a mesh routing protocol below the IP layer." I'm also anxious about that sentence. The need for a mesh under vs. routing over should be motivated; also, if that happens, then the IETF might not be the place for this work. It already happens in a number of places such as SP100, HART or 802.15.5.=20 It seems more consistent to focus on IP and delegate a routing over protocol to the Routing Area. So I'd rather have 6LoWPAN support the RL2N (RSN ML) efforts because they are defining a mesh technology that is L2 agnostic, fit into the IETF scope and benefit from the area experience in routing, as opposed to proposing yet another mesh under protocol that might not be well considered by the mentioned standard organizations. Pascal _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Aug 27 11:59:13 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgzf-0002YL-Ih; Mon, 27 Aug 2007 11:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPgze-0002Y4-2A for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 11:59:10 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPgzb-0004wD-Ui for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 11:59:09 -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 l7RFx5nB012604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Aug 2007 08:59:06 -0700 (PDT) Message-ID: <46D2F46C.9040308@eecs.berkeley.edu> Date: Mon, 27 Aug 2007 08:57:32 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" , 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] Rechartering consensus... References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0528132875==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0528132875== Content-Type: multipart/alternative; boundary="------------010403070301090102030608" This is a multi-part message in MIME format. --------------010403070301090102030608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit >> 6lowpan requires a mesh routing protocol below the IP layer. For sure the word "requires" is incorrect. I don't think that there's any question at this point that it's possible to route over. There is still reasonable debate over what the optimal thing to do is, where different people have very different views of what "optimal" means! :) ksjp Pascal Thubert (pthubert) wrote: >> "6lowpan Mesh Routing" >> >> JP> One of these "hot" topic. And of course, the main question will >> to be >> discuss whether Mesh-under routing is required if Route over is >> available. >> In particular, open questions are "If we claim a need for a mesh >> under routing, >> does that mean that we'll see a plethora of IDs showing how to adapt >> > all > >> protocols (e.g. MANET) used in a 802.15.4 environment ?" >> >> > [Pascal] Hi JP: > > "While most routing protocols are defined above the IP layer, 6lowpan > requires a mesh routing protocol below the IP layer." > > I'm also anxious about that sentence. The need for a mesh under vs. > routing over should be motivated; also, if that happens, then the IETF > might not be the place for this work. It already happens in a number of > places such as SP100, HART or 802.15.5. > > It seems more consistent to focus on IP and delegate a routing over > protocol to the Routing Area. So I'd rather have 6LoWPAN support the > RL2N (RSN ML) efforts because they are defining a mesh technology that > is L2 agnostic, fit into the IETF scope and benefit from the area > experience in routing, as opposed to proposing yet another mesh under > protocol that might not be well considered by the mentioned standard > organizations. > > Pascal > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > --------------010403070301090102030608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >> 6lowpan requires a mesh routing protocol below the IP layer.

For sure the word "requires" is incorrect.  I don't think that there's any question at this point that it's possible to route over.  There is still reasonable debate over what the optimal thing to do is, where different people have very different views of what "optimal" means! :)

ksjp

Pascal Thubert (pthubert) wrote: 
"6lowpan Mesh Routing"

JP> One of these "hot" topic. And of course, the main question will
to be
discuss whether Mesh-under routing is required if Route over is
available.
In particular, open questions are "If we claim a need for a mesh
under routing,
does that mean that we'll see a plethora of IDs showing how to adapt
    
all
  
protocols (e.g. MANET) used in a 802.15.4 environment ?"

    
[Pascal] Hi JP:

"While most routing protocols are defined above the IP layer, 6lowpan
requires a mesh routing protocol below the IP layer."

I'm also anxious about that sentence. The need for a mesh under vs.
routing over should be motivated; also, if that happens, then the IETF
might not be the place for this work. It already happens in a number of
places such as SP100, HART or 802.15.5. 

It seems more consistent to focus on IP and delegate a routing over
protocol to the Routing Area. So I'd rather have 6LoWPAN support the
RL2N (RSN ML) efforts because they are defining a mesh technology that
is L2 agnostic, fit into the IETF scope and benefit from the area
experience in routing, as opposed to proposing yet another mesh under
protocol that might not be well considered by the mentioned standard
organizations.

Pascal

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan
--------------010403070301090102030608-- --===============0528132875== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0528132875==-- From 6lowpan-bounces@ietf.org Mon Aug 27 12:14:58 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhEw-00031o-1n; Mon, 27 Aug 2007 12:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhEv-00031h-1c for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 12:14:57 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPhEt-0005Ke-O2 for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 12:14:57 -0400 Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.0/8.14.0) with ESMTP id l7RGEdH1001568; Mon, 27 Aug 2007 18:14:39 +0200 (CEST) In-Reply-To: <46D2F46C.9040308@eecs.berkeley.edu> References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> <46D2F46C.9040308@eecs.berkeley.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19FB6C53-30D9-431A-96B2-779E1C08F8D0@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Subject: Re: [6lowpan] Rechartering consensus... Date: Mon, 27 Aug 2007 18:14:37 +0200 To: Kris Pister X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org On Aug 27 2007, at 17:57, Kris Pister wrote: > 6lowpan requires a mesh routing protocol below the IP layer. > > For sure the word "requires" is incorrect. I'm sure the term "6lowpan" can be redefined to make this statement true. For now, RFC4919 takes the stance that L2 routing ("mesh") is an integral part of the 6lowpan requirements. If we want to change this, I'd like to hear a good argument why this recent consensus is no longer valid. Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Aug 27 12:19:45 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhJZ-0004kl-EO; Mon, 27 Aug 2007 12:19:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhJX-0004k0-NQ for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 12:19:43 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPhJV-0005TA-Qh for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 12:19:43 -0400 Received: by ug-out-1314.google.com with SMTP id j3so52152ugf for <6lowpan@lists.ietf.org>; Mon, 27 Aug 2007 09:19:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DxmOuLHaqHWCrFU80L69kVeND7kF+OhH8ofADO2T3VCBiLUgts8uuVIMNNA3+jYDKEkme03bWnm0L/nwzc+RSgAzHnq8HBKmu/aY4xuKiC9zE34ZH93PFno2WghcKmv8PWAizX3t+qsEJbmZ89rjGLC/iAly7UmtOY0UrjT9FyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=E+VbNP6KZRfSxze+nHzmpvjX8cflAu+I45A+UxLIqwqeux9sfy/Wzog/wVBQrPkCdhr/yC2oxeIbiRUFMPeZ5KcajUDlKJokg7uCYTw+kI8bbCXDZpRBN+GlxWHRzasXaCGo0Fqu2MmhZvU/RHdQwy1zZGUC58jiyJtkuC4khNg= Received: by 10.142.212.19 with SMTP id k19mr335351wfg.1188231578662; Mon, 27 Aug 2007 09:19:38 -0700 (PDT) Received: by 10.142.97.19 with HTTP; Mon, 27 Aug 2007 09:19:38 -0700 (PDT) Message-ID: <1edd46e70708270919g671ca16bp2b22f2e3a5c08071@mail.gmail.com> Date: Mon, 27 Aug 2007 09:19:38 -0700 From: "Joe Polastre" To: "Carsten Bormann" Subject: Re: [6lowpan] Rechartering consensus... In-Reply-To: <19FB6C53-30D9-431A-96B2-779E1C08F8D0@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> <46D2F46C.9040308@eecs.berkeley.edu> <19FB6C53-30D9-431A-96B2-779E1C08F8D0@tzi.org> X-Google-Sender-Auth: 56cb35785dcba1f2 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org > For now, RFC4919 takes the stance that L2 routing ("mesh") is an > integral part of the 6lowpan requirements. First comment is that mesh is a networking protocol, not a data-link protocol. Thus, it cannot be an L2 "routing" requirement. Since IP is at L3, I agree with Kris--mesh can either be L2.5 (which is a bit weird IMHO), it can co-exist with IP (in an undefined way), or it can be leveraged above IP similar to overlays. -Joe _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Mon Aug 27 12:40:24 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhdT-000607-RF; Mon, 27 Aug 2007 12:40:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPhdS-000601-Oa for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 12:40:19 -0400 Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPhdR-00062y-Eq for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 12:40:18 -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 l7RGeFZc013505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@lists.ietf.org>; Mon, 27 Aug 2007 09:40:16 -0700 (PDT) Message-ID: <46D2FE0C.6080109@eecs.berkeley.edu> Date: Mon, 27 Aug 2007 09:38:36 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: 6lowpan <6lowpan@lists.ietf.org> Subject: Re: [6lowpan] Rechartering consensus... References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> <46D2F46C.9040308@eecs.berkeley.edu> <19FB6C53-30D9-431A-96B2-779E1C08F8D0@tzi.org> <1edd46e70708270919g671ca16bp2b22f2e3a5c08071@mail.gmail.com> In-Reply-To: <1edd46e70708270919g671ca16bp2b22f2e3a5c08071@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0196579691==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============0196579691== Content-Type: multipart/alternative; boundary="------------020300050309060308080701" This is a multi-part message in MIME format. --------------020300050309060308080701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Carsten - I'm using 6lowpan in the broad sense of the original acronym, not just RFC4919. That may be incorrect, and I should use different terminology. Joe - what layer does MPLS fit in? MPLS looks a little weird, and a little "2.5"-ish, but to me it's the approach that makes the most sense for 6lowpan. I haven't gone back to read all of the discussion, but it seems like the only thing that got added in v6 was the flow label. This flow label provides a wonderful opportunity to work with protocols like HART and sp100 that use an L3 graph-ID to govern L2 operation. I think that we could define a different HC that keeps the v6 flow label and uses that to control L2. I'm not sure how much of RSVP, etc would be needed to pull this off, but it seems like it should be possible to do something very similar to what already exists for MPLS (but probably simplified, compressed, etc). I'd like to work on this with someone who is more facile with all of the L3 stuff (which I am not). ksjp Joe Polastre wrote: >> For now, RFC4919 takes the stance that L2 routing ("mesh") is an >> integral part of the 6lowpan requirements. >> > > First comment is that mesh is a networking protocol, not a data-link > protocol. Thus, it cannot be an L2 "routing" requirement. > > Since IP is at L3, I agree with Kris--mesh can either be L2.5 (which > is a bit weird IMHO), it can co-exist with IP (in an undefined way), > or it can be leveraged above IP similar to overlays. > > -Joe > --------------020300050309060308080701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Carsten - I'm using 6lowpan in the broad sense of the original acronym, not just RFC4919.  That may be incorrect, and I should use different terminology.

Joe - what layer does MPLS fit in?  MPLS looks a little weird, and a little "2.5"-ish, but to me it's the approach that makes the most sense for 6lowpan.  I haven't gone back to read all of the discussion, but it seems like the only thing that got added in v6 was the flow label.  This flow label provides a wonderful opportunity to work with protocols like HART and sp100 that use an L3 graph-ID to govern L2 operation.  I think that we could define a different HC that keeps the v6 flow label and uses that to control L2.  I'm not sure how much of RSVP, etc would be needed to pull this off, but it seems like it should be possible to do something very similar to what already exists for MPLS (but probably simplified, compressed, etc).  I'd like to work on this with someone who is more facile with all of the L3 stuff (which I am not).

ksjp

Joe Polastre wrote: 
For now, RFC4919 takes the stance that L2 routing ("mesh") is an
integral part of the 6lowpan requirements.
    

First comment is that mesh is a networking protocol, not a data-link
protocol.  Thus, it cannot be an L2 "routing" requirement.

Since IP is at L3, I agree with Kris--mesh can either be L2.5 (which
is a bit weird IMHO), it can co-exist with IP (in an undefined way),
or it can be leveraged above IP similar to overlays.

-Joe
--------------020300050309060308080701-- --===============0196579691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0196579691==-- From 6lowpan-bounces@ietf.org Mon Aug 27 16:58:46 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPlfZ-0007jG-Ra; Mon, 27 Aug 2007 16:58:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPlfZ-0007jA-2W for 6lowpan@ietf.org; Mon, 27 Aug 2007 16:58:45 -0400 Received: from mv-osn-hcb003.ocn.ad.jp ([60.37.51.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPlfX-0005hB-6u for 6lowpan@ietf.org; Mon, 27 Aug 2007 16:58:45 -0400 Received: from vcpure.ocn.ne.jp (mv-osn-hcb003 [60.37.51.8]) by mv-osn-hcb003.ocn.ad.jp (Postfix) with ESMTP id 0489834002 for <6lowpan@ietf.org>; Tue, 28 Aug 2007 05:58:41 +0900 (JST) Received: from dell4500c (p5005-ipad104fukuokachu.fukuoka.ocn.ne.jp [60.40.212.5]) by vcpure.ocn.ne.jp (Postfix) with ESMTP for <6lowpan@ietf.org>; Tue, 28 Aug 2007 05:58:40 +0900 (JST) From: "Owner" To: <6lowpan@ietf.org> Date: Tue, 28 Aug 2007 05:58:47 +0900 Organization: mhoer48_word@hotmail.co.jp Message-ID: <000601c7e8ed$10245c20$306d1460$@ocn.ne.jp> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acfo7Q8GtrsrRiWDTIuN+yijKe/qKg== Content-Language: ja X-Spam-Score: 4.8 (++++) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [6lowpan] (no subject) X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0761064930==" Errors-To: 6lowpan-bounces@ietf.org ‚±‚ê‚Í MIME Œ`Ž®‚̃}ƒ‹ƒ`ƒp[ƒg ƒƒbƒZ[ƒW‚Å‚·B --===============0761064930== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C7E938.800C0420" Content-Language: ja ‚±‚ê‚Í MIME Œ`Ž®‚̃}ƒ‹ƒ`ƒp[ƒg ƒƒbƒZ[ƒW‚Å‚·B ------=_NextPart_000_0007_01C7E938.800C0420 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit ------=_NextPart_000_0007_01C7E938.800C0420 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

------=_NextPart_000_0007_01C7E938.800C0420-- --===============0761064930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0761064930==-- From 6lowpan-bounces@ietf.org Mon Aug 27 22:16:53 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPqdM-0000Ir-JT; Mon, 27 Aug 2007 22:16:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPqdL-0000Ih-1R for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 22:16:47 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPqdJ-0004Ss-Q5 for 6lowpan@lists.ietf.org; Mon, 27 Aug 2007 22:16:47 -0400 Received: by ug-out-1314.google.com with SMTP id j3so133333ugf for <6lowpan@lists.ietf.org>; Mon, 27 Aug 2007 19:16:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=YZkxXan3dAVhOm6OcA/GZhUnUhzT2VgiXpAAIp5WPyG+X/WQc/+g8ApkMHMIS6GZZFLvEGzqvC1a6E6d+8iAgNy7eTlEk8g2fuWrWq8SdfnrVMdAYz0oLHz9du1CcMSyKdLOicMx7jnbxVCXDbATBMAkTHeQca7o5QrCINHhZQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Os/gcJpUOdCDgkve3uGcY/3CJBVs5OdG+0f+QvKtx5qKFnNYC6HctptKWZMZZYYpV9X6KPXldKUOqbggZRGkAloqQQd1OiZb66mhU7RsTDJ+3I6LOdLR7qTI3uSGBJwNlIOMzDFwAJXC3+YpzYh4FWT/X7vL4eDzYKoLu8OCLc0= Received: by 10.143.33.19 with SMTP id l19mr551132wfj.1188267403512; Mon, 27 Aug 2007 19:16:43 -0700 (PDT) Received: by 10.142.97.19 with HTTP; Mon, 27 Aug 2007 19:16:43 -0700 (PDT) Message-ID: <1edd46e70708271916g56f13ddai7f6343c494ebabe5@mail.gmail.com> Date: Mon, 27 Aug 2007 19:16:43 -0700 From: "Joe Polastre" To: "Kris Pister" Subject: Re: [6lowpan] Rechartering consensus... In-Reply-To: <46D2FE0C.6080109@eecs.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> <46D2F46C.9040308@eecs.berkeley.edu> <19FB6C53-30D9-431A-96B2-779E1C08F8D0@tzi.org> <1edd46e70708270919g671ca16bp2b22f2e3a5c08071@mail.gmail.com> <46D2FE0C.6080109@eecs.berkeley.edu> X-Google-Sender-Auth: 974e09fb80dba63f X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org To me, its a matter of defining abstractions clearly. Data link traditionally meant two points connected directly with the use of a physical wire (ie, it sits right above the "physical layer"). In this domain, we have this quirky ability to have multiple direct connections. For example, I may be able to directly connect with Kris, but I can also connect with Kris via John. From a software layering perspective, I can leverage both options at L2/L2.5 to make it look to the network layer like I have a reliable direct data-link connection to Kris, regardless of whether I reach Kris directly or talk to him via John. This becomes murkier if all of your "direct" connections are not direct at all or have no possible direct path--then you're potentially treading on the realm of L3 protocols. This is why this mesh networking domain has had the problem of communicating data and metadata between layers transparently, since each of the layers seems to muddle in other layers' business. I agree that MPLS is probably most applicable here, and really is one of these L2.5 services because it is abstracting all kinds of ugly mess underneath to look like a single data link to L3 protocols. -Joe On 8/27/07, Kris Pister wrote: > > Carsten - I'm using 6lowpan in the broad sense of the original acronym, not > just RFC4919. That may be incorrect, and I should use different > terminology. > > Joe - what layer does MPLS fit in? MPLS looks a little weird, and a little > "2.5"-ish, but to me it's the approach that makes the most sense for > 6lowpan. I haven't gone back to read all of the discussion, but it seems > like the only thing that got added in v6 was the flow label. This flow > label provides a wonderful opportunity to work with protocols like HART and > sp100 that use an L3 graph-ID to govern L2 operation. I think that we could > define a different HC that keeps the v6 flow label and uses that to control > L2. I'm not sure how much of RSVP, etc would be needed to pull this off, > but it seems like it should be possible to do something very similar to what > already exists for MPLS (but probably simplified, compressed, etc). I'd > like to work on this with someone who is more facile with all of the L3 > stuff (which I am not). > > ksjp > > > Joe Polastre wrote: > > For now, RFC4919 takes the stance that L2 routing ("mesh") is an > integral part of the 6lowpan requirements. > > First comment is that mesh is a networking protocol, not a data-link > protocol. Thus, it cannot be an L2 "routing" requirement. > > Since IP is at L3, I agree with Kris--mesh can either be L2.5 (which > is a bit weird IMHO), it can co-exist with IP (in an undefined way), > or it can be leveraged above IP similar to overlays. > > -Joe > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www1.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Aug 28 02:49:32 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPutE-000258-Dx; Tue, 28 Aug 2007 02:49:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPutD-000253-Kl for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 02:49:27 -0400 Received: from mail.sf.archrock.com ([64.147.171.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPutC-0002VN-9q for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 02:49:27 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id A9F59A95DD; Mon, 27 Aug 2007 23:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-10 required=6.6 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_DUL=2.046] Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hH72B8jcB6L; Mon, 27 Aug 2007 23:49:22 -0700 (PDT) Received: from [192.168.1.143] (adsl-71-142-82-225.dsl.pltn13.pacbell.net [71.142.82.225]) by mail.sf.archrock.com (Postfix) with ESMTP id F29B4A95D6; Mon, 27 Aug 2007 23:49:21 -0700 (PDT) Message-ID: <46D3C56B.7070702@archrock.com> Date: Mon, 27 Aug 2007 23:49:15 -0700 From: Jonathan Hui User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Polastre Subject: Re: [6lowpan] Rechartering consensus... References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> <46D2F46C.9040308@eecs.berkeley.edu> <19FB6C53-30D9-431A-96B2-779E1C08F8D0@tzi.org> <1edd46e70708270919g671ca16bp2b22f2e3a5c08071@mail.gmail.com> <46D2FE0C.6080109@eecs.berkeley.edu> <1edd46e70708271916g56f13ddai7f6343c494ebabe5@mail.gmail.com> In-Reply-To: <1edd46e70708271916g56f13ddai7f6343c494ebabe5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Joe Polastre wrote: > To me, its a matter of defining abstractions clearly. Data link > traditionally meant two points connected directly with the use of a > physical wire (ie, it sits right above the "physical layer"). A minor but significant clarification, the data link in the IP world has traditionally meant two *or more* devices connected directly over a single shared-media. This is why so many protocols rely on link-local multicast and why LAN technologies that do not support it must emulate it, as we saw with LANE. It is also why we see some push from members in this working group for a "mesh-under" routing and forwarding strategy. > In this domain, we have this quirky ability to have multiple direct > connections. For example, I may be able to directly connect with > Kris, but I can also connect with Kris via John. From a software > layering perspective, I can leverage both options at L2/L2.5 to make > it look to the network layer like I have a reliable direct data-link > connection to Kris, regardless of whether I reach Kris directly or > talk to him via John. This becomes murkier if all of your "direct" > connections are not direct at all or have no possible direct > path--then you're potentially treading on the realm of L3 protocols. > This is why this mesh networking domain has had the problem of > communicating data and metadata between layers transparently, since > each of the layers seems to muddle in other layers' business. > > I agree that MPLS is probably most applicable here, and really is one > of these L2.5 services because it is abstracting all kinds of ugly > mess underneath to look like a single data link to L3 protocols. Putting MPLS' applicability to L2Ns aside, one thing to learn from MPLS is that the control protocols are, largely, IP protocols. Thus, MPLS is "route-over" but redefines the forwarding mechanisms to be below IP. But, yes, many claimed advantages of MPLS (e.g. label lookup, traffic engineering, etc.) may also see similar advantages in L2Ns. -- Jonathan Hui jhui@archrock.com _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Aug 28 05:09:49 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPx51-0002eA-5U; Tue, 28 Aug 2007 05:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPx4z-0002e4-AW for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 05:09:45 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPx4x-0004su-Vk for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 05:09:45 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Aug 2007 11:08:54 +0200 X-IronPort-AV: i="4.19,315,1183327200"; d="scan'208"; a="151631466:sNHT3116306450" 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 l7S98sRk014216; Tue, 28 Aug 2007 11:08:54 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7S98V4L008739; Tue, 28 Aug 2007 09:08:47 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 11:08:33 +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: [6lowpan] Rechartering consensus... Date: Tue, 28 Aug 2007 11:08:29 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC046587BA@xmb-ams-337.emea.cisco.com> In-Reply-To: <19FB6C53-30D9-431A-96B2-779E1C08F8D0@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Rechartering consensus... Thread-Index: AcfoxWaA4tCAPaZRTQqX7nc97SNu1wAg3sMg References: <1182290571.6218.29.camel@dellx1> <467FFF42.9010402@cisco.com> <0A790B2E-E99C-4E7B-9D83-622C2D229CEA@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC046585C5@xmb-ams-337.emea.cisco.com> <46D2F46C.9040308@eecs.berkeley.edu> <19FB6C53-30D9-431A-96B2-779E1C08F8D0@tzi.org> From: "Pascal Thubert \(pthubert\)" To: "Carsten Bormann" , "Kris Pister" , "Joe Polastre" X-OriginalArrivalTime: 28 Aug 2007 09:08:33.0629 (UTC) FILETIME=[027778D0:01C7E953] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3328; t=1188292134; x=1189156134; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Rechartering=20consensus... |Sender:=20; bh=fOsEFC8Of8rWrpZGgdKlfE6Comgtuq1Pbe2RNyVZvB0=; b=DQWs56RAzMDAa0XeaerA297t34K8RKx2VBymDLoyjVyJnkh78B/PsLarvtl2NNf1weLiVGmb 4a7vu8BUnFY3sLyatyQWfGZ2xGeYEBqOZVUZPINhocOT8UnAxlRYpwkb; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: 6lowpan <6lowpan@lists.ietf.org> X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: 6lowpan-bounces@ietf.org Hi Carsten, Yes, I suspect we want to alter the wording of a requirement in the charter. I've not seen similar text in RFC 4919 but I might have missed it. Rather, the RFC states in page 5 the requirement on a routing protocol. We want IPv6 in the sensor space ASAP so that applications in edge servers can be developed for it and 6LoWPAN is a major step on that path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you name it) are being deployed in the field and it would be great that the standard versions move to IPv6 as the de facto network layer and provide the associated LINK abstraction. I understand that the SP100-NetTrans task group has already taken the position to use 6LoWPAN as the network layer. A mesh under is one fine way to provide the link abstraction that IP needs, and a frame relay PVC based cloud is the proof that the model works. There is little question in my mind that 6LoWPAN can work with WiHART or similar once they provide this abstraction. What's tricky is the word "requires" in the proposed re-charter that Geoff sent in June for this thread. A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will have trouble optimizing the support of multicast upon which IPv6 relies for basic operations. Also, when we consider the self-forming, self-healing characteristics that we are looking for, then some history might help us avoid past mistakes. There have been a number of attempts to provide mesh under mode in the WAN space, including PNNI, NBBS etc...=20 After years of trials and failure, IP routing has emerged to be the most consistent solution to optimize end-to-end connectivity, with the tooling and management support that comes with it. Further, this enabled a new virtual switched network, MPLS, which benefits from IP routing for its path computation, optimization (Traffic Engineering Constrained Path) and isolation (Virtual Private Networks).=20 So in my mind, it is not true that 6LoWPAN requires a mesh under protocol. What is true is that the routing that 6LoWPAN requires would largely benefit from IP technology should it be IP based. As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management. So my proposal is: - work with external standard groups such as HCF and SP100 to insure that 6LoWPAN is compatible with their link abstractions. - work with the routing area to provide an alternate IP-based routing over solution What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: Monday, August 27, 2007 6:15 PM >To: Kris Pister >Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] Rechartering consensus... > >On Aug 27 2007, at 17:57, Kris Pister wrote: > >> 6lowpan requires a mesh routing protocol below the IP layer. >> >> For sure the word "requires" is incorrect. > >I'm sure the term "6lowpan" can be redefined to make this statement >true. >For now, RFC4919 takes the stance that L2 routing ("mesh") is an >integral part of the 6lowpan requirements. >If we want to change this, I'd like to hear a good argument why this >recent consensus is no longer valid. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan From 6lowpan-bounces@ietf.org Tue Aug 28 09:45:18 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ1Nb-00088G-27; Tue, 28 Aug 2007 09:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ1NZ-00088A-CX for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 09:45:13 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ1NX-000296-Kz for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 09:45:13 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 3584210027FEC; Tue, 28 Aug 2007 05:47:23 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLJ6hXx7f2Bv; Tue, 28 Aug 2007 05:47:20 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Tue, 28 Aug 2007 05:47:20 -0400 (EDT) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC046587BA@xmb-ams-337.emea.cisco.com> To: "Pascal Thubert \(pthubert\)" Subject: RE: [6lowpan] Rechartering consensus... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Rene Struik Date: Tue, 28 Aug 2007 09:40:43 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2|May 14, 2007) at 08/28/2007 09:40:44 AM, Serialize complete at 08/28/2007 09:40:44 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0022297993==" Errors-To: 6lowpan-bounces@ietf.org This is a multipart message in MIME format. --===============0022297993== Content-Type: multipart/alternative; boundary="=_alternative 004B8AF685257345_=" This is a multipart message in MIME format. --=_alternative 004B8AF685257345_= Content-Type: text/plain; charset="US-ASCII" Dear Pascal: With due respect, I am not clear how this would "better" security at all, since I do not know what your metric is. Please explain. More generally, it seems you would do the community a favor if you could expand in some detail on trust lifecycle management and outline the resources (crypto primitives, implementation cost protocols (both in hardware/software), time latency, packet expansion, etc.) required to implement IP security with sensors. Some references to peer-reviewed papers that elaborate on this would also be helpful. Best regards, Rene ==== [from the 6lowpan thread] As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management. Rene ----- Certicom Research http://www.certicom.com "Pascal Thubert \(pthubert\)" 08/28/2007 05:05 AM To "Carsten Bormann" , "Kris Pister" , "Joe Polastre" cc 6lowpan <6lowpan@lists.ietf.org> Subject RE: [6lowpan] Rechartering consensus... Hi Carsten, Yes, I suspect we want to alter the wording of a requirement in the charter. I've not seen similar text in RFC 4919 but I might have missed it. Rather, the RFC states in page 5 the requirement on a routing protocol. We want IPv6 in the sensor space ASAP so that applications in edge servers can be developed for it and 6LoWPAN is a major step on that path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you name it) are being deployed in the field and it would be great that the standard versions move to IPv6 as the de facto network layer and provide the associated LINK abstraction. I understand that the SP100-NetTrans task group has already taken the position to use 6LoWPAN as the network layer. A mesh under is one fine way to provide the link abstraction that IP needs, and a frame relay PVC based cloud is the proof that the model works. There is little question in my mind that 6LoWPAN can work with WiHART or similar once they provide this abstraction. What's tricky is the word "requires" in the proposed re-charter that Geoff sent in June for this thread. A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will have trouble optimizing the support of multicast upon which IPv6 relies for basic operations. Also, when we consider the self-forming, self-healing characteristics that we are looking for, then some history might help us avoid past mistakes. There have been a number of attempts to provide mesh under mode in the WAN space, including PNNI, NBBS etc... After years of trials and failure, IP routing has emerged to be the most consistent solution to optimize end-to-end connectivity, with the tooling and management support that comes with it. Further, this enabled a new virtual switched network, MPLS, which benefits from IP routing for its path computation, optimization (Traffic Engineering Constrained Path) and isolation (Virtual Private Networks). So in my mind, it is not true that 6LoWPAN requires a mesh under protocol. What is true is that the routing that 6LoWPAN requires would largely benefit from IP technology should it be IP based. As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management. So my proposal is: - work with external standard groups such as HCF and SP100 to insure that 6LoWPAN is compatible with their link abstractions. - work with the routing area to provide an alternate IP-based routing over solution What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: Monday, August 27, 2007 6:15 PM >To: Kris Pister >Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] Rechartering consensus... > >On Aug 27 2007, at 17:57, Kris Pister wrote: > >> 6lowpan requires a mesh routing protocol below the IP layer. >> >> For sure the word "requires" is incorrect. > >I'm sure the term "6lowpan" can be redefined to make this statement >true. >For now, RFC4919 takes the stance that L2 routing ("mesh") is an >integral part of the 6lowpan requirements. >If we want to change this, I'd like to hear a good argument why this >recent consensus is no longer valid. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --=_alternative 004B8AF685257345_= Content-Type: text/html; charset="US-ASCII"
Dear Pascal:

With due respect, I am not clear how this would "better" security at all, since I do not know what your metric is. Please explain.

More generally, it seems you would do the community a favor if you could expand in some detail on trust lifecycle management and outline the resources (crypto primitives, implementation cost protocols (both in hardware/software), time latency, packet expansion, etc.) required to implement IP security with sensors. Some references to peer-reviewed papers that elaborate on this would also be helpful.

Best regards, Rene

====
[from the 6lowpan thread]

As Kris and
Joe discussed in this thread, IP routing would enable us to extend the
MPLS network down to the sensors, for a better security and QoS
management.


Rene
-----
Certicom Research
http://www.certicom.com


"Pascal Thubert \(pthubert\)" <pthubert@cisco.com>

08/28/2007 05:05 AM

To
"Carsten Bormann" <cabo@tzi.org>, "Kris Pister" <pister@eecs.berkeley.edu>, "Joe Polastre" <joe@polastre.com>
cc
6lowpan <6lowpan@lists.ietf.org>
Subject
RE: [6lowpan] Rechartering consensus...





Hi Carsten,

Yes, I suspect we want to alter the wording of a requirement in the
charter. I've not seen similar text in RFC 4919 but I might have missed
it. Rather, the RFC states in page 5 the requirement on a routing
protocol.

We want IPv6 in the sensor space ASAP so that applications in edge
servers can be developed for it and 6LoWPAN is a major step on that
path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you
name it) are being deployed in the field and it would be great that the
standard versions move to IPv6 as the de facto network layer and provide
the associated LINK abstraction. I understand that the SP100-NetTrans
task group has already taken the position to use 6LoWPAN as the network
layer.

A mesh under is one fine way to provide the link abstraction that IP
needs, and a frame relay PVC based cloud is the proof that the model
works. There is little question in my mind that 6LoWPAN can work with
WiHART or similar once they provide this abstraction. What's tricky is
the word "requires" in the proposed re-charter that Geoff sent in June
for this thread.

A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will have
trouble optimizing the support of multicast upon which IPv6 relies for
basic operations. Also, when we consider the self-forming, self-healing
characteristics that we are looking for, then some history might help us
avoid past mistakes. There have been a number of attempts to provide
mesh under mode in the WAN space, including PNNI, NBBS etc...

After years of trials and failure, IP routing has emerged to be the most
consistent solution to optimize end-to-end connectivity, with the
tooling and management support that comes with it. Further, this enabled
a new virtual switched network, MPLS, which benefits from IP routing for
its path computation, optimization (Traffic Engineering Constrained
Path) and isolation (Virtual Private Networks).

So in my mind, it is not true that 6LoWPAN requires a mesh under
protocol. What is true is that the routing that 6LoWPAN requires would
largely benefit from IP technology should it be IP based. As Kris and
Joe discussed in this thread, IP routing would enable us to extend the
MPLS network down to the sensors, for a better security and QoS
management.

So my proposal is:
- work with external standard groups such as HCF and SP100 to insure
that 6LoWPAN is compatible with their link abstractions.
- work with the routing area to provide an alternate IP-based routing
over solution

What do you think?

Pascal

>-----Original Message-----
>From: Carsten Bormann [mailto:cabo@tzi.org]
>Sent: Monday, August 27, 2007 6:15 PM
>To: Kris Pister
>Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan
>Subject: Re: [6lowpan] Rechartering consensus...
>
>On Aug 27 2007, at 17:57, Kris Pister wrote:
>
>> 6lowpan requires a mesh routing protocol below the IP layer.
>>
>> For sure the word "requires" is incorrect.
>
>I'm sure the term "6lowpan" can be redefined to make this statement
>true.
>For now, RFC4919 takes the stance that L2 routing ("mesh") is an
>integral part of the 6lowpan requirements.
>If we want to change this, I'd like to hear a good argument why this
>recent consensus is no longer valid.
>
>Gruesse, Carsten

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan
--=_alternative 004B8AF685257345_=-- --===============0022297993== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============0022297993==-- From 6lowpan-bounces@ietf.org Tue Aug 28 11:30:55 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ31q-0002vB-Mp; Tue, 28 Aug 2007 11:30:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ31o-0002v1-GW for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 11:30:52 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ31m-0005ta-BX for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 11:30:52 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Aug 2007 17:28:05 +0200 X-IronPort-AV: i="4.19,317,1183327200"; d="scan'208,217"; a="151681354:sNHT319715776" 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 l7SFS4D6008728; Tue, 28 Aug 2007 17:28:04 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7SFRs4T018339; Tue, 28 Aug 2007 15:28:00 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Aug 2007 17:27:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [6lowpan] Rechartering consensus... Date: Tue, 28 Aug 2007 17:27:45 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04658A87@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Rechartering consensus... Thread-Index: AcfpebwXqcD9WptxRmSm/hJDrhV2AwADQkdA References: <7892795E1A87F04CADFCCF41FADD00FC046587BA@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert \(pthubert\)" To: "Rene Struik" X-OriginalArrivalTime: 28 Aug 2007 15:27:54.0194 (UTC) FILETIME=[00D21320:01C7E988] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=23016; t=1188314884; x=1189178884; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Rechartering=20consensus... |Sender:=20; bh=7xwCvvCZ6KVEorQVnhD1RiIU63+hxEeI7Kk+7sGKas0=; b=oPqJZZzPU/4cuy+mHa0YYMkbEAtKxHhDfoUGTVS1u8ywpojEoUE8cO8zBKVmrR0J3WX/T6C+ msWbsLjiGJvW8TgTM0ev9nbzP9UT14MXCpvNZxBBDSYozBEDpFNoa2wW; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8136d1e28e0aab8a4e130297ed2e1fc4 Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1371480779==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1371480779== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E988.0060E54F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E988.0060E54F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rene: =20 I was discussing the VPN functionality. It could be possible to deploy VPN up to the sensors and even split a sensor network into multiple VPNs though that one is really far fetched. The point is that for a same crypto cost, end to end security at IP level avoids the risk of the gateway being compromised: Same discussion exactly as 802.11e/EAP vs. VPN. in, say, 802.11 networks... =20 Pascal ________________________________ From: Rene Struik [mailto:RStruik@certicom.com]=20 Sent: Tuesday, August 28, 2007 3:41 PM To: Pascal Thubert (pthubert) Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris Pister Subject: RE: [6lowpan] Rechartering consensus... =20 Dear Pascal:=20 With due respect, I am not clear how this would "better" security at all, since I do not know what your metric is. Please explain.=20 More generally, it seems you would do the community a favor if you could expand in some detail on trust lifecycle management and outline the resources (crypto primitives, implementation cost protocols (both in hardware/software), time latency, packet expansion, etc.) required to implement IP security with sensors. Some references to peer-reviewed papers that elaborate on this would also be helpful.=20 Best regards, Rene=20 =3D=3D=3D=3D=20 [from the 6lowpan thread]=20 As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management.=20 Rene=20 ----- Certicom Research http://www.certicom.com=20 "Pascal Thubert \(pthubert\)" =20 08/28/2007 05:05 AM=20 To "Carsten Bormann" , "Kris Pister" , "Joe Polastre" =20 cc 6lowpan <6lowpan@lists.ietf.org>=20 Subject RE: [6lowpan] Rechartering consensus... =20 =20 =20 Hi Carsten, Yes, I suspect we want to alter the wording of a requirement in the charter. I've not seen similar text in RFC 4919 but I might have missed it. Rather, the RFC states in page 5 the requirement on a routing protocol. We want IPv6 in the sensor space ASAP so that applications in edge servers can be developed for it and 6LoWPAN is a major step on that path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you name it) are being deployed in the field and it would be great that the standard versions move to IPv6 as the de facto network layer and provide the associated LINK abstraction. I understand that the SP100-NetTrans task group has already taken the position to use 6LoWPAN as the network layer. A mesh under is one fine way to provide the link abstraction that IP needs, and a frame relay PVC based cloud is the proof that the model works. There is little question in my mind that 6LoWPAN can work with WiHART or similar once they provide this abstraction. What's tricky is the word "requires" in the proposed re-charter that Geoff sent in June for this thread. A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will have trouble optimizing the support of multicast upon which IPv6 relies for basic operations. Also, when we consider the self-forming, self-healing characteristics that we are looking for, then some history might help us avoid past mistakes. There have been a number of attempts to provide mesh under mode in the WAN space, including PNNI, NBBS etc...=20 After years of trials and failure, IP routing has emerged to be the most consistent solution to optimize end-to-end connectivity, with the tooling and management support that comes with it. Further, this enabled a new virtual switched network, MPLS, which benefits from IP routing for its path computation, optimization (Traffic Engineering Constrained Path) and isolation (Virtual Private Networks).=20 So in my mind, it is not true that 6LoWPAN requires a mesh under protocol. What is true is that the routing that 6LoWPAN requires would largely benefit from IP technology should it be IP based. As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management. So my proposal is: - work with external standard groups such as HCF and SP100 to insure that 6LoWPAN is compatible with their link abstractions. - work with the routing area to provide an alternate IP-based routing over solution What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: Monday, August 27, 2007 6:15 PM >To: Kris Pister >Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] Rechartering consensus... > >On Aug 27 2007, at 17:57, Kris Pister wrote: > >> 6lowpan requires a mesh routing protocol below the IP layer. >> >> For sure the word "requires" is incorrect. > >I'm sure the term "6lowpan" can be redefined to make this statement >true. >For now, RFC4919 takes the stance that L2 routing ("mesh") is an >integral part of the 6lowpan requirements. >If we want to change this, I'd like to hear a good argument why this >recent consensus is no longer valid. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan ------_=_NextPart_001_01C7E988.0060E54F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Rene:

 

I was discussing the VPN = functionality. It could be possible to deploy VPN up to the sensors and even split a = sensor network into multiple VPNs though that one is really far fetched. The = point is that for a same crypto cost, end to end security at IP level avoids the = risk of the gateway being compromised: Same discussion exactly as 802.11e/EAP = vs. VPN. in, say, 802.11 networks…

 

Pascal

From: Rene = Struik [mailto:RStruik@certicom.com]
Sent: Tuesday, August 28, = 2007 3:41 PM
To: Pascal Thubert = (pthubert)
Cc: 6lowpan; Carsten = Bormann; Joe Polastre; Kris Pister
Subject: RE: [6lowpan] Rechartering consensus...

 


Dear Pascal:

With due respect, I am not clear how this would "better" security at = all, since I do not know what your metric is. Please explain. =

More generally, it seems you would do the community a favor if you could = expand in some detail on trust lifecycle management and outline the resources = (crypto primitives, implementation cost protocols (both in hardware/software), = time latency, packet expansion, etc.) required to implement IP security with sensors. Some references to peer-reviewed papers that elaborate on this = would also be helpful.

Best regards, Rene

=3D=3D=3D=3D
[from the 6lowpan thread]

As Kris and
Joe discussed in this thread, IP routing = would enable us to extend the
MPLS network down to the sensors, for a = better security and QoS
management. =


Rene
-----
Certicom Research
http://www.certicom.com

"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> =

08/28/2007 05:05 AM

To

"Carsten Bormann" <cabo@tzi.org>, "Kris Pister" <pister@eecs.berkeley.edu>, "Joe Polastre" <joe@polastre.com>

cc

6lowpan = <6lowpan@lists.ietf.org>

Subject

RE: [6lowpan] Rechartering = consensus...

 

 

 




Hi Carsten,

Yes, I suspect we want to alter the = wording of a requirement in the
charter. I've not seen similar text in = RFC 4919 but I might have missed
it. Rather, the RFC states in page 5 the requirement on a routing
protocol.

We want IPv6 in the sensor space ASAP so = that applications in edge
servers can be developed for it and = 6LoWPAN is a major step on that
path. Proprietary versions of mesh under = protocols (TSMP, X-mesh, you
name it) are being deployed in the field = and it would be great that the
standard versions move to IPv6 as the de = facto network layer and provide
the associated LINK abstraction. I = understand that the SP100-NetTrans
task group has already taken the position = to use 6LoWPAN as the network
layer.

A mesh under is one fine way to provide = the link abstraction that IP
needs, and a frame relay PVC based cloud = is the proof that the model
works. There is little question in my = mind that 6LoWPAN can work with
WiHART or similar once they provide this abstraction. What's tricky is
the word "requires" in the = proposed re-charter that Geoff sent in June
for this thread.

A L2 mesh will provide a P2MP or NBMA = abstraction for IP, but will have
trouble optimizing the support of = multicast upon which IPv6 relies for
basic operations. Also, when we consider = the self-forming, self-healing
characteristics that we are looking for, = then some history might help us
avoid past mistakes. There have been a = number of attempts to provide
mesh under mode in the WAN space, = including PNNI, NBBS etc...

After years of trials and failure, IP = routing has emerged to be the most
consistent solution to optimize = end-to-end connectivity, with the
tooling and management support that comes = with it. Further, this enabled
a new virtual switched network, MPLS, = which benefits from IP routing for
its path computation, optimization = (Traffic Engineering Constrained
Path) and isolation (Virtual Private = Networks).

So in my mind, it is not true that = 6LoWPAN requires a mesh under
protocol. What is true is that the = routing that 6LoWPAN requires would
largely benefit from IP technology should = it be IP based. As Kris and
Joe discussed in this thread, IP routing = would enable us to extend the
MPLS network down to the sensors, for a = better security and QoS
management.

So my proposal is:
- work with external standard groups such = as HCF and SP100 to insure
that 6LoWPAN is compatible with their = link abstractions.
- work with the routing area to provide = an alternate IP-based routing
over solution

What do you think?

Pascal

>-----Original = Message-----
>From: Carsten Bormann = [mailto:cabo@tzi.org]
>Sent: Monday, August 27, 2007 6:15 = PM
>To: Kris Pister
>Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan
>Subject: Re: [6lowpan] Rechartering consensus...
>
>On Aug 27 2007, at 17:57, Kris Pister = wrote:
>
>> 6lowpan requires a mesh routing = protocol below the IP layer.
>>
>> For sure the word = "requires" is incorrect.
>
>I'm sure the term "6lowpan" = can be redefined to make this statement
>true.
>For now, RFC4919 takes the stance = that L2 routing ("mesh") is an
>integral part of the 6lowpan = requirements.
>If we want to change this, I'd like = to hear a good argument why this
>recent consensus is no longer = valid.
>
>Gruesse, Carsten

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

------_=_NextPart_001_01C7E988.0060E54F-- --===============1371480779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1371480779==-- From 6lowpan-bounces@ietf.org Tue Aug 28 11:43:35 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ3E6-00040Y-TQ; Tue, 28 Aug 2007 11:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ3E5-00040O-GX for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 11:43:33 -0400 Received: from mail.ca.certicom.com ([38.113.160.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ3E2-0006CE-Vu for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 11:43:33 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id B249F1002849E; Tue, 28 Aug 2007 07:45:42 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AxBNzUSJm1Z; Tue, 28 Aug 2007 07:45:33 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Tue, 28 Aug 2007 07:45:33 -0400 (EDT) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC04658A87@xmb-ams-337.emea.cisco.com> To: "Pascal Thubert \(pthubert\)" Subject: RE: [6lowpan] Rechartering consensus... MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: Rene Struik Date: Tue, 28 Aug 2007 11:38:55 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2|May 14, 2007) at 08/28/2007 11:38:57 AM, Serialize complete at 08/28/2007 11:38:57 AM X-Spam-Score: -0.0 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1576360917==" Errors-To: 6lowpan-bounces@ietf.org This is a multipart message in MIME format. --===============1576360917== Content-Type: multipart/alternative; boundary="=_alternative 00565D6F85257345_=" This is a multipart message in MIME format. --=_alternative 00565D6F85257345_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal: I am somewhat doubtful as to "same crypto cost", flexibility of trust=20 configurations, initial set-up, trust maintenance, enforcement of security = policies, and such. So far, I have not seen any evidence that this can be=20 realized on sensor networks with currently standardized IP protocols (but=20 perhaps I have the wrong set of a few hundred of papers on this... ).=20 However, I would love to be delighted and convinced that this can indeed=20 be realized after all. It may help if you could exemplify what you would like to realize, by=20 stating different steps in the key management lifecycle, security=20 objectives, crypto protocols and surrounding security policies to realize=20 these objectives, impact on message sizes, estimates on energy use, and=20 latency on low-cost platforms. Additionally, it would help to understand=20 what communication behavior one would like to support (e.g.. unicast,=20 multicast, broadcast) and how these communication behaviors are utilized=20 to facilitate, e.g., key updates. Finally, it would help to understand=20 what happens if a change of network topology occurs, e.g., network merge,=20 partition, replacement of device, etc., and how you envision this can be=20 facilitated in a secure fashion using currently standardized IP=20 protocols). Best regards, Rene=20 ----- Certicom Research http://www.certicom.com "Pascal Thubert \(pthubert\)" =20 08/28/2007 11:26 AM To "Rene Struik" cc "6lowpan" <6lowpan@lists.ietf.org>, "Carsten Bormann" , "Joe = Polastre" , "Kris Pister" Subject RE: [6lowpan] Rechartering consensus... Hi Rene: =20 I was discussing the VPN functionality. It could be possible to deploy VPN = up to the sensors and even split a sensor network into multiple VPNs=20 though that one is really far fetched. The point is that for a same crypto = cost, end to end security at IP level avoids the risk of the gateway being = compromised: Same discussion exactly as 802.11e/EAP vs. VPN. in, say,=20 802.11 networks? =20 Pascal From: Rene Struik [mailto:RStruik@certicom.com]=20 Sent: Tuesday, August 28, 2007 3:41 PM To: Pascal Thubert (pthubert) Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris Pister Subject: RE: [6lowpan] Rechartering consensus... =20 Dear Pascal:=20 With due respect, I am not clear how this would "better" security at all,=20 since I do not know what your metric is. Please explain.=20 More generally, it seems you would do the community a favor if you could=20 expand in some detail on trust lifecycle management and outline the=20 resources (crypto primitives, implementation cost protocols (both in=20 hardware/software), time latency, packet expansion, etc.) required to=20 implement IP security with sensors. Some references to peer-reviewed=20 papers that elaborate on this would also be helpful.=20 Best regards, Rene=20 =3D=3D=3D=3D=20 [from the 6lowpan thread]=20 As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management.=20 Rene=20 ----- Certicom Research http://www.certicom.com=20 "Pascal Thubert \(pthubert\)" =20 08/28/2007 05:05 AM=20 To "Carsten Bormann" , "Kris Pister"=20 , "Joe Polastre" =20 cc 6lowpan <6lowpan@lists.ietf.org>=20 Subject RE: [6lowpan] Rechartering consensus... =20 =20 =20 Hi Carsten, Yes, I suspect we want to alter the wording of a requirement in the charter. I've not seen similar text in RFC 4919 but I might have missed it. Rather, the RFC states in page 5 the requirement on a routing protocol. We want IPv6 in the sensor space ASAP so that applications in edge servers can be developed for it and 6LoWPAN is a major step on that path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you name it) are being deployed in the field and it would be great that the standard versions move to IPv6 as the de facto network layer and provide the associated LINK abstraction. I understand that the SP100-NetTrans task group has already taken the position to use 6LoWPAN as the network layer. A mesh under is one fine way to provide the link abstraction that IP needs, and a frame relay PVC based cloud is the proof that the model works. There is little question in my mind that 6LoWPAN can work with WiHART or similar once they provide this abstraction. What's tricky is the word "requires" in the proposed re-charter that Geoff sent in June for this thread. A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will have trouble optimizing the support of multicast upon which IPv6 relies for basic operations. Also, when we consider the self-forming, self-healing characteristics that we are looking for, then some history might help us avoid past mistakes. There have been a number of attempts to provide mesh under mode in the WAN space, including PNNI, NBBS etc...=20 After years of trials and failure, IP routing has emerged to be the most consistent solution to optimize end-to-end connectivity, with the tooling and management support that comes with it. Further, this enabled a new virtual switched network, MPLS, which benefits from IP routing for its path computation, optimization (Traffic Engineering Constrained Path) and isolation (Virtual Private Networks).=20 So in my mind, it is not true that 6LoWPAN requires a mesh under protocol. What is true is that the routing that 6LoWPAN requires would largely benefit from IP technology should it be IP based. As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management. So my proposal is: - work with external standard groups such as HCF and SP100 to insure that 6LoWPAN is compatible with their link abstractions. - work with the routing area to provide an alternate IP-based routing over solution What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: Monday, August 27, 2007 6:15 PM >To: Kris Pister >Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] Rechartering consensus... > >On Aug 27 2007, at 17:57, Kris Pister wrote: > >> 6lowpan requires a mesh routing protocol below the IP layer. >> >> For sure the word "requires" is incorrect. > >I'm sure the term "6lowpan" can be redefined to make this statement >true. >For now, RFC4919 takes the stance that L2 routing ("mesh") is an >integral part of the 6lowpan requirements. >If we want to change this, I'd like to hear a good argument why this >recent consensus is no longer valid. > >Gruesse, Carsten =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --=_alternative 00565D6F85257345_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Pascal:

I am somewhat doubtful as to "s= ame crypto cost", flexibility of trust configurations, initial set-up, trust maintenance, enforcement of security policies, and such. So far, I have not seen any evidence that this can be realized on sensor networks with currently standardized IP protocols (but perhaps I have the wrong set of a few hundred of papers on this... ). However, I would love to be delighted and convinced that this can indeed be realized after all.

It may help if you could exemplify w= hat you would like to realize, by stating different steps in the key management lifecycle, security objectives, crypto protocols and surrounding security policies to realize these objectives, impact on message sizes, estimates on energy use, and latency on low-cost platforms. Additionally, it would help to understand what communication behavior one would like to support (e.g.. unicast, multicast, broadcast) and how these communication behaviors are utilized to facilitate, e.g., key updates. Finally, it would help to understand what happens if a change of network topology occurs, e.g., netwo= rk merge, partition, replacement of device, etc., and how you envision this can be facilitated in a secure fashion using currently standardized IP protocols).

Best regards,

Rene
-----
Certicom Research
http://www.certicom.com


"Pascal Thubert = \(pthubert\)" <pthubert@cisco.com>

08/28/2007 11:26 AM

To
"Rene Struik" <RStruik@= certicom.com>
cc
"6lowpan" <6lowpan@list= s.ietf.org>, "Carsten Bormann" <cabo@tzi.org>, "Joe Polastre" <joe@polastre.com>, "Kris Pister" <pister@eecs.berkeley.= edu>
Subject
RE: [6lowpan] Rechartering consensus= ...





Hi Rene:
 
I was discussing the VPN = functionality. It could be possible to deploy VPN up to the sensors and even split a sensor network into multiple VPNs though that one is really far fetched. The point is that for a same crypto cost, end to end security at IP level avoids the risk of the gateway being compromised: Same discussion exactly as 802.1= 1e/EAP vs. VPN. in, say, 802.11 networks…
 
Pascal


From: Rene Struik [mailto:RStruik= @certicom.com]
Sent: Tuesday, August 28, 2007 3:41 PM
To: Pascal Thubert (pthubert)
Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris Pister
Subject: RE: [6lowpan] Rechartering consensus...
 

Dear Pascal:

With due respect, I am not clear how this would "better" security at all, since I do not know what your metric is. Please explain.

More generally, it seems you would do the community a favor if you could expand in some detail on trust lifecycle management and outline the resourc= es (crypto primitives, implementation cost protocols (both in hardware/softwar= e), time latency, packet expansion, etc.) required to implement IP security with sensors. Some references to peer-reviewed papers that elaborate on this would also be helpful.

Best regards, Rene

=3D=3D=3D=3D
[from the 6lowpan thread]
As Kris and
Joe discussed in this thread, IP routing would enable us to extend the
MPLS network down to the sensors, for a better security and QoS
management.


Rene
-----
Certicom Research
http://www.certicom.com

"Pascal Thubert = \(pthubert\)" <pthubert@cisco.com>

08/28/2007 05:05 AM


To
"Carsten Bormann&qu= ot; <cabo@tzi.org>, "Kris Pister" <pister@eecs.berkeley.edu&= gt;, "Joe Polastre" <joe@polastre.com>
cc
6lowpan <6lowpan@lists.ietf.org&g= t;
Subject
RE: [6lowpan] Rechartering consensus= ...

 


   





Hi Carsten,

Yes, I suspect we want to alter the wording of a requirement in the
charter. I've not seen similar text in RFC 4919 but I might have missed
it. Rather, the RFC states in page 5 the requirement on a routing
protocol.

We want IPv6 in the sensor space ASAP so that applications in edge
servers can be developed for it and 6LoWPAN is a major step on that
path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you
name it) are being deployed in the field and it would be great that the
standard versions move to IPv6 as the de facto network layer and provide
the associated LINK abstraction. I understand that the SP100-NetTrans
task group has already taken the position to use 6LoWPAN as the network
layer.

A mesh under is one fine way to provide the link abstraction that IP
needs, and a frame relay PVC based cloud is the proof that the model
works. There is little question in my mind that 6LoWPAN can work with
WiHART or similar once they provide this abstraction. What's tricky is
the word "requires" in the proposed re-charter that Geoff sent in June
for this thread.

A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will have
trouble optimizing the support of multicast upon which IPv6 relies for
basic operations. Also, when we consider the self-forming, self-healing
characteristics that we are looking for, then some history might help us
avoid past mistakes. There have been a number of attempts to provide
mesh under mode in the WAN space, including PNNI, NBBS etc...

After years of trials and failure, IP routing has emerged to be the most
consistent solution to optimize end-to-end connectivity, with the
tooling and management support that comes with it. Further, this enabled
a new virtual switched network, MPLS, which benefits from IP routing for
its path computation, optimization (Traffic Engineering Constrained
Path) and isolation (Virtual Private Networks).

So in my mind, it is not true that 6LoWPAN requires a mesh under
protocol. What is true is that the routing that 6LoWPAN requires would
largely benefit from IP technology should it be IP based. As Kris and
Joe discussed in this thread, IP routing would enable us to extend the
MPLS network down to the sensors, for a better security and QoS
management.

So my proposal is:
- work with external standard groups such as HCF and SP100 to insure
that 6LoWPAN is compatible with their link abstractions.
- work with the routing area to provide an alternate IP-based routing
over solution

What do you think?

Pascal

>-----Original Message-----
>From: Carsten Bormann [mailto:cabo@tzi.org]
>Sent: Monday, August 27, 2007 6:15 PM
>To: Kris Pister
>Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan
>Subject: Re: [6lowpan] Rechartering consensus...
>
>On Aug 27 2007, at 17:57, Kris Pister wrote:
>
>> 6lowpan requires a mesh routing protocol below the IP layer.
>>
>> For sure the word "requires" is incorrect.
>
>I'm sure the term "6lowpan" can be redefined to make this statement
>true.
>For now, RFC4919 takes the stance that L2 routing ("mesh") is an
>integral part of the 6lowpan requirements.
>If we want to change this, I'd like to hear a good argument why this
>recent consensus is no longer valid.
>
>Gruesse, Carsten

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan
--=_alternative 00565D6F85257345_=-- --===============1576360917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1576360917==-- From 6lowpan-bounces@ietf.org Tue Aug 28 12:43:00 2007 Return-path: <6lowpan-bounces@ietf.org> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ49b-0008KX-0y; Tue, 28 Aug 2007 12:42:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ49a-0008KS-Fm for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 12:42:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ49Y-0007uc-62 for 6lowpan@lists.ietf.org; Tue, 28 Aug 2007 12:42:58 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 28 Aug 2007 18:42:53 +0200 X-IronPort-AV: i="4.19,317,1183327200"; d="scan'208,217"; a="151689281:sNHT159258740" 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 l7SGgrUr029559; Tue, 28 Aug 2007 18:42: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 l7SGgo4F018276; Tue, 28 Aug 2007 16:42: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, 28 Aug 2007 18:42:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [6lowpan] Rechartering consensus... Date: Tue, 28 Aug 2007 18:42:38 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC04658ADC@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] Rechartering consensus... Thread-Index: Acfpijkak/0/dt5fSXiXaBJNGn0DJgAAP3HA References: <7892795E1A87F04CADFCCF41FADD00FC04658A87@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert \(pthubert\)" To: "Rene Struik" X-OriginalArrivalTime: 28 Aug 2007 16:42:50.0745 (UTC) FILETIME=[78F94E90:01C7E992] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=33252; t=1188319373; x=1189183373; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:=20RE=3A=20[6lowpan]=20Rechartering=20consensus... |Sender:=20; bh=JI712VQlRo3epBwa+ztNt1o51EHxbBHFAs9hs9rFh8M=; b=rqstqI/ykLBQiC0/m82nGxHwjGiwoepcG6bWDYjFHaM5vCbyowH9fJAzDHDvhugzrTiu5oK9 o4/dRvQ5c5/VU6NfG5eWjFXxyCXP+PhT7TvnLf52JgypI/d9hEOz50n3; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b13c40fa086532dc9cda406f708f0e2c Cc: 6lowpan <6lowpan@lists.ietf.org>, Carsten Bormann X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1053055255==" Errors-To: 6lowpan-bounces@ietf.org This is a multi-part message in MIME format. --===============1053055255== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E992.78A61593" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E992.78A61593 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rene =20 You can stack as many hundreds of pages as you like, you might still end up missing some. A mailing list such as this one is a good place to exchange ideas, share knowledge and solve problems, open-mindedly as opposed to aggressively. In the specific case, you might be interested in the work done at CAPWAP and EPC Global for RFID. This is an example of how provisioning can be done in this space, and that art might help 6LoWPAN in the chartered work on bootstrapping. Now if we already had all your answers figured out, I guess that this group and a number of others would be done, wouldn't it?=20 =20 On the constructive side, you're listing requirements that might or might not appear in various configurations. Other requirements might appear as well. For instance, in terms of security objectives, do we want to support global mobility - this was discussed in the context of the first objective of our new charter-? It might be difficult to do that if you constrain your security design to the mesh network. OTOH, RFC 4877 is a tool that you can use over the Internet, building on RFC 4301, 4103 and 4106. Do we want to reinvent that sort of wheel? =20 Also, I did not find that you rejected the concept that end to end security is generally an improvement over multiple consecutive secured networks, and I consider the initial case closed. =20 Pascal ________________________________ From: Rene Struik [mailto:RStruik@certicom.com]=20 Sent: Tuesday, August 28, 2007 5:39 PM To: Pascal Thubert (pthubert) Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris Pister Subject: RE: [6lowpan] Rechartering consensus... =20 Hi Pascal:=20 I am somewhat doubtful as to "same crypto cost", flexibility of trust configurations, initial set-up, trust maintenance, enforcement of security policies, and such. So far, I have not seen any evidence that this can be realized on sensor networks with currently standardized IP protocols (but perhaps I have the wrong set of a few hundred of papers on this... ). However, I would love to be delighted and convinced that this can indeed be realized after all.=20 It may help if you could exemplify what you would like to realize, by stating different steps in the key management lifecycle, security objectives, crypto protocols and surrounding security policies to realize these objectives, impact on message sizes, estimates on energy use, and latency on low-cost platforms. Additionally, it would help to understand what communication behavior one would like to support (e.g.. unicast, multicast, broadcast) and how these communication behaviors are utilized to facilitate, e.g., key updates. Finally, it would help to understand what happens if a change of network topology occurs, e.g., network merge, partition, replacement of device, etc., and how you envision this can be facilitated in a secure fashion using currently standardized IP protocols).=20 Best regards,=20 Rene=20 ----- Certicom Research http://www.certicom.com=20 "Pascal Thubert \(pthubert\)" =20 08/28/2007 11:26 AM=20 To "Rene Struik" =20 cc "6lowpan" <6lowpan@lists.ietf.org>, "Carsten Bormann" , "Joe Polastre" , "Kris Pister" =20 Subject RE: [6lowpan] Rechartering consensus... =20 =20 =20 Hi Rene:=20 =20 I was discussing the VPN functionality. It could be possible to deploy VPN up to the sensors and even split a sensor network into multiple VPNs though that one is really far fetched. The point is that for a same crypto cost, end to end security at IP level avoids the risk of the gateway being compromised: Same discussion exactly as 802.11e/EAP vs. VPN. in, say, 802.11 networks...=20 =20 Pascal=20 =20 ________________________________ From: Rene Struik [mailto:RStruik@certicom.com]=20 Sent: Tuesday, August 28, 2007 3:41 PM To: Pascal Thubert (pthubert) Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris Pister Subject: RE: [6lowpan] Rechartering consensus...=20 =20 Dear Pascal:=20 With due respect, I am not clear how this would "better" security at all, since I do not know what your metric is. Please explain.=20 More generally, it seems you would do the community a favor if you could expand in some detail on trust lifecycle management and outline the resources (crypto primitives, implementation cost protocols (both in hardware/software), time latency, packet expansion, etc.) required to implement IP security with sensors. Some references to peer-reviewed papers that elaborate on this would also be helpful.=20 Best regards, Rene=20 =3D=3D=3D=3D=20 [from the 6lowpan thread]=20 As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management.=20 Rene=20 ----- Certicom Research http://www.certicom.com=20 "Pascal Thubert \(pthubert\)" =20 08/28/2007 05:05 AM=20 =20 To "Carsten Bormann" , "Kris Pister" , "Joe Polastre" =20 cc 6lowpan <6lowpan@lists.ietf.org>=20 Subject RE: [6lowpan] Rechartering consensus... =20 =20 =20 =20 Hi Carsten, Yes, I suspect we want to alter the wording of a requirement in the charter. I've not seen similar text in RFC 4919 but I might have missed it. Rather, the RFC states in page 5 the requirement on a routing protocol. We want IPv6 in the sensor space ASAP so that applications in edge servers can be developed for it and 6LoWPAN is a major step on that path. Proprietary versions of mesh under protocols (TSMP, X-mesh, you name it) are being deployed in the field and it would be great that the standard versions move to IPv6 as the de facto network layer and provide the associated LINK abstraction. I understand that the SP100-NetTrans task group has already taken the position to use 6LoWPAN as the network layer. A mesh under is one fine way to provide the link abstraction that IP needs, and a frame relay PVC based cloud is the proof that the model works. There is little question in my mind that 6LoWPAN can work with WiHART or similar once they provide this abstraction. What's tricky is the word "requires" in the proposed re-charter that Geoff sent in June for this thread. A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will have trouble optimizing the support of multicast upon which IPv6 relies for basic operations. Also, when we consider the self-forming, self-healing characteristics that we are looking for, then some history might help us avoid past mistakes. There have been a number of attempts to provide mesh under mode in the WAN space, including PNNI, NBBS etc...=20 After years of trials and failure, IP routing has emerged to be the most consistent solution to optimize end-to-end connectivity, with the tooling and management support that comes with it. Further, this enabled a new virtual switched network, MPLS, which benefits from IP routing for its path computation, optimization (Traffic Engineering Constrained Path) and isolation (Virtual Private Networks).=20 So in my mind, it is not true that 6LoWPAN requires a mesh under protocol. What is true is that the routing that 6LoWPAN requires would largely benefit from IP technology should it be IP based. As Kris and Joe discussed in this thread, IP routing would enable us to extend the MPLS network down to the sensors, for a better security and QoS management. So my proposal is: - work with external standard groups such as HCF and SP100 to insure that 6LoWPAN is compatible with their link abstractions. - work with the routing area to provide an alternate IP-based routing over solution What do you think? Pascal >-----Original Message----- >From: Carsten Bormann [mailto:cabo@tzi.org] >Sent: Monday, August 27, 2007 6:15 PM >To: Kris Pister >Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan >Subject: Re: [6lowpan] Rechartering consensus... > >On Aug 27 2007, at 17:57, Kris Pister wrote: > >> 6lowpan requires a mesh routing protocol below the IP layer. >> >> For sure the word "requires" is incorrect. > >I'm sure the term "6lowpan" can be redefined to make this statement >true. >For now, RFC4919 takes the stance that L2 routing ("mesh") is an >integral part of the 6lowpan requirements. >If we want to change this, I'd like to hear a good argument why this >recent consensus is no longer valid. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan=20 ------_=_NextPart_001_01C7E992.78A61593 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Rene

 

You can stack as many hundreds of = pages as you like, you might still end up missing some. A mailing list such as = this one is a good place to exchange ideas, share knowledge and solve problems, = open-mindedly as opposed to aggressively. In the specific case, you might be = interested in the work done at CAPWAP and EPC Global for RFID. This is an example of = how provisioning can be done in this space, and that art might help 6LoWPAN in the = chartered work on bootstrapping. Now if we already had all your answers figured = out, I guess that this group and a number of others would be done, = wouldn’t it?

 

On the constructive side, = you’re listing requirements that might or might not appear in various = configurations. Other requirements might appear as well. For instance, in terms of = security objectives, do we want to support global mobility – this was = discussed in the context of the first objective of our new charter-? It might be = difficult to do that if you constrain your security design to the mesh network. = OTOH, RFC 4877 is a tool that you can use over the Internet, building on RFC 4301, = 4103 and 4106. Do we want to reinvent that sort of = wheel?

 

Also, I did not find that you = rejected the concept that end to end security is generally an improvement over = multiple consecutive secured networks, and I consider the initial case = closed.

 

Pascal

From: Rene = Struik [mailto:RStruik@certicom.com]
Sent: Tuesday, August 28, = 2007 5:39 PM
To: Pascal Thubert = (pthubert)
Cc: 6lowpan; Carsten = Bormann; Joe Polastre; Kris Pister
Subject: RE: [6lowpan] Rechartering consensus...

 


Hi Pascal:

I am somewhat doubtful as to "same crypto cost", flexibility of = trust configurations, initial set-up, trust maintenance, enforcement of = security policies, and such. So far, I have not seen any evidence that this can = be realized on sensor networks with currently standardized IP protocols = (but perhaps I have the wrong set of a few hundred of papers on this... ). = However, I would love to be delighted and convinced that this can indeed be = realized after all.

It may help if you could exemplify what you would like to realize, by = stating different steps in the key management lifecycle, security objectives, = crypto protocols and surrounding security policies to realize these objectives, = impact on message sizes, estimates on energy use, and latency on low-cost = platforms. Additionally, it would help to understand what communication behavior = one would like to support (e.g.. unicast, multicast, broadcast) and how these communication behaviors are utilized to facilitate, e.g., key updates. = Finally, it would help to understand what happens if a change of network topology occurs, e.g., network merge, partition, replacement of device, etc., and = how you envision this can be facilitated in a secure fashion using currently = standardized IP protocols).

Best regards,

Rene
-----
Certicom Research
http://www.certicom.com

"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> =

08/28/2007 11:26 AM

To

"Rene Struik" <RStruik@certicom.com>

cc

"6lowpan" = <6lowpan@lists.ietf.org>, "Carsten Bormann" <cabo@tzi.org>, "Joe = Polastre" <joe@polastre.com>, "Kris Pister" <pister@eecs.berkeley.edu>

Subject

RE: [6lowpan] Rechartering = consensus...

 

 

 




Hi Rene:
 
I was discussing the VPN functionality. It could be = possible to deploy VPN up to the sensors and even split a sensor network into = multiple VPNs though that one is really far fetched. The point is that for a same = crypto cost, end to end security at IP level avoids the risk of the gateway = being compromised: Same discussion exactly as 802.11e/EAP vs. VPN. in, say, = 802.11 networks…
 
Pascal

 


From: Rene = Struik [mailto:RStruik@certicom.com]
Sent: Tuesday, August 28, 2007 3:41 PM
To: Pascal Thubert (pthubert)
Cc: 6lowpan; Carsten Bormann; Joe Polastre; Kris = Pister
Subject: RE: [6lowpan] Rechartering = consensus...
 

Dear Pascal:

With due respect, I am not clear how this would "better" = security at all, since I do not know what your metric is. Please explain. =

More generally, it seems you would do the community a favor if you could = expand in some detail on trust lifecycle management and outline the resources = (crypto primitives, implementation cost protocols (both in hardware/software), = time latency, packet expansion, etc.) required to implement IP security with sensors. Some references to peer-reviewed papers that elaborate on this = would also be helpful.

Best regards, Rene

=3D=3D=3D=3D
[from the 6lowpan thread]

As Kris and
Joe discussed in this thread, IP routing would enable us to extend = the
MPLS network down to the sensors, for a better security and QoS
management.


Rene
-----
Certicom Research
http://www.certicom.com

"Pascal Thubert \(pthubert\)" <pthubert@cisco.com> =

08/28/2007 05:05 AM

 

To

"Carsten Bormann" <cabo@tzi.org>, "Kris Pister" <pister@eecs.berkeley.edu>, "Joe Polastre" <joe@polastre.com>

cc

6lowpan = <6lowpan@lists.ietf.org>

Subject

RE: [6lowpan] Rechartering = consensus...


 

 

 

 





Hi Carsten,

Yes, I suspect we want to alter the wording of a requirement in the
charter. I've not seen similar text in RFC 4919 but I might have = missed
it. Rather, the RFC states in page 5 the requirement on a routing
protocol.

We want IPv6 in the sensor space ASAP so that applications in edge
servers can be developed for it and 6LoWPAN is a major step on that
path. Proprietary versions of mesh under protocols (TSMP, X-mesh, = you
name it) are being deployed in the field and it would be great that = the
standard versions move to IPv6 as the de facto network layer and = provide
the associated LINK abstraction. I understand that the = SP100-NetTrans
task group has already taken the position to use 6LoWPAN as the = network
layer.

A mesh under is one fine way to provide the link abstraction that IP
needs, and a frame relay PVC based cloud is the proof that the model
works. There is little question in my mind that 6LoWPAN can work = with
WiHART or similar once they provide this abstraction. What's tricky = is
the word "requires" in the proposed re-charter that Geoff sent = in June
for this thread.

A L2 mesh will provide a P2MP or NBMA abstraction for IP, but will = have
trouble optimizing the support of multicast upon which IPv6 relies = for
basic operations. Also, when we consider the self-forming, = self-healing
characteristics that we are looking for, then some history might help = us
avoid past mistakes. There have been a number of attempts to provide
mesh under mode in the WAN space, including PNNI, NBBS etc...

After years of trials and failure, IP routing has emerged to be the = most
consistent solution to optimize end-to-end connectivity, with the
tooling and management support that comes with it. Further, this = enabled
a new virtual switched network, MPLS, which benefits from IP routing = for
its path computation, optimization (Traffic Engineering Constrained
Path) and isolation (Virtual Private Networks).

So in my mind, it is not true that 6LoWPAN requires a mesh under
protocol. What is true is that the routing that 6LoWPAN requires = would
largely benefit from IP technology should it be IP based. As Kris = and
Joe discussed in this thread, IP routing would enable us to extend = the
MPLS network down to the sensors, for a better security and QoS
management.

So my proposal is:
- work with external standard groups such as HCF and SP100 to insure
that 6LoWPAN is compatible with their link abstractions.
- work with the routing area to provide an alternate IP-based = routing
over solution

What do you think?

Pascal

>-----Original Message-----
>From: Carsten Bormann [mailto:cabo@tzi.org]
>Sent: Monday, August 27, 2007 6:15 PM
>To: Kris Pister
>Cc: Carsten Bormann; Pascal Thubert (pthubert); 6lowpan
>Subject: Re: [6lowpan] Rechartering consensus...
>
>On Aug 27 2007, at 17:57, Kris Pister wrote:
>
>> 6lowpan requires a mesh routing protocol below the IP = layer.
>>
>> For sure the word "requires" is incorrect.
>
>I'm sure the term "6lowpan" can be redefined to make this statement
>true.
>For now, RFC4919 takes the stance that L2 routing ("mesh") = is an
>integral part of the 6lowpan requirements.
>If we want to change this, I'd like to hear a good argument why = this
>recent consensus is no longer valid.
>
>Gruesse, Carsten

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

------_=_NextPart_001_01C7E992.78A61593-- --===============1053055255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www1.ietf.org/mailman/listinfo/6lowpan --===============1053055255==--