From roll-bounces@ietf.org Mon Jun 2 02:20:39 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B1928C137; Mon, 2 Jun 2008 02:20:39 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED523A6CA6 for ; Mon, 2 Jun 2008 02:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTo1rGcni3mI for ; Mon, 2 Jun 2008 02:20:37 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by core3.amsl.com (Postfix) with ESMTP id 2C5F83A6CC5 for ; Mon, 2 Jun 2008 02:15:36 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m529FQbp010893; Mon, 2 Jun 2008 12:15:26 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 31499-355-63; Mon, 2 Jun 2008 12:15:25 +0300 (EEST) Received: from [130.233.152.99] (e3n-3.netlab.hut.fi [130.233.152.99]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id m529ERVk009181; Mon, 2 Jun 2008 12:14:28 +0300 Message-ID: <4843B9F3.50503@tkk.fi> Date: Mon, 02 Jun 2008 12:14:27 +0300 From: Jukka MJ Manner User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: JP Vasseur References: In-Reply-To: X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: ROLL WG Subject: Re: [Roll] Some thoughts on the requirements documents [2nd try] X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, thanks for the clarification. So we work in parallel tracks for now, but then the hard part comes, when we try to figure out what are the commonalities, and whether we need separate solutions (and how many), as Miguel mentioned. The whole point of my initial message was to try to make this second phase, to look into the commonalities, start a bit earlier, to have more time to find a rough consensus. Regards, Jukka JP Vasseur wrote: > Hi, > > > On 5/30/08 10:16 AM, "Jukka MJ Manner" wrote: > >> Hi JP, >> >> Don't get me wrong, I'm not complaining as you seem to think. >> Application driven approach is fine. I'm trying to understand how four >> sets of requirements (in the broad sense incl. security), partly >> mutually excluding, are used in the future. Is the WG in fact going >> towards 4 distinct parallel tracks in the survey, and specification of >> the architecture? > > No, the survey will look take into account all the requirements spelled out > in the 4 requirement documents. And of course, the architecture ID and > potential protocol work will not have parallel tracks. > > So it is a non-goal to have a unified vision of how >> routing in sensor networks in the broad sense should perform. > > This only place whether we'll have parallel "tracks" is for the routing > requirements, which makes sense by essence. > > Thanks. > > JP. > >> Regards, >> Jukka >> >> JP Vasseur wrote: >>> Hi, >>> >>> >>> On 5/30/08 7:26 AM, "Jukka MJ Manner" wrote: >>> >>>> Hi JP, >>>> >>>> Some answers below. >>>> >>>> Jukka >>>> >>>> JP Vasseur wrote: >>>>> Hi Jukka, >>>>> >>>>> >>>>> On 5/29/08 4:17 AM, "Jukka MJ Manner" wrote: >>>>> >>>>>> [2nd try, 1st one bounced for some reason] >>>>> You need to subscribe to the list. >>>> I quite well know, thanks - I've been hanging around in the IETF for >>>> quite some time. And I was subscribed on the list, too. >>>> >>>>>> Hi >>>>>> >>>>>> I went through the various requirements documents and I'm a bit puzzled. >>>>>> In general the drafts are easy to read and we have many interesting >>>>>> scenarios described that open up nicely the environment. Yet, the drafts >>>>>> list similar requirements, there is very little difference in what they >>>>>> expect the routing service to do. >>>>> Two comments here: >>>>> (1) I think that there are significant differences between the requirement >>>>> set forth in the IDs, in term of functionality (e.g. constrained based >>>>> routing, scale, ....) >>>> To me the documents looked, in terms of _requirements_ very, very >>>> similar. Sure, there are small differences, but most of the things are >>>> the same. >>> Just to take one example, the specification of a routing protocol for a few >>> dozen of nodes (Home Automation) and several hundreds of thousands (urban >>> networks) is not exactly the same and has strong implications on the design. >>> >>>>> (2) There is no issue in having some similar routing requirements spelled >>>>> out in the IDs. This is a good news. >>>> The point is: what is the value of saying similar things many times? >>> Please look at the history of the WG. We decided to be application driven. >>> Thus the task consists of analyzing the routing requirements of (in our >>> case) 4 applications. If it turns out that several applications have similar >>> requirements, this is a perfectly good outcome, that will simply the task of >>> the WG to select or specify a new WG. >>> >>>>>> If we are to work on a solution later on, it is somewhat challenging to >>>>>> find out the what our goals truly are. >>>>> Sounds fairly obvious to me. How can you select/define a solution w/o >>>>> knowing what the requirements are ? >>>> The point was that the current drafts talk about usecases and list >>>> requirements in a mixed way, and repeat the same things. For the work to >>>> proceed, we eventually need to gather a single set of requirements, in >>>> particular to make the work more focused. The WG charter lists three >>>> usecase/reqs drafts, >>> 4 >>> >>> so does that mean we need to interpret all three >>>> concurrently while drafting solutions? Reading a single list of >>>> requirements would be easier, IMHO. >>> The super-set of requirements will be taken into account in the protocol >>> survey and then protocol selection/design. >>> >>>> E.g., one draft says we need to support couple hundred nodes, another >>>> one says we need to support couple thousand, one drafts says we could >>>> support multicast, another says that multicast is a must. >>> Ah so you saw some differences .... >>> >>> >>> Then there are >>>> those performance requirements (see below). >>>> >>>>>> IMHO, the requirements documents should focus on the scenarios and use >>>>>> cases of sensor networks, and list in general what the routing subsystem >>>>>> aught to do. These drafts should not use RFC 2119 language. >>>>>> >>>>> No. "Requirements" and "Use cases" (what we usually call "Applicability >>>>> statement" at the IETF) have very different purposes and what we need to do >>>>> according to our charter is first to spell out the requirement documents. >>>> The point is that if you look at the WGs in the IETF (NSIS, DCCP, PCN, >>>> 6lowpan, DNA, Netlmm, PANA, to name a few), they typically have one >>>> requirements/goals document describing in a single place what the work >>>> is tackling. Roll has 3 documents, it doesn't make it any simpler for an >>>> outsider, or probably even the WG, to figure out the requirements of the >>>> work. >>> This is the approach that we took. Note that other WGs took the same >>> approach (e.g. PCE, ...) and have been very successful. >>> >>>>> Note that RFC 2119 is very much appropriate in requirement documents. >>>> RFC2119 only talks about language issues, it doesn't tell how one should >>>> present requirements. >>> Please look around and you will see many requirements documents with RFC >>> 2119 language. >>> >>>>>> We need a separate document that lists the concrete goals of such a >>>>>> routing subsystem/protocol/architecture/service/whateveryouwanttocallit. >>>>> Not sure what you mean here. >>>> Use the current drafts as the use cases for Roll (without RFC2119 >>>> language). Then take out the requirements, use RFC2119 language and >>>> formulate a single document that can then be used to steer the design of >>>> a solution. >>> No, the requirements will make use of the RFC 2119 language. >>> >>>>>> Here there is also a clear need to separate functional and performance >>>>>> requirements. Typically performance values and goals are mutually >>>>>> exclusive, e.g., we can't have low power and high performance at the >>>>>> same time (with some definition of what is low and what is high). >>>>> One of the key reasons why the Internet has been so successful is that we >>>>> avoid to specify performances, so I disagree with your vision here. >>>> I kinda know that... Again, the point is that the drafts already do >>>> that, i.e., they specify absolute performance values to be achieved. I >>>> don't want to have strict performance values, but the WG documents >>>> already do that. Should these then be taken out from the existing drafts? >>> They are indicative. >>> >>>>> Of course, we will use performance related metric during our protocol >>>>> survey >>>>> evaluation. >>>> If the various WG requirement documents list performance values, then >>>> the WG must achieve those. (I would expect an eventual AD and/or IESG >>>> review to ask you to remove those performance requirements, though.) >>>> >>>>>> This latter document is used in both analysing the existing schemes and >>>>>> drafting a potential solution. >>>>> See >>>>> > http://www.ietf.org/internet-drafts/draft-levis-roll-protocols-survey-00.tx>>>> > t >>>> Yes, I know the draft. >>>> >>>>> I would expect that we end up with one >>>>>> general solution, where the parameters can be tuned to certain direction >>>>>> to make it fit different use cases. >>>>> Absolutely. >>>>> >>>>>> Actually, we also need to document the threats we see in the >>>>>> environment, and focus on the routing subsystem. The current drafts have >>>>>> some thoughts about that, but its only a beginning. >>>>> Please elaborate. >>>> Well, the industrial use cases draft already talks about trust issues >>>> and compartmentalizing things. The urban reqs also hints at some threats >>>> that would be present in that environment. The home reqs doesn't list >>>> any, yet. Several WGs have a separate document that highlights the >>>> threats, c.f. RFC4081 or RFC4832. >>>> >>>> Maybe I'm just the only one having difficulty in seeing where the work >>>> of the WG as a whole is going and what the goals are. In that case you >>>> can just neglect my questions and suggestions. >>> All comments are most welcome. But indeed, I haven't received any other >>> similar complaints. This is indeed quite the opposite with many comments >>> from regular contributors finding that the WG formed a few months ago was >>> moving fairly quickly. There is still quite some work on the requirements >>> IDs but we're getting close to our Milestone. >>> > -- Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 Helsinki University of Technology Fax: +358+(0)9+451 2474 Department of Communications Office: E309 (Otakaari 5) and Networking E-mail: jukka.manner@tkk.fi P.O. Box 3000, FIN-02015 TKK WWW: www.netlab.tkk.fi Finland Private:+358+(0)50+320 3018 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Jun 4 08:13:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666BA3A697B; Wed, 4 Jun 2008 08:13:48 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B7A3A68F0 for ; Wed, 4 Jun 2008 08:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=-0.661, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqLvPhrQZAzr for ; Wed, 4 Jun 2008 08:13:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6C65E3A6A99 for ; Wed, 4 Jun 2008 08:13:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,590,1204531200"; d="scan'208";a="108346104" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Jun 2008 08:13:49 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m54FDnrN023839 for ; Wed, 4 Jun 2008 08:13:49 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m54FDlWM020842 for ; Wed, 4 Jun 2008 15:13:49 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 11:13:48 -0400 Received: from 10.21.67.41 ([10.21.67.41]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 4 Jun 2008 15:13:48 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 04 Jun 2008 17:13:45 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: Detailed comments on draft-ietf-roll-home-routing-reqs Thread-Index: AcjGVZS9IxBTuhaAS0m4iHdje4EXOQ== Mime-version: 1.0 X-OriginalArrivalTime: 04 Jun 2008 15:13:48.0178 (UTC) FILETIME=[96A20720:01C8C655] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6466; t=1212592429; x=1213456429; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Detailed=20comments=20on=20draft-ietf-roll-home -routing-reqs=20 |Sender:=20; bh=4Qs5nnU8PsfKV9YyXQ3L5OcSMNvjUpIHYru8t0O0kK0=; b=CgzMRyB7EF5OxcvxordkVjT1bev/GUO5PDqWEOlIkzNGNYRdtZCMl7nGOG mN87AH7vNqEFWQz69nlsnTok7r2Npfon70RL5d37Z2BBVW3oF6L1hyvOO1hn jB5BYiiHOP; Authentication-Results: sj-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear WG, I made a detailed review of draft-ietf-roll-home-routing-reqs Here are my comments (not of equil importance): 1) idnits Checking nits according to http://www.ietf.org/ID-Checklist.html: = ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 2) Each acronym must be expanded the first time it is used (e.g. PANs in section 2) 3) Remove reference to I-D.culler-roll-routing-reqs (ID has expired) 4) Section 3.1 =B3Some existing = home automation solutions use a clever mix of a "subnet groupcast" message with no acknowledgement and no forwarding before sending acknowledged singlecast messages to each lighting device.=B2 This might be a good place to define the term =B3groupcast=B2 more carefull= y. 5) Section 3.1 =B3 Thus, a solution is needed for addressing groups of nodes without prior management of group membership in the receiving nodes. =B3 Is it a =B3must=B2 or a MUST? 6) Section 3.2 =B3 The power grid may experience periods where more wind-generated power is produced than is needed. Typically this may happen during night hours. The washing machine and dish washer may just as well work while power is cheap. The electric car should also charge its batteries on cheap power. =B3 -> Add the example of power dynamic pricing that can be used to regulate the operation of a set of devices in the home. 7) Section 3.2 " Most of these applications are mains powered and may thus provide reliable routing resources." I would suggest to reword the sentence. Indeed, a battery node may still provide reliable routing but this is a constrained resource (battery operated) that the routing decision may want to avoid if an alternate path exist. 8) As written section 3.4 is about auto-conf rather than routing (requires for auto-conf)? Would you want to slightly elaborate there? 9) section 3.5: " ROLL resources" ? Why would the router have to wait for some time ? Because you make the assumption of devices in deep sleep mode? 10) Section 3.6 S/ROLL devices/constrained devices or please define a "ROLL" device in the terminology section 11) Could you elaborate on the routing requirements here: " A plethora of applications could be developed for home alarm system: most of them, most of the time, have prevention and monitoring activity in which routing requirements are deterministic, but all of them have an alarm state in which nodes may burst an aperiodic alarm. " 12) Section 3.9: I guess that you meant " leaving only a few 100 bytes of RAM powered during the deep sleep phase." 13) Section 4.1: " The routing protocol must provide the ability to route a packet towards a single device (unicast), a set of devices (also referred to as "groupcast" in this document) or all devices (broadcast) in the house. - Don't you mean to use a MUST here ? - Please insert a section prior to this requirements on the definition of Groupcast. 14) You wrote: " Alternatively, a companion specification SHOULD define how to indirectly address a group of nodes on the application layer via classic broadcast in the network layer; e.g. by use of a bitmap in a header extension. " But you cannot have a SHOULD in this document on a document defined somewhere else. 15) You wrote: "[ABR NOTE: IETF-71 WG meeting indicated that the term "constrained" has a very specific meaning in the routing community inside IETF. What I understood was that the draft should be using the term "metric-based routing"]" I do not think so. The term "constrained based routing" used in this document is appropriate if what you require is to have the ability the compute the shortest path based on some metrics (there could be more than one metrics) taking into account some link or node constraints. If this is what you need, then you indeed refer to constrained based routing. Based on what you wrote " Simple battery-powered nodes such as movement sensors on garage doors and rain meters may not be able to assist in routing. Depending on the node type, the node never listens at all, listens rarely or makes contact on demand to a pre-configured target node. Attempting to communicate to such nodes may require long time before getting a response." You do refer to constrained based routing. 16) = "The routing protocol MUST support metric-based routing taking into account node properties (CPU, memory, level of energy, sleep intervals, safety/convenience of changing battery). " S/metric-based routing/constrained based routing. The metric-based routing refers to the ability to use different metrics to compute the shortest path, which is a different requirement ? Is that needed for Home Automation ? In your case you may either need: 1) Constrained based routing: e.g. Avoid a node whose battery level < X 2) Multi-metric based routing: assign different metrics for a specific link (for example, one metric to reflect the bandwidth, one metric to reflect the propagation delay, ...). 17) = " The routing protocol SHOULD make use of the fact that if not being able to deliver a packet, it is most likely that the sending node moved; rather than the rest of the network." You may want to be more explicit on what this actually translate to for the routing protocol. 18) Section 4.7. Please expand PAN when first used. 19) " home PAN MUST provide a set of features including 0 configuration of the routing protocol for a new node to be added to the network. " Do you really mean "0 configuration" ?? What about optional configuration of timers ? 20) " Furthermore, a failing node MUST NOT have a global impact on the routing protocol. " This is a very strong requirement ... Are you sure that this is what you mean? I feel more comfortable about your second 21) It would be nice if you could elaborate a little bit on the traffic pattern for the various use cases since health monitoring and alarm significantly differs on that aspect. Please provide some number of packet sizes, frequency at which packets are sent out, ... 22) Could you flesh out the security requirements ? 23) Acknolegment: list of people (if any) that you want to thank for their contribution/feed-backs/... 24) Remove [I-D.culler-roll-routing-reqs] as informative reference. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Jun 4 18:24:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204823A6961; Wed, 4 Jun 2008 18:24:31 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A0B3A6992 for ; Wed, 4 Jun 2008 18:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dFZSFnuyD+2 for ; Wed, 4 Jun 2008 18:24:29 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 15E763A6961 for ; Wed, 4 Jun 2008 18:24:26 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so273254wah.25 for ; Wed, 04 Jun 2008 18:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=PlEuRYWiT4LgyYESjYHlZQ09Vg3/cJg+Ut2p+9EcEGs=; b=n3GvPk3b3FNKuJP4SfsX2ePR60tgF8dbNrwrftoKkUOZak72g5NRw0uH/WMWuZj4ui wzDJPAepWwoyzz1Gu46EumyJjla+3NYkWSCvv+lTJDD2lL+DFekunTbAHykhy0jYWgR+ TZ8aBn1LjpWmoBB+xF1zayWlPnltA90iOfZzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=RBqRW2Kez7e6S15r6JOBddhROXOkC1hmfY6hNEi4wX2Wr5v4DfQxBvpx+W7qbSjmIO vpGHLn4XmM5Gjtdbt8b5lD6U3OACZgwORxYF466/HwpoV58RfCDJ+or09v7YW2SRhKub oOGJejP5KM6aeAp8wIgLqq35cD8ZJXV4fcXP0= Received: by 10.114.201.1 with SMTP id y1mr830797waf.216.1212629070514; Wed, 04 Jun 2008 18:24:30 -0700 (PDT) Received: from EM60-254-226-34.pool.e-mobile.ne.jp ( [60.254.226.34]) by mx.google.com with ESMTPS id v37sm4288435wah.44.2008.06.04.18.24.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Jun 2008 18:24:30 -0700 (PDT) From: Ryuji Wakikawa To: Miguel Sanchez In-Reply-To: <86c3ed7b0805301150u3eb6f137gc9fe8fb9295543c2@mail.gmail.com> References: <20080529093001.D1E7E3A6B6F@core3.amsl.com> <7A71A0CD-7B0E-4CEA-918B-BB3158FFBFA1@gmail.com> <86c3ed7b0805301150u3eb6f137gc9fe8fb9295543c2@mail.gmail.com> Message-Id: <9668780C-AF45-48CC-AD28-8B6028715C2F@gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 5 Jun 2008 10:24:19 +0900 X-Mailer: Apple Mail (2.924) Cc: roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hello Miguel, Thanks for your comments. On 2008/05/31, at 3:50, Miguel Sanchez wrote: > Hi Ryuji, > > > Here you have my comments. > > On page 8, Body Network: you mention air-bag control and 100msec = > latency. However, you later refer to the power train latency for = > the air-bag control (from 2 to 6 msec). OK, the document was not clear on this. 100msec latency is required for most of devices in the body network. = The air-bag control is an exception in the body network. > Next, on Infotainment Network: you mention a latency of 100msec = > (including phone communication) but as you put Electronic Toll = > Collection on the same network you later admit that latency for that = > has to be much lower. > > I find these two cases above confusing: having a certain latency for = > some services but one. (Not sure 100msec for the hands-free is going = > to be comfortable either). right. Section 2.2 tries to describe the current in-vehicle network. The current in-vehicle network (bus system) is specially designed to = meet the required latency per services. The category of in-vehicle network described in Section 2.2 are the = typical classification in vehicle industry. I will separate some exceptions such as air-bag and ETC from these = category. > Page 10, Path reliability: What is that? I know what you mean but = > you may want to elaborate on this concept. Two things I had in my mind are 1. link quality is considered as a metric of ROLL routing 2. try and error approach to detect the route errors might not be = appropriate for some services. > Page 13, Security: For encryption, key management needs to be = > addressed. right. We will add the texts for the key management in the next = revision. thanks, ryuji > > > Regards, > > Miguel S=E1nchez > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Jun 4 18:35:26 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70DEE3A6A09; Wed, 4 Jun 2008 18:35:26 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD163A68FB for ; Wed, 4 Jun 2008 18:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hurHuPY-BTt for ; Wed, 4 Jun 2008 18:35:24 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 5832D3A67A8 for ; Wed, 4 Jun 2008 18:35:24 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so373686rvf.49 for ; Wed, 04 Jun 2008 18:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=YAkMRLsyjIYORri+fLgsDhKxbto2j3xtXEZBeI/az/k=; b=lwx9/fstkYRvo5wNPYmmua5xzPmkZkbcu734o1lLEJBZ7o4n7xCgJzqVrhuNoS1mxd Fn0Q+7ezTS22KBJ4q+FPPGZMM1VnYjWpgfMrumOiL5GCb6Dw/rXBWGyU7qc2SlMGRzdu WSDKFASH1mvxVbTBKki2+wjCcyIcGk0Vay4go= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=v1RP6afgB99LOpESKc8aR71mJHRCh1e0LOpO5jCiqLz73+0zoOmsJNQ0IEfQCsHjou Dh3KLnExWN/8Qk6EfWHAaTRJwNhbbpLvnoyoBeaqiIYNwp/f5QwfubXd8MNtjLvD+d2S PYOGrMaSB6Uh0MBs7aPp17vQgbShnasWap9Uc= Received: by 10.114.148.2 with SMTP id v2mr841774wad.202.1212629726890; Wed, 04 Jun 2008 18:35:26 -0700 (PDT) Received: from EM60-254-226-34.pool.e-mobile.ne.jp ( [60.254.226.34]) by mx.google.com with ESMTPS id l22sm4336985waf.26.2008.06.04.18.35.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Jun 2008 18:35:26 -0700 (PDT) From: Ryuji Wakikawa To: =?EUC-KR?Q?=B1=E8=B9=CC=C1=A1[USN=BF=AC=B1=B8=B4=E3=B4=E7]?= In-Reply-To: <3daed01c8c5fb$05c50400$e72a0693@oasys.kt.co.kr> References: <20080529093001.D1E7E3A6B6F@core3.amsl.com> <3daed01c8c5fb$05c50400$e72a0693@oasys.kt.co.kr> Message-Id: <2ACEA2B7-74E5-49D2-911C-7B4211365790@gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 5 Jun 2008 10:35:11 +0900 X-Mailer: Apple Mail (2.924) Cc: roll@ietf.org Subject: Re: [Roll] Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org SGVsbG8gS2ltLAoKVGhhbmtzIGZvciBjb21tZW50cy4KCk9uIDIwMDgvMDYvMDQsIGF0IDEzOjI1 LCDquYDrr7jsoJBbVVNO7Jew6rWs64u064u5XSB3cm90ZToKPgo+IEhpLCBSeXVqaSwKPgo+IChI aSwgZXZlcnlvbmUsIHRoaXMgaXMgbXkgdmVyeSBmaXJzdCBwb3N0aW5nLiBJIGhvcGUgd2UgaGF2 ZSBtb3JlICAKPiBjaGFuY2VzIHRvIGRpc2N1c3MgYWxsIFJPTEwgdGhpbmdzIHRocm91Z2ggdGhl IG1haWxpbmcgbGlzdC4pCj4KPiBJIGZvdW5kIG91dCB0aGlzIGRvY3VtZW50IGlzIHByZXR0eSBp bnRlcmVzdGluZyBzaW5jZSBJIGFtIG5vdCBzbyAgCj4gZmFtaWxpYXIgd2l0aCB0aGUgc3ViamVj dCBhbmQgaXQgZ2l2ZXMgbWUgcXVpdGUgZ29vZCBsZXNzb25zLiAgCj4gSG93ZXZlciwgSSBhbHNv IGNvbnNpZGVyIGl0IG5lZWRzIHRvIGNsYXJpZnkgc29tZSBpc3N1ZXMgYW5kIGJlIG1vcmUgIAo+ IGVsYWJvcmF0ZS4gSGVyZSBhcmUgbXkgdGlwcy4KPgo+Cj4gCeKAoiAyLjMuIEluLVZlaGljbGUg TmV0d29yayBTaXplOiBJIGRvbuKAmXQgdGhpbmsgdmVyeSBzcGVjaWZpYyAgCj4gdmVoaWNsZSBz aXplIG5lZWRzIHRvIGJlIHByZXNlbnRlZCBoZXJlIHNpbmNlIGFsbCBhcmUgYXdhcmUgb2Ygcm91 Z2ggIAo+IHNpemVzIG9mIHZhcmlvdXMgdmVoaWNsZXMgYW5kIHJvdXRpbmcgcHJvdG9jb2wgaXMg bm90IHRoYXQgbXVjaCAgCj4gc2Vuc2l0aXZlIHRvIHRoZSBleGFjdCBuZXR3b3JrIHNpemUuIEFu ZCwgSSBhbSBub3QgcXVpdGUgc3VyZSB0aGF0ICAKPiB0aGlzIGtpbmQgb2YgZG9jdW1lbnQgaXMg ZmluZSB0byBtZW50aW9uIG9yIHJlZmVyIHRoZSBzcGVjaWZpYyAgCj4gcHJvZHVjdCBuYW1lIG9y IG1vZGVsIGxpa2UgTEVYVVMgYW5kIFRveW90YS4KCk9LLgpXZSB0cnkgdG8gZXhwbGFpbiB0aGUg bm9kZSBkZW5zaXR5IGlzIGV4dHJlbWVseSBoaWdoIGNvbXBhcmVkIHRvIG90aGVyICAKc2NlbmFy aW9zLgpXZSBjYW4gcmVtb3ZlIHRoZSBleGFtcGxlIHNwZWMuIG5vIGludGVudGlvbiB0byBwcm9t b3RlIHRveW90YSAgCnZlaGljbGVzIGluIElFVEY7LSkKCj4gCeKAoiAzLjEuIExvdyBQb3dlcjog eW91IG1lbnRpb25lZCB1bi1wb3dlcmVkIGRldmljZXMsIGJ1dCBJIGJlbGlldmUgIAo+IGFsbCBk ZXZpY2VzIHNob3VsZCBiZSBwb3dlcmVkIHRvIG9wZXJhdGUuIFNvIEkgdGhpbmsgeW91IG1heSBi ZSAgCj4gY29uZnVzZWQgd2l0aCBiYXR0ZXJ5LXBvd2VyZWQgZGV2aWNlcy4KCjotKQpyaWdodCwg d2Ugd2lsbCBmaXggdGhpcy4KCj4gCeKAoiAzLjcuIE5ldHdvcmsgQ29udmVyZ2VuY2U6IHRoZSBl eHBsYW5hdGlvbiBpbiB0aGUgZmlyc3QgcGFyYWdyYXBoICAKPiBpcyBhYm91dCByb3V0ZSByZWNv dmVyeS4gSSB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gd2l0aCBuZXR3b3JrICAKPiBjb252ZXJn ZW5jZSwgYnV0IEkgc3RpbGwgdGhpbmssIGZvciByb3V0aW5nIHJlcXVpcmVtZW50cywgbmV0d29y ayAgCj4gY29udmVyZ2VuY2UgaXMgbm90IHNvIHByb3BlciB0ZXJtIHJhdGhlciB0aGFuIHJvdXRl IHJlY292ZXJ5LiBBbmQgIAo+IHRoZSBzZWNvbmQgcGFyYWdyYXBoIGlzIG5vdCB0aGF0IHJlbGF0 ZWQgdG8gcm91dGluZyByZXF1aXJlbWVudHMuCgpvawoKPiAJ4oCiIDMuOC4gTWFuYWdlYWJpbGl0 eTogYXV0by1jb25maWd1cmF0aW9uIGlzIHJlcXVpcmVkIGluIHNvbWUgTExOICAKPiBzY2VuYXJp b3MsIGJ1dCByb3V0aW5nIHByb3RvY29sIGlzIG5vdCByZXNwb25zaWJsZSBmb3IgYXV0by0gCj4g Y29uZmlndXJhdGlvbiBvciBkaXJlY3RseSByZWxhdGVkIHRvIGl0LiBJIHRoaW5rIOKAnHJvdXRp bmcgcHJvdG9jb2wgIAo+IHNob3VsZCBiZSBleHRlbnNpYmxlIGZvciBuZXcgZGV2aWNlc+KAnSBp cyBlbm91Z2ggZm9yIHRoZSBleHBsYW5hdGlvbi4KPiAJ4oCiIDMuOS4gTW9iaWxpdHk6IHRoZXJl IGFyZSBkaWZmZXJlbnQga2luZHMgb2YgbW9iaWxpdHkuIEkgdGhpbmsgaXQgIAo+IGlzIGJldHRl ciB0byBtZW50aW9uIG5vZGUgbW9iaWxpdHkgcmF0aGVyIHRoYW4gbW9iaWxpdHkuIEFuZCBpbiB0 aGUgIAo+IGxhc3QgbGluZSwg4oCcdG8gYWRlcXVhdGUgY29uZGl0aW9uIGZvciBlYWNoIGRldmlj ZeKAnSBpcyBub3Qgd2VsbCAgCj4gdW5kZXJzdG9vZCBmb3IgbWUuIENvdWxkIHlvdSBleHBsYWlu PwoKVGhlIGxhc3QgbGluZSBpbmRpY2F0ZXMgdGhhdAp3aGVuIHRoZSBjb25kaXRpb24gb2YgYSBy b3V0ZSBwYXRoIGlzIGNoYW5nZWQsIHRoZSBST0xMIHJvdXRpbmcgc2hvdWxkICAKY2hhbmdlIHRo ZSBwYXRoIHRvIGZ1bGZpbGwgdGhlIHNlcnZpY2UgcmVxdWlyZW1lbnRzIChleC4gbGF0ZW5jeSku Cgo+IAnigKIgMy4xMCBTZWN1cml0eTogVGhpcyBzdWJzZWN0aW9uIHNlZW1zIHRvIGRlc2NyaWJl IGp1c3QgZ2VuZXJhbCAgCj4gc2VjdXJpdHkgaXNzdWVzIGluIHdpcmVsZXNzIG5ldHdvcmtzIG5v dCBzcGVjaWZpYyB0byByb3V0aW5nICAKPiByZXF1aXJlbWVudHMgZm9yIExMTi4gSXQgaXMgbmVl ZGVkIG1vcmUgc3BlY2lmaWMgc2VjdXJpdHkgY29uY2VybnMgIAo+IGZvciByb3V0aW5nIHJlcXVp cmVtZW50IHN1Y2ggYXMgZW5jcnlwdGlvbiBvZiByb3V0aW5nIGNvbnRyb2wgIAo+IG1lc3NhZ2Vz IG9yIG5vZGVzIGluIHRoZSBzZWxlY3RlZCBwYXRoIHdoaWNoIG5lZWQgdG8gYmUgYXV0aGVudGlj YXRlZC4KClRoYW5rcyBmb3IgYWxsIHlvdXIgY29tbWVudHMuCldlIHdpbGwgdXBkYXRlIHRoZSBk b2N1bWVudCAoaG9wZWZ1bGx5IGJlZm9yZSBEdWJsaW4pLgoKcmVnYXJkcwpyeXVqaQoKPgo+IEkg YW0gZXhwZWN0aW5nIHlvdXIgb3BpbmlvbiBvbiB0aGUgYWJvdmUgbXkgY29tbWVudHMuCj4KPiBU aGFuayB5b3UuCj4KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gS2ltLCBNaWplb20sIFBoLiBE LCBQLkUuCj4gU2VuaW9yIFJlc2VhcmNoZXIKPiBVU04gU2VydmljZSBEaXZpc2lvbgo+IEZ1dHVy ZSBUZWNobm9sb2d5IExhYm9yYXRvcnksIEtULCBTb3V0aCBLb3JlYQo+IFRlbC4gKzgyLTItNTI2 LTYwNjMKPiBDZWxsLiArODItMTAtOTg4My00OTUxCj4gRS1tYWlsOiBtamtpbUBrdC5jb20sIG1p amVvbUBnbWFpbC5jb20KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4KPiAtLS0tLeybkOuzuCDr qZTsi5zsp4AtLS0tLQo+IOuztOuCuCDsgqzrnow6ICJSeXVqaSBXYWtpa2F3YSIgPHJ5dWppLndh a2lrYXdhQGdtYWlsLmNvbT4KPiDrs7Trgrgg64Kg7KecOiAyMDA4LTA1LTI5IOyYpO2bhCA2OjQ4 OjIxCj4g67Cb64qUIOyCrOuejDogInJvbGxAaWV0Zi5vcmciIDxyb2xsQGlldGYub3JnPgo+IOyw uOyhsDogImgta3V3YWJhcmFAanAudG95b3RhLWl0Yy5jb20iIDxoLWt1d2FiYXJhQGpwLnRveW90 YS1pdGMuY29tPgo+IOygnOuqqTogW1JvbGxdIEZ3ZDogSS1EIEFjdGlvbjpkcmFmdC13YWtpa2F3 YS1yb2xsLWludmVoaWNsZS0gCj4gcmVxcy0wMC50eHQKPgo+IEhlbGxvIGFsbCwKPgo+IFdlIHB1 Ymxpc2hlZCBhIG5ldyByZXF1aXJlbWVudCBkb2N1bWVudCBmb3IgUk9MTCByb3V0aW5nIHByb3Rv Y29scy4KPiBBbHRob3VnaCBhbiBpbi12ZWhpY2xlIG5ldHdvcmsgaXMgbm90IGN1cnJlbnRseSBj aGFydGVyZWQgaW4gV0csCj4gd2UgYXJlIHZlcnkgaW50ZXJlc3RlZCBpbiBST0xMIGFjdGl2aXR5 IGZvciB0aGUgZnV0dXJlIGF1dG9tb2JpbGUuCj4KPiBBcyBKdWtrYSAgbWVudGlvbmVkLCBzb21l IHJlcXVpcmVtZW50cyBhcmUgdmVyeSBzaW1pbGFyIHRvIG90aGVyCj4gcmVxdWlyZW1lbnRzIGRv Y3VtZW50cy4KPiBXZSB0cmllZCB0byBoaWdobGlnaHQgdGhlIGRpZmZlcmVuY2VzIGluIHRoZSBk b2N1bWVudC4KPgo+IEFueSBmZWVkYmFjayB3aWxsIGJlIGFwcHJlY2lhdGVkLgo+Cj4gdGhhbmtz LAo+IHJ5dWppCj4KPiBCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToKPgo+ID4gRnJvbTogSW50ZXJu ZXQtRHJhZnRzQGlldGYub3JnCj4gPiBkYXRlOiAyMDA4LzUvMjkxODozMDowMTpKU1QKPiA+IFRv OiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcKPiA+IFN1YmplY3Q6IEktRCBBY3Rpb246ZHJhZnQtd2Fr aWthd2Etcm9sbC1pbnZlaGljbGUtcmVxcy0wMC50eHQKPiA+IFJlcGx5LXRvOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcKPiA+Cj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMKPiA+IGRpcmVjdG9yaWVzLgo+ID4KPiA+ ICAgICAgIFRpdGxlICAgICAgICAgICA6IEluLVZlaGljbGUgUm91dGluZyBSZXF1aXJlbWVudHMg aW4gTG93ICAKPiBQb3dlciBhbmQKPiA+IExvc3N5IE5ldHdvcmtzCj4gPiAgICAgICBBdXRob3Io cykgICAgICAgOiBSLiBXYWtpa2F3YSwgSC4gS3V3YWJhcmEKPiA+ICAgICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LXdha2lrYXdhLXJvbGwtaW52ZWhpY2xlLXJlcXMtMDAudHh0Cj4gPiAgICAg ICBQYWdlcyAgICAgICAgICAgOiAyMAo+ID4gICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAwOC0w NS0yOQo+ID4KPiA+IFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgdGhlIHJvdXRpbmcgcmVxdWlyZW1l bnRzIGZvciBpbi12ZWhpY2xlIGxvdwo+ID4gcG93ZXIgYW5kIGxvc3N5IG5ldHdvcmtzLiAgQXV0 b21vYmlsZXMgYXJlIGFscmVhZHkgZXF1aXBwZWQgd2l0aAo+ID4gc2V2ZXJhbCBzZW5zb3JzIGFu ZCBkZXZpY2VzIG5hbWVkIEVsZWN0cm9uaWMgQ29udHJvbCBVbml0IChFQ1UpIGZvcgo+ID4gY29u dHJvbGxpbmcsIG1vbml0b3JpbmcgYW5kIGVudGVydGFpbm1lbnQsIGV0Yy4gIEZvciB0aGUgZnV0 dXJlIGluLQo+ID4gdmVoaWNsZSBuZXR3b3JrcywgdGhlIHNoaWZ0IHRvIHdpcmVsZXNzIGlzIGRl c2lyYWJsZSBkdWUgdG8gaGVhdnkKPiA+IHdlaWdodCBhbmQgdm9sdW1lIG9mIGNhYmxlcyBpbiB2 ZWhpY2xlcyBhbmQgdG8gYmUgYWJsZSB0byAgCj4gZWZmaWNpZW50bHkKPiA+IGluc3RhbGwgZGV2 aWNlcy4gIEhvd2V2ZXIsIHdpdGggdGhlIGxpbWl0YXRpb24gb2YgbG93IHBvd2VyLCBpbi0KPiA+ IHZlaGljbGUgbmV0d29yayBzdGlsbCByZXF1aXJlcyByZWxpYWJpbGl0eSBhbmQgc2NhbGFiaWxp dHkgaW4gbmF0dXJlCj4gPiBvZiB0aGUgcm9sbHMgb2YgRUNVLiAgVGhlIHJvdXRpbmcgcHJvdG9j b2wgc2hvdWxkIHN1cHBvcnQgdGhlCj4gPiBmZWF0dXJlcyBvZiBsb3ctcG93ZXIsIGhpZ2gtcmVs aWFiaWxpdHksIFN1Ym5ldHRpbmcsIFFvUywgTW9iaWxpdHksCj4gPiBldGMuICBUaGlzIGRvY3Vt ZW50IGJyaWVmbHkgZXhwbGFpbnMgdGhlIGluLXZlaGljbGUgbmV0d29ya3MgYW5kCj4gPiBFQ1Vz LCB0aGVuIGRpc2N1c3NlcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgZnV0dXJlIHdpcmVsZXNz IGluLQo+ID4gdmVoaWNsZSBuZXR3b3Jrcy4KPiA+Cj4gPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5l dC1EcmFmdCBpczoKPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXdha2lrYXdhLXJvbGwtaW52ZWhpY2xlLXJlcXMtMDAudHh0Cj4gPgo+ID4gSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ogo+ID4gZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8KPiA+Cj4gPiBCZWxvdyBpcyB0aGUgZGF0YSB3aGlj aCB3aWxsIGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyCj4gPiBpbXBsZW1lbnRh dGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQo+ ID4gSW50ZXJuZXQtRHJhZnQuCj4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fClJvbGwgbWFpbGluZyBsaXN0ClJvbGxAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsCg== From roll-bounces@ietf.org Fri Jun 6 04:57:57 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666C228C1C7; Fri, 6 Jun 2008 04:57:57 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78A133A67AE for ; Fri, 6 Jun 2008 02:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NbnQntCZC+E for ; Fri, 6 Jun 2008 02:06:37 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 596CA28C1F2 for ; Fri, 6 Jun 2008 02:06:17 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 11:06:24 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EA2CAE3@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: test email Thread-Index: AcjHtJhDi/kV4rBtR4mbZNYx3K+ksg== From: "Jesper R. Christensen" To: X-Mailman-Approved-At: Fri, 06 Jun 2008 04:57:55 -0700 Subject: [Roll] test email X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0946862439==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============0946862439== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C7B4.98931AE5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C7B4.98931AE5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 Best regards / Med venlig hilsen Jesper R. Christensen | IT-Director Zensys A/S Emdrupvej 26 | 2100 Copenhagen O | Denmark Phone: +45 3913 0000 | Direct: +45 3913 0028 | Fax: +45 70 20 99 50 e-mail: jrc@zen-sys.com = =20 Zensys: www.zen-sys.com = =20 =20 ------_=_NextPart_001_01C8C7B4.98931AE5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 

Best regards / Med venlig hilsen
Jesper = R.=20 Christensen | IT-Director

Zensys A/S
Emdrupvej 26 | 2100 Copenhagen O | Denmark
Phone: = +45 3913=20 0000 | Direct: +45 3913 0028 | Fax: +45 70 20 99 50

e-mail: jrc@zen-sys.com <= FONT=20 size=3D2>
Zensys: www.zen-sys.com 
 
------_=_NextPart_001_01C8C7B4.98931AE5-- --===============0946862439== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0946862439==-- From roll-bounces@ietf.org Mon Jun 9 01:14:52 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFEFE3A6ADC; Mon, 9 Jun 2008 01:14:52 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6795A3A68CC for ; Mon, 9 Jun 2008 01:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YD2JsBRD4uqs for ; Mon, 9 Jun 2008 01:14:50 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id B2CCB3A688E for ; Mon, 9 Jun 2008 01:14:49 -0700 (PDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 10:15:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EB68C19@zensys17.zensys.local> In-Reply-To: <86c3ed7b0805301118j18ddc19dy9a111d9073f4ca3b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: test Thread-Index: AcjCgYzgLyywAZ11SSWliU7hhQLLJAHhw4cA References: <86c3ed7b0805301118j18ddc19dy9a111d9073f4ca3b@mail.gmail.com> From: "Anders Brandt" To: Subject: [Roll] test X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1442144488==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org This is a multi-part message in MIME format. --===============1442144488== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CA08.ED126A11" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CA08.ED126A11 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry for spamming - I have had problems posting messages to the list for some time. =20 - Anders ------_=_NextPart_001_01C8CA08.ED126A11 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sorry for spamming - I have had problems = posting=20 messages to the list for some time.
 
- Anders
------_=_NextPart_001_01C8CA08.ED126A11-- --===============1442144488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1442144488==-- From roll-bounces@ietf.org Mon Jun 9 06:03:35 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186E43A6C4E; Mon, 9 Jun 2008 06:03:35 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F133A6C4C for ; Mon, 9 Jun 2008 06:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3UHhVtr8T8n for ; Mon, 9 Jun 2008 06:03:33 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.245.51]) by core3.amsl.com (Postfix) with SMTP id 3BA043A6778 for ; Mon, 9 Jun 2008 06:03:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1213016630!26455630!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 7627 invoked from network); 9 Jun 2008 13:03:50 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-4.tower-119.messagelabs.com with SMTP; 9 Jun 2008 13:03:50 -0000 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id m59D3nkx011066 for ; Mon, 9 Jun 2008 06:03:49 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id m59D3l33007143 for ; Mon, 9 Jun 2008 08:03:48 -0500 (CDT) Received: from zuk35exm62.ds.mot.com (zuk35exm62.ea.mot.com [10.178.4.14]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id m59D3fwO006985 for ; Mon, 9 Jun 2008 08:03:44 -0500 (CDT) Received: from [127.0.0.1] ([10.161.201.117]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 14:03:26 +0100 Message-ID: <484D2A26.30801@gmail.com> Date: Mon, 09 Jun 2008 15:03:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ryuji Wakikawa References: <20080529093001.D1E7E3A6B6F@core3.amsl.com> <7A71A0CD-7B0E-4CEA-918B-BB3158FFBFA1@gmail.com> <86c3ed7b0805301150u3eb6f137gc9fe8fb9295543c2@mail.gmail.com> <9668780C-AF45-48CC-AD28-8B6028715C2F@gmail.com> In-Reply-To: <9668780C-AF45-48CC-AD28-8B6028715C2F@gmail.com> X-Antivirus: avast! (VPS 080608-0, 08/06/2008), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 09 Jun 2008 13:03:26.0950 (UTC) FILETIME=[34E21860:01C8CA31] X-CFilter-Loop: Reflected Cc: roll@ietf.org Subject: Re: [Roll] latencies (was: Fwd: I-D Action:draft-wakikawa-roll-invehicle-reqs-00.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Ryuji Wakikawa wrote: > Hello Miguel, > = > Thanks for your comments. > = > On 2008/05/31, at 3:50, Miguel Sanchez wrote: > = >> Hi Ryuji, >> = >> = >> Here you have my comments. >> = >> On page 8, Body Network: you mention air-bag control and 100msec = >> latency. However, you later refer to the power train latency for >> the air-bag control (from 2 to 6 msec). > = > OK, the document was not clear on this. 100msec latency is required > for most of devices in the body network. The air-bag control is an > exception in the body network. As a side note, humans are typically feeling 'instantaneous' reaction when pressing a button if it takes less than 50ms to happen. Examples are: top of the line SLR camera actuators are around 50ms, piano key action requires in the order of 5ms and less to feel natural. Bluetooth 128kbps audio streaming has very high latency, hundreds of milliseconds, un-adapted to phone conversations, but ok for mp3 music playing. I'm not surprised the airbag control requires 2-6msec and I'd even like it to be much shorter to feel safer at higher speeds :-) It's interesting to note that a WiFi link could ensure 1ms latency and even less (ping on 802.11g goes down to 30useconds). However, I feel somewhat unsure about using wifi to trigger the airbag shot, I'm not sure what, but something. Alex >> Next, on Infotainment Network: you mention a latency of 100msec = >> (including phone communication) but as you put Electronic Toll = >> Collection on the same network you later admit that latency for >> that has to be much lower. >> = >> I find these two cases above confusing: having a certain latency >> for some services but one. (Not sure 100msec for the hands-free is >> going to be comfortable either). > = > right. Section 2.2 tries to describe the current in-vehicle network. = > The current in-vehicle network (bus system) is specially designed to > meet the required latency per services. The category of in-vehicle > network described in Section 2.2 are the typical classification in > vehicle industry. > = > I will separate some exceptions such as air-bag and ETC from these = > category. > = >> Page 10, Path reliability: What is that? I know what you mean but >> you may want to elaborate on this concept. > = > Two things I had in my mind are > = > 1. link quality is considered as a metric of ROLL routing 2. try and > error approach to detect the route errors might not be appropriate > for some services. > = >> Page 13, Security: For encryption, key management needs to be = >> addressed. > = > right. We will add the texts for the key management in the next = > revision. > = > thanks, ryuji > = >> = >> Regards, >> = >> Miguel S=E1nchez >> = >> = > = > _______________________________________________ Roll mailing list = > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > = ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email = ______________________________________________________________________ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Jun 9 09:28:08 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8E183A6950; Mon, 9 Jun 2008 09:28:08 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213743A6950; Mon, 9 Jun 2008 09:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.575 X-Spam-Level: X-Spam-Status: No, score=-0.575 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RDNS_NONE=0.1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi-ASnwuCD7R; Mon, 9 Jun 2008 09:28:06 -0700 (PDT) Received: from grab.coslabs.com (unknown [199.233.92.34]) by core3.amsl.com (Postfix) with ESMTP id 6DD643A68D7; Mon, 9 Jun 2008 09:28:06 -0700 (PDT) Received: from [199.233.92.20] (dev20.coslabs.com [199.233.92.20]) by grab.coslabs.com (8.13.6/8.13.6) with ESMTP id m59GRcQe024369; Mon, 9 Jun 2008 10:27:38 -0600 (MDT) From: Geoff Mulligan To: Mark Townsley In-Reply-To: <484D4B7D.507@cisco.com> References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com> Date: Mon, 09 Jun 2008 10:27:33 -0600 Message-Id: <1213028853.5997.20.camel@dellx1> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Mark, this is interesting news. This can save another byte and if there would be no large push against this then compressing out another byte would be good. This is currently in the HC1g draft and would allow consistency between 6lowpan and SP100. geoff On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: > Geoff Mulligan wrote: > > Aren't both abstractions equally valid? I think that the biggest issue > > with a mesh under is that there is no one standard for it. ISA100 is > > one; I have done another using AODVtiny; I think Jennic has one using > > their mesh protocol and there are others. If IEEE had defined a > > multi-hop L2 mesh then we could point at that and define a solution for > > ND and bootstrapping and security and ... for it. > > > > The WG decided a couple of meetings ago that we would focus on solutions > > for the Route Over abstraction. [If while we are doing this we can keep > > in mind some of the issues w.r.t. mesh under that's good.] > > > > Somewhat independent from this is the HC1G draft that is important to > > deal with since we do need a way to efficiently handle non-local > > addresses. So as to remove the mesh under vs. route over issues from > > the HC1G draft I would like to see the draft updated to remove the UDP > > checksum optimization. > > > I'm more optimistic about keeping the UDP checksum optimization. There > are other forces at work which may relax the UDP checksum requirement in > IPv6 in certain cases. So as long as you have well thought out > reasoning, I wouldn't be afraid of keeping it in. > > - Mark > > I would like to ask the WG if we should consider taking > > draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of > > removing the UDP checksum compression. > > > > geoff > > > > On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: > > > >> Hi Pascal, > >> > >> So let's drop the mesh-under/route-over terminology for a second, I > >> think they are confusing since everyone seems to have a different > >> definition for those terms. > >> > >> What I am mainly concerned about is the kind of IP Link abstraction > >> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. > >> 802.15.4 and possible others through a BbR), what I've been calling > >> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the > >> radio range of 802.15.4), what I've been calling route-over. My point > >> to Mark's concern was that solutions to some work items within 6LoWPAN > >> will be different depending on our IP Link abstraction. From what I > >> understand, ISA100.11a has chosen option (i). But to your point below, > >> using IP routing to provide connectivity between nodes within the same > >> IP Link doesn't seem right to me, so it'd be great if you could help > >> me see a path to get there. > >> > >> A lot of this confusion can be cleaned up within the 6LoWPAN > >> architecture document. But I think Mark's concern still stands: > >> whether or not we're focused on one or both of these IP Link > >> abstractions. > >> > >> -- > >> Jonathan Hui > >> > >> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: > >> > >> > >>> Hi: > >>> > >>> My understanding is that defining how mesh-under computes its routes > >>> is > >>> out of scope for the IETF overall. I'm not even sure we need to > >>> document > >>> requirements in that space. It's good that we push some requirements > >>> to > >>> ROLL on route-over, and that's certainly the right time to do so. > >>> > >>> To Jonathan: I do not completely agree that ISA100 is mesh under. The > >>> routing is not specified and left to the system manager > >>> implementation. > >>> My personal hope is to promote a ROLL solution in ISA100.11a next > >>> release. See > >>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . > >>> > >>> So the current release of ISA100.11a is at the same level as 6LoWPAN > >>> on > >>> the matter of routing. > >>> > >>> In a same fashion, ISA does not define the backbone operation, the > >>> fragment recovery mechanism or the Explicit Congestion Notification. > >>> For > >>> all those features, there's a hope at ISA that the IETF will come up > >>> with more generic solutions that they can apply. But time is running > >>> out. > >>> > >>> 6LoWPAN hasn't produced anything for the last 6 months. At this rate, > >>> ISA will have to define everything on its own and hopefully publish an > >>> informational to this group. > >>> > >>> At the moment, the first draft of ISA100.11a is in letter ballot. The > >>> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, > >>> which > >>> is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN > >>> so ISA is using NaLP headers starting with b'00'. > >>> > >>> What ISA needs from 6LoWPAN in very short term is in that order: > >>> - promote Jonathan's draft as a convergence specification so ISA can > >>> at > >>> least use standard HC headers. > >>> This enables: non-Link-Local-Address compression > >>> Hops limit compression > >>> UDP checksum compression > >>> Better placement of HC2 > >>> Which are all mandatory for ISA100.11a > >>> - better define the NaLPs. > >>> There should be a way to indicate to a 6LoWPAN node whether a NaLP > >>> can > >>> be skipped and what its length is. > >>> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes > >>> to report congestion. > >>> - specify a fragment flow control and recovery protocol at the 6LoWPAN > >>> Shim layer > >>> There is no rocket science in any of this and it all could/should be > >>> carried out swiftly. > >>> > >>> What ISA needs in longer term: > >>> - define backbone operation when the backbone federates multiple > >>> LoWPANs > >>> into a single link (or subnet, TBD). > >>> This is more theoretical work for us. Related to proxy ND, a new > >>> registration protocols, multilink subnet, etc... > >>> > >>> Pascal > >>> > >>> > >>>> -----Original Message----- > >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > >>>> > >>> Behalf Of Jonathan Hui > >>> > >>>> Sent: jeudi 22 mai 2008 00:20 > >>>> To: Mark Townsley (townsley) > >>>> Cc: 6lowpan@ietf.org > >>>> Subject: Re: [6lowpan] New charter for 6lowpan > >>>> > >>>> > >>>> Hi Mark: > >>>> > >>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: > >>>> > >>>>>> - To your point on ND, this is precisely why the architecture draft > >>>>>> is so important. We haven't given it as much attention lately, but > >>>>>> it will help resolve the question your raise and many other > >>>>>> questions in the future. For example, the architecture draft > >>>>>> identifies two modes of operation: mesh-under and route-over. Both > >>>>>> of which may require different ND mechanisms. This doesn't apply to > >>>>>> just ND, but may apply questions of fragmentation, header > >>>>>> compression, security, etc. > >>>>>> > >>>>> I worry about the under/over debate. It seems that with all the > >>>>> effort and enthusiasm in ROLL, we might be well-served at the moment > >>>>> by focusing on helping them be successful with route-over than > >>>>> spending too much of our time on route-under. > >>>>> > >>>> I worry too, especially since it will pull the WG in different > >>>> directions. I'm with you on the preference for route-over, but others > >>>> in this group feel strongly about mesh-under as well, especially > >>>> since > >>>> ISA100.11a seems to have adopted a mesh-under approach. I've > >>>> personally been focused on developing route-over solutions while > >>>> being > >>>> conscious of supporting mesh-under when possible (evident with > >>>> 6lowpan- > >>>> hc). However, things will start to diverge when we start to talk > >>>> about > >>>> bootstrapping, ND, etc. So we should make a conscious decision of > >>>> whether we're supporting one or both. > >>>> > >>>> -- > >>>> Jonathan Hui > >>>> > >>>> > >>>>>> - I hesitate a bit that we suggest possible solutions to ND in the > >>>>>> charter ("reusing the 802.15.4 network structure (use the > >>>>>> coordinators)") especially since the definition of such link > >>>>>> mechanisms are still in motion within the IEEE. It seems more > >>>>>> productive to me if we can develop mechanisms that are less > >>>>>> dependent on the specific structure of 802.15.4 mechanisms. > >>>>>> > >>>>> I agree that we should develop mechanisms that could work > >>>>> generically whenever possible. > >>>>> > >>>>> - Mark > >>>>> > >>>>>> Rest of the charter looks good to me. > >>>>>> > >>>>>> Thanks. > >>>>>> > >>>>>> -- > >>>>>> Jonathan Hui > >>>>>> > >>>>>> > >>>>>> > >>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: > >>>>>> > >>>>>> > >>>>>>> Pascal Thubert (pthubert) wrote: > >>>>>>> > >>>>>>>> Hi Mark: > >>>>>>>> > >>>>>>>> I think we need a work item (usually implicit) around the concept > >>>>>>>> of > >>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in several > >>>>>>>> aspects: > >>>>>>>> > >>>>>>>> > >>>>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a > >>>>>>>> to > >>>>>>>> conform to 6LoWPAN would be a major win, but is certainly not a > >>>>>>>> given. > >>>>>>>> At the moment, the ISA100.11a documents expose discrepencies with > >>>>>>>> RFC > >>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc > >>>>>>>> resolve > >>>>>>>> for the most part. > >>>>>>>> > >>>>>>>> > >>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager > >>>>>>> > >>> to > >>> > >>>>>>> improve RFC 4944, but not eager to endorse changes that inhibit > >>>>>>> interoperability. > >>>>>>> > >>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop > >>>>>>>> radio > >>>>>>>> mesh exposes the network to congestion collapse, as described in > >>>>>>>> > >>>>>>>> > >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec > >>> > >>>>>>>> overy . I think that the WG should dedicate some bandwitdth to > >>>>>>>> provide > >>>>>>>> additional functions that would improve the LoWPAN operation WRT > >>>>>>>> flow > >>>>>>>> control and recovery of fragments. > >>>>>>>> > >>>>>>>> > >>>>>>> Fragmentation, OK, but why is flow control a network layer issue > >>>>>>> rather > >>>>>>> than a transport layer issue? > >>>>>>> > >>>>>>>> Another aspect of ISA100.11a is the concept of a backbone router. > >>>>>>>> It > >>>>>>>> would be appropriate that the IETF comes up with a proposal to > >>>>>>>> implement > >>>>>>>> the concept in the IPv6 world. This partially falls under the > >>>>>>>> first work > >>>>>>>> item on ND but might also include ND proxy over the backbone > >>>>>>>> which is a > >>>>>>>> stretch to the work item. More in > >>>>>>>> > >>>>>>>> > >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router > >>> > >>>>>>>> . > >>>>>>>> > >>>>>>>> > >>>>>>> Well, don't we need to define what ND looks like on a lowpan > >>>>>>> before we > >>>>>>> decide whether it needs to be proxied or not? > >>>>>>> > >>>>>>> - Mark > >>>>>>> > >>>>>>>> What do you think? > >>>>>>>> > >>>>>>>> Pascal > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] > >>>>>>>>> On > >>>>>>>>> > >>>>>>>>> > >>>>>>>> Behalf Of Mark Townsley > >>>>>>>> > >>>>>>>> > >>>>>>>>> (townsley) > >>>>>>>>> Sent: jeudi 15 mai 2008 23:02 > >>>>>>>>> To: 6lowpan@ietf.org > >>>>>>>>> Subject: [6lowpan] New charter for 6lowpan > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I'd like to ask the group one final time for comments on the > >>>>>>>>> proposed > >>>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. > >>>>>>>>> > >>>>>>>>> As I said before, soon after the format document was published, > >>>>>>>>> there > >>>>>>>>> > >>>>>>>>> > >>>>>>>> is > >>>>>>>> > >>>>>>>> > >>>>>>>>> nothing stopping the WG from discussing and working on new and > >>>>>>>>> existing > >>>>>>>>> items at this time. In fact, activity helps us to decide what > >>>>>>>>> should be > >>>>>>>>> in and out of the charter. Please do not construe not having a > >>>>>>>>> charter > >>>>>>>>> in place as a reason not to update drafts, or discuss topics > >>>>>>>>> that need > >>>>>>>>> to be discussed. Just as when we have BoF's and mailing lists > >>>>>>>>> before > >>>>>>>>> creating a new WG, it is good to have WG meetings and on-lists > >>>>>>>>> discussions when creating new WG charters. > >>>>>>>>> > >>>>>>>>> - Mark > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> 6lowpan mailing list > >>>>>>> 6lowpan@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan > >>>>>>> > >>>>>> > >>>> _______________________________________________ > >>>> 6lowpan mailing list > >>>> 6lowpan@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/6lowpan > >>>> > >> _______________________________________________ > >> 6lowpan mailing list > >> 6lowpan@ietf.org > >> https://www.ietf.org/mailman/listinfo/6lowpan > >> > > > > _______________________________________________ > > 6lowpan mailing list > > 6lowpan@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowpan > > > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Jun 9 09:58:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916753A6C94; Mon, 9 Jun 2008 09:58:31 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80C83A6C8D; Mon, 9 Jun 2008 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWcdTd9op9Pq; Mon, 9 Jun 2008 09:58:30 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 960843A6C64; Mon, 9 Jun 2008 09:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m59GwVVV001131; Mon, 9 Jun 2008 18:58:35 +0200 (CEST) Message-Id: <10CC11D0-9363-440E-BFF8-58E26A60CCEB@tzi.org> From: Carsten Bormann To: Mark Townsley In-Reply-To: <484D5B93.2080802@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 18:58:31 +0200 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com> <1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> X-Mailer: Apple Mail (2.924) Cc: roll@ietf.org, Geoff Mulligan , 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Jun 09 2008, at 18:34, Mark Townsley wrote: > zero out the UDP checksum While I agree with the sentiment, it's maybe worthwhile to remember the rationale[/ization] for requiring a checksum: IPv6 does not have a header checksum, and the UDP checksum (which, as does the TCP checksum, covers the IPv6 pseudoheader and thus some of the more important header fields no longer protected by the IPv4 header checksum) is the only checksum that guards against misdelivery of packets. Of course, this architectural concern has to be weighed against other concerns, including implementation issues, as well as the fact that the v4/v6 asymmetry adds one more real-world IPv6 deployment issue. Just one data point here. Gruesse, Carsten _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Jun 9 11:15:21 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9563A6C94; Mon, 9 Jun 2008 11:15:21 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B5328C165; Mon, 9 Jun 2008 08:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7odvYFJ9zInS; Mon, 9 Jun 2008 08:25:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id AE33E3A69AA; Mon, 9 Jun 2008 08:25:39 -0700 (PDT) Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 17:25:57 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m59FPvhm005930; Mon, 9 Jun 2008 17:25:57 +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.13.8/8.13.8) with ESMTP id m59FPvKc016379; Mon, 9 Jun 2008 15:25:57 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:25:57 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:25:57 +0200 Message-ID: <484D4B7D.507@cisco.com> Date: Mon, 09 Jun 2008 17:25:49 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Geoff Mulligan References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> In-Reply-To: <1211496860.23290.41.camel@dellx1> X-OriginalArrivalTime: 09 Jun 2008 15:25:57.0319 (UTC) FILETIME=[1D4CDD70:01C8CA45] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13184; t=1213025157; x=1213889157; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[6lowpan]=20ISA100.11a=20status=20and=2 0requirements=20(was=20RE=3A=09New=09charter=0A=20for=206low pan) |Sender:=20; bh=7dyFetNY1nNiFalgVOBxlt8uZOv4vnXd1flUpsr+oqA=; b=oQA8GdB6Kfslc3qeyKRJtro8Al6ZPsNaClUnafjW8FRjw458APuf89pmEJ NF9iB1atcbGe1p2TrFY31aLPmjKOf0WFR1Xzfu8MMmNWDlyzX6K4zDqSg35T C216mfAmJi; Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Mailman-Approved-At: Mon, 09 Jun 2008 11:15:20 -0700 Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Geoff Mulligan wrote: > Aren't both abstractions equally valid? I think that the biggest issue > with a mesh under is that there is no one standard for it. ISA100 is > one; I have done another using AODVtiny; I think Jennic has one using > their mesh protocol and there are others. If IEEE had defined a > multi-hop L2 mesh then we could point at that and define a solution for > ND and bootstrapping and security and ... for it. > > The WG decided a couple of meetings ago that we would focus on solutions > for the Route Over abstraction. [If while we are doing this we can keep > in mind some of the issues w.r.t. mesh under that's good.] > > Somewhat independent from this is the HC1G draft that is important to > deal with since we do need a way to efficiently handle non-local > addresses. So as to remove the mesh under vs. route over issues from > the HC1G draft I would like to see the draft updated to remove the UDP > checksum optimization. > I'm more optimistic about keeping the UDP checksum optimization. There are other forces at work which may relax the UDP checksum requirement in IPv6 in certain cases. So as long as you have well thought out reasoning, I wouldn't be afraid of keeping it in. - Mark > I would like to ask the WG if we should consider taking > draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of > removing the UDP checksum compression. > > geoff > > On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: > >> Hi Pascal, >> >> So let's drop the mesh-under/route-over terminology for a second, I >> think they are confusing since everyone seems to have a different >> definition for those terms. >> >> What I am mainly concerned about is the kind of IP Link abstraction >> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. >> 802.15.4 and possible others through a BbR), what I've been calling >> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the >> radio range of 802.15.4), what I've been calling route-over. My point >> to Mark's concern was that solutions to some work items within 6LoWPAN >> will be different depending on our IP Link abstraction. From what I >> understand, ISA100.11a has chosen option (i). But to your point below, >> using IP routing to provide connectivity between nodes within the same >> IP Link doesn't seem right to me, so it'd be great if you could help >> me see a path to get there. >> >> A lot of this confusion can be cleaned up within the 6LoWPAN >> architecture document. But I think Mark's concern still stands: >> whether or not we're focused on one or both of these IP Link >> abstractions. >> >> -- >> Jonathan Hui >> >> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: >> >> >>> Hi: >>> >>> My understanding is that defining how mesh-under computes its routes >>> is >>> out of scope for the IETF overall. I'm not even sure we need to >>> document >>> requirements in that space. It's good that we push some requirements >>> to >>> ROLL on route-over, and that's certainly the right time to do so. >>> >>> To Jonathan: I do not completely agree that ISA100 is mesh under. The >>> routing is not specified and left to the system manager >>> implementation. >>> My personal hope is to promote a ROLL solution in ISA100.11a next >>> release. See >>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >>> >>> So the current release of ISA100.11a is at the same level as 6LoWPAN >>> on >>> the matter of routing. >>> >>> In a same fashion, ISA does not define the backbone operation, the >>> fragment recovery mechanism or the Explicit Congestion Notification. >>> For >>> all those features, there's a hope at ISA that the IETF will come up >>> with more generic solutions that they can apply. But time is running >>> out. >>> >>> 6LoWPAN hasn't produced anything for the last 6 months. At this rate, >>> ISA will have to define everything on its own and hopefully publish an >>> informational to this group. >>> >>> At the moment, the first draft of ISA100.11a is in letter ballot. The >>> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, >>> which >>> is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN >>> so ISA is using NaLP headers starting with b'00'. >>> >>> What ISA needs from 6LoWPAN in very short term is in that order: >>> - promote Jonathan's draft as a convergence specification so ISA can >>> at >>> least use standard HC headers. >>> This enables: non-Link-Local-Address compression >>> Hops limit compression >>> UDP checksum compression >>> Better placement of HC2 >>> Which are all mandatory for ISA100.11a >>> - better define the NaLPs. >>> There should be a way to indicate to a 6LoWPAN node whether a NaLP >>> can >>> be skipped and what its length is. >>> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes >>> to report congestion. >>> - specify a fragment flow control and recovery protocol at the 6LoWPAN >>> Shim layer >>> There is no rocket science in any of this and it all could/should be >>> carried out swiftly. >>> >>> What ISA needs in longer term: >>> - define backbone operation when the backbone federates multiple >>> LoWPANs >>> into a single link (or subnet, TBD). >>> This is more theoretical work for us. Related to proxy ND, a new >>> registration protocols, multilink subnet, etc... >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>> >>> Behalf Of Jonathan Hui >>> >>>> Sent: jeudi 22 mai 2008 00:20 >>>> To: Mark Townsley (townsley) >>>> Cc: 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>> >>>> >>>> Hi Mark: >>>> >>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>> >>>>>> - To your point on ND, this is precisely why the architecture draft >>>>>> is so important. We haven't given it as much attention lately, but >>>>>> it will help resolve the question your raise and many other >>>>>> questions in the future. For example, the architecture draft >>>>>> identifies two modes of operation: mesh-under and route-over. Both >>>>>> of which may require different ND mechanisms. This doesn't apply to >>>>>> just ND, but may apply questions of fragmentation, header >>>>>> compression, security, etc. >>>>>> >>>>> I worry about the under/over debate. It seems that with all the >>>>> effort and enthusiasm in ROLL, we might be well-served at the moment >>>>> by focusing on helping them be successful with route-over than >>>>> spending too much of our time on route-under. >>>>> >>>> I worry too, especially since it will pull the WG in different >>>> directions. I'm with you on the preference for route-over, but others >>>> in this group feel strongly about mesh-under as well, especially >>>> since >>>> ISA100.11a seems to have adopted a mesh-under approach. I've >>>> personally been focused on developing route-over solutions while >>>> being >>>> conscious of supporting mesh-under when possible (evident with >>>> 6lowpan- >>>> hc). However, things will start to diverge when we start to talk >>>> about >>>> bootstrapping, ND, etc. So we should make a conscious decision of >>>> whether we're supporting one or both. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>>>> charter ("reusing the 802.15.4 network structure (use the >>>>>> coordinators)") especially since the definition of such link >>>>>> mechanisms are still in motion within the IEEE. It seems more >>>>>> productive to me if we can develop mechanisms that are less >>>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>>>> >>>>> I agree that we should develop mechanisms that could work >>>>> generically whenever possible. >>>>> >>>>> - Mark >>>>> >>>>>> Rest of the charter looks good to me. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> >>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>>> >>>>>> >>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> >>>>>>>> Hi Mark: >>>>>>>> >>>>>>>> I think we need a work item (usually implicit) around the concept >>>>>>>> of >>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>>>> aspects: >>>>>>>> >>>>>>>> >>>>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>>>> to >>>>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>>>> given. >>>>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>>>> RFC >>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>>>> resolve >>>>>>>> for the most part. >>>>>>>> >>>>>>>> >>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager >>>>>>> >>> to >>> >>>>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>>>> interoperability. >>>>>>> >>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>>>> radio >>>>>>>> mesh exposes the network to congestion collapse, as described in >>>>>>>> >>>>>>>> >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>> >>>>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>>>> provide >>>>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>>>> flow >>>>>>>> control and recovery of fragments. >>>>>>>> >>>>>>>> >>>>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>>>> rather >>>>>>> than a transport layer issue? >>>>>>> >>>>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>>>> It >>>>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>>>> implement >>>>>>>> the concept in the IPv6 world. This partially falls under the >>>>>>>> first work >>>>>>>> item on ND but might also include ND proxy over the backbone >>>>>>>> which is a >>>>>>>> stretch to the work item. More in >>>>>>>> >>>>>>>> >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>> >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>> Well, don't we need to define what ND looks like on a lowpan >>>>>>> before we >>>>>>> decide whether it needs to be proxied or not? >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>>>> On >>>>>>>>> >>>>>>>>> >>>>>>>> Behalf Of Mark Townsley >>>>>>>> >>>>>>>> >>>>>>>>> (townsley) >>>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>>> To: 6lowpan@ietf.org >>>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>>> >>>>>>>>> >>>>>>>>> I'd like to ask the group one final time for comments on the >>>>>>>>> proposed >>>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>>>> >>>>>>>>> As I said before, soon after the format document was published, >>>>>>>>> there >>>>>>>>> >>>>>>>>> >>>>>>>> is >>>>>>>> >>>>>>>> >>>>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>>>> existing >>>>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>>>> should be >>>>>>>>> in and out of the charter. Please do not construe not having a >>>>>>>>> charter >>>>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>>>> that need >>>>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>>>> before >>>>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>>>> discussions when creating new WG charters. >>>>>>>>> >>>>>>>>> - Mark >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>> >>>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Jun 9 11:15:22 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197A13A6CA5; Mon, 9 Jun 2008 11:15:22 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B19B3A6C66; Mon, 9 Jun 2008 08:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIvlcz+yHIIg; Mon, 9 Jun 2008 08:56:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F07F03A6C79; Mon, 9 Jun 2008 08:56:42 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 17:57:01 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m59Fv0e3020597; Mon, 9 Jun 2008 17:57:00 +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.13.8/8.13.8) with ESMTP id m59Fv0OM028255; Mon, 9 Jun 2008 15:57:00 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:57:00 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 17:56:59 +0200 Message-ID: <484D52C5.2060701@cisco.com> Date: Mon, 09 Jun 2008 17:56:53 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Geoff Mulligan References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> In-Reply-To: <1211496860.23290.41.camel@dellx1> X-OriginalArrivalTime: 09 Jun 2008 15:56:59.0916 (UTC) FILETIME=[737E9CC0:01C8CA49] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13296; t=1213027020; x=1213891020; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[6lowpan]=20ISA100.11a=20status=20and=2 0requirements=20(was=20RE=3A=09New=09charter=0A=20for=206low pan) |Sender:=20; bh=wMCVDuFNhyOMO6GCdJkse/kENFnTO8Xrp5csSc8Gsos=; b=Xu6KDkkBwzunpaff+vtaVpOLy1W7i1Ilv49rx3oAhYywcgBfFZwQfR6L7A dRSFRUqbltses54MqWTmYe0gz+/J9cu2WgNUcytLHbMZQHXnNQ28aS8vdl0y NUHMlJzjRk; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Mailman-Approved-At: Mon, 09 Jun 2008 11:15:20 -0700 Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Geoff Mulligan wrote: > Aren't both abstractions equally valid? I think that the biggest issue > with a mesh under is that there is no one standard for it. ISA100 is > one; I have done another using AODVtiny; I think Jennic has one using > their mesh protocol and there are others. If IEEE had defined a > multi-hop L2 mesh then we could point at that and define a solution for > ND and bootstrapping and security and ... for it. > > The WG decided a couple of meetings ago that we would focus on solutions > for the Route Over abstraction. [If while we are doing this we can keep > in mind some of the issues w.r.t. mesh under that's good.] > > Somewhat independent from this is the HC1G draft that is important to > deal with since we do need a way to efficiently handle non-local > addresses. It would seem to me that HC1G would be very important to understanding how ROLL is going to work. If you are routing between subnets at L3, then by definition you cannot be using link-local addressing on them. So, either ROLL is stuck with 128-bit addresses in data packets, or we figure out how to compress global addresses. Or, am I missing something obvious? - Mark > So as to remove the mesh under vs. route over issues from > the HC1G draft I would like to see the draft updated to remove the UDP > checksum optimization. > > I would like to ask the WG if we should consider taking > draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of > removing the UDP checksum compression. > > geoff > > On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: > >> Hi Pascal, >> >> So let's drop the mesh-under/route-over terminology for a second, I >> think they are confusing since everyone seems to have a different >> definition for those terms. >> >> What I am mainly concerned about is the kind of IP Link abstraction >> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. >> 802.15.4 and possible others through a BbR), what I've been calling >> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the >> radio range of 802.15.4), what I've been calling route-over. My point >> to Mark's concern was that solutions to some work items within 6LoWPAN >> will be different depending on our IP Link abstraction. From what I >> understand, ISA100.11a has chosen option (i). But to your point below, >> using IP routing to provide connectivity between nodes within the same >> IP Link doesn't seem right to me, so it'd be great if you could help >> me see a path to get there. >> >> A lot of this confusion can be cleaned up within the 6LoWPAN >> architecture document. But I think Mark's concern still stands: >> whether or not we're focused on one or both of these IP Link >> abstractions. >> >> -- >> Jonathan Hui >> >> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: >> >> >>> Hi: >>> >>> My understanding is that defining how mesh-under computes its routes >>> is >>> out of scope for the IETF overall. I'm not even sure we need to >>> document >>> requirements in that space. It's good that we push some requirements >>> to >>> ROLL on route-over, and that's certainly the right time to do so. >>> >>> To Jonathan: I do not completely agree that ISA100 is mesh under. The >>> routing is not specified and left to the system manager >>> implementation. >>> My personal hope is to promote a ROLL solution in ISA100.11a next >>> release. See >>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >>> >>> So the current release of ISA100.11a is at the same level as 6LoWPAN >>> on >>> the matter of routing. >>> >>> In a same fashion, ISA does not define the backbone operation, the >>> fragment recovery mechanism or the Explicit Congestion Notification. >>> For >>> all those features, there's a hope at ISA that the IETF will come up >>> with more generic solutions that they can apply. But time is running >>> out. >>> >>> 6LoWPAN hasn't produced anything for the last 6 months. At this rate, >>> ISA will have to define everything on its own and hopefully publish an >>> informational to this group. >>> >>> At the moment, the first draft of ISA100.11a is in letter ballot. The >>> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, >>> which >>> is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN >>> so ISA is using NaLP headers starting with b'00'. >>> >>> What ISA needs from 6LoWPAN in very short term is in that order: >>> - promote Jonathan's draft as a convergence specification so ISA can >>> at >>> least use standard HC headers. >>> This enables: non-Link-Local-Address compression >>> Hops limit compression >>> UDP checksum compression >>> Better placement of HC2 >>> Which are all mandatory for ISA100.11a >>> - better define the NaLPs. >>> There should be a way to indicate to a 6LoWPAN node whether a NaLP >>> can >>> be skipped and what its length is. >>> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes >>> to report congestion. >>> - specify a fragment flow control and recovery protocol at the 6LoWPAN >>> Shim layer >>> There is no rocket science in any of this and it all could/should be >>> carried out swiftly. >>> >>> What ISA needs in longer term: >>> - define backbone operation when the backbone federates multiple >>> LoWPANs >>> into a single link (or subnet, TBD). >>> This is more theoretical work for us. Related to proxy ND, a new >>> registration protocols, multilink subnet, etc... >>> >>> Pascal >>> >>> >>>> -----Original Message----- >>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>> >>> Behalf Of Jonathan Hui >>> >>>> Sent: jeudi 22 mai 2008 00:20 >>>> To: Mark Townsley (townsley) >>>> Cc: 6lowpan@ietf.org >>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>> >>>> >>>> Hi Mark: >>>> >>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>> >>>>>> - To your point on ND, this is precisely why the architecture draft >>>>>> is so important. We haven't given it as much attention lately, but >>>>>> it will help resolve the question your raise and many other >>>>>> questions in the future. For example, the architecture draft >>>>>> identifies two modes of operation: mesh-under and route-over. Both >>>>>> of which may require different ND mechanisms. This doesn't apply to >>>>>> just ND, but may apply questions of fragmentation, header >>>>>> compression, security, etc. >>>>>> >>>>> I worry about the under/over debate. It seems that with all the >>>>> effort and enthusiasm in ROLL, we might be well-served at the moment >>>>> by focusing on helping them be successful with route-over than >>>>> spending too much of our time on route-under. >>>>> >>>> I worry too, especially since it will pull the WG in different >>>> directions. I'm with you on the preference for route-over, but others >>>> in this group feel strongly about mesh-under as well, especially >>>> since >>>> ISA100.11a seems to have adopted a mesh-under approach. I've >>>> personally been focused on developing route-over solutions while >>>> being >>>> conscious of supporting mesh-under when possible (evident with >>>> 6lowpan- >>>> hc). However, things will start to diverge when we start to talk >>>> about >>>> bootstrapping, ND, etc. So we should make a conscious decision of >>>> whether we're supporting one or both. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>>>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>>>> charter ("reusing the 802.15.4 network structure (use the >>>>>> coordinators)") especially since the definition of such link >>>>>> mechanisms are still in motion within the IEEE. It seems more >>>>>> productive to me if we can develop mechanisms that are less >>>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>>>> >>>>> I agree that we should develop mechanisms that could work >>>>> generically whenever possible. >>>>> >>>>> - Mark >>>>> >>>>>> Rest of the charter looks good to me. >>>>>> >>>>>> Thanks. >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> >>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>>> >>>>>> >>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> >>>>>>>> Hi Mark: >>>>>>>> >>>>>>>> I think we need a work item (usually implicit) around the concept >>>>>>>> of >>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>>>> aspects: >>>>>>>> >>>>>>>> >>>>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>>>> to >>>>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>>>> given. >>>>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>>>> RFC >>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>>>> resolve >>>>>>>> for the most part. >>>>>>>> >>>>>>>> >>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager >>>>>>> >>> to >>> >>>>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>>>> interoperability. >>>>>>> >>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>>>> radio >>>>>>>> mesh exposes the network to congestion collapse, as described in >>>>>>>> >>>>>>>> >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>> >>>>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>>>> provide >>>>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>>>> flow >>>>>>>> control and recovery of fragments. >>>>>>>> >>>>>>>> >>>>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>>>> rather >>>>>>> than a transport layer issue? >>>>>>> >>>>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>>>> It >>>>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>>>> implement >>>>>>>> the concept in the IPv6 world. This partially falls under the >>>>>>>> first work >>>>>>>> item on ND but might also include ND proxy over the backbone >>>>>>>> which is a >>>>>>>> stretch to the work item. More in >>>>>>>> >>>>>>>> >>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>> >>>>>>>> . >>>>>>>> >>>>>>>> >>>>>>> Well, don't we need to define what ND looks like on a lowpan >>>>>>> before we >>>>>>> decide whether it needs to be proxied or not? >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>>>> On >>>>>>>>> >>>>>>>>> >>>>>>>> Behalf Of Mark Townsley >>>>>>>> >>>>>>>> >>>>>>>>> (townsley) >>>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>>> To: 6lowpan@ietf.org >>>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>>> >>>>>>>>> >>>>>>>>> I'd like to ask the group one final time for comments on the >>>>>>>>> proposed >>>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>>>> >>>>>>>>> As I said before, soon after the format document was published, >>>>>>>>> there >>>>>>>>> >>>>>>>>> >>>>>>>> is >>>>>>>> >>>>>>>> >>>>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>>>> existing >>>>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>>>> should be >>>>>>>>> in and out of the charter. Please do not construe not having a >>>>>>>>> charter >>>>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>>>> that need >>>>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>>>> before >>>>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>>>> discussions when creating new WG charters. >>>>>>>>> >>>>>>>>> - Mark >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>> >>>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Jun 9 11:15:22 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462483A6CA9; Mon, 9 Jun 2008 11:15:22 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2671528C173; Mon, 9 Jun 2008 09:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.44 X-Spam-Level: X-Spam-Status: No, score=-6.44 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6Nj0AifUT+2; Mon, 9 Jun 2008 09:34:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 394933A695B; Mon, 9 Jun 2008 09:34:31 -0700 (PDT) Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jun 2008 18:34:40 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m59GYZA5030566; Mon, 9 Jun 2008 18:34:35 +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.13.8/8.13.8) with ESMTP id m59GYZjj011056; Mon, 9 Jun 2008 16:34:35 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 18:34:35 +0200 Received: from dhcp-144-254-57-206.cisco.com ([144.254.57.206]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 18:34:34 +0200 Message-ID: <484D5B93.2080802@cisco.com> Date: Mon, 09 Jun 2008 18:34:27 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Geoff Mulligan References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com> <1213028853.5997.20.camel@dellx1> In-Reply-To: <1213028853.5997.20.camel@dellx1> X-OriginalArrivalTime: 09 Jun 2008 16:34:34.0106 (UTC) FILETIME=[B318B5A0:01C8CA4E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15901; t=1213029275; x=1213893275; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[6lowpan]=20ISA100.11a=20status=20and=2 0requirements=20(was=09RE=3A=09New=09charter=0A=20for=206low pan) |Sender:=20; bh=gsmUslBaQayZDIKl9/tBT5j8xdWkOijb1CDoxXjY8RQ=; b=e2O1dio6OYmQ8ppWHt+ppKXrMBSsY+cJQXpA8qOqX3CHehBnjkFFsXTGbQ Wm4iMra7yYKNgAYN147G65xY4ezbvlE6/sRePKpK1EaxtxhFnN7F8c8ojzyz lR+RdknAMA; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Mailman-Approved-At: Mon, 09 Jun 2008 11:15:20 -0700 Cc: roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Geoff Mulligan wrote: > Mark, > this is interesting news. This can save another byte and if there > would be no large push against this then compressing out another byte > would be good. > I can't promise anything, but 6lowpan certainly isn't the only place where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty much any UDP-based tunneling protocol running on a router in hardware at high scale or speeds is running into the same problem. I know of implementations today that zero out the UDP checksum, and IMHO a good implementation that is "liberal in what it accepts" would not drop the packet with a zero UDP checksum arriving over IPv6 (in fact, its annoying that one would even have to differentiate between IPv4 and IPv6 at all here if you ask me). > This is currently in the HC1g draft and would allow consistency between > 6lowpan and SP100. > I suppose that isn't a bad thing. - Mark > geoff > > On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: > >> Geoff Mulligan wrote: >> >>> Aren't both abstractions equally valid? I think that the biggest issue >>> with a mesh under is that there is no one standard for it. ISA100 is >>> one; I have done another using AODVtiny; I think Jennic has one using >>> their mesh protocol and there are others. If IEEE had defined a >>> multi-hop L2 mesh then we could point at that and define a solution for >>> ND and bootstrapping and security and ... for it. >>> >>> The WG decided a couple of meetings ago that we would focus on solutions >>> for the Route Over abstraction. [If while we are doing this we can keep >>> in mind some of the issues w.r.t. mesh under that's good.] >>> >>> Somewhat independent from this is the HC1G draft that is important to >>> deal with since we do need a way to efficiently handle non-local >>> addresses. So as to remove the mesh under vs. route over issues from >>> the HC1G draft I would like to see the draft updated to remove the UDP >>> checksum optimization. >>> >>> >> I'm more optimistic about keeping the UDP checksum optimization. There >> are other forces at work which may relax the UDP checksum requirement in >> IPv6 in certain cases. So as long as you have well thought out >> reasoning, I wouldn't be afraid of keeping it in. >> >> - Mark >> >>> I would like to ask the WG if we should consider taking >>> draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of >>> removing the UDP checksum compression. >>> >>> geoff >>> >>> On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: >>> >>> >>>> Hi Pascal, >>>> >>>> So let's drop the mesh-under/route-over terminology for a second, I >>>> think they are confusing since everyone seems to have a different >>>> definition for those terms. >>>> >>>> What I am mainly concerned about is the kind of IP Link abstraction >>>> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops (e.g. >>>> 802.15.4 and possible others through a BbR), what I've been calling >>>> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the >>>> radio range of 802.15.4), what I've been calling route-over. My point >>>> to Mark's concern was that solutions to some work items within 6LoWPAN >>>> will be different depending on our IP Link abstraction. From what I >>>> understand, ISA100.11a has chosen option (i). But to your point below, >>>> using IP routing to provide connectivity between nodes within the same >>>> IP Link doesn't seem right to me, so it'd be great if you could help >>>> me see a path to get there. >>>> >>>> A lot of this confusion can be cleaned up within the 6LoWPAN >>>> architecture document. But I think Mark's concern still stands: >>>> whether or not we're focused on one or both of these IP Link >>>> abstractions. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: >>>> >>>> >>>> >>>>> Hi: >>>>> >>>>> My understanding is that defining how mesh-under computes its routes >>>>> is >>>>> out of scope for the IETF overall. I'm not even sure we need to >>>>> document >>>>> requirements in that space. It's good that we push some requirements >>>>> to >>>>> ROLL on route-over, and that's certainly the right time to do so. >>>>> >>>>> To Jonathan: I do not completely agree that ISA100 is mesh under. The >>>>> routing is not specified and left to the system manager >>>>> implementation. >>>>> My personal hope is to promote a ROLL solution in ISA100.11a next >>>>> release. See >>>>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >>>>> >>>>> So the current release of ISA100.11a is at the same level as 6LoWPAN >>>>> on >>>>> the matter of routing. >>>>> >>>>> In a same fashion, ISA does not define the backbone operation, the >>>>> fragment recovery mechanism or the Explicit Congestion Notification. >>>>> For >>>>> all those features, there's a hope at ISA that the IETF will come up >>>>> with more generic solutions that they can apply. But time is running >>>>> out. >>>>> >>>>> 6LoWPAN hasn't produced anything for the last 6 months. At this rate, >>>>> ISA will have to define everything on its own and hopefully publish an >>>>> informational to this group. >>>>> >>>>> At the moment, the first draft of ISA100.11a is in letter ballot. The >>>>> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, >>>>> which >>>>> is an evolution from 802.15.4. But the formats are not exactly 6LoWPAN >>>>> so ISA is using NaLP headers starting with b'00'. >>>>> >>>>> What ISA needs from 6LoWPAN in very short term is in that order: >>>>> - promote Jonathan's draft as a convergence specification so ISA can >>>>> at >>>>> least use standard HC headers. >>>>> This enables: non-Link-Local-Address compression >>>>> Hops limit compression >>>>> UDP checksum compression >>>>> Better placement of HC2 >>>>> Which are all mandatory for ISA100.11a >>>>> - better define the NaLPs. >>>>> There should be a way to indicate to a 6LoWPAN node whether a NaLP >>>>> can >>>>> be skipped and what its length is. >>>>> - define IP ECN bits in a 6LoWPAN header for use by intermediate nodes >>>>> to report congestion. >>>>> - specify a fragment flow control and recovery protocol at the 6LoWPAN >>>>> Shim layer >>>>> There is no rocket science in any of this and it all could/should be >>>>> carried out swiftly. >>>>> >>>>> What ISA needs in longer term: >>>>> - define backbone operation when the backbone federates multiple >>>>> LoWPANs >>>>> into a single link (or subnet, TBD). >>>>> This is more theoretical work for us. Related to proxy ND, a new >>>>> registration protocols, multilink subnet, etc... >>>>> >>>>> Pascal >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>>>>> >>>>>> >>>>> Behalf Of Jonathan Hui >>>>> >>>>> >>>>>> Sent: jeudi 22 mai 2008 00:20 >>>>>> To: Mark Townsley (townsley) >>>>>> Cc: 6lowpan@ietf.org >>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>> >>>>>> >>>>>> Hi Mark: >>>>>> >>>>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>>>> >>>>>> >>>>>>>> - To your point on ND, this is precisely why the architecture draft >>>>>>>> is so important. We haven't given it as much attention lately, but >>>>>>>> it will help resolve the question your raise and many other >>>>>>>> questions in the future. For example, the architecture draft >>>>>>>> identifies two modes of operation: mesh-under and route-over. Both >>>>>>>> of which may require different ND mechanisms. This doesn't apply to >>>>>>>> just ND, but may apply questions of fragmentation, header >>>>>>>> compression, security, etc. >>>>>>>> >>>>>>>> >>>>>>> I worry about the under/over debate. It seems that with all the >>>>>>> effort and enthusiasm in ROLL, we might be well-served at the moment >>>>>>> by focusing on helping them be successful with route-over than >>>>>>> spending too much of our time on route-under. >>>>>>> >>>>>>> >>>>>> I worry too, especially since it will pull the WG in different >>>>>> directions. I'm with you on the preference for route-over, but others >>>>>> in this group feel strongly about mesh-under as well, especially >>>>>> since >>>>>> ISA100.11a seems to have adopted a mesh-under approach. I've >>>>>> personally been focused on developing route-over solutions while >>>>>> being >>>>>> conscious of supporting mesh-under when possible (evident with >>>>>> 6lowpan- >>>>>> hc). However, things will start to diverge when we start to talk >>>>>> about >>>>>> bootstrapping, ND, etc. So we should make a conscious decision of >>>>>> whether we're supporting one or both. >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> >>>>>> >>>>>>>> - I hesitate a bit that we suggest possible solutions to ND in the >>>>>>>> charter ("reusing the 802.15.4 network structure (use the >>>>>>>> coordinators)") especially since the definition of such link >>>>>>>> mechanisms are still in motion within the IEEE. It seems more >>>>>>>> productive to me if we can develop mechanisms that are less >>>>>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>>>>>> >>>>>>>> >>>>>>> I agree that we should develop mechanisms that could work >>>>>>> generically whenever possible. >>>>>>> >>>>>>> - Mark >>>>>>> >>>>>>> >>>>>>>> Rest of the charter looks good to me. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi Mark: >>>>>>>>>> >>>>>>>>>> I think we need a work item (usually implicit) around the concept >>>>>>>>>> of >>>>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in several >>>>>>>>>> aspects: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - A major one is a better fit with ISA100.11a. Getting ISA100.11a >>>>>>>>>> to >>>>>>>>>> conform to 6LoWPAN would be a major win, but is certainly not a >>>>>>>>>> given. >>>>>>>>>> At the moment, the ISA100.11a documents expose discrepencies with >>>>>>>>>> RFC >>>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan-hc >>>>>>>>>> resolve >>>>>>>>>> for the most part. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm eager >>>>>>>>> >>>>>>>>> >>>>> to >>>>> >>>>> >>>>>>>>> improve RFC 4944, but not eager to endorse changes that inhibit >>>>>>>>> interoperability. >>>>>>>>> >>>>>>>>> >>>>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a multihop >>>>>>>>>> radio >>>>>>>>>> mesh exposes the network to congestion collapse, as described in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>> >>>>> >>>>>>>>>> overy . I think that the WG should dedicate some bandwitdth to >>>>>>>>>> provide >>>>>>>>>> additional functions that would improve the LoWPAN operation WRT >>>>>>>>>> flow >>>>>>>>>> control and recovery of fragments. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Fragmentation, OK, but why is flow control a network layer issue >>>>>>>>> rather >>>>>>>>> than a transport layer issue? >>>>>>>>> >>>>>>>>> >>>>>>>>>> Another aspect of ISA100.11a is the concept of a backbone router. >>>>>>>>>> It >>>>>>>>>> would be appropriate that the IETF comes up with a proposal to >>>>>>>>>> implement >>>>>>>>>> the concept in the IPv6 world. This partially falls under the >>>>>>>>>> first work >>>>>>>>>> item on ND but might also include ND proxy over the backbone >>>>>>>>>> which is a >>>>>>>>>> stretch to the work item. More in >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>> >>>>> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Well, don't we need to define what ND looks like on a lowpan >>>>>>>>> before we >>>>>>>>> decide whether it needs to be proxied or not? >>>>>>>>> >>>>>>>>> - Mark >>>>>>>>> >>>>>>>>> >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Pascal >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] >>>>>>>>>>> On >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Behalf Of Mark Townsley >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> (townsley) >>>>>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>>>>> To: 6lowpan@ietf.org >>>>>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'd like to ask the group one final time for comments on the >>>>>>>>>>> proposed >>>>>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>>>>>> >>>>>>>>>>> As I said before, soon after the format document was published, >>>>>>>>>>> there >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> is >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> nothing stopping the WG from discussing and working on new and >>>>>>>>>>> existing >>>>>>>>>>> items at this time. In fact, activity helps us to decide what >>>>>>>>>>> should be >>>>>>>>>>> in and out of the charter. Please do not construe not having a >>>>>>>>>>> charter >>>>>>>>>>> in place as a reason not to update drafts, or discuss topics >>>>>>>>>>> that need >>>>>>>>>>> to be discussed. Just as when we have BoF's and mailing lists >>>>>>>>>>> before >>>>>>>>>>> creating a new WG, it is good to have WG meetings and on-lists >>>>>>>>>>> discussions when creating new WG charters. >>>>>>>>>>> >>>>>>>>>>> - Mark >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 6lowpan mailing list >>>>>>>>> 6lowpan@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> >>>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >>> >>> > > > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Jun 9 12:28:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0846D3A6AAC; Mon, 9 Jun 2008 12:28:16 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41DFC28B23E; Mon, 9 Jun 2008 12:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.759 X-Spam-Level: X-Spam-Status: No, score=-6.759 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGwPC3yT-NyS; Mon, 9 Jun 2008 12:28:11 -0700 (PDT) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id A12C23A6AAC; Mon, 9 Jun 2008 12:28:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-4.tower-83.messagelabs.com!1213039708!44627487!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 10536 invoked from network); 9 Jun 2008 19:28:29 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-4.tower-83.messagelabs.com with SMTP; 9 Jun 2008 19:28:29 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 20:28:28 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 20:28:27 +0100 Message-Id: <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> From: Lloyd Wood To: Mark Townsley In-Reply-To: <484D5B93.2080802@cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 9 Jun 2008 20:28:26 +0100 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com> <1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 09 Jun 2008 19:28:28.0138 (UTC) FILETIME=[FE43A4A0:01C8CA66] Cc: Geoff Mulligan , roll@ietf.org, Jay Werb , "Polyzois, Christos A" , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements (was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On 9 Jun 2008, at 17:34, Mark Townsley wrote: > Geoff Mulligan wrote: >> Mark, >> this is interesting news. This can save another byte and if there >> would be no large push against this then compressing out another byte >> would be good. >> > I can't promise anything, but 6lowpan certainly isn't the only place > where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty > much any UDP-based tunneling protocol running on a router in > hardware at > high scale or speeds is running into the same problem. The pseudo-header checksum is the only thing preventing misdelivery; the header gets checked once at the endpoint (IPv6) as opposed to being checked and recomputed at every hop (IPv4). I'm not convinced that the IPv6 design choices here were right - I'd have gone for a header checksum across immutable fields, skipping TTL, CoS and the like, that wouldn't require recomputing, and which would have constrained misdelivery to a single link, rather than the path - this would be more useful for resends and diagnostics, while increasing the pain for NAT. Here, IPv6 assumes a tight application/ application control loop and path where the cost of resending a packet across the entire path is low. That raw IPv6 header tunnelling sans UDP header (or GRE sans optional checksum or MPLS) lacks any self-checking mechanism for reliability should be of some concern. RFC2460 p28 section 8.1 Upper-Layer Checksums: [..] o Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a UDP checksum over the packet and the pseudo-header, and, if that computation yields a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6 receivers must discard UDP packets containing a zero checksum, and should log the error. ^^^^ [..] That 'must' is clear and unambiguous. The side-effects mean that this should NOT be thought of as an optimization. L. > I know of > implementations today that zero out the UDP checksum, and IMHO a good > implementation that is "liberal in what it accepts" would not drop the > packet with a zero UDP checksum arriving over IPv6 (in fact, its > annoying that one would even have to differentiate between IPv4 and > IPv6 > at all here if you ask me). >> This is currently in the HC1g draft and would allow consistency >> between >> 6lowpan and SP100. >> > I suppose that isn't a bad thing. > > - Mark >> geoff >> >> On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: >> >>> Geoff Mulligan wrote: >>> >>>> Aren't both abstractions equally valid? I think that the biggest >>>> issue >>>> with a mesh under is that there is no one standard for it. >>>> ISA100 is >>>> one; I have done another using AODVtiny; I think Jennic has one >>>> using >>>> their mesh protocol and there are others. If IEEE had defined a >>>> multi-hop L2 mesh then we could point at that and define a >>>> solution for >>>> ND and bootstrapping and security and ... for it. >>>> >>>> The WG decided a couple of meetings ago that we would focus on >>>> solutions >>>> for the Route Over abstraction. [If while we are doing this we >>>> can keep >>>> in mind some of the issues w.r.t. mesh under that's good.] >>>> >>>> Somewhat independent from this is the HC1G draft that is >>>> important to >>>> deal with since we do need a way to efficiently handle non-local >>>> addresses. So as to remove the mesh under vs. route over issues >>>> from >>>> the HC1G draft I would like to see the draft updated to remove >>>> the UDP >>>> checksum optimization. >>>> >>>> >>> I'm more optimistic about keeping the UDP checksum optimization. >>> There >>> are other forces at work which may relax the UDP checksum >>> requirement in >>> IPv6 in certain cases. So as long as you have well thought out >>> reasoning, I wouldn't be afraid of keeping it in. >>> >>> - Mark >>> >>>> I would like to ask the WG if we should consider taking >>>> draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of >>>> removing the UDP checksum compression. >>>> >>>> geoff >>>> >>>> On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: >>>> >>>> >>>>> Hi Pascal, >>>>> >>>>> So let's drop the mesh-under/route-over terminology for a >>>>> second, I >>>>> think they are confusing since everyone seems to have a different >>>>> definition for those terms. >>>>> >>>>> What I am mainly concerned about is the kind of IP Link >>>>> abstraction >>>>> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops >>>>> (e.g. >>>>> 802.15.4 and possible others through a BbR), what I've been >>>>> calling >>>>> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the >>>>> radio range of 802.15.4), what I've been calling route-over. My >>>>> point >>>>> to Mark's concern was that solutions to some work items within >>>>> 6LoWPAN >>>>> will be different depending on our IP Link abstraction. From >>>>> what I >>>>> understand, ISA100.11a has chosen option (i). But to your point >>>>> below, >>>>> using IP routing to provide connectivity between nodes within >>>>> the same >>>>> IP Link doesn't seem right to me, so it'd be great if you could >>>>> help >>>>> me see a path to get there. >>>>> >>>>> A lot of this confusion can be cleaned up within the 6LoWPAN >>>>> architecture document. But I think Mark's concern still stands: >>>>> whether or not we're focused on one or both of these IP Link >>>>> abstractions. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: >>>>> >>>>> >>>>> >>>>>> Hi: >>>>>> >>>>>> My understanding is that defining how mesh-under computes its >>>>>> routes >>>>>> is >>>>>> out of scope for the IETF overall. I'm not even sure we need to >>>>>> document >>>>>> requirements in that space. It's good that we push some >>>>>> requirements >>>>>> to >>>>>> ROLL on route-over, and that's certainly the right time to do so. >>>>>> >>>>>> To Jonathan: I do not completely agree that ISA100 is mesh >>>>>> under. The >>>>>> routing is not specified and left to the system manager >>>>>> implementation. >>>>>> My personal hope is to promote a ROLL solution in ISA100.11a next >>>>>> release. See >>>>>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >>>>>> >>>>>> So the current release of ISA100.11a is at the same level as >>>>>> 6LoWPAN >>>>>> on >>>>>> the matter of routing. >>>>>> >>>>>> In a same fashion, ISA does not define the backbone operation, >>>>>> the >>>>>> fragment recovery mechanism or the Explicit Congestion >>>>>> Notification. >>>>>> For >>>>>> all those features, there's a hope at ISA that the IETF will >>>>>> come up >>>>>> with more generic solutions that they can apply. But time is >>>>>> running >>>>>> out. >>>>>> >>>>>> 6LoWPAN hasn't produced anything for the last 6 months. At this >>>>>> rate, >>>>>> ISA will have to define everything on its own and hopefully >>>>>> publish an >>>>>> informational to this group. >>>>>> >>>>>> At the moment, the first draft of ISA100.11a is in letter >>>>>> ballot. The >>>>>> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, >>>>>> which >>>>>> is an evolution from 802.15.4. But the formats are not exactly >>>>>> 6LoWPAN >>>>>> so ISA is using NaLP headers starting with b'00'. >>>>>> >>>>>> What ISA needs from 6LoWPAN in very short term is in that order: >>>>>> - promote Jonathan's draft as a convergence specification so >>>>>> ISA can >>>>>> at >>>>>> least use standard HC headers. >>>>>> This enables: non-Link-Local-Address compression >>>>>> Hops limit compression >>>>>> UDP checksum compression >>>>>> Better placement of HC2 >>>>>> Which are all mandatory for ISA100.11a >>>>>> - better define the NaLPs. >>>>>> There should be a way to indicate to a 6LoWPAN node whether a >>>>>> NaLP >>>>>> can >>>>>> be skipped and what its length is. >>>>>> - define IP ECN bits in a 6LoWPAN header for use by >>>>>> intermediate nodes >>>>>> to report congestion. >>>>>> - specify a fragment flow control and recovery protocol at the >>>>>> 6LoWPAN >>>>>> Shim layer >>>>>> There is no rocket science in any of this and it all could/ >>>>>> should be >>>>>> carried out swiftly. >>>>>> >>>>>> What ISA needs in longer term: >>>>>> - define backbone operation when the backbone federates multiple >>>>>> LoWPANs >>>>>> into a single link (or subnet, TBD). >>>>>> This is more theoretical work for us. Related to proxy ND, a new >>>>>> registration protocols, multilink subnet, etc... >>>>>> >>>>>> Pascal >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- >>>>>>> bounces@ietf.org] On >>>>>>> >>>>>>> >>>>>> Behalf Of Jonathan Hui >>>>>> >>>>>> >>>>>>> Sent: jeudi 22 mai 2008 00:20 >>>>>>> To: Mark Townsley (townsley) >>>>>>> Cc: 6lowpan@ietf.org >>>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>>> >>>>>>> >>>>>>> Hi Mark: >>>>>>> >>>>>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>>>>> >>>>>>> >>>>>>>>> - To your point on ND, this is precisely why the >>>>>>>>> architecture draft >>>>>>>>> is so important. We haven't given it as much attention >>>>>>>>> lately, but >>>>>>>>> it will help resolve the question your raise and many other >>>>>>>>> questions in the future. For example, the architecture draft >>>>>>>>> identifies two modes of operation: mesh-under and route- >>>>>>>>> over. Both >>>>>>>>> of which may require different ND mechanisms. This doesn't >>>>>>>>> apply to >>>>>>>>> just ND, but may apply questions of fragmentation, header >>>>>>>>> compression, security, etc. >>>>>>>>> >>>>>>>>> >>>>>>>> I worry about the under/over debate. It seems that with all the >>>>>>>> effort and enthusiasm in ROLL, we might be well-served at the >>>>>>>> moment >>>>>>>> by focusing on helping them be successful with route-over than >>>>>>>> spending too much of our time on route-under. >>>>>>>> >>>>>>>> >>>>>>> I worry too, especially since it will pull the WG in different >>>>>>> directions. I'm with you on the preference for route-over, but >>>>>>> others >>>>>>> in this group feel strongly about mesh-under as well, especially >>>>>>> since >>>>>>> ISA100.11a seems to have adopted a mesh-under approach. I've >>>>>>> personally been focused on developing route-over solutions while >>>>>>> being >>>>>>> conscious of supporting mesh-under when possible (evident with >>>>>>> 6lowpan- >>>>>>> hc). However, things will start to diverge when we start to talk >>>>>>> about >>>>>>> bootstrapping, ND, etc. So we should make a conscious decision >>>>>>> of >>>>>>> whether we're supporting one or both. >>>>>>> >>>>>>> -- >>>>>>> Jonathan Hui >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> - I hesitate a bit that we suggest possible solutions to ND >>>>>>>>> in the >>>>>>>>> charter ("reusing the 802.15.4 network structure (use the >>>>>>>>> coordinators)") especially since the definition of such link >>>>>>>>> mechanisms are still in motion within the IEEE. It seems more >>>>>>>>> productive to me if we can develop mechanisms that are less >>>>>>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>>>>>>> >>>>>>>>> >>>>>>>> I agree that we should develop mechanisms that could work >>>>>>>> generically whenever possible. >>>>>>>> >>>>>>>> - Mark >>>>>>>> >>>>>>>> >>>>>>>>> Rest of the charter looks good to me. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jonathan Hui >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi Mark: >>>>>>>>>>> >>>>>>>>>>> I think we need a work item (usually implicit) around the >>>>>>>>>>> concept >>>>>>>>>>> of >>>>>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in >>>>>>>>>>> several >>>>>>>>>>> aspects: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - A major one is a better fit with ISA100.11a. Getting >>>>>>>>>>> ISA100.11a >>>>>>>>>>> to >>>>>>>>>>> conform to 6LoWPAN would be a major win, but is certainly >>>>>>>>>>> not a >>>>>>>>>>> given. >>>>>>>>>>> At the moment, the ISA100.11a documents expose >>>>>>>>>>> discrepencies with >>>>>>>>>>> RFC >>>>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan- >>>>>>>>>>> hc >>>>>>>>>>> resolve >>>>>>>>>>> for the most part. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm >>>>>>>>>> eager >>>>>>>>>> >>>>>>>>>> >>>>>> to >>>>>> >>>>>> >>>>>>>>>> improve RFC 4944, but not eager to endorse changes that >>>>>>>>>> inhibit >>>>>>>>>> interoperability. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a >>>>>>>>>>> multihop >>>>>>>>>>> radio >>>>>>>>>>> mesh exposes the network to congestion collapse, as >>>>>>>>>>> described in >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>> >>>>>> >>>>>>>>>>> overy . I think that the WG should dedicate some >>>>>>>>>>> bandwitdth to >>>>>>>>>>> provide >>>>>>>>>>> additional functions that would improve the LoWPAN >>>>>>>>>>> operation WRT >>>>>>>>>>> flow >>>>>>>>>>> control and recovery of fragments. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Fragmentation, OK, but why is flow control a network layer >>>>>>>>>> issue >>>>>>>>>> rather >>>>>>>>>> than a transport layer issue? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Another aspect of ISA100.11a is the concept of a backbone >>>>>>>>>>> router. >>>>>>>>>>> It >>>>>>>>>>> would be appropriate that the IETF comes up with a >>>>>>>>>>> proposal to >>>>>>>>>>> implement >>>>>>>>>>> the concept in the IPv6 world. This partially falls under >>>>>>>>>>> the >>>>>>>>>>> first work >>>>>>>>>>> item on ND but might also include ND proxy over the backbone >>>>>>>>>>> which is a >>>>>>>>>>> stretch to the work item. More in >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>> >>>>>> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Well, don't we need to define what ND looks like on a lowpan >>>>>>>>>> before we >>>>>>>>>> decide whether it needs to be proxied or not? >>>>>>>>>> >>>>>>>>>> - Mark >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> What do you think? >>>>>>>>>>> >>>>>>>>>>> Pascal >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org >>>>>>>>>>>> ] >>>>>>>>>>>> On >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Behalf Of Mark Townsley >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> (townsley) >>>>>>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>>>>>> To: 6lowpan@ietf.org >>>>>>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I'd like to ask the group one final time for comments on >>>>>>>>>>>> the >>>>>>>>>>>> proposed >>>>>>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>>>>>>> >>>>>>>>>>>> As I said before, soon after the format document was >>>>>>>>>>>> published, >>>>>>>>>>>> there >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> is >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> nothing stopping the WG from discussing and working on >>>>>>>>>>>> new and >>>>>>>>>>>> existing >>>>>>>>>>>> items at this time. In fact, activity helps us to decide >>>>>>>>>>>> what >>>>>>>>>>>> should be >>>>>>>>>>>> in and out of the charter. Please do not construe not >>>>>>>>>>>> having a >>>>>>>>>>>> charter >>>>>>>>>>>> in place as a reason not to update drafts, or discuss >>>>>>>>>>>> topics >>>>>>>>>>>> that need >>>>>>>>>>>> to be discussed. Just as when we have BoF's and mailing >>>>>>>>>>>> lists >>>>>>>>>>>> before >>>>>>>>>>>> creating a new WG, it is good to have WG meetings and on- >>>>>>>>>>>> lists >>>>>>>>>>>> discussions when creating new WG charters. >>>>>>>>>>>> >>>>>>>>>>>> - Mark >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 6lowpan mailing list >>>>>>>>>> 6lowpan@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>> >>>>>>> >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>> >>>> >>>> >> >> >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 00:33:48 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30A93A67F3; Tue, 10 Jun 2008 00:33:48 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D403A67F3; Tue, 10 Jun 2008 00:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meQaPkLyQDY4; Tue, 10 Jun 2008 00:33:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 71AA33A6833; Tue, 10 Jun 2008 00:33:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,616,1204498800"; d="scan'208";a="11230063" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2008 09:34:03 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5A7Y3fr010656; Tue, 10 Jun 2008 09:34:03 +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.13.8/8.13.8) with ESMTP id m5A7Y3W1003966; Tue, 10 Jun 2008 07:34:03 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, 10 Jun 2008 09:34:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 09:33:19 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> In-Reply-To: <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjKZwgLFVdhUFh3QziyFpw2ZoduoAAZAcbw References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> From: "Pascal Thubert (pthubert)" To: "Lloyd Wood" , "Mark Townsley (townsley)" X-OriginalArrivalTime: 10 Jun 2008 07:34:03.0125 (UTC) FILETIME=[5B237A50:01C8CACC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=24534; t=1213083243; x=1213947243; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[6lowpan]=20ISA100.11a=20statu s=20and=20requirements(was=09RE=3A=09New=09charter=20for=206 lowpan) |Sender:=20; bh=wonKVezO3S8d5KU/FPomky9jQQylZtNGYuGGVzEtl6k=; b=SKuKegGoUon0VA4kJLbjBAJQjGSBfjuPJh0bb197QEZWnBitKnFGcgAK/n zfxwgVcmP1cPbvD/vkqZIGl64ir2/RHPth8ciK1JKWmQMaHdg8ZJu6xeM/iJ Q934jpNMK8; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Geoff Mulligan , roll@ietf.org, Jay Werb , "Chernoguzov, Alexander \(PA35\)" , "Polyzois, Christos A" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Lloyd: There is some history in the ML about UDP checksum compression and ISA100.11a. On 3/3 I wrote: " Per RFC 4944: "The UDP header's checksum field is not compressed and is therefore carried in full." The UDP checksum is not the only way to protect the IP pseudo header, the UDP header and the payload. ISA 100.11a is defining a transport-level security that does all this and more, since it has a larger signature and provides mutual authentication at the same time. Also, the ISA100.11a transport-level security is usually hardware-assisted, so it requires little power or CPU time on the field device, whereas UDP checksum will be a costly CPU operation. So ISA100.11a is an example where the UDP checksum could and actually should be compressed over the LoWPAN, leaving it up to be reconstructed by a backbone router should the packet go any further than the LOWPAN itself. Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to standardize it to mean that the UDP checksum is compressed, provided that the headers and payload are equally or better protected than if the checksum was used. " Then followed a thread entitled: "[6lowpan] Compressing the UDP checksum" In short, there was a general agreement that this was doable under circumstances; In particular, the current draft under review of ISA100.11a transport section (under review) has the following text: " 1.4.3 Eliding the UDP checksum ISA100.11a uses both HC1 and HC2, and extends the UDP common compressed header encoding to compress the UDP upper layer checksum by relying on the Transport layer security to provide the same service, and more. For that purpose, the Transport layer builds an ISA100.11a pseudo-header by concatenating the UDP pseudo-header for IPv6 as described in the previous section, the source UDP port and the destination UDP port: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Upper-Layer Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source UDP port | Destination UDP port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ISA100.11a pseudo-header is filled and placed before the UDP payload for the crypto process. If encryption is performed on the message, the pseudo-header is not encrypted, but the pseudo-header is part of the MIC in any case. Once the crypto process is completed, the pseudo-header is removed from the message, and the IP and UDP headers are put in its place for transmission. On the receiving side, the transport layer will restore the pseudo-header based on the received packet prior to the crypto process to validate that none of the protected fields was tempered with. When HC2 is applied, bit 3 in the UDP common compressed header encoding, which is reserved in RFC 4944, is set to express whether the checksum is elided. When so, the 8 bytes of UDP header can be compressed down to a single byte that contains the partially compressed ports, using 4 bits each. Note 1: When the packet is not protected by the Transport layer security, the UDP checksum can not be compressed and must be carried in full as prescribed by RFC 4944. If Transport Layer Security is active for a given packet, then the UDP checksum might be elided as prescribed above. Note 2: If the UDP upper layer checksum field is elided, it is up to the other endpoint across the DLL subnet to recompute the UDP checksum as part of the 6LoWPAN expansion, if necessary. This is required in particular for a middlebox such as a backbone router that forwards the uncompressed packet as opposed to terminating the transport. Note 3: If the UDP checksum is not elided and security is applied, then the UDP checksum must be computed after the security operation is complete and the security fields are filled. The UDP payload that is used for the UDP checksum includes all data from the UDP header on, including the security fields, application data and MIC fields, whether the application data is encrypted or not. " This proposal provides better guarantees than the UDP checksum alone. Part of it because the security signature is longer and the UDP checksum, and part of it because that security authenticates the data as well. Would you agree that compressing the UDP checksum is valid in this case? Pascal >-----Original Message----- >From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Lloyd Wood >Sent: lundi 9 juin 2008 21:28 >To: Mark Townsley (townsley) >Cc: Geoff Mulligan; roll@ietf.org; Jay Werb; Polyzois,Christos A; Chernoguzov,Alexander (PA35); >6lowpan@ietf.org >Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) > > >On 9 Jun 2008, at 17:34, Mark Townsley wrote: > >> Geoff Mulligan wrote: >>> Mark, >>> this is interesting news. This can save another byte and if there >>> would be no large push against this then compressing out another byte >>> would be good. >>> >> I can't promise anything, but 6lowpan certainly isn't the only place >> where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty >> much any UDP-based tunneling protocol running on a router in >> hardware at >> high scale or speeds is running into the same problem. > >The pseudo-header checksum is the only thing preventing misdelivery; >the header gets checked once at the endpoint (IPv6) as opposed to >being checked and recomputed at every hop (IPv4). > >I'm not convinced that the IPv6 design choices here were right - I'd >have gone for a header checksum across immutable fields, skipping TTL, >CoS and the like, that wouldn't require recomputing, and which would >have constrained misdelivery to a single link, rather than the path - >this would be more useful for resends and diagnostics, while >increasing the pain for NAT. Here, IPv6 assumes a tight application/ >application control loop and path where the cost of resending a packet >across the entire path is low. > >That raw IPv6 header tunnelling sans UDP header (or GRE sans optional >checksum or MPLS) lacks any self-checking mechanism for reliability >should be of some concern. > >RFC2460 p28 section 8.1 Upper-Layer Checksums: > >[..] >o Unlike IPv4, when UDP packets are originated by an IPv6 node, the >UDP checksum is not optional. That is, whenever originating a UDP >packet, an IPv6 node must compute a UDP checksum over the packet and >the pseudo-header, and, if that computation yields a result of zero, >it must be changed to hex FFFF for placement in the UDP header. IPv6 >receivers must discard UDP packets containing a zero checksum, and >should log the error. ^^^^ >[..] > >That 'must' is clear and unambiguous. The side-effects mean that this >should NOT be thought of as an optimization. >L. > >> I know of >> implementations today that zero out the UDP checksum, and IMHO a good >> implementation that is "liberal in what it accepts" would not drop the >> packet with a zero UDP checksum arriving over IPv6 (in fact, its >> annoying that one would even have to differentiate between IPv4 and >> IPv6 >> at all here if you ask me). >>> This is currently in the HC1g draft and would allow consistency >>> between >>> 6lowpan and SP100. >>> >> I suppose that isn't a bad thing. >> >> - Mark >>> geoff >>> >>> On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: >>> >>>> Geoff Mulligan wrote: >>>> >>>>> Aren't both abstractions equally valid? I think that the biggest >>>>> issue >>>>> with a mesh under is that there is no one standard for it. >>>>> ISA100 is >>>>> one; I have done another using AODVtiny; I think Jennic has one >>>>> using >>>>> their mesh protocol and there are others. If IEEE had defined a >>>>> multi-hop L2 mesh then we could point at that and define a >>>>> solution for >>>>> ND and bootstrapping and security and ... for it. >>>>> >>>>> The WG decided a couple of meetings ago that we would focus on >>>>> solutions >>>>> for the Route Over abstraction. [If while we are doing this we >>>>> can keep >>>>> in mind some of the issues w.r.t. mesh under that's good.] >>>>> >>>>> Somewhat independent from this is the HC1G draft that is >>>>> important to >>>>> deal with since we do need a way to efficiently handle non-local >>>>> addresses. So as to remove the mesh under vs. route over issues >>>>> from >>>>> the HC1G draft I would like to see the draft updated to remove >>>>> the UDP >>>>> checksum optimization. >>>>> >>>>> >>>> I'm more optimistic about keeping the UDP checksum optimization. >>>> There >>>> are other forces at work which may relax the UDP checksum >>>> requirement in >>>> IPv6 in certain cases. So as long as you have well thought out >>>> reasoning, I wouldn't be afraid of keeping it in. >>>> >>>> - Mark >>>> >>>>> I would like to ask the WG if we should consider taking >>>>> draft-hui-6lowpan-hc-00.txt on a a WG document, with the change of >>>>> removing the UDP checksum compression. >>>>> >>>>> geoff >>>>> >>>>> On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: >>>>> >>>>> >>>>>> Hi Pascal, >>>>>> >>>>>> So let's drop the mesh-under/route-over terminology for a >>>>>> second, I >>>>>> think they are confusing since everyone seems to have a different >>>>>> definition for those terms. >>>>>> >>>>>> What I am mainly concerned about is the kind of IP Link >>>>>> abstraction >>>>>> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops >>>>>> (e.g. >>>>>> 802.15.4 and possible others through a BbR), what I've been >>>>>> calling >>>>>> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. the >>>>>> radio range of 802.15.4), what I've been calling route-over. My >>>>>> point >>>>>> to Mark's concern was that solutions to some work items within >>>>>> 6LoWPAN >>>>>> will be different depending on our IP Link abstraction. From >>>>>> what I >>>>>> understand, ISA100.11a has chosen option (i). But to your point >>>>>> below, >>>>>> using IP routing to provide connectivity between nodes within >>>>>> the same >>>>>> IP Link doesn't seem right to me, so it'd be great if you could >>>>>> help >>>>>> me see a path to get there. >>>>>> >>>>>> A lot of this confusion can be cleaned up within the 6LoWPAN >>>>>> architecture document. But I think Mark's concern still stands: >>>>>> whether or not we're focused on one or both of these IP Link >>>>>> abstractions. >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hi: >>>>>>> >>>>>>> My understanding is that defining how mesh-under computes its >>>>>>> routes >>>>>>> is >>>>>>> out of scope for the IETF overall. I'm not even sure we need to >>>>>>> document >>>>>>> requirements in that space. It's good that we push some >>>>>>> requirements >>>>>>> to >>>>>>> ROLL on route-over, and that's certainly the right time to do so. >>>>>>> >>>>>>> To Jonathan: I do not completely agree that ISA100 is mesh >>>>>>> under. The >>>>>>> routing is not specified and left to the system manager >>>>>>> implementation. >>>>>>> My personal hope is to promote a ROLL solution in ISA100.11a next >>>>>>> release. See >>>>>>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >>>>>>> >>>>>>> So the current release of ISA100.11a is at the same level as >>>>>>> 6LoWPAN >>>>>>> on >>>>>>> the matter of routing. >>>>>>> >>>>>>> In a same fashion, ISA does not define the backbone operation, >>>>>>> the >>>>>>> fragment recovery mechanism or the Explicit Congestion >>>>>>> Notification. >>>>>>> For >>>>>>> all those features, there's a hope at ISA that the IETF will >>>>>>> come up >>>>>>> with more generic solutions that they can apply. But time is >>>>>>> running >>>>>>> out. >>>>>>> >>>>>>> 6LoWPAN hasn't produced anything for the last 6 months. At this >>>>>>> rate, >>>>>>> ISA will have to define everything on its own and hopefully >>>>>>> publish an >>>>>>> informational to this group. >>>>>>> >>>>>>> At the moment, the first draft of ISA100.11a is in letter >>>>>>> ballot. The >>>>>>> current draft mostly applies 6loWPAN formats over ISA100.11a DLL, >>>>>>> which >>>>>>> is an evolution from 802.15.4. But the formats are not exactly >>>>>>> 6LoWPAN >>>>>>> so ISA is using NaLP headers starting with b'00'. >>>>>>> >>>>>>> What ISA needs from 6LoWPAN in very short term is in that order: >>>>>>> - promote Jonathan's draft as a convergence specification so >>>>>>> ISA can >>>>>>> at >>>>>>> least use standard HC headers. >>>>>>> This enables: non-Link-Local-Address compression >>>>>>> Hops limit compression >>>>>>> UDP checksum compression >>>>>>> Better placement of HC2 >>>>>>> Which are all mandatory for ISA100.11a >>>>>>> - better define the NaLPs. >>>>>>> There should be a way to indicate to a 6LoWPAN node whether a >>>>>>> NaLP >>>>>>> can >>>>>>> be skipped and what its length is. >>>>>>> - define IP ECN bits in a 6LoWPAN header for use by >>>>>>> intermediate nodes >>>>>>> to report congestion. >>>>>>> - specify a fragment flow control and recovery protocol at the >>>>>>> 6LoWPAN >>>>>>> Shim layer >>>>>>> There is no rocket science in any of this and it all could/ >>>>>>> should be >>>>>>> carried out swiftly. >>>>>>> >>>>>>> What ISA needs in longer term: >>>>>>> - define backbone operation when the backbone federates multiple >>>>>>> LoWPANs >>>>>>> into a single link (or subnet, TBD). >>>>>>> This is more theoretical work for us. Related to proxy ND, a new >>>>>>> registration protocols, multilink subnet, etc... >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- >>>>>>>> bounces@ietf.org] On >>>>>>>> >>>>>>>> >>>>>>> Behalf Of Jonathan Hui >>>>>>> >>>>>>> >>>>>>>> Sent: jeudi 22 mai 2008 00:20 >>>>>>>> To: Mark Townsley (townsley) >>>>>>>> Cc: 6lowpan@ietf.org >>>>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>>>> >>>>>>>> >>>>>>>> Hi Mark: >>>>>>>> >>>>>>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>>>>>> >>>>>>>> >>>>>>>>>> - To your point on ND, this is precisely why the >>>>>>>>>> architecture draft >>>>>>>>>> is so important. We haven't given it as much attention >>>>>>>>>> lately, but >>>>>>>>>> it will help resolve the question your raise and many other >>>>>>>>>> questions in the future. For example, the architecture draft >>>>>>>>>> identifies two modes of operation: mesh-under and route- >>>>>>>>>> over. Both >>>>>>>>>> of which may require different ND mechanisms. This doesn't >>>>>>>>>> apply to >>>>>>>>>> just ND, but may apply questions of fragmentation, header >>>>>>>>>> compression, security, etc. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I worry about the under/over debate. It seems that with all the >>>>>>>>> effort and enthusiasm in ROLL, we might be well-served at the >>>>>>>>> moment >>>>>>>>> by focusing on helping them be successful with route-over than >>>>>>>>> spending too much of our time on route-under. >>>>>>>>> >>>>>>>>> >>>>>>>> I worry too, especially since it will pull the WG in different >>>>>>>> directions. I'm with you on the preference for route-over, but >>>>>>>> others >>>>>>>> in this group feel strongly about mesh-under as well, especially >>>>>>>> since >>>>>>>> ISA100.11a seems to have adopted a mesh-under approach. I've >>>>>>>> personally been focused on developing route-over solutions while >>>>>>>> being >>>>>>>> conscious of supporting mesh-under when possible (evident with >>>>>>>> 6lowpan- >>>>>>>> hc). However, things will start to diverge when we start to talk >>>>>>>> about >>>>>>>> bootstrapping, ND, etc. So we should make a conscious decision >>>>>>>> of >>>>>>>> whether we're supporting one or both. >>>>>>>> >>>>>>>> -- >>>>>>>> Jonathan Hui >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> - I hesitate a bit that we suggest possible solutions to ND >>>>>>>>>> in the >>>>>>>>>> charter ("reusing the 802.15.4 network structure (use the >>>>>>>>>> coordinators)") especially since the definition of such link >>>>>>>>>> mechanisms are still in motion within the IEEE. It seems more >>>>>>>>>> productive to me if we can develop mechanisms that are less >>>>>>>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I agree that we should develop mechanisms that could work >>>>>>>>> generically whenever possible. >>>>>>>>> >>>>>>>>> - Mark >>>>>>>>> >>>>>>>>> >>>>>>>>>> Rest of the charter looks good to me. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jonathan Hui >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi Mark: >>>>>>>>>>>> >>>>>>>>>>>> I think we need a work item (usually implicit) around the >>>>>>>>>>>> concept >>>>>>>>>>>> of >>>>>>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in >>>>>>>>>>>> several >>>>>>>>>>>> aspects: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - A major one is a better fit with ISA100.11a. Getting >>>>>>>>>>>> ISA100.11a >>>>>>>>>>>> to >>>>>>>>>>>> conform to 6LoWPAN would be a major win, but is certainly >>>>>>>>>>>> not a >>>>>>>>>>>> given. >>>>>>>>>>>> At the moment, the ISA100.11a documents expose >>>>>>>>>>>> discrepencies with >>>>>>>>>>>> RFC >>>>>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft-hui-6lowpan- >>>>>>>>>>>> hc >>>>>>>>>>>> resolve >>>>>>>>>>>> for the most part. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm >>>>>>>>>>> eager >>>>>>>>>>> >>>>>>>>>>> >>>>>>> to >>>>>>> >>>>>>> >>>>>>>>>>> improve RFC 4944, but not eager to endorse changes that >>>>>>>>>>> inhibit >>>>>>>>>>> interoperability. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a >>>>>>>>>>>> multihop >>>>>>>>>>>> radio >>>>>>>>>>>> mesh exposes the network to congestion collapse, as >>>>>>>>>>>> described in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>>> >>>>>>> >>>>>>>>>>>> overy . I think that the WG should dedicate some >>>>>>>>>>>> bandwitdth to >>>>>>>>>>>> provide >>>>>>>>>>>> additional functions that would improve the LoWPAN >>>>>>>>>>>> operation WRT >>>>>>>>>>>> flow >>>>>>>>>>>> control and recovery of fragments. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Fragmentation, OK, but why is flow control a network layer >>>>>>>>>>> issue >>>>>>>>>>> rather >>>>>>>>>>> than a transport layer issue? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Another aspect of ISA100.11a is the concept of a backbone >>>>>>>>>>>> router. >>>>>>>>>>>> It >>>>>>>>>>>> would be appropriate that the IETF comes up with a >>>>>>>>>>>> proposal to >>>>>>>>>>>> implement >>>>>>>>>>>> the concept in the IPv6 world. This partially falls under >>>>>>>>>>>> the >>>>>>>>>>>> first work >>>>>>>>>>>> item on ND but might also include ND proxy over the backbone >>>>>>>>>>>> which is a >>>>>>>>>>>> stretch to the work item. More in >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>>> >>>>>>> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Well, don't we need to define what ND looks like on a lowpan >>>>>>>>>>> before we >>>>>>>>>>> decide whether it needs to be proxied or not? >>>>>>>>>>> >>>>>>>>>>> - Mark >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> What do you think? >>>>>>>>>>>> >>>>>>>>>>>> Pascal >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org >>>>>>>>>>>>> ] >>>>>>>>>>>>> On >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Behalf Of Mark Townsley >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> (townsley) >>>>>>>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>>>>>>> To: 6lowpan@ietf.org >>>>>>>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I'd like to ask the group one final time for comments on >>>>>>>>>>>>> the >>>>>>>>>>>>> proposed >>>>>>>>>>>>> new charter. I've also asked the ROLL WG chairs to comment. >>>>>>>>>>>>> >>>>>>>>>>>>> As I said before, soon after the format document was >>>>>>>>>>>>> published, >>>>>>>>>>>>> there >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> is >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> nothing stopping the WG from discussing and working on >>>>>>>>>>>>> new and >>>>>>>>>>>>> existing >>>>>>>>>>>>> items at this time. In fact, activity helps us to decide >>>>>>>>>>>>> what >>>>>>>>>>>>> should be >>>>>>>>>>>>> in and out of the charter. Please do not construe not >>>>>>>>>>>>> having a >>>>>>>>>>>>> charter >>>>>>>>>>>>> in place as a reason not to update drafts, or discuss >>>>>>>>>>>>> topics >>>>>>>>>>>>> that need >>>>>>>>>>>>> to be discussed. Just as when we have BoF's and mailing >>>>>>>>>>>>> lists >>>>>>>>>>>>> before >>>>>>>>>>>>> creating a new WG, it is good to have WG meetings and on- >>>>>>>>>>>>> lists >>>>>>>>>>>>> discussions when creating new WG charters. >>>>>>>>>>>>> >>>>>>>>>>>>> - Mark >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 6lowpan mailing list >>>>>>>>>>> 6lowpan@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 6lowpan mailing list >>>>>>>> 6lowpan@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 6lowpan mailing list >>>>> 6lowpan@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>> >>>>> >>>>> >>> >>> >>> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 04:11:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A721D3A6832; Tue, 10 Jun 2008 04:11:59 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706963A6765; Tue, 10 Jun 2008 04:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.759 X-Spam-Level: X-Spam-Status: No, score=-6.759 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR99POX02WL2; Tue, 10 Jun 2008 04:11:55 -0700 (PDT) Received: from mail133.messagelabs.com (mail133.messagelabs.com [195.245.230.179]) by core3.amsl.com (Postfix) with SMTP id A341C3A6832; Tue, 10 Jun 2008 04:11:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-133.messagelabs.com!1213096330!21900445!11 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 21040 invoked from network); 10 Jun 2008 11:12:15 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-14.tower-133.messagelabs.com with SMTP; 10 Jun 2008 11:12:15 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 12:12:03 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 12:12:02 +0100 Message-Id: From: Lloyd Wood To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 12:12:01 +0100 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 11:12:03.0170 (UTC) FILETIME=[CF73F420:01C8CAEA] Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org below On 10 Jun 2008, at 08:33, Pascal Thubert (pthubert) wrote: > > Per RFC 4944: > "The UDP header's checksum field is not compressed and is therefore > carried in full." > > The UDP checksum is not the only way to protect the IP pseudo header, > the UDP header and the payload. > ISA 100.11a is defining a transport-level security that does all this > and more, since it has a larger signature and provides mutual > authentication at the same time. The end-to-end principle tells us that that is not good enough if that is not implemented between endhosts across the entire path - this is like saying that we're going across an Ethernet link, Ethernet's CRC32 is stronger than the UDP checksum, therefore we'll just leave out the UDP checksum and recompute it once we're across the Ethernet link. RFC4944 deliberately leaves the UDP checksum alone to preserve an end- to-end integrity check - if it is altered (compressed) and then altered back, you cannot be sure that errors have not been introduced (more likely software bugs than transmission errors). Those errors cannot be easily detected by an endhost, because the checksum has been recomputed and is no longer a valid end-to-end check. A recomputed checksum is far less useful for protection - one reason why the IPv4 header checksum was simply removed in IPv6. > Also, the ISA100.11a transport-level security is usually > hardware-assisted, so it requires little power or CPU time on the > field > device, whereas UDP checksum will be a costly CPU operation. Sorry, false argument. google hardware-assisted UDP checksum. It's not computationally difficult or hard. When adding TLS and compressing the UDP header, is the UDP checksum verified across the entire payload and pseudo-header before this is done, to check that you're starting with good material? There's still an unavoidable need for a necessary UDP checksum computation there. If you're going to replace then recompute the checksum leaving the subnet, you need to compute it going in to check that what you're about to checksum across is good. > So ISA100.11a is an example where the UDP checksum could and actually > should be compressed over the LoWPAN, leaving it up to be > reconstructed > by a backbone router should the packet go any further than the LOWPAN > itself. > > Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to > standardize it to mean that the UDP checksum is compressed, provided > that the headers and payload are equally or better protected than if > the > checksum was used. That misunderstands the end-to-end principle and the nature of protection across the entire path; it's really not equal, despite the weakness of the UDP checksum strength, because the UDP checksum is across the whole path between endhosts, and the TLS protection is not. Wait a bit, you'll probably want that reserved bit for something more useful in a while. (I am reminded of the furore over reusing the three MPLS experimental bits - that kept Stewart Bryant flying round the world for months.) > Then followed a thread entitled: > "[6lowpan] Compressing the UDP checksum" > > In short, there was a general agreement that this was doable under > circumstances; In particular, the current draft under review of > ISA100.11a transport section (under review) has the following text: > > " > 1.4.3 Eliding the UDP checksum > ISA100.11a uses both HC1 and HC2, and extends the UDP common > compressed > header encoding to compress the UDP upper layer checksum by relying on > the Transport layer security to provide the same service, and more. > For that purpose, the Transport layer builds an ISA100.11a pseudo- > header > by concatenating the UDP pseudo-header for IPv6 as described in the > previous section, the source UDP port and the destination UDP port: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Source Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Destination Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Upper-Layer Packet Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | zero | Next Header | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source UDP port | Destination UDP port | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The ISA100.11a pseudo-header is filled and placed before the UDP > payload > for the crypto process. If encryption is performed on the message, the > pseudo-header is not encrypted, but the pseudo-header is part of the > MIC > in any case. > Once the crypto process is completed, the pseudo-header is removed > from > the message, and the IP and UDP headers are put in its place for > transmission. On the receiving side, the transport layer will restore > the pseudo-header based on the received packet prior to the crypto > process to validate that none of the protected fields was tempered > with. spelling - tampered. > When HC2 is applied, bit 3 in the UDP common compressed header > encoding, > which is reserved in RFC 4944, is set to express whether the > checksum is > elided. When so, the 8 bytes of UDP header can be compressed down to a > single byte that contains the partially compressed ports, using 4 bits > each. > Note 1: When the packet is not protected by the Transport layer > security, the UDP checksum can not be compressed and must be carried > in > full as prescribed by RFC 4944. If Transport Layer Security is active > for a given packet, then the UDP checksum might be elided as > prescribed > above. > Note 2: If the UDP upper layer checksum field is elided, it is up to double space > > the other endpoint across the DLL subnet to recompute the UDP checksum > as part of the 6LoWPAN expansion, if necessary. This is required in > particular for a middlebox such as a backbone router that forwards the > uncompressed packet as opposed to terminating the transport. > Note 3: If the UDP checksum is not elided and security is applied, > then > the UDP checksum must be computed after the security operation is > complete and the security fields are filled. The UDP payload that is > used for the UDP checksum includes all data from the UDP header on, > including the security fields, application data and MIC fields, > whether > the application data is encrypted or not. > " > > This proposal provides better guarantees than the UDP checksum alone. > Part of it because the security signature is longer and the UDP > checksum, and part of it because that security authenticates the > data as > well. But it's only across the 6lowpan part of the path, not across the full path end-to-end, which is the UDP checksum's key feature. You're disobeying the spirit of the text in RFC2460. Do you really think that attention will be paid to the must in your Note 1? It's a slippery slope. > Would you agree that compressing the UDP checksum is valid in this > case? Sorry, it's not. I looked in vain for any mention of the end-to-end principle in the previous mailing list discussion. If you're only adding a header for tunnelling, UDP-Lite or something else can give you a sanity check across the tunnelling header alone, leaving protection of the tunnelled packet up to the checksum in that packet without the overhead of going over the entire paylaod. (IPv6 needs some sort of pseudo-header check from every transport protocol, and the IPv6 header doesn't have it, so UDP-Lite/IPv6 seems attractive. Leaving this up to transport layer designers seems a poor design choice.) But messing with payload integrity checks has subtle and far-reaching consequences. L. > Pascal > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On >> Behalf Of > Lloyd Wood >> Sent: lundi 9 juin 2008 21:28 >> To: Mark Townsley (townsley) >> Cc: Geoff Mulligan; roll@ietf.org; Jay Werb; Polyzois,Christos A; > Chernoguzov,Alexander (PA35); >> 6lowpan@ietf.org >> Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was > RE: New charter for 6lowpan) >> >> >> On 9 Jun 2008, at 17:34, Mark Townsley wrote: >> >>> Geoff Mulligan wrote: >>>> Mark, >>>> this is interesting news. This can save another byte and if there >>>> would be no large push against this then compressing out another > byte >>>> would be good. >>>> >>> I can't promise anything, but 6lowpan certainly isn't the only place >>> where the UDP checksum mandate in IPv6 is seen as unworkable. Pretty >>> much any UDP-based tunneling protocol running on a router in >>> hardware at >>> high scale or speeds is running into the same problem. >> >> The pseudo-header checksum is the only thing preventing misdelivery; >> the header gets checked once at the endpoint (IPv6) as opposed to >> being checked and recomputed at every hop (IPv4). >> >> I'm not convinced that the IPv6 design choices here were right - I'd >> have gone for a header checksum across immutable fields, skipping >> TTL, >> CoS and the like, that wouldn't require recomputing, and which would >> have constrained misdelivery to a single link, rather than the path - >> this would be more useful for resends and diagnostics, while >> increasing the pain for NAT. Here, IPv6 assumes a tight application/ >> application control loop and path where the cost of resending a >> packet >> across the entire path is low. >> >> That raw IPv6 header tunnelling sans UDP header (or GRE sans optional >> checksum or MPLS) lacks any self-checking mechanism for reliability >> should be of some concern. >> >> RFC2460 p28 section 8.1 Upper-Layer Checksums: >> >> [..] >> o Unlike IPv4, when UDP packets are originated by an IPv6 node, the >> UDP checksum is not optional. That is, whenever originating a UDP >> packet, an IPv6 node must compute a UDP checksum over the packet and >> the pseudo-header, and, if that computation yields a result of zero, >> it must be changed to hex FFFF for placement in the UDP header. IPv6 >> receivers must discard UDP packets containing a zero checksum, and >> should log the error. ^^^^ >> [..] >> >> That 'must' is clear and unambiguous. The side-effects mean that this >> should NOT be thought of as an optimization. >> L. >> >>> I know of >>> implementations today that zero out the UDP checksum, and IMHO a >>> good >>> implementation that is "liberal in what it accepts" would not drop > the >>> packet with a zero UDP checksum arriving over IPv6 (in fact, its >>> annoying that one would even have to differentiate between IPv4 and >>> IPv6 >>> at all here if you ask me). >>>> This is currently in the HC1g draft and would allow consistency >>>> between >>>> 6lowpan and SP100. >>>> >>> I suppose that isn't a bad thing. >>> >>> - Mark >>>> geoff >>>> >>>> On Mon, 2008-06-09 at 17:25 +0200, Mark Townsley wrote: >>>> >>>>> Geoff Mulligan wrote: >>>>> >>>>>> Aren't both abstractions equally valid? I think that the biggest >>>>>> issue >>>>>> with a mesh under is that there is no one standard for it. >>>>>> ISA100 is >>>>>> one; I have done another using AODVtiny; I think Jennic has one >>>>>> using >>>>>> their mesh protocol and there are others. If IEEE had defined a >>>>>> multi-hop L2 mesh then we could point at that and define a >>>>>> solution for >>>>>> ND and bootstrapping and security and ... for it. >>>>>> >>>>>> The WG decided a couple of meetings ago that we would focus on >>>>>> solutions >>>>>> for the Route Over abstraction. [If while we are doing this we >>>>>> can keep >>>>>> in mind some of the issues w.r.t. mesh under that's good.] >>>>>> >>>>>> Somewhat independent from this is the HC1G draft that is >>>>>> important to >>>>>> deal with since we do need a way to efficiently handle non-local >>>>>> addresses. So as to remove the mesh under vs. route over issues >>>>>> from >>>>>> the HC1G draft I would like to see the draft updated to remove >>>>>> the UDP >>>>>> checksum optimization. >>>>>> >>>>>> >>>>> I'm more optimistic about keeping the UDP checksum optimization. >>>>> There >>>>> are other forces at work which may relax the UDP checksum >>>>> requirement in >>>>> IPv6 in certain cases. So as long as you have well thought out >>>>> reasoning, I wouldn't be afraid of keeping it in. >>>>> >>>>> - Mark >>>>> >>>>>> I would like to ask the WG if we should consider taking >>>>>> draft-hui-6lowpan-hc-00.txt on a a WG document, with the change >>>>>> of >>>>>> removing the UDP checksum compression. >>>>>> >>>>>> geoff >>>>>> >>>>>> On Thu, 2008-05-22 at 09:14 -0700, Jonathan Hui wrote: >>>>>> >>>>>> >>>>>>> Hi Pascal, >>>>>>> >>>>>>> So let's drop the mesh-under/route-over terminology for a >>>>>>> second, I >>>>>>> think they are confusing since everyone seems to have a >>>>>>> different >>>>>>> definition for those terms. >>>>>>> >>>>>>> What I am mainly concerned about is the kind of IP Link >>>>>>> abstraction >>>>>>> 6LoWPAN provides: (i) an IP Link is formed by multiple L2 hops >>>>>>> (e.g. >>>>>>> 802.15.4 and possible others through a BbR), what I've been >>>>>>> calling >>>>>>> mesh-under (ii) an IP Link is defined by a single L2 hop (e.g. > the >>>>>>> radio range of 802.15.4), what I've been calling route-over. My >>>>>>> point >>>>>>> to Mark's concern was that solutions to some work items within >>>>>>> 6LoWPAN >>>>>>> will be different depending on our IP Link abstraction. From >>>>>>> what I >>>>>>> understand, ISA100.11a has chosen option (i). But to your point >>>>>>> below, >>>>>>> using IP routing to provide connectivity between nodes within >>>>>>> the same >>>>>>> IP Link doesn't seem right to me, so it'd be great if you could >>>>>>> help >>>>>>> me see a path to get there. >>>>>>> >>>>>>> A lot of this confusion can be cleaned up within the 6LoWPAN >>>>>>> architecture document. But I think Mark's concern still stands: >>>>>>> whether or not we're focused on one or both of these IP Link >>>>>>> abstractions. >>>>>>> >>>>>>> -- >>>>>>> Jonathan Hui >>>>>>> >>>>>>> On May 22, 2008, at 12:47 AM, Pascal Thubert (pthubert) wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi: >>>>>>>> >>>>>>>> My understanding is that defining how mesh-under computes its >>>>>>>> routes >>>>>>>> is >>>>>>>> out of scope for the IETF overall. I'm not even sure we need to >>>>>>>> document >>>>>>>> requirements in that space. It's good that we push some >>>>>>>> requirements >>>>>>>> to >>>>>>>> ROLL on route-over, and that's certainly the right time to do > so. >>>>>>>> >>>>>>>> To Jonathan: I do not completely agree that ISA100 is mesh >>>>>>>> under. The >>>>>>>> routing is not specified and left to the system manager >>>>>>>> implementation. >>>>>>>> My personal hope is to promote a ROLL solution in ISA100.11a > next >>>>>>>> release. See >>>>>>>> http://tools.ietf.org/html/draft-ietf-roll-indus-routing-req . >>>>>>>> >>>>>>>> So the current release of ISA100.11a is at the same level as >>>>>>>> 6LoWPAN >>>>>>>> on >>>>>>>> the matter of routing. >>>>>>>> >>>>>>>> In a same fashion, ISA does not define the backbone operation, >>>>>>>> the >>>>>>>> fragment recovery mechanism or the Explicit Congestion >>>>>>>> Notification. >>>>>>>> For >>>>>>>> all those features, there's a hope at ISA that the IETF will >>>>>>>> come up >>>>>>>> with more generic solutions that they can apply. But time is >>>>>>>> running >>>>>>>> out. >>>>>>>> >>>>>>>> 6LoWPAN hasn't produced anything for the last 6 months. At this >>>>>>>> rate, >>>>>>>> ISA will have to define everything on its own and hopefully >>>>>>>> publish an >>>>>>>> informational to this group. >>>>>>>> >>>>>>>> At the moment, the first draft of ISA100.11a is in letter >>>>>>>> ballot. The >>>>>>>> current draft mostly applies 6loWPAN formats over ISA100.11a > DLL, >>>>>>>> which >>>>>>>> is an evolution from 802.15.4. But the formats are not exactly >>>>>>>> 6LoWPAN >>>>>>>> so ISA is using NaLP headers starting with b'00'. >>>>>>>> >>>>>>>> What ISA needs from 6LoWPAN in very short term is in that >>>>>>>> order: >>>>>>>> - promote Jonathan's draft as a convergence specification so >>>>>>>> ISA can >>>>>>>> at >>>>>>>> least use standard HC headers. >>>>>>>> This enables: non-Link-Local-Address compression >>>>>>>> Hops limit compression >>>>>>>> UDP checksum compression >>>>>>>> Better placement of HC2 >>>>>>>> Which are all mandatory for ISA100.11a >>>>>>>> - better define the NaLPs. >>>>>>>> There should be a way to indicate to a 6LoWPAN node whether a >>>>>>>> NaLP >>>>>>>> can >>>>>>>> be skipped and what its length is. >>>>>>>> - define IP ECN bits in a 6LoWPAN header for use by >>>>>>>> intermediate nodes >>>>>>>> to report congestion. >>>>>>>> - specify a fragment flow control and recovery protocol at the >>>>>>>> 6LoWPAN >>>>>>>> Shim layer >>>>>>>> There is no rocket science in any of this and it all could/ >>>>>>>> should be >>>>>>>> carried out swiftly. >>>>>>>> >>>>>>>> What ISA needs in longer term: >>>>>>>> - define backbone operation when the backbone federates >>>>>>>> multiple >>>>>>>> LoWPANs >>>>>>>> into a single link (or subnet, TBD). >>>>>>>> This is more theoretical work for us. Related to proxy ND, a >>>>>>>> new >>>>>>>> registration protocols, multilink subnet, etc... >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan- >>>>>>>>> bounces@ietf.org] On >>>>>>>>> >>>>>>>>> >>>>>>>> Behalf Of Jonathan Hui >>>>>>>> >>>>>>>> >>>>>>>>> Sent: jeudi 22 mai 2008 00:20 >>>>>>>>> To: Mark Townsley (townsley) >>>>>>>>> Cc: 6lowpan@ietf.org >>>>>>>>> Subject: Re: [6lowpan] New charter for 6lowpan >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi Mark: >>>>>>>>> >>>>>>>>> On May 20, 2008, at 8:24 AM, Mark Townsley wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>>> - To your point on ND, this is precisely why the >>>>>>>>>>> architecture draft >>>>>>>>>>> is so important. We haven't given it as much attention >>>>>>>>>>> lately, but >>>>>>>>>>> it will help resolve the question your raise and many other >>>>>>>>>>> questions in the future. For example, the architecture draft >>>>>>>>>>> identifies two modes of operation: mesh-under and route- >>>>>>>>>>> over. Both >>>>>>>>>>> of which may require different ND mechanisms. This doesn't >>>>>>>>>>> apply to >>>>>>>>>>> just ND, but may apply questions of fragmentation, header >>>>>>>>>>> compression, security, etc. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I worry about the under/over debate. It seems that with all > the >>>>>>>>>> effort and enthusiasm in ROLL, we might be well-served at the >>>>>>>>>> moment >>>>>>>>>> by focusing on helping them be successful with route-over >>>>>>>>>> than >>>>>>>>>> spending too much of our time on route-under. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I worry too, especially since it will pull the WG in different >>>>>>>>> directions. I'm with you on the preference for route-over, but >>>>>>>>> others >>>>>>>>> in this group feel strongly about mesh-under as well, > especially >>>>>>>>> since >>>>>>>>> ISA100.11a seems to have adopted a mesh-under approach. I've >>>>>>>>> personally been focused on developing route-over solutions > while >>>>>>>>> being >>>>>>>>> conscious of supporting mesh-under when possible (evident with >>>>>>>>> 6lowpan- >>>>>>>>> hc). However, things will start to diverge when we start to > talk >>>>>>>>> about >>>>>>>>> bootstrapping, ND, etc. So we should make a conscious decision >>>>>>>>> of >>>>>>>>> whether we're supporting one or both. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jonathan Hui >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>> - I hesitate a bit that we suggest possible solutions to ND >>>>>>>>>>> in the >>>>>>>>>>> charter ("reusing the 802.15.4 network structure (use the >>>>>>>>>>> coordinators)") especially since the definition of such link >>>>>>>>>>> mechanisms are still in motion within the IEEE. It seems >>>>>>>>>>> more >>>>>>>>>>> productive to me if we can develop mechanisms that are less >>>>>>>>>>> dependent on the specific structure of 802.15.4 mechanisms. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I agree that we should develop mechanisms that could work >>>>>>>>>> generically whenever possible. >>>>>>>>>> >>>>>>>>>> - Mark >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Rest of the charter looks good to me. >>>>>>>>>>> >>>>>>>>>>> Thanks. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jonathan Hui >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On May 16, 2008, at 11:46 AM, Mark Townsley wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Pascal Thubert (pthubert) wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Mark: >>>>>>>>>>>>> >>>>>>>>>>>>> I think we need a work item (usually implicit) around the >>>>>>>>>>>>> concept >>>>>>>>>>>>> of >>>>>>>>>>>>> improving existing WG RFCs. RFC 4944 can be improved in >>>>>>>>>>>>> several >>>>>>>>>>>>> aspects: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> - A major one is a better fit with ISA100.11a. Getting >>>>>>>>>>>>> ISA100.11a >>>>>>>>>>>>> to >>>>>>>>>>>>> conform to 6LoWPAN would be a major win, but is certainly >>>>>>>>>>>>> not a >>>>>>>>>>>>> given. >>>>>>>>>>>>> At the moment, the ISA100.11a documents expose >>>>>>>>>>>>> discrepencies with >>>>>>>>>>>>> RFC >>>>>>>>>>>>> 4944 that http://www.tools.ietf.org/html/draft- >>>>>>>>>>>>> hui-6lowpan- >>>>>>>>>>>>> hc >>>>>>>>>>>>> resolve >>>>>>>>>>>>> for the most part. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Are the resolutions backwards compatible with RFC 4944? I'm >>>>>>>>>>>> eager >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> to >>>>>>>> >>>>>>>> >>>>>>>>>>>> improve RFC 4944, but not eager to endorse changes that >>>>>>>>>>>> inhibit >>>>>>>>>>>> interoperability. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> - The issue of fragmentation. Applying RFC 4944 over a >>>>>>>>>>>>> multihop >>>>>>>>>>>>> radio >>>>>>>>>>>>> mesh exposes the network to congestion collapse, as >>>>>>>>>>>>> described in >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-rec >>>>>>>> >>>>>>>> >>>>>>>>>>>>> overy . I think that the WG should dedicate some >>>>>>>>>>>>> bandwitdth to >>>>>>>>>>>>> provide >>>>>>>>>>>>> additional functions that would improve the LoWPAN >>>>>>>>>>>>> operation WRT >>>>>>>>>>>>> flow >>>>>>>>>>>>> control and recovery of fragments. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Fragmentation, OK, but why is flow control a network layer >>>>>>>>>>>> issue >>>>>>>>>>>> rather >>>>>>>>>>>> than a transport layer issue? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Another aspect of ISA100.11a is the concept of a backbone >>>>>>>>>>>>> router. >>>>>>>>>>>>> It >>>>>>>>>>>>> would be appropriate that the IETF comes up with a >>>>>>>>>>>>> proposal to >>>>>>>>>>>>> implement >>>>>>>>>>>>> the concept in the IPv6 world. This partially falls under >>>>>>>>>>>>> the >>>>>>>>>>>>> first work >>>>>>>>>>>>> item on ND but might also include ND proxy over the > backbone >>>>>>>>>>>>> which is a >>>>>>>>>>>>> stretch to the work item. More in >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> > http://www.tools.ietf.org/html/draft-thubert-6lowpan-backbone-router >>>>>>>> >>>>>>>> >>>>>>>>>>>>> . >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Well, don't we need to define what ND looks like on a >>>>>>>>>>>> lowpan >>>>>>>>>>>> before we >>>>>>>>>>>> decide whether it needs to be proxied or not? >>>>>>>>>>>> >>>>>>>>>>>> - Mark >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> What do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> Pascal >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: 6lowpan-bounces@ietf.org > [mailto:6lowpan-bounces@ietf.org >>>>>>>>>>>>>> ] >>>>>>>>>>>>>> On >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> Behalf Of Mark Townsley >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> (townsley) >>>>>>>>>>>>>> Sent: jeudi 15 mai 2008 23:02 >>>>>>>>>>>>>> To: 6lowpan@ietf.org >>>>>>>>>>>>>> Subject: [6lowpan] New charter for 6lowpan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'd like to ask the group one final time for comments on >>>>>>>>>>>>>> the >>>>>>>>>>>>>> proposed >>>>>>>>>>>>>> new charter. I've also asked the ROLL WG chairs to > comment. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I said before, soon after the format document was >>>>>>>>>>>>>> published, >>>>>>>>>>>>>> there >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> is >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> nothing stopping the WG from discussing and working on >>>>>>>>>>>>>> new and >>>>>>>>>>>>>> existing >>>>>>>>>>>>>> items at this time. In fact, activity helps us to decide >>>>>>>>>>>>>> what >>>>>>>>>>>>>> should be >>>>>>>>>>>>>> in and out of the charter. Please do not construe not >>>>>>>>>>>>>> having a >>>>>>>>>>>>>> charter >>>>>>>>>>>>>> in place as a reason not to update drafts, or discuss >>>>>>>>>>>>>> topics >>>>>>>>>>>>>> that need >>>>>>>>>>>>>> to be discussed. Just as when we have BoF's and mailing >>>>>>>>>>>>>> lists >>>>>>>>>>>>>> before >>>>>>>>>>>>>> creating a new WG, it is good to have WG meetings and on- >>>>>>>>>>>>>> lists >>>>>>>>>>>>>> discussions when creating new WG charters. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Mark >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 6lowpan mailing list >>>>>>>>>>>> 6lowpan@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 6lowpan mailing list >>>>>>>>> 6lowpan@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>>>> >>>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 6lowpan mailing list >>>>>>> 6lowpan@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 6lowpan mailing list >>>>>> 6lowpan@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6lowpan >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ >> >> >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 04:49:39 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E9C3A6A56; Tue, 10 Jun 2008 04:49:39 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15D953A6A56; Tue, 10 Jun 2008 04:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKg0Qquxw7nx; Tue, 10 Jun 2008 04:49:34 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9E6443A699E; Tue, 10 Jun 2008 04:49:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,617,1204498800"; d="scan'208";a="11269877" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2008 13:49:54 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5ABnsPE011375; Tue, 10 Jun 2008 13:49: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.13.8/8.13.8) with ESMTP id m5ABnsMO011554; Tue, 10 Jun 2008 11:49:54 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, 10 Jun 2008 13:49:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 13:49:16 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjK6wCUe0ByGqbWSZ2gXeNwI0jsxAAABCsg References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> From: "Pascal Thubert (pthubert)" To: "Lloyd Wood" X-OriginalArrivalTime: 10 Jun 2008 11:49:54.0470 (UTC) FILETIME=[1940D460:01C8CAF0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=518; t=1213098594; x=1213962594; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=20=22Pascal=20Thubert=20(pthubert)=22=20 |Subject:=20RE=3A=20[Roll]=20[6lowpan]=20ISA100.11a=20statu s=20and=20requirements(was=09RE=3A=09New=09charter=20for=206 lowpan) |Sender:=20; bh=DSGhhwOW6FpcIz1tSyOamCPxdsC5mzHXEWiyNvdFqdY=; b=I8lA0QrUMRDUtx1nHfLFVvrwpdETR/A9wkoHPnGSvoH4BDNvW7NPNmIq+v +rWGwOf0Ek+JnIZWrwlANHgwrHK2qJY/IV6WqY39M/icRRRel8am8E/YxfMQ jDXSAMykG2; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Lloyd: This is great reading and might prevent mistakes in using UDP CS compression; but does not apply here: - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) Message Integrity Check (MIC) instead of UDP checksum. - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) - And we are designing for devices that might not have hardware assist other than maybe what's specified by 802.15.4 so that's what we use. I hope it's clearer now... Pascal _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 05:27:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6846B3A69F4; Tue, 10 Jun 2008 05:27:16 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81DF3A69F4; Tue, 10 Jun 2008 05:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.679 X-Spam-Level: X-Spam-Status: No, score=-6.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2K7zpDoxn5x; Tue, 10 Jun 2008 05:27:11 -0700 (PDT) Received: from mail83.messagelabs.com (mail83.messagelabs.com [195.245.231.83]) by core3.amsl.com (Postfix) with SMTP id 2801D3A67F5; Tue, 10 Jun 2008 05:27:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-13.tower-83.messagelabs.com!1213100851!60600154!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 15691 invoked from network); 10 Jun 2008 12:27:31 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-13.tower-83.messagelabs.com with SMTP; 10 Jun 2008 12:27:31 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 13:27:31 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 13:27:30 +0100 Message-Id: <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> From: Lloyd Wood To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 13:27:30 +0100 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 12:27:30.0635 (UTC) FILETIME=[5A0849B0:01C8CAF5] Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On 10 Jun 2008, at 12:49, Pascal Thubert (pthubert) wrote: > Hi Lloyd: > > This is great reading and might prevent mistakes in using UDP CS > compression; > but does not apply here: > > - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) > Message Integrity Check (MIC) instead of UDP checksum. Pascal, End-to-end UDP has the UDP checksum, ISA100.11a transport doesn't. How can this be "end-to-end UDP" when it clearly doesn't want to be UDP? Sitting directly on top of IP at both endhosts and doing the pseudo- header check yourself as a transport layer alternative to UDP, without the overhead of unwanted UDP fields that get faked up, would seem to make more sense here than sort-of-tunnelling in UDP from the endhost and then subverting and reconstituting the UDP fields. RFC4944 is about carrying IPv6 across 802.15.4 networks, and prohibits UDP checksum compression for good reason. Modifying that to allow checksum compression might work for IA100.11a if and only if both endhosts are sitting on the 802.15.4 network communicating via ISA100.11a, and the packet never goes any further - ie you're relying solely on the MIC, and the UDP checksum is never used. If the packet goes further and a reconstituted UDP checksum is required at the endhost for an integrity check - that's the slippery slope where the end-to-end principle has many warnings. Applying TLS across the 6lowpan part of such a path does not mitigate end-to-end concerns here. And, thanks to NAT/relaying etc., it can't be guaranteed that the packet will go no further - a slippery slope. > - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) TLS was intended and is used simply as a shorthand for transport layer security - a term you used in the email I was replying to. I don't accept that RFC4346 now owns the term. This quote to you from Geoff Mulligan on 22 May seems relevant and applicable here: "There is some concern that has been expressed that we are prematurely optimizing the headers. I'm not convinced that the benefits of saving 3 bytes outweighs un-thought-of issues that might come about because of these optimizations." cheers, L. > - And we are designing for devices that might not have hardware assist > other than maybe what's specified by 802.15.4 so that's what we use. > > I hope it's clearer now... > > Pascal DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 07:13:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD303A69C7; Tue, 10 Jun 2008 07:13:40 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127853A6874; Tue, 10 Jun 2008 07:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.36 X-Spam-Level: X-Spam-Status: No, score=-6.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2DeOuJKakOn; Tue, 10 Jun 2008 07:13:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DE2593A68FF; Tue, 10 Jun 2008 07:13:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,617,1204498800"; d="scan'208";a="11290274" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Jun 2008 16:13:51 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5AEDpkX002278; Tue, 10 Jun 2008 16:13:51 +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.13.8/8.13.8) with ESMTP id m5AEDpWP018455; Tue, 10 Jun 2008 14:13:51 GMT Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 16:13:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 10 Jun 2008 16:13:13 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> In-Reply-To: <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjK9WJeVzovBCloQ0GlrVDF7V/s8AABX1pw References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> From: "Pascal Thubert (pthubert)" To: "Lloyd Wood" X-OriginalArrivalTime: 10 Jun 2008 14:13:50.0868 (UTC) FILETIME=[34F29540:01C8CB04] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3153; t=1213107231; x=1213971231; 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[Roll]=20[6lowpan]=20ISA100.11a=20statu s=20and=20requirements(was=09RE=3A=09New=09charter=20for=206 lowpan) |Sender:=20; bh=g2g67pYOf2/6k9zZAUpWPUx9HwyOnKwS/RbhtXmYZ4A=; b=gyItGOMmoPTT32i70dPgiUrL3gMz45Ug9C/QjyjWfSjztX93kKuLqDAIWF Dtge9EEX0xOt3OSf5l2mh3pIyQcJv9OoiOkx3LWftu52VRGm1qg1uQX1NbVW UOrQG6Eeog; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi Lloyd: >> - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) >> Message Integrity Check (MIC) instead of UDP checksum. > >Pascal, > >End-to-end UDP has the UDP checksum, ISA100.11a transport doesn't. How >can this be "end-to-end UDP" when it clearly doesn't want to be UDP? >Sitting directly on top of IP at both endhosts and doing the pseudo- >header check yourself as a transport layer alternative to UDP, without >the overhead of unwanted UDP fields that get faked up, would seem to >make more sense here than sort-of-tunnelling in UDP from the endhost >and then subverting and reconstituting the UDP fields. [Pascal] The only fake is that we still call the ISA100.11a transport UDP though it's not. This is done to reuse the IPv6 next header and the 6LoWPAN HC2 though we know it's improper. The transport is a UDP variant in that the checksum is computed differently, has additional security properties and gets placed somewhere else. But the end to end principle is respected exactly as with original UDP. > >RFC4944 is about carrying IPv6 across 802.15.4 networks, and prohibits >UDP checksum compression for good reason. Modifying that to allow >checksum compression might work for IA100.11a if and only if both >endhosts are sitting on the 802.15.4 network communicating via >ISA100.11a, and the packet never goes any further - ie you're relying >solely on the MIC, and the UDP checksum is never used. If the packet >goes further and a reconstituted UDP checksum is required at the >endhost for an integrity check - that's the slippery slope where the >end-to-end principle has many warnings. Applying TLS across the >6lowpan part of such a path does not mitigate end-to-end concerns >here. And, thanks to NAT/relaying etc., it can't be guaranteed that >the packet will go no further - a slippery slope. > [Pascal] No. The ISA100.11a transport is end to end as usual in the IP model; both ends need to be ISA100.11a nodes so that they know how to terminate the ISA100.11a transport. The IP network in the middle is transparent and could be the Internet, that's the end to end principle. IPv6 and UDP are compressed over the LoWPAN, that's 6LoWPAN. > >> - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) > >TLS was intended and is used simply as a shorthand for transport layer >security - a term you used in the email I was replying to. I don't >accept that RFC4346 now owns the term. > >This quote to you from Geoff Mulligan on 22 May seems relevant and >applicable here: >"There is some concern that has been expressed that we are prematurely >optimizing the headers. I'm not convinced that the benefits of saving >3 bytes outweighs un-thought-of issues that might come about because >of these optimizations." [Pascal] ISA100.11a has spent quite some effort doing its work. For instance, we made sure that the points raised in draft-ietf-tsvwg-udp-guidelines were all addressed. For the particular aspect of how we compute the checksum, we pretend it is as good or better than in the original UDP. Are you challenging that? Pascal _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 07:59:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9769B3A6937; Tue, 10 Jun 2008 07:59:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735E43A6839; Tue, 10 Jun 2008 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VksXJJxHnYe; Tue, 10 Jun 2008 07:59:28 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 2D3253A6811; Tue, 10 Jun 2008 07:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5AExX3e018401; Tue, 10 Jun 2008 16:59:36 +0200 (CEST) From: Carsten Bormann To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> Message-Id: <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 16:59:33 +0200 X-Mailer: Apple Mail (2.924) Cc: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On Jun 10 2008, at 16:13, Pascal Thubert (pthubert) wrote: > we still call the ISA100.11a transport > UDP though it's not OK, so this transport protocol would like to use an 8-byte header with a source port number, a destination port number, and two highly compressible fields (redundant length, and the now redundant checksum), but it has its own *end-to-end* checksum, which is better than 16-bit one's complement and *does* include a pseudo header. Two observations: 1) compression works best when it is done cross-layer. So one would want to compress the whole stack from IP upwards to the ISA100 transport. This of course could include knowledge about the layer above UDP, just as we have included knowledge about RTP in RFC 3095/5225. 2) Given this transport, the end system is likely to want back the feature of UDPv4 that allowed sending a zero checksum. This transport is a nice example for how it was a mistake to conflate policy and mechanism in UDPv6: Encoding the *policy* not to send packets without a checksum that includes a pseudo-header with the *mechanism* to never allow zero checksums in UDPv6. Of course, you should not have mechanism that a policy makes sure you will never use, but the mechanism is already there for IPv4, and the example is exactly one such case where the policy would not imply non- use of the mechanism. Obviously, if an end system does not want protection from UDP (and it shouldn't want it in the ISA100 case), it should say so by setting the checksum to zero. The mechanism/policy conflation mentioned above makes that impossible. Changing UDPv6 at this stage is a big step. If that is not what we (the IETF/the IPv6 implementers community) want to do, there is no way for the end system to make that statement. This does not mean that we shouldn't honor it. Gruesse, Carsten _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 12:36:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62F43A6ACF; Tue, 10 Jun 2008 12:36:59 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1B013A6ACF; Tue, 10 Jun 2008 12:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.652 X-Spam-Level: X-Spam-Status: No, score=-6.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEWbfVUx9xuF; Tue, 10 Jun 2008 12:36:57 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with SMTP id CBF423A6993; Tue, 10 Jun 2008 12:36:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-82.messagelabs.com!1213126638!54011994!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 8508 invoked from network); 10 Jun 2008 19:37:18 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-11.tower-82.messagelabs.com with SMTP; 10 Jun 2008 19:37:18 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 20:37:18 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 20:37:16 +0100 Message-Id: <508253DB-DD52-4202-9102-50BB14DB36BC@surrey.ac.uk> From: Lloyd Wood To: Pascal Thubert (pthubert) In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 20:37:16 +0100 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 19:37:17.0263 (UTC) FILETIME=[640F75F0:01C8CB31] Cc: Geoff Mulligan , roll@ietf.org, "Polyzois, Christos A" , Jay Werb , "Chernoguzov, Alexander \(PA35\)" , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On 10 Jun 2008, at 15:13, Pascal Thubert (pthubert) wrote: > Hi Lloyd: > >>> - ISA100.11a Transport is end-to-end UDP with AES/CCM (RFC 3610) >>> Message Integrity Check (MIC) instead of UDP checksum. >> >> Pascal, >> >> End-to-end UDP has the UDP checksum, ISA100.11a transport doesn't. >> How >> can this be "end-to-end UDP" when it clearly doesn't want to be UDP? >> Sitting directly on top of IP at both endhosts and doing the pseudo- >> header check yourself as a transport layer alternative to UDP, >> without >> the overhead of unwanted UDP fields that get faked up, would seem to >> make more sense here than sort-of-tunnelling in UDP from the endhost >> and then subverting and reconstituting the UDP fields. > > [Pascal] The only fake is that we still call the ISA100.11a transport > UDP though it's not. This is done to reuse It's a pretence, then. (US readers: pretense.) > the IPv6 next header and the > 6LoWPAN HC2 though we know it's improper. right. > The transport is a UDP variant > in that the checksum is computed differently, has additional security > properties and gets placed somewhere else. But the end to end > principle > is respected exactly as with original UDP. But the proposed way to handle the UDP checksum does not respect the e2e UDP checksum, so this really isn't UDP; just a convenient way to stick something else on top, even if that something else has a separate, higher and therefore better, e2e check. >> RFC4944 is about carrying IPv6 across 802.15.4 networks, and >> prohibits >> UDP checksum compression for good reason. Modifying that to allow >> checksum compression might work for IA100.11a if and only if both >> endhosts are sitting on the 802.15.4 network communicating via >> ISA100.11a, and the packet never goes any further - ie you're relying >> solely on the MIC, and the UDP checksum is never used. If the packet >> goes further and a reconstituted UDP checksum is required at the >> endhost for an integrity check - that's the slippery slope where the >> end-to-end principle has many warnings. Applying TLS across the >> 6lowpan part of such a path does not mitigate end-to-end concerns >> here. And, thanks to NAT/relaying etc., it can't be guaranteed that >> the packet will go no further - a slippery slope. > > [Pascal] No. The ISA100.11a transport is end to end as usual in the IP > model; both ends need to be ISA100.11a nodes so that they know how to > terminate the ISA100.11a transport. The IP network in the middle is > transparent and could be the Internet, where the regenerated UDP checksum will be relied on by e.g. NAT boxes, which recompute the checksum again. Ugh. Okay, once NAT's involved the checksums are all messed up and regenerated and not pristine anyway. Not a convincing example. Better example: there's an application sitting on a node on the Internet, pretending to be an ISA100.11a node, and regenerating the UDP checksum so that this application can just use ordinary sockets to talk to a node on a 15.4 net is desirable and inevitable. This will make developing for ISA convenient; it is guaranteed to happen, and has properly happened already. Everything gets virtualized. What happens when the regenerated UDP checksum and the ISA checksum from a packet on the 15.4 net disagree about whether the packet is good? UDP says 'discard, so the app never sees it', but the UDP checksum is no longer really the e2e arbiter here. If ISA sat on IP direct, this would be avoided. > that's the end to end principle. > IPv6 and UDP are compressed over the LoWPAN, that's 6LoWPAN. But the UDP header is no longer being used to provide header and payload protection; it's really just in there for convenience. >>> - ISA100.11a is NOT using TLS or better suited D-TLS (RFC 4346/4347) >> >> TLS was intended and is used simply as a shorthand for transport >> layer >> security - a term you used in the email I was replying to. I don't >> accept that RFC4346 now owns the term. >> >> This quote to you from Geoff Mulligan on 22 May seems relevant and >> applicable here: >> "There is some concern that has been expressed that we are >> prematurely >> optimizing the headers. I'm not convinced that the benefits of saving >> 3 bytes outweighs un-thought-of issues that might come about because >> of these optimizations." > > [Pascal] ISA100.11a has spent quite some effort doing its work. For > instance, we made sure that the points raised in > draft-ietf-tsvwg-udp-guidelines were all addressed. For the particular > aspect of how we compute the checksum, we pretend it is as good or > better than in the original UDP. Are you challenging that? Yes, I'm challenging that pretence, simply because it is a pretence; thanks for the explanations to this point. I can see how ISA is e2e between ISA nodes thanks to internal consistency/pseudoheader checks; what I can't see is why that UDP header is in there having its semantics munged, when it's only used as a layering hack. Separately, the zero-checksum 'changing something well-known just because we're compensating for it by layering something else on top' idea makes me uncomfortable; the pieces will be reused badly. How long before someone says 'zero-checksum UDP is great, because it's faster, so let's do zero-checksum ISA, as that's faster too', and goes on to rediscover that implementations with UDP checksums off introduce problems? There's willingness to alter RFC2460 and RFC4346 to get a zero checksum here; how will the next group to come along alter existing specs as well? Slippery slope. (I think if ISA sat over UDP-Lite, there would be slightly less of a pretence here, as redundant coverage of the payload from a checksum that's not trustworthy would at least be removed. And there's less data for the Lite checksum to be computed across. But really, ISA over IP direct doing its own pseudoheader check without the UDP fields makes a lot more sense to me.) ISA100.11a should be sitting parallel to TCP/UDP/SCTP, not on top of UDP. Still, never mind; it is, of course, late to change the ISA100 design (but, oddly, not too late to change RFCs 2460 and 4346?) . Feel free to ignore me. cheers, L. and I'll feel free to say "told you so" in a decade or so. DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 12:47:52 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD583A690C; Tue, 10 Jun 2008 12:47:52 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 321473A6913; Tue, 10 Jun 2008 12:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.639 X-Spam-Level: X-Spam-Status: No, score=-6.639 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY3Qb5pwtnAN; Tue, 10 Jun 2008 12:47:48 -0700 (PDT) Received: from mail78.messagelabs.com (mail78.messagelabs.com [195.245.230.131]) by core3.amsl.com (Postfix) with SMTP id C33D33A690C; Tue, 10 Jun 2008 12:47:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-14.tower-78.messagelabs.com!1213127289!49202653!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 4247 invoked from network); 10 Jun 2008 19:48:09 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-14.tower-78.messagelabs.com with SMTP; 10 Jun 2008 19:48:09 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 20:48:09 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 20:48:08 +0100 Message-Id: From: Lloyd Wood To: Carsten Bormann In-Reply-To: <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 20:48:08 +0100 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 10 Jun 2008 19:48:08.0703 (UTC) FILETIME=[E85950F0:01C8CB32] Cc: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org On 10 Jun 2008, at 15:59, Carsten Bormann wrote: > > 2) Given this transport, the end system is likely to want back the > feature of UDPv4 that allowed sending a zero checksum. This transport > is a nice example for how it was a mistake to conflate policy and > mechanism in UDPv6: Encoding the *policy* not to send packets without > a checksum that includes a pseudo-header with the *mechanism* to never > allow zero checksums in UDPv6. Yes, it would have been nicer if the mandatory pseudoheader was part of the IPv6 header, rather than having to be reimplemented by every transport protocol using IPv6, including ICMP. The pseudoheader check is necessary. The payload check is not. That's what UDP-Lite gives. > Of course, you should not have mechanism that a policy makes sure you > will never use, but the mechanism is already there for IPv4, and the > example is exactly one such case where the policy would not imply non- > use of the mechanism. > > Obviously, if an end system does not want protection from UDP (and it > shouldn't want it in the ISA100 case), it should say so by setting the > checksum to zero. No. It should either: a. Use UDP-Lite, to avoid checksum coverage of its payload, and still get a pseudoheader check from UDP. b. Implement its own transport protocol, in parallel with UDP/TCP/ SCTP, with its own pseudoheader check, doing payload coverage however it likes. The endhost pseudoheader check has to come from somewhere. > The mechanism/policy conflation mentioned above > makes that impossible. Not impossible. It comes down to the pain of using UDP-Lite, or the pain of writing your own proper gets-a-protocol-number transport protocol with its own pseudoheader check. Either is better from layering/size/complexity viewpoints than layering over UDP and turning UDP checksums off. > Changing UDPv6 at this stage is a big step. If that is not what we > (the IETF/the IPv6 implementers community) want to do, there is no way > for the end system to make that statement. This does not mean that we > shouldn't honor it. Sorry, I'm unclear on the meaning of your last sentence here; the double negative (triple from the previous sentence) doesn't help. tschuess, L. DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 14:51:08 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEB0A3A6928; Tue, 10 Jun 2008 14:51:08 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26CA3A6928; Tue, 10 Jun 2008 14:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPyXVMVOI87E; Tue, 10 Jun 2008 14:51:06 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 1A2843A67FE; Tue, 10 Jun 2008 14:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id m5ALotfY004195; Tue, 10 Jun 2008 23:50:58 +0200 (CEST) Message-Id: From: Carsten Bormann To: Lloyd Wood In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 23:50:55 +0200 References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> X-Mailer: Apple Mail (2.924) Cc: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > a. Use UDP-Lite, to avoid checksum coverage of its payload, and > still get a pseudoheader check from UDP. How does that help with getting rid of the checksum? With UDP-lite, you now have two, with different coverage. > b. Implement its own transport protocol, in parallel with UDP/TCP/ > SCTP, with its own pseudoheader check, doing payload coverage > however it likes. That's what they did. They want to do this on top of UDP, which is a usual way to build new transport protocols these days (cf. RTP). If UDPv6 were like UDPv4, this would be a better fit. >> The mechanism/policy conflation mentioned above >> makes that impossible. > > Not impossible. It comes down to the pain of using UDP-Lite, or the > pain of writing your own proper gets-a-protocol-number transport > protocol with its own pseudoheader check. Either is better from > layering/size/complexity viewpoints than layering over UDP and > turning UDP checksums off. I don't agree with "better" here. Being able to use UDP reduces complexity here; certainly from an implementation point of view (if you consider that there will be hosts with common operating systems on e.g. Ethernets that want to talk to lowpans). >> Changing UDPv6 at this stage is a big step. If that is not what we >> (the IETF/the IPv6 implementers community) want to do, there is no >> way >> for the end system to make that statement. This does not mean that >> we >> shouldn't honor it. > > Sorry, I'm unclear on the meaning of your last sentence here; the > double negative (triple from the previous sentence) doesn't help. I'm just saying that, in the first-hop/last-hop case, HC could help 2460 a little here, just (as you noted) NATs tend to "help" with maintaining that checksum, by proxying out the UDP checksum generation/ check to the next hop, as long as there is something else that provides e2e protection. In the first-hop case, it is easy for the host to make the statement (by providing a mechanism for eliding the checksum); in the last-hop case, there would need to be some agreement (implied or signaled). Gruesse, Carsten _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Tue Jun 10 15:00:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38F8E28C129; Tue, 10 Jun 2008 15:00:50 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBD6328C0F4; Tue, 10 Jun 2008 15:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.631 X-Spam-Level: X-Spam-Status: No, score=-6.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH3renz9yDoV; Tue, 10 Jun 2008 15:00:47 -0700 (PDT) Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with SMTP id 27A2F28C0E9; Tue, 10 Jun 2008 15:00:47 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-72.messagelabs.com!1213135267!21733814!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 19762 invoked from network); 10 Jun 2008 22:01:07 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-11.tower-72.messagelabs.com with SMTP; 10 Jun 2008 22:01:07 -0000 Received: from ads30.surrey.ac.uk ([131.227.120.130]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 23:01:07 +0100 Received: from [192.168.1.208] ([82.44.158.76]) by ads30.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Jun 2008 23:01:07 +0100 Message-Id: From: Lloyd Wood To: Carsten Bormann In-Reply-To: Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 10 Jun 2008 23:01:06 +0100 X-OriginalArrivalTime: 10 Jun 2008 22:01:07.0835 (UTC) FILETIME=[7C483CB0:01C8CB45] Cc: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org References: <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-337.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-962968881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337.emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <1211496860.23290.41.camel@dellx1> <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> <484D5B93.2080802@cisco.com> <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> X-Mailer: Apple Mail (2.924) Return-Path: L.Wood@surrey.ac.uk X-OriginalArrivalTime: 10 Jun 2008 22:01:07.0358 (UTC) FILETIME=[7BFF73E0:01C8CB45] inline... On 10 Jun 2008, at 22:50, Carsten Bormann wrote: >> a. Use UDP-Lite, to avoid checksum coverage of its payload, and >> still get a pseudoheader check from UDP. > > How does that help with getting rid of the checksum? > With UDP-lite, you now have two, with different coverage. > >> b. Implement its own transport protocol, in parallel with UDP/TCP/ >> SCTP, with its own pseudoheader check, doing payload coverage >> however it likes. > > That's what they did. No, ISA sits _over_ UDP, not over IP as UDP/TCP/SCTP do. > They want to do this on top of UDP, which is a usual way to build > new transport protocols these days (cf. RTP). No, it's a way to really build more 'session-like' protocols. I wouldn't call RTP a full transport, as it doesn't care about describing length, or about reliability. > If UDPv6 were like UDPv4, this would be a better fit. > >>> The mechanism/policy conflation mentioned above >>> makes that impossible. >> >> Not impossible. It comes down to the pain of using UDP-Lite, or the >> pain of writing your own proper gets-a-protocol-number transport >> protocol with its own pseudoheader check. Either is better from >> layering/size/complexity viewpoints than layering over UDP and >> turning UDP checksums off. > > I don't agree with "better" here. > Being able to use UDP reduces complexity here; certainly from an > implementation point of view (if you consider that there will be > hosts with common operating systems on e.g. Ethernets that want to > talk to lowpans). ...which makes removing the UDP checksum more problematic. >>> Changing UDPv6 at this stage is a big step. If that is not what we >>> (the IETF/the IPv6 implementers community) want to do, there is no >>> way >>> for the end system to make that statement. This does not mean >>> that we >>> shouldn't honor it. >> >> Sorry, I'm unclear on the meaning of your last sentence here; the >> double negative (triple from the previous sentence) doesn't help. > > I'm just saying that, in the first-hop/last-hop case, HC could help > 2460 a little here, just (as you noted) NATs tend to "help" with > maintaining that checksum, They don't "help". Quite the opposite - by recomputing the checksum the value of the end-to-end guarantee offered by the checksum is reduced. HC may save bits on the wire, but it doesn't help overall reliability. HC can't make anything as reliable, or more reliable. > by proxying out the UDP checksum generation/check to the next hop, > as long as there is something else that provides e2e protection. Why fake up a checksum at a proxy unless something is going to use it? And if something does, there are e2e implications. (I doubt that we will ever agree here.) > In the first-hop case, it is easy for the host to make the > statement (by providing a mechanism for eliding the checksum); in > the last-hop case, there would need to be some agreement (implied or > signaled). > > Gruesse, Carsten > DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Jun 11 01:12:56 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6C3F28C0E9; Wed, 11 Jun 2008 01:12:56 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB383A69E5; Wed, 11 Jun 2008 01:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.356 X-Spam-Level: X-Spam-Status: No, score=-4.356 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8OTW9usrh2g; Wed, 11 Jun 2008 01:12:50 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 33A7B3A69B4; Wed, 11 Jun 2008 01:12:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,623,1204520400"; d="scan'208";a="10700520" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jun 2008 04:13:14 -0400 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 m5B8DEFJ021834; Wed, 11 Jun 2008 04:13:14 -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.13.8/8.13.8) with ESMTP id m5B8DErM010078; Wed, 11 Jun 2008 08:13:14 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 04:13:13 -0400 Received: from 144.254.188.136 ([144.254.188.136]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jun 2008 08:13:13 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 11 Jun 2008 10:13:10 +0200 From: JP Vasseur To: Lloyd Wood , Carsten Bormann Message-ID: Thread-Topic: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) Thread-Index: AcjLmvxl9hLwOgAkyk+5spkQmgCMVg== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 11 Jun 2008 08:13:13.0916 (UTC) FILETIME=[FEBB77C0:01C8CB9A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4840; t=1213171994; x=1214035994; 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[Roll]=20[6lowpan]=20ISA100.11a=20statu s=20and=20requirements(was=20RE=3A=20New=0A=20charter=20for= 206lowpan) |Sender:=20 |To:=20Lloyd=20Wood=20,=20Carsten=20Bo rmann=20; bh=spdz10fLz9s/I3LuTIB+U8oAgOrAg98QhAbGZwoV/1w=; b=yuq3+LqggEBTPSL/kPUsQPRyHsA4MaqaIYnWOO6nA8m+j4JxKvUaSNo4Dr zuLD7rsLiBJx4Gp5lSF06KV5Wg+Slau4v/T5bU+0reTK8w4TGJA3//I8+XIN E9NXc9NCAC; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I think that the ROLL ML can be removed from this thread. Thanks. JP. On 6/11/08 12:01 AM, "Lloyd Wood" wrote: > References: > <482CA4DC.40508@cisco.com> <7892795E1A87F04CADFCCF41FADD00FC05AFD65A@xmb-ams-3 > 37.emea.cisco.com> <482DD69F.7080304@cisco.com> <208D4602-AE7F-457E-9377-96296 > 8881CDE@archrock.com> <4832ED46.1070304@cisco.com> <86848218-AF7E-4E9C-9A6C-5B > 125868E048@archrock.com> <7892795E1A87F04CADFCCF41FADD00FC05B61014@xmb-ams-337 > .emea.cisco.com> <528EF8DF-1E03-4646-8C9B-FEFBC05DF616@archrock.com> <12114968 > 60.23290.41.camel@dellx1> > <484D4B7D.507@cisco.com><1213028853.5997.20.camel@dellx1> > <484D5B93.2080802@cisco.com> > <3CD8DE83-2D2E-4B0F-B87B-737B64EE1D2A@surrey.ac.uk> > <7892795E1A87F04CADFCCF41FADD00FC05CC4D05@xmb-ams-337.emea.cisco.com> > > <7892795E1A87F04CADFCCF41FADD00FC05CC4EED@xmb-ams-337.emea.cisco.com> > <61D4CAAA-C788-499D-BB6B-B33C04D48BFD@surrey.ac.uk> > <7892795E1A87F04CADFCCF41FADD00FC05CC5002@xmb-ams-337.emea.cisco.com> > <6C4EBF19-A0FA-4063-8C66-BB877E939F54@tzi.org> > 7069-490C-AFA5-340840E9E82A@tzi.org> > X-Mailer: Apple Mail (2.924) > Return-Path: L.Wood@surrey.ac.uk > X-OriginalArrivalTime: 10 Jun 2008 22:01:07.0358 (UTC) > FILETIME=[7BFF73E0:01C8CB45] > > inline... > > On 10 Jun 2008, at 22:50, Carsten Bormann wrote: > >>> a. Use UDP-Lite, to avoid checksum coverage of its payload, and >>> still get a pseudoheader check from UDP. >> >> How does that help with getting rid of the checksum? >> With UDP-lite, you now have two, with different coverage. >> >>> b. Implement its own transport protocol, in parallel with UDP/TCP/ >>> SCTP, with its own pseudoheader check, doing payload coverage >>> however it likes. >> >> That's what they did. > > No, ISA sits _over_ UDP, not over IP as UDP/TCP/SCTP do. > >> They want to do this on top of UDP, which is a usual way to build >> new transport protocols these days (cf. RTP). > > No, it's a way to really build more 'session-like' protocols. I > wouldn't call RTP a full transport, as it doesn't care about > describing length, or about reliability. > >> If UDPv6 were like UDPv4, this would be a better fit. >> >>>> The mechanism/policy conflation mentioned above >>>> makes that impossible. >>> >>> Not impossible. It comes down to the pain of using UDP-Lite, or the >>> pain of writing your own proper gets-a-protocol-number transport >>> protocol with its own pseudoheader check. Either is better from >>> layering/size/complexity viewpoints than layering over UDP and >>> turning UDP checksums off. >> >> I don't agree with "better" here. >> Being able to use UDP reduces complexity here; certainly from an >> implementation point of view (if you consider that there will be >> hosts with common operating systems on e.g. Ethernets that want to >> talk to lowpans). > > ...which makes removing the UDP checksum more problematic. > > >>>> Changing UDPv6 at this stage is a big step. If that is not what we >>>> (the IETF/the IPv6 implementers community) want to do, there is no >>>> way >>>> for the end system to make that statement. This does not mean >>>> that we >>>> shouldn't honor it. >>> >>> Sorry, I'm unclear on the meaning of your last sentence here; the >>> double negative (triple from the previous sentence) doesn't help. >> >> I'm just saying that, in the first-hop/last-hop case, HC could help >> 2460 a little here, just (as you noted) NATs tend to "help" with >> maintaining that checksum, > > They don't "help". Quite the opposite - by recomputing the checksum > the value of the end-to-end guarantee offered by the checksum is > reduced. HC may save bits on the wire, but it doesn't help overall > reliability. HC can't make anything as reliable, or more reliable. > > >> by proxying out the UDP checksum generation/check to the next hop, >> as long as there is something else that provides e2e protection. > > Why fake up a checksum at a proxy unless something is going to use it? > And if something does, there are e2e implications. > > (I doubt that we will ever agree here.) > >> In the first-hop case, it is easy for the host to make the >> statement (by providing a mechanism for eliding the checksum); in >> the last-hop case, there would need to be some agreement (implied or >> signaled). >> >> Gruesse, Carsten >> > > DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Wed Jun 11 01:46:06 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFBC93A68F4; Wed, 11 Jun 2008 01:46:05 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F83B3A68FF for ; Wed, 11 Jun 2008 01:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYZi5LoK4L9T for ; Wed, 11 Jun 2008 01:46:01 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id CA8F53A68F4 for ; Wed, 11 Jun 2008 01:46:00 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2113255fga.41 for ; Wed, 11 Jun 2008 01:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=cZ7/Zd8T0el5sdJBYwQJyHchRZ+Z5erMthPOPlTxMlE=; b=ZFy+v/f8szkP/UnqPrlbkPuKyQfZ8TuDGay6Y9QUnEiitqfqCg0MJ1PYn1I1ygtwBr lJfvoI4dhWSulJD3Q53MyqSOtb3SLAoHdXcfbclFzDlczz29w/4yvBNYGVdvikjn6H99 hGjnYrLQyH3CkED6gH2cYpVf5TwiZzx2hZJZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=XHceCfflK6MRSJGhwpZ5RxDlDK4KHgvypJmv8rGyDohTOhIbXz9+/mmkfUeylZ/fYz KG6WghzlLRD62unWYqoivBjmPHuoPzBR+QdLDjWvewShnXjlS/Jg3Ofco7X7h1VpJZ1b MGbehXPOWsRFxxeFGplGtizBMxCU+ua5jdFbY= Received: by 10.86.33.19 with SMTP id g19mr4276162fgg.4.1213173984383; Wed, 11 Jun 2008 01:46:24 -0700 (PDT) Received: by 10.86.58.6 with HTTP; Wed, 11 Jun 2008 01:46:24 -0700 (PDT) Message-ID: <86c3ed7b0806110146t55234092x24226010ccdfe717@mail.gmail.com> Date: Wed, 11 Jun 2008 10:46:24 +0200 From: "Miguel Sanchez" To: "JP Vasseur" In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 980f9db1541f87a9 Cc: 6lowpan <6lowpan@ietf.org>, roll@ietf.org Subject: Re: [Roll] [6lowpan] ISA100.11a status and requirements(was RE: New charter for 6lowpan) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1516049891==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============1516049891== Content-Type: multipart/alternative; boundary="----=_Part_31995_14875486.1213173984368" ------=_Part_31995_14875486.1213173984368 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Please do so. Miguel S=E1nchez On Wed, Jun 11, 2008 at 10:13 AM, JP Vasseur wrote: > I think that the ROLL ML can be removed from this thread. > > Thanks. > > JP. > > > ------=_Part_31995_14875486.1213173984368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Please do so.

Miguel S=E1nchez

On = Wed, Jun 11, 2008 at 10:13 AM, JP Vasseur <jvasseur@cisco.com> wrote:
I think that the ROLL ML can be removed from this thread.

Thanks.

JP.



------=_Part_31995_14875486.1213173984368-- --===============1516049891== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1516049891==-- From roll-bounces@ietf.org Wed Jun 11 01:46:12 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1E63A6A15; Wed, 11 Jun 2008 01:46:12 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1263F3A6886; Wed, 11 Jun 2008 01:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHxmyMOgHsFs; Wed, 11 Jun 2008 01:46:09 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E644D3A6971; Wed, 11 Jun 2008 01:46:06 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,623,1204498800"; d="scan'208";a="11361262" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 11 Jun 2008 10:46:30 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5B8kUrH006357; Wed, 11 Jun 2008 10:46:30 +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.13.8/8.13.8) with ESMTP id m5B8kUbx027402; Wed, 11 Jun 2008 08:46:30 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 10:46:30 +0200 Received: from Townsley-MacBook.local ([64.103.30.122]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 10:46:30 +0200 Message-ID: <484F90E4.9050200@cisco.com> Date: Wed, 11 Jun 2008 10:46:28 +0200 From: Mark Townsley User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: roll@ietf.org, 6lowpan <6lowpan@ietf.org> References: In-Reply-To: X-OriginalArrivalTime: 11 Jun 2008 08:46:30.0248 (UTC) FILETIME=[A4A38E80:01C8CB9F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1236; t=1213173990; x=1214037990; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20HC1G=20a=20requirement=20for=20roll?=20 |Sender:=20; bh=os+CTMQxRgbRhoTvkHH1oIyevjdJzkNLWlPmvT944R8=; b=pqTEAnnJS1tNrK423g3SK6E6hH044R/AYHK3+lZ63xV6zpua5+J5Ok06M0 Arc0mokAF9WOprUiZPuFjpgccVI6P3hHQMqIwgHT8c4RqVIIXoZVzEaTiDDW KwhUAdC/Cz; Authentication-Results: ams-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: [Roll] HC1G a requirement for roll? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org I posed this question earlier, but it seems to have been lost in the thread discussing UDP checksums. I'd like to know if this really is important, or if there is some obvious answer that I am missing... (HC1G as explained to me is the ability to compress the address field for a non-link-local IPv6 address when transmitting - something that has not been defined by 6lowpan yet and we are making chartering decisions on). Mark Townsley wrote: > It would seem to me that HC1G would be very important to understanding > how ROLL is going to work. If you are routing between subnets at L3, > then by definition you cannot be using link-local addressing on them. > So, either ROLL is stuck with 128-bit addresses in data packets, or we > figure out how to compress global addresses. Or, am I missing something > obvious? If we have accepted that routing lowpan subnets means using a non-link-local address, which means using a globally unique address, which finally means a 128 bit address field in all lowpan data packets, then we of course do not need to define how to compress global addresses. But, I'd like to know if that decision has been made, or if there is some other solution. Thanks, - Mark _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Jun 12 01:15:51 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261C93A6996; Thu, 12 Jun 2008 01:15:51 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0149E3A6996 for ; Thu, 12 Jun 2008 01:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpqB7AXGFff2 for ; Thu, 12 Jun 2008 01:15:49 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C8A163A6843 for ; Thu, 12 Jun 2008 01:15:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,630,1204520400"; d="scan'208";a="10815455" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 12 Jun 2008 04:16:16 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5C8GGsY025080; Thu, 12 Jun 2008 04:16:16 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5C8GFHl002258; Thu, 12 Jun 2008 08:16:15 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jun 2008 04:16:15 -0400 Received: from 10.21.113.47 ([10.21.113.47]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Jun 2008 08:16:15 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 12 Jun 2008 10:16:14 +0200 From: JP Vasseur To: Nie Pin , Message-ID: Thread-Topic: My comments on Vol 5, Issue 2 and Vol 5, Issue 3 Thread-Index: AcjMZJR7XRYch0rhf0m3IJwLU1K9iQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 12 Jun 2008 08:16:15.0945 (UTC) FILETIME=[95A4A390:01C8CC64] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2962; t=1213258576; x=1214122576; 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=20My=20comments=20on=20Vol=205,=20Issue=2 02=20and=20Vol=205,=20Issue=203 |Sender:=20 |To:=20Nie=20Pin=20,=20; bh=2hz8xESvRoXrd7GKMwjNkAKT8jApcDDrzjFYyqsXWGc=; b=fcHA96UbLbJWKWcBovqjHgCLPgROmrb1M7ohoVzBA1JhCVKfnHq9R3IFfw 2yZ7rtv2vusNhaDzW8Iuesz4YdYpJgWnby8549nfp3UabeSwFaDKJuoEm3Dl vdx4saxMJg; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Roll] My comments on Vol 5, Issue 2 and Vol 5, Issue 3 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, On 6/11/08 11:17 PM, "Nie Pin" wrote: > Hi, dear all, > I'm a rookie in this mailing list, so forgive me if I make any stupid > questions. > > Based on some recent messages, I have following comments: > In Roll Digest, Vol 5, Issue 2 (JP Vasseur) >> 19) " home PAN MUST provide a set of features including 0 configuration of >> the routing protocol for a new node to be added to the network. " >> Do you really mean "0 configuration" ?? What about optional > configuration of >> timers ? > I think the "0 configuration" here implies "plug and play (PnP)" > capability. This is very important in some emergency applications, like > construction health monitoring in the aftershock. Well, the term "0 configuration" requires clarification though. > >> 20) " Furthermore, a failing node MUST NOT have a global impact on the >> routing protocol. " >> This is a very strong requirement ... Are you sure that this is what you >> mean? I feel more comfortable about your second > This requirement may be very strong, but it is necessary I think. Take > tree based routing algorithm as example, it is required any falling node > should not propagate impact on other nodes, except for its subtree nodes. That depends ... You can have tree-based topology where there is a propagation of some limited/aggregated reachability information. Again it is a question of clarification that is needed here for the term "impact". > > In Roll Digest, Vol 5, Issue 3 (Ryuji Wakikawa) >>> ? 2.3. In-Vehicle Network Size: I don?t think very specific >>> vehicle size needs to be presented here since all are aware of rough >>> sizes of various vehicles and routing protocol is not that much >>> sensitive to the exact network size. And, I am not quite sure that >>> this kind of document is fine to mention or refer the specific >>> product name or model like LEXUS and Toyota. > >> OK. >> We try to explain the node density is extremely high compared to other >> scenarios. >> We can remove the example spec. no intention to promote toyota >> vehicles in IETF;-) > > I do believe it is important to clarify the target vehicles and > applications. Long vehicle (up to 20-30 meters), like container truck > and oil carrier, has significant difference from normal vehicles. They > may even have extra requirements, such as cargo (maybe toxic liquids or > weapon) protection in emergency. For a traveling bus with 50 seats, it > also imposes different concerns. Plus, IMO, it is more likely the sensor > network will be firstly deployed for these cases. > Btw, I ever saw a long truck cannot make a U turn in a 6 lane wide road :)) Well, bear in mind that this document is related to "Home" and vehicule application are for the time being out of the scope of the charter. Thanks. JP. > > > > NiePin > > TML@HUT, Helsinki, Finland. > ANTD@NIST, Gaithersburg, MD, USA. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Jun 12 01:32:20 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38843A68CC; Thu, 12 Jun 2008 01:32:20 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FF333A690D for ; Wed, 11 Jun 2008 14:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y-AL3elOIrx for ; Wed, 11 Jun 2008 14:22:05 -0700 (PDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by core3.amsl.com (Postfix) with ESMTP id 178AA3A68B8 for ; Wed, 11 Jun 2008 14:22:04 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id m5BLMP0N012419; Thu, 12 Jun 2008 00:22:25 +0300 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 24526-110-89; Thu, 12 Jun 2008 00:22:25 +0300 (EEST) Received: from smtp01.hut.fi (smtp01.hut.fi [130.233.228.170]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id m5BLITba010423; Thu, 12 Jun 2008 00:18:29 +0300 Received: from pmxchannel-daemon.smtp01.hut-mail by smtp01.hut-mail (iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)) id <0K2B00145HUUJL@smtp01.hut-mail>; Thu, 12 Jun 2008 00:18:30 +0300 (EEST) Received: from cc.hut.fi (taku [10.10.15.2]) by smtp01.hut-mail (iPlanet Messaging Server 5.2 HotFix 2.09 (built Nov 18 2005)) with ESMTP id <0K2B0090ZHTLDV@smtp01.hut-mail>; Thu, 12 Jun 2008 00:17:45 +0300 (EEST) Received: from [10.10.11.2] (Forwarded-For: [129.6.140.99]) by mailstore2.hut-mail (mshttpd); Wed, 11 Jun 2008 17:17:44 -0400 Date: Wed, 11 Jun 2008 17:17:44 -0400 From: Nie Pin To: roll@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.09 (built Nov 18 2005) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-Mailman-Approved-At: Thu, 12 Jun 2008 01:32:19 -0700 Subject: [Roll] My comments on Vol 5, Issue 2 and Vol 5, Issue 3 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi, dear all, I'm a rookie in this mailing list, so forgive me if I make any stupid questions. Based on some recent messages, I have following comments: In Roll Digest, Vol 5, Issue 2 (JP Vasseur) >19) " home PAN MUST provide a set of features including 0 configuration of >the routing protocol for a new node to be added to the network. " >Do you really mean "0 configuration" ?? What about optional configuration of >timers ? I think the "0 configuration" here implies "plug and play (PnP)" capability. This is very important in some emergency applications, like construction health monitoring in the aftershock. >20) " Furthermore, a failing node MUST NOT have a global impact on the >routing protocol. " >This is a very strong requirement ... Are you sure that this is what you >mean? I feel more comfortable about your second This requirement may be very strong, but it is necessary I think. Take tree based routing algorithm as example, it is required any falling node should not propagate impact on other nodes, except for its subtree nodes. In Roll Digest, Vol 5, Issue 3 (Ryuji Wakikawa) >> ? 2.3. In-Vehicle Network Size: I don?t think very specific >> vehicle size needs to be presented here since all are aware of rough >> sizes of various vehicles and routing protocol is not that much >> sensitive to the exact network size. And, I am not quite sure that >> this kind of document is fine to mention or refer the specific >> product name or model like LEXUS and Toyota. >OK. >We try to explain the node density is extremely high compared to other >scenarios. >We can remove the example spec. no intention to promote toyota >vehicles in IETF;-) I do believe it is important to clarify the target vehicles and applications. Long vehicle (up to 20-30 meters), like container truck and oil carrier, has significant difference from normal vehicles. They may even have extra requirements, such as cargo (maybe toxic liquids or weapon) protection in emergency. For a traveling bus with 50 seats, it also imposes different concerns. Plus, IMO, it is more likely the sensor network will be firstly deployed for these cases. Btw, I ever saw a long truck cannot make a U turn in a 6 lane wide road :)) NiePin TML@HUT, Helsinki, Finland. ANTD@NIST, Gaithersburg, MD, USA. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Jun 13 10:16:31 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B64C3A6991; Fri, 13 Jun 2008 10:16:31 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D08A3A6945 for ; Fri, 13 Jun 2008 10:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.372 X-Spam-Level: X-Spam-Status: No, score=-5.372 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqwQE0aa9OEO for ; Fri, 13 Jun 2008 10:16:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2AC383A693A for ; Fri, 13 Jun 2008 10:16:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204520400"; d="scan'208,217";a="10956162" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2008 13:17:00 -0400 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 m5DHH1gO028014 for ; Fri, 13 Jun 2008 13:17:01 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5DHH0GC005049 for ; Fri, 13 Jun 2008 17:17:00 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 13:17:00 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 17:17:00 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 19:16:58 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: *Preliminary* Agenda for ROLL WG - Dublin Thread-Index: AcjNeUkHIgHOyLweL0S81KoOz0Zzcw== Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 17:17:00.0875 (UTC) FILETIME=[4ABDD1B0:01C8CD79] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2801; t=1213377421; x=1214241421; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20*Preliminary*=20Agenda=20for=20ROLL=20WG=20-=20 Dublin |Sender:=20 |To:=20; bh=fT5Zx7q37zUwGQVMAxaveCVUugF+z1hSGKfa1d8JfVw=; b=RhRdUBnvyhc1RtXayR6+QMqE2Lbs02BXQGIRqke2enr4z9RQvd2RhINu6v jIQdQ47FRCLVUbYEKdg26BGACpdWNYTYGu8NckA52WhGVhc9WWK5EFLxh8wK x+sGpu54dA; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Roll] *Preliminary* Agenda for ROLL WG - Dublin X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1202612885==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1202612885== Content-type: multipart/alternative; boundary="B_3296229419_9787758" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3296229419_9787758 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit MONDAY, July 28, 2008 0800-1800 IETF Registration - Convention Lobby 0800-0900 Beverages - Convention Lobby 1130-1300 Break 1300-1500 Afternoon Session I Convention 1 INT l3vpn Layer 3 Virtual Private Networks WG Ballroom 2 INT csi Cga & Send maIntenance WG Conservatory IRTF hiprg Host Identity Protocol Newcastle OPS dime Diameter Maintenance and Extensions WG Convention 3 RAI speermint Session PEERing for Multimedia INTerconnect WG Newcastle RTG roll Routing Over Low power and Lossy networks WG Ballroom 1 SEC dkim Domain Keys Identified Mail WG Conservatory SEC krb-wg Kerberos WG Rathcoole TSV dccp Datagram Congestion Control Protocol WG --B_3296229419_9787758 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable *Preliminary* Agenda for ROLL WG - Dublin MONDAY, July 28, 2008
0800-1800 IETF Registration - Convention Lobby
0800-0900 Beverages - Convention Lobby

1130-1300 Break
1300-1500 Afternoon Session I
Convention 1    INT    l3v= pn    Layer 3 Virtual Private Networks WG
Ballroom 2    INT    csi  = ;  Cga & Send maIntenance WG
Conservatory    IRTF    hiprg    Host Identit= y Protocol
Newcastle    OPS    dime  = ;  Diameter Maintenance and Extensions WG
Convention 3    RAI    speermi= nt    Session PEERing for Multimedia INTerconnect WG Newcastle    RTG    = roll    Routing Over Low power and Lossy networks WG=
Ballroom 1    SEC    dkim =    Domain Keys Identified Mail WG
Conservatory    SEC    krb-wg =    Kerberos WG
Rathcoole    TSV    dccp  = ;  Datagram Congestion Control Prot= ocol WG --B_3296229419_9787758-- --===============1202612885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============1202612885==-- From roll-bounces@ietf.org Fri Jun 13 10:21:57 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC3A3A6774; Fri, 13 Jun 2008 10:21:57 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214B13A6765 for ; Fri, 13 Jun 2008 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.339 X-Spam-Level: X-Spam-Status: No, score=-5.339 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOJvph7gU39l for ; Fri, 13 Jun 2008 10:21:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 474EE3A68AD for ; Fri, 13 Jun 2008 10:21:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204520400"; d="scan'208,217";a="10965920" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2008 13:22:22 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5DHMLT2030784 for ; Fri, 13 Jun 2008 13:22:21 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5DHMLkA014170 for ; Fri, 13 Jun 2008 17:22:21 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 13:22:21 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 17:22:21 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 19:22:19 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: [Roll] *Preliminary* Agenda for ROLL WG - Dublin Thread-Index: AcjNeUkHIgHOyLweL0S81KoOz0ZzcwAAL9XD In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 17:22:21.0464 (UTC) FILETIME=[09D3D180:01C8CD7A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4540; t=1213377741; x=1214241741; 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:=20FW=3A=20[Roll]=20*Preliminary*=20Agenda=20for=2 0ROLL=20WG=20-=20Dublin |Sender:=20 |To:=20; bh=88r3A9cK0c88yvt72jinlpH0TDlOlq57QnkbMvRjFgY=; b=vApxg+Eh1W7vMccGM2m1xRKgp+NUbmHvyZogxsn98Rl2L4OXDht3bfMdke sABT7797f9Yq2yuYtCzNJJFJ+LEtLrhAKGNJ6Z7MkCoT5ddHTAZb4gYF2AYs rNz5pXb2hr; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: [Roll] FW: *Preliminary* Agenda for ROLL WG - Dublin X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2106013429==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============2106013429== Content-type: multipart/alternative; boundary="B_3296229739_9797515" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3296229739_9797515 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Title should read =B3Preliminary schedule=B2 Speaking of the agenda, let us know if you plan to request a slot. Thanks. JP. ------ Forwarded Message From: JP Vasseur Date: Fri, 13 Jun 2008 19:16:58 +0200 To: Subject: [Roll] *Preliminary* Agenda for ROLL WG - Dublin MONDAY, July 28, 2008 0800-1800 IETF Registration - Convention Lobby 0800-0900 Beverages - Convention Lobby 1130-1300 Break 1300-1500 Afternoon Session I Convention 1 INT l3vpn Layer 3 Virtual Private Networks WG Ballroom 2 INT csi Cga & Send maIntenance WG Conservatory IRTF hiprg Host Identity Protocol Newcastle OPS dime Diameter Maintenance and Extensions WG Convention 3 RAI speermint Session PEERing for Multimedia INTerconnect WG Newcastle RTG roll Routing Over Low power and Lossy networks WG Ballroom 1 SEC dkim Domain Keys Identified Mail WG Conservatory SEC krb-wg Kerberos WG Rathcoole TSV dccp Datagram Congestion Control Protocol WG _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------ End of Forwarded Message --B_3296229739_9797515 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable FW: [Roll] *Preliminary* Agenda for ROLL WG - Dublin Title should read “Preliminary schedule”

Speaking of the agenda, let us know if you plan to request a slot.

Thanks.

JP.

------ Forwarded Message
From: JP Vasseur <jvasseur@cisco.com= >
Date: Fri, 13 Jun 2008 19:16:58 +0200
To: <roll@ietf.org>
Subject: [Roll] *Preliminary* Agenda for ROLL WG - Dublin

MONDAY, July 28, 2008
0800-1800 IETF Registration - Convention Lobby
0800-0900 Beverages - Convention Lobby

1130-1300 Break
1300-1500 Afternoon Session I
Convention 1    INT    l3vpn    Layer 3 Virtual Private Networks WG
Ballroom 2    INT    csi    Cga & Send maIntenance WG
Conservatory    IRTF    hiprg   &nb= sp;Host Identity Protocol
Newcastle    OPS    = dime    Diameter Maintenance and Extensions WG
Convention 3    RAI    = speermint    Session PEERing for Multimedia INTercon= nect WG
Newcastle    RTG    = roll    Routing Over Low power and Lossy networks WG=
Ballroom 1    SEC    dkim    Domain Keys Identified Mail WG
Conservatory    SEC    = krb-wg    Kerberos WG
Rathcoole    TSV    = dccp    Datagram Congestion Co= ntrol Protocol WG
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll

------ End of Forwarded Message
 --B_3296229739_9797515-- --===============2106013429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============2106013429==-- From roll-bounces@ietf.org Fri Jun 13 10:36:16 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224D83A69F7; Fri, 13 Jun 2008 10:36:16 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4796F3A68CE; Fri, 13 Jun 2008 10:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.318 X-Spam-Level: X-Spam-Status: No, score=-6.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOgmRvCByYb2; Fri, 13 Jun 2008 10:36:14 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1CF8F3A63D3; Fri, 13 Jun 2008 10:36:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204520400"; d="scan'208";a="10967431" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jun 2008 13:36:46 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5DHajYl002249; Fri, 13 Jun 2008 13:36:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5DHajeH019716; Fri, 13 Jun 2008 17:36:45 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 13:36:45 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 17:36:45 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 19:36:44 +0200 From: JP Vasseur To: JP Vasseur , Geoff Mulligan , 6lowpan <6lowpan@ietf.org>, Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjNbsoM3pueslg16k+6HMsPQSTpQQADUHlm In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 17:36:45.0722 (UTC) FILETIME=[0CF71FA0:01C8CD7C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2511; t=1213378605; x=1214242605; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20new=20charter=20text |Sender:=20 |To:=20JP=20Vasseur=20,=20Geoff=20Mulli gan=20,=0A=20=20=20=20=20=20=20=206lowp an=20<6lowpan@ietf.org>,=20; bh=p3KDLV9r4eNHryguRB8wQQ9X7ShPg0n0ZJIPuE5Vpng=; b=O2CCkYhlU12w10JKMIZ2P84IbvgxCZx+mfNebysU02FwirKPdSPn06FA7j OM2lL816TXUcA9cWEkN5MXQ5FCzMF0QsxG+NM0+ibajXuT0kg9NydEB4EOsz QcMGxJeuAD; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [Roll] [6lowpan] New new charter text X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Adding ROLL. On 6/13/08 6:01 PM, "JP Vasseur" wrote: > Hi Geoff, > > Thanks for sending out the new revision. One question, one comment. > > Question: could you explain the rationale for leaving out the fragmentation > recovery item? > > Comment: > > "3. Produce "6LoWPAN Architecture" to describe the design and > implementation of 6LoWPAN networks. This document will cover the > concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such > as operation with sleeping nodes, network components (both battery- > and line-powered), addressing, and IPv4/IPv6 network connections. > As a spin-off from that document, "6LoWPAN Routing Requirements" will > describe 6LoWPAN-specific requirements on routing protocols used in > 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. > Both documents will be informational." > > I do not understand the rationale here: I think that we should first > determine whether we both need a mesh-under *and* a route-over approach. You > know my opinion: we have numerous examples in the past of such approaches > that ALL failed for obvious technical reasons but this is my technical > opinion. As far as 6lowpan is concerned, shouldn't we first have a > discussion to get a consensus there ? *If* it turns out that both are > needed, then add an introductory section in the architecture document > pointing to the requirement document(s). > > Thus I would rather suggest not to list this as a WG item but to leave it > out for the moment and continue to have the discussion until we have a > consensus. Then at that point we could decide what to do. On the other hand, > having a separate documents listing the 6LoWPAN specific routing > requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot > of sense. > > Thoughts ? > > Thanks. > > JP. > > > > On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: > >> With the input from the authors we've put the "Use Cases" back into the >> text for the charter for the working group with a delivery date of Dec >> 08. >> >> Attached is the NEW new charter text. >> >> geoff >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Jun 13 10:36:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC693A6A15; Fri, 13 Jun 2008 10:36:50 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211AA3A63D3; Fri, 13 Jun 2008 10:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AErv7ZhlHCdA; Fri, 13 Jun 2008 10:36:48 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C9C113A69FE; Fri, 13 Jun 2008 10:36:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,639,1204520400"; d="scan'208";a="10958318" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2008 13:37:19 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m5DHbJ0v005552; Fri, 13 Jun 2008 13:37:19 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m5DHbJ8w020047; Fri, 13 Jun 2008 17:37:19 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jun 2008 13:37:17 -0400 Received: from 10.21.114.143 ([10.21.114.143]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Jun 2008 17:37:17 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 13 Jun 2008 19:37:15 +0200 From: JP Vasseur To: JP Vasseur , Geoff Mulligan Message-ID: Thread-Topic: [6lowpan] New new charter text Thread-Index: AcjNe6j+sv9E+5tBh0GrrU+BorLQ1AAAHVuq In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 13 Jun 2008 17:37:17.0550 (UTC) FILETIME=[1FEFB0E0:01C8CD7C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4341; t=1213378639; x=1214242639; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Re=3A=20[6lowpan]=20New=20new=20charter=20text |Sender:=20 |To:=20JP=20Vasseur=20,=20Geoff=20Mulli gan=20; bh=IZMU2nMi02ptvGBX2DqS8hl7SaAYRZ/f+lVuQLPx/aM=; b=LXIj40Cvv29C9k6BGdbxVwt0Nv5UkLjJfDGJTUQTc8GJX6um47CJIyJIs8 uCA//hxSKgPD4zuTU0NiIonRLRiCqOC8jehRitSwJo7Ku+kATwZFvsgMKaIX 5wh4s8VyNq; Authentication-Results: rtp-dkim-2; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: roll@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] New new charter text X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Adding ROLL. On 6/13/08 7:33 PM, "JP Vasseur" wrote: > Hi Geoff, > > > On 6/13/08 7:25 PM, "Geoff Mulligan" wrote: > >> JP, >> As I said previously, when Carsten, Mark and I reviewed the >> comments/messages on the list it was clear that ND, Architecture, and >> Security were priority items along with dealing with enhancements to >> compression of non link local addresses and that there was clear support >> to take these on within the working group. And now also the Use Cases >> draft. >> >> I am less certain that there is consensus that fragment recovery is a >> necessary working group item at this point. So I will ask the WG. >> >> As to your question about the Arch doc, I'm not sure that I understand >> the question or the timing? The text for this hasn't changed for >> months. It seems that there are members of the WG that want to see the >> architectural description that includes both a mesh under solution and a >> route over. How would you propose that we determine if there is a need >> for both? > > My proposal would be to have a discussion on this topic first, trying to > reach a consensus in the WG on whether or not we need to define a mesh-under > solution. Once we have reached a consensus, then move on and start to > incorporate it as part of the architecture ID or another document. > > In term of routing requirement ID, I would suggest: > * To move ahead with the 6lowpan specific requirement ID, owned by the > 6lowpan WG and reviewed by ROLL, > * hold-off on the mesh-under routing requirements until we have reached a > consensus. > > Makes sense ? > > Thanks. > > JP. > >> >> geoff >> >> On Fri, 2008-06-13 at 18:01 +0200, JP Vasseur wrote: >>> Hi Geoff, >>> >>> Thanks for sending out the new revision. One question, one comment. >>> >>> Question: could you explain the rationale for leaving out the fragmentation >>> recovery item? >>> >>> Comment: >>> >>> "3. Produce "6LoWPAN Architecture" to describe the design and >>> implementation of 6LoWPAN networks. This document will cover the >>> concepts of "Mesh Under" and "Route Over", 802.15.4 design issues such >>> as operation with sleeping nodes, network components (both battery- >>> and line-powered), addressing, and IPv4/IPv6 network connections. >>> As a spin-off from that document, "6LoWPAN Routing Requirements" will >>> describe 6LoWPAN-specific requirements on routing protocols used in >>> 6LoWPANs, addressing both the "route-over" and "mesh-under" approach. >>> Both documents will be informational." >>> >>> I do not understand the rationale here: I think that we should first >>> determine whether we both need a mesh-under *and* a route-over approach. You >>> know my opinion: we have numerous examples in the past of such approaches >>> that ALL failed for obvious technical reasons but this is my technical >>> opinion. As far as 6lowpan is concerned, shouldn't we first have a >>> discussion to get a consensus there ? *If* it turns out that both are >>> needed, then add an introductory section in the architecture document >>> pointing to the requirement document(s). >>> >>> Thus I would rather suggest not to list this as a WG item but to leave it >>> out for the moment and continue to have the discussion until we have a >>> consensus. Then at that point we could decide what to do. On the other hand, >>> having a separate documents listing the 6LoWPAN specific routing >>> requirements, owned by the 6lowpan WG and reviewed by ROLL would make a lot >>> of sense. >>> >>> Thoughts ? >>> >>> Thanks. >>> >>> JP. >>> >>> >>> >>> On 6/13/08 3:59 PM, "Geoff Mulligan" wrote: >>> >>>> With the input from the authors we've put the "Use Cases" back into the >>>> text for the charter for the working group with a delivery date of Dec >>>> 08. >>>> >>>> Attached is the NEW new charter text. >>>> >>>> geoff >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >> > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Jun 23 01:30:59 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3173A692D; Mon, 23 Jun 2008 01:30:59 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F327A3A692D for ; Mon, 23 Jun 2008 01:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.228 X-Spam-Level: X-Spam-Status: No, score=0.228 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsWaZdz5X3V7 for ; Mon, 23 Jun 2008 01:30:56 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id F20883A6881 for ; Mon, 23 Jun 2008 01:30:55 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 10:30:54 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EFC8088@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs Thread-Index: AcjGVZS9IxBTuhaAS0m4iHdje4EXOQK6OuEVAPK4J7A= References: From: "Jakob Buron" To: Subject: Re: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear WG, a new revision of the home automation I-D based on JPs comments will be pos= ted soon. Please see my inline comments for an overview of the proposed cha= nges by Anders and myself. Do let me know if you have any feedback at this = point. Kind regards, Jakob > -----Original Message----- > From: JP Vasseur > Date: Wed, 04 Jun 2008 17:13:45 +0200 > To: > Subject: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs > = > Dear WG, > = > I made a detailed review of draft-ietf-roll-home-routing-reqs > = > Here are my comments (not of equil importance): > = > 1) idnits > Checking nits according to http://www.ietf.org/ID-Checklist.html: > = > -------------------------------------------------------------- > -------------- > = > ** There is 1 instance of too long lines in the document, the = > longest one > being 1 character in excess of 72. > = Will fix. > 2) Each acronym must be expanded the first time it is used (e.g. PANs = > in section 2) OK. > 3) Remove reference to I-D.culler-roll-routing-reqs (ID has expired) OK > 4) Section 3.1 > =B3Some existing = > home automation solutions use a clever mix of a "subnet groupcast" > message with no acknowledgement and no forwarding before sending > acknowledged singlecast messages to each lighting device.=B2 This = > might be a good place to define the term =B3groupcast=B2 more carefully. I'll add a definition of groupcast in Section 4.1. > 5) Section 3.1 > =B3 Thus, a solution is needed for addressing groups of nodes without = > prior management of group membership in the receiving nodes. =B3 Is it a = > =B3must=B2 or a MUST? I'll remove this sentence since requirements should not appear in use cases= . = > 6) Section 3.2 > =B3 The power grid may experience periods where more wind-generated = > power > is produced than is needed. Typically this may happen during night > hours. The washing machine and dish washer may just as well work > while power is cheap. The electric car should also charge its = > batteries on cheap power. =B3 > -> Add the example of power dynamic pricing that can be used > to regulate > -> the > operation of a set of devices in the home. We already have the "start-device-when-power-is-cheap" case. I'll add "stop= -device-when-power-is-expensive" case. This should be useful for air condit= ioning/climate control systems. > 7) Section 3.2 > " Most of these applications are mains powered and may thus provide = > reliable routing resources." > I would suggest to reword the sentence. Indeed, a battery node may = > still provide reliable routing but this is a constrained resource = > (battery > operated) that the routing decision may want to avoid if an alternate = > path exist. I will change to "Most of these applications are mains powered and are thus= ideal for providing reliable, always-on routing resources. Battery-powered= nodes, by comparison, are constrained routing resources and may only provi= de reliable routing under some circumstances." Giorgio - do you agree on this wording? Can we link this to a health care e= xample of reliable routing via battery-powered devices? 8) As written section 3.4 is about auto-conf rather than routing = > (requires for auto-conf)? Would you want to slightly elaborate there? Inserted at the end of sec. 3.4: "Distribution of unique addresses is usually performed by a central control= ler. In this case, it must be possible to route the inclusion request from= the joining node to the central controller even before the joining node is= assigned a unique address." > 9) section 3.5: " ROLL resources" ? Why would the router have to wait = > for some time ? Because you make the assumption of devices in deep = > sleep mode? "ROLL resources" changed to "ROLL devices". The router only has to wait if the receiver is sleeping. An acknowledgment-= mechanism is needed to manage this, but that is beyond the scope if this I-= D. I'll clarify that the router has to wait _if_ the receiver is sleeping. > 10) Section 3.6 > S/ROLL devices/constrained devices or please define a "ROLL" = > device in the terminology section I'll define a ROLL device as "A ROLL network node with constrained CPU and = memory resources; potentially constrained power resources." > 11) Could you elaborate on the routing requirements here: " A plethora = > of applications could be developed for home alarm > system: most of them, most of the time, have prevention and monitoring = > activity in which routing requirements are deterministic, but all of = > them have an alarm state in which nodes may burst an aperiodic alarm. = > " I will highly appreciate contributions here, Giorgio, you probably have som= e thought on this. Do you want to add something? > 12) Section 3.9: I guess that you meant " leaving only a few 100 bytes = > of RAM powered during the deep sleep phase." I'll add "of RAM". > 13) Section 4.1: > " The routing protocol must provide the ability to route a packet = > towards a single device (unicast), a set of devices (also referred to = > as "groupcast" > in this document) or all devices (broadcast) in the house. > - Don't you mean to use a MUST here ? Will be changed to: "Broadcast and groupcast in home automation MAY be used to deliver the illu= sion that all recipients respond simultaneously. Distant recipients out of= direct range may not react to the (unacknowledged) groupcast. Acknowledge= d unicast delivery MUST be used subsequently." > - Please insert a section prior to this requirements on the definition = > of Groupcast. I propose to add this section: "Groupcast, in the context of home automation, is defined as the ability to= simultaneously transmit a message to a group of recipients without prior i= nteraction with the group members (i.e. group setup). A use-case for groupc= ast is given in Section 3.1. " > 14) You wrote: " Alternatively, a companion specification SHOULD = > define how to indirectly address a group of nodes on the application = > layer via classic broadcast in the network layer; e.g. by use of a = > bitmap in a header extension. " > But you cannot have a SHOULD in this document on a document defined = > somewhere else. OK - that sentence will be removed. > 15) You wrote: > "[ABR NOTE: IETF-71 WG meeting indicated that the term "constrained" > has a very specific meaning in the routing community inside IETF. > What I understood was that the draft should be using the term = > "metric-based routing"]" > I do not think so. The term "constrained based routing" used in this = > document is appropriate if what you require is to have the ability the = > compute the shortest path based on some metrics (there could be more = > than one metrics) taking into account some link or node constraints. = > If this is what you need, then you indeed refer to constrained based = > routing. > Based on what you wrote > " Simple battery-powered nodes such as movement sensors on garage = > doors and rain meters may not be able to assist in routing. Depending = > on the node type, the node never listens at all, listens rarely or = > makes contact on demand to a pre-configured target node. Attempting to = > communicate to such nodes may require long time before getting a = > response." > You do refer to constrained based routing. > 16) > "The routing protocol MUST support metric-based routing taking into = > account node properties (CPU, memory, level of energy, sleep = > intervals, safety/convenience of changing battery). " > S/metric-based routing/constrained based routing. > The metric-based routing refers to the ability to use different = > metrics to compute the shortest path, which is a different requirement = > ? > Is that needed for Home Automation ? > In your case you may either need: > 1) Constrained based routing: e.g. Avoid a node whose battery level < = > X > 2) Multi-metric based routing: assign different metrics for a specific = > link (for example, one metric to reflect the bandwidth, one metric to = > reflect the propagation delay, ...). I agree with JPs taxonomy of routing types, and I believe that we need cons= traint-based routing. Multi-metric routing would be too complicated for a s= imple network. If there are no objections on the ML, we'll revert back to the term "constr= aint-based routing" instead of "metric-based routing". > 17) > " The routing protocol SHOULD make use of the fact that if not being = > able to deliver a packet, it is most likely that the sending node = > moved; rather than the rest of the network." > You may want to be more explicit on what this actually translate to = > for the routing protocol. A non-responsive node can either be caused by 1) a failure in the node, 2) = a failed link on the path to the node or 3) a moved node. In the first two = cases, the node can be expected to reappear at roughly the same location in= the network, whereas it can return anywhere in the network in the latter c= ase. The search strategy in the routing protocol will behave differently de= pending on this expectation. > 18) Section 4.7. Please expand PAN when first used. OK > 19) " home PAN MUST provide a set of features including 0 = > configuration of the routing protocol for a new node to be added to = > the network. " > Do you really mean "0 configuration" ?? What about optional = > configuration of timers ? We mean zero configuration, as defined by Giorgio: " From ROLL perspective, zero-configuration means only and above all, that = a node can obtain an address and join the network on its own, without human= intervention." I propose to add this definition and keep the 0 configuration requirement. > 20) " Furthermore, a failing node MUST NOT have a global impact on the = > routing protocol. " > This is a very strong requirement ... Are you sure that this is what = > you mean? I feel more comfortable about your second Agreed. I propose to delete the first requirement and make the second a MUS= T: "The routing protocol MUST support the ability to isolate a misbehaving nod= e thus preserving the correct operation the overall network." Giorgio has a very good comment on the unspecified impact of a central cont= roller failing. This case is important for sure, but not all ROLL networks = need to have a central controller, so I would propose to avoid discussing i= t here. > 21) It would be nice if you could elaborate a little bit on the = > traffic pattern for the various use cases since health monitoring and = > alarm significantly differs on that aspect. > Please provide some number of packet sizes, frequency at which packets = > are sent out, ... I'll add some numbers for the home appliance remote control and motion sens= or cases. Perhaps Giorgio could add some data on a healthcare scenario? > 22) Could you flesh out the security requirements ? This is still not clear from our side either. I'll add some general guideli= nes, though. > 23) Acknolegment: list of people (if any) that you want to = > thank for their contribution/feed-backs/... Good idea. > 24) Remove [I-D.culler-roll-routing-reqs] as informative reference. > = OK. > Thanks. > = > JP. > = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > = > = -- Jakob Buron Software Engineer Zensys A/S Emdrupvej 26 DK-2100 Copenhagen O Phone : +45 39130043 www.zen-sys.com = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Mon Jun 23 04:19:09 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3D43A6912; Mon, 23 Jun 2008 04:19:09 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7543A68B3 for ; Mon, 23 Jun 2008 04:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep2oucnnlq5u for ; Mon, 23 Jun 2008 04:19:02 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 869BD3A68AC for ; Mon, 23 Jun 2008 04:19:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,690,1204520400"; d="scan'208,217";a="11901817" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 23 Jun 2008 07:19:02 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5NBJ215012724 for ; Mon, 23 Jun 2008 07:19:02 -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.13.8/8.13.8) with ESMTP id m5NBJ2E1026603 for ; Mon, 23 Jun 2008 11:19:02 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 07:19:01 -0400 Received: from 10.21.148.106 ([10.21.148.106]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Mon, 23 Jun 2008 11:19:00 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 23 Jun 2008 13:18:59 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: ROLL WG Agenda Thread-Index: AcjVIu6tCPQk0VdSoEO6w1CK15Z1Rg== Mime-version: 1.0 X-OriginalArrivalTime: 23 Jun 2008 11:19:01.0019 (UTC) FILETIME=[EFE166B0:01C8D522] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3377; t=1214219942; x=1215083942; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20ROLL=20WG=20Agenda |Sender:=20 |To:=20; bh=mRHV3fc8YzKyR13uGR7iBzHhVp6k3mVjKXldmUhHjmU=; b=Z7/ep0eWPkDxfX2btUuszHvkw6TS/DK3dqDfWeeVLCd1eKPnTMet8Waosz RD3xH6yydQyjBXiGqIMx6vohRG/VtCNsjM1d1/Zbz61pVMrIflzHVsoGljN2 MEdYHYqAeq; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] ROLL WG Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0909033056==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0909033056== Content-type: multipart/alternative; boundary="B_3297071940_20447721" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3297071940_20447721 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, The ROLL WG will meet in Dublin. The provisional agenda is: MONDAY, July 28, 2008 0800-1800 IETF Registration - Convention Lobby 0800-0900 Beverages - Convention Lobby 1130-1300 Break 1300-1500 Afternoon Session I Convention 1 INT l3vpn Layer 3 Virtual Private Networks WG Ballroom 2 INT csi Cga & Send maIntenance WG Conservatory IRTF hiprg Host Identity Protocol Newcastle OPS dime Diameter Maintenance and Extensions WG Convention 3 RAI speermint Session PEERing for Multimedia INTerconnect WG Newcastle RTG roll Routing Over Low power and Lossy networks WG Conservatory SEC krb-wg Kerberos WG Ballroom 1 SEC dkim Domain Keys Identified Mail WG Rathcoole TSV dccp Datagram Congestion Control Protocol WG If you need a slot, please let us know. JP. --B_3297071940_20447721 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable ROLL WG Agenda Dear WG,

The ROLL WG will meet in Dublin. The provisional agenda is:

MONDAY, July 28, 2008
0800-1800 IETF Registration - Convention Lobby
0800-0900 Beverages - Convention Lobby

1130-1300 Break
1300-1500 Afternoon Session I
Convention 1    INT    l3vpn    Layer 3 Virtual Private Networks WG
Ballroom 2    INT    csi    Cga & Send maIntenance WG
Conservatory    IRTF    hiprg   &nb= sp;Host Identity Protocol
Newcastle    OPS    = dime    Diameter Maintenance and Extensions WG
Convention 3    RAI    = speermint    Session PEERing for Multimedia INTercon= nect WG
Newcastle    RTG    = roll    Routing Over Low power and Lossy networks WG=
Conservatory    SEC    krb-wg    Kerberos WG
Ballroom 1    SEC    dkim    Domain Keys Identified Mail WG
Rathcoole    TSV    = dccp    Datagram Congestion Co= ntrol Protocol WG

If you need a slot, please let us know.

JP. --B_3297071940_20447721-- --===============0909033056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0909033056==-- From roll-bounces@ietf.org Mon Jun 23 09:22:50 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949813A69B2; Mon, 23 Jun 2008 09:22:50 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE8E3A67CF for ; Mon, 23 Jun 2008 09:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEHTXG8Yhy6u for ; Mon, 23 Jun 2008 09:22:44 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id C24413A69BB for ; Mon, 23 Jun 2008 09:22:13 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2321327wfd.31 for ; Mon, 23 Jun 2008 09:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=xcBPjYro2ljbdcuK0z9vHkmsw8nqvfrJZ7XjU28TE9Q=; b=oguu6jZx2du66z8ITpLkqqagjbByrHJuae1iukLYYQTfbXHL1rMXwDBJx6W7U9Zxcp ysvEi+4tJTzMzaoyujNylDrC2WPc2fwkTZSePyrNKMI9J26jGicTLz4txAcn8in7hCmV 9mHt8ANVKHJmIh4CkMGIbqXfM8olceE5r7344= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=O580450+y18Xvr7GXh1k44DkAtUoRxaHAVxPi4fG6KiKPnWxCdSxz2+GGuQec+DmB/ HGAtVbCm+t4rVpHgbCUy8+Y9ASGU2CErbyciPfDiIu7husmsFu1T3DsPV3mJVz3InJSq 2q3AQew8+XKbXbj72AUpxyBiYlg+j96t/cRhA= Received: by 10.142.215.5 with SMTP id n5mr4047024wfg.27.1214238133928; Mon, 23 Jun 2008 09:22:13 -0700 (PDT) Received: from ?10.0.1.196? ( [219.110.223.29]) by mx.google.com with ESMTPS id 29sm9177538wfg.0.2008.06.23.09.22.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Jun 2008 09:22:13 -0700 (PDT) From: Ryuji Wakikawa To: JP Vasseur In-Reply-To: References: Message-Id: <71C87420-99ED-4255-A045-94E1B483F9BF@gmail.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 01:22:10 +0900 X-Mailer: Apple Mail (2.924) Cc: roll@ietf.org Subject: Re: [Roll] ROLL WG Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Hi JP, We want 15min slot for "In-Vehicle Routing Requirements". http://tools.ietf.org/html/draft-wakikawa-roll-invehicle-reqs-00 thanks ryuji On 2008/06/23, at 20:18, JP Vasseur wrote: > Dear WG, > > The ROLL WG will meet in Dublin. The provisional agenda is: > > MONDAY, July 28, 2008 > 0800-1800 IETF Registration - Convention Lobby > 0800-0900 Beverages - Convention Lobby > > 1130-1300 Break > 1300-1500 Afternoon Session I > Convention 1 INT l3vpn Layer 3 Virtual Private Networks WG > Ballroom 2 INT csi Cga & Send maIntenance WG > Conservatory IRTF hiprg Host Identity Protocol > Newcastle OPS dime Diameter Maintenance and Extensions WG > Convention 3 RAI speermint Session PEERing for Multimedia > INTerconnect WG > Newcastle RTG roll Routing Over Low power and Lossy > networks WG > Conservatory SEC krb-wg Kerberos WG > Ballroom 1 SEC dkim Domain Keys Identified Mail WG > Rathcoole TSV dccp Datagram Congestion Control Protocol WG > > If you need a slot, please let us know. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Jun 26 02:44:35 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6090A3A69F7; Thu, 26 Jun 2008 02:44:35 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 349363A69F7 for ; Thu, 26 Jun 2008 02:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.308 X-Spam-Level: *** X-Spam-Status: No, score=3.308 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azWZMyMhkp+p for ; Thu, 26 Jun 2008 02:44:29 -0700 (PDT) Received: from maile.telecomitalia.it (maile.telecomitalia.it [156.54.233.31]) by core3.amsl.com (Postfix) with ESMTP id 72C9A3A692B for ; Thu, 26 Jun 2008 02:44:28 -0700 (PDT) Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 11:44:29 +0200 Received: from grfhub701ba020.griffon.local ([10.188.101.111]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 11:44:28 +0200 Received: from GRFMBX706BA020.griffon.local ([10.188.101.20]) by grfhub701ba020.griffon.local ([10.188.101.111]) with mapi; Thu, 26 Jun 2008 11:44:28 +0200 From: Porcu Giorgio To: "roll@ietf.org" Date: Thu, 26 Jun 2008 11:44:28 +0200 Thread-Topic: R:[Roll] Detailed comments on draft-ietf-roll-home-routing-reqs Thread-Index: AQHI12Tl19vyu1gwo0SaOrGyxIaL2Q== Message-ID: Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jun 2008 09:44:28.0710 (UTC) FILETIME=[3A28FC60:01C8D771] Subject: [Roll] R: Detailed comments on draft-ietf-roll-home-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear WG, here there are a few comments about HA draft. Welcome to Jakob and thank you for your help! I wish we'll get a stable draft version before the Dublin meeting. Anyway, my opinion is included in the discuss with JP, I'd like to see in t= he new revision some updates mainly in these part: - 3.2 Energy conservation and optimizing energy consumption - 3.9 Battery powered devices - 4.2 Metric-based Routing ---------------------- Section 0. Abstract. ---------------------- >This document presents home control and automation application > specific requirements for ROuting in Low power and Lossy networks > (ROLL). There is a typing error: "ROuting" instead of "Routing" ;-) ----------------- Section 3.2 ---------------- > 6) Section 3.2 >> -> Add the example of power dynamic pricing that can be used >> -> to regulate >> -> the operation of a set of devices in the home. > We already have the "start-device-when-power-is-cheap" case. I'll add "st= op-device-when-power-is-expensive" case. This should be useful for air cond= itioning/climate control systems. IMHO, we have to consider two different aspects here. Of course, as JP says, it's important to focus on the power dynamic pricing= using the case study "stop-device-when-power-is-expensive" (I'm looking fo= rward to read it!), but, at the same time, I think it useful to stress, in = the "Energy conservation and optimizing energy consumption." part, that the= energy of the nodes involved in routing must be optimized too. I mean, for e.g., if an application must change a home-device to stand-by m= ode, of course it must spend less energy than that required by the stand-by= mode. It could be a very important application scenario, which can have relevant = consequences on the routing process. Let me know what do you think about it. Jakob wrote: >I will change to "Most of these applications are mains powered and are thu= s ideal for providing reliable, always-on routing resources. Battery-powere= d nodes, by comparison, are constrained routing >resources and may only pro= vide reliable routing under some circumstances." >Giorgio - do you agree on this wording? Can we link this to a health care = example of reliable routing via battery-powered devices? Sure! Well done. ---------------- Section 3.8 ---------------- >> 11) Could you elaborate on the routing requirements here: " A plethora >> of applications could be developed for home alarm >> system: most of them, most of the time, have prevention and monitoring >> activity in which routing requirements are deterministic, but all of >> them have an alarm state in which nodes may burst an aperiodic alarm. >> " >I will highly appreciate contributions here, Giorgio, you probably have so= me thought on this. Do you want to add something? Yes! I'd like to introduce in this scenario the panic button application to= explain it better. You'll receive asap my contribution :) ---------------- Section 3.9. ---------------- JP wrote: >> 2. >> 12) Section 3.9(Battery-powered devices) I guess that you meant " >> leaving only a few 100 bytes of RAM powered during the deep sleep >> phase." Jakob wrote: >I'll add "of RAM". This point isn't so clear for me. In this section ("battery powered devices"), it seems a strong requirement = (a few 100 byte of RAM powered). Why RAM? Why "few 100 bytes"? The main requirement is to save up as much as possible energy... but how an= d, above all, how much memory RAM I had to powered during the sleep phase = seems a little extreme requirement.. It means that I'm wrong if I use a NVRAM during this phase or not? Sorry, maybe it is only a personal gap ... ---------------- Section 4.1 ---------------- Jakob wrote: >I propose to add this section: >"Groupcast, in the context of home automation, is defined as the ability t= o simultaneously transmit a message to a group of recipients without prior = interaction with the group members (i.e. group setup). A >use-case for grou= pcast is given in Section 3.1. " It is ok for me! ---------------- Section 4.2 ---------------- Jakob wrote: >I agree with JPs taxonomy of routing types, and I believe that we need con= straint-based routing. Multi-metric routing would be too complicated for a = simple network. >If there are no objections on the ML, we'll revert back to the term "const= raint-based routing" instead of "metric-based routing". I agree with JPs taxonomy too but it's not only a question of terminology = for me. We could use "constraing-based routing" term as well, but I think it is of = no help to remove the opportunity to choose between a bandwith metric and a= power metric or (why not) an hybrid. Sorry, maybe I've misunderstood the meaning of your comment... ---------------- Section 4.7 ---------------- Jakob wrote: >" From ROLL perspective, zero-configuration means only and above all, that= a node can obtain an address and join the network on its own, without huma= n intervention." >I propose to add this definition and keep the 0 configuration requirement. ok. Excuse me for my boring mail;) Regards Giorgio ___________________________________________________________________________= ___________ --- La vita =E8 come una commedia: non importa quanto =E8 lunga, ma come =E8 re= citata. (Seneca) Men do not care how nobly they live, but only how long, although it is with= in the reach of every man to live nobly, but within no man's power to live = long (Seneca the Younger) ________________________________________ Da: roll-bounces@ietf.org [roll-bounces@ietf.org] per conto di roll-request= @ietf.org [roll-request@ietf.org] Inviato: luned=EC 23 giugno 2008 21.00 A: roll@ietf.org Oggetto: Roll Digest, Vol 5, Issue 14 Send Roll mailing list submissions to roll@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/roll or, via email, send a message with subject or body 'help' to roll-request@ietf.org You can reach the person managing the list at roll-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Roll digest..." Today's Topics: 1. Re: Detailed comments on draft-ietf-roll-home-routing-reqs (Jakob Buron) 2. ROLL WG Agenda (JP Vasseur) 3. Re: ROLL WG Agenda (Ryuji Wakikawa) ---------------------------------------------------------------------- Message: 1 Date: Mon, 23 Jun 2008 10:30:54 +0200 From: "Jakob Buron" Subject: Re: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs To: Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EFC8088@zensys17.zensys.local> Content-Type: text/plain; charset=3D"iso-8859-1" Dear WG, a new revision of the home automation I-D based on JPs comments will be pos= ted soon. Please see my inline comments for an overview of the proposed cha= nges by Anders and myself. Do let me know if you have any feedback at this = point. Kind regards, Jakob > -----Original Message----- > From: JP Vasseur > Date: Wed, 04 Jun 2008 17:13:45 +0200 > To: > Subject: [Roll] Detailed comments on draft-ietf-roll-home-routing-reqs > > Dear WG, > > I made a detailed review of draft-ietf-roll-home-routing-reqs > > Here are my comments (not of equil importance): > > 1) idnits > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > -------------------------------------------------------------- > -------------- > > ** There is 1 instance of too long lines in the document, the > longest one > being 1 character in excess of 72. > Will fix. > 2) Each acronym must be expanded the first time it is used (e.g. PANs > in section 2) OK. > 3) Remove reference to I-D.culler-roll-routing-reqs (ID has expired) OK > 4) Section 3.1 > ?Some existing > home automation solutions use a clever mix of a "subnet groupcast" > message with no acknowledgement and no forwarding before sending > acknowledged singlecast messages to each lighting device.? This > might be a good place to define the term ?groupcast? more carefully. I'll add a definition of groupcast in Section 4.1. > 5) Section 3.1 > ? Thus, a solution is needed for addressing groups of nodes without > prior management of group membership in the receiving nodes. ? Is it a > ?must? or a MUST? I'll remove this sentence since requirements should not appear in use cases. > 6) Section 3.2 > ? The power grid may experience periods where more wind-generated > power > is produced than is needed. Typically this may happen during night > hours. The washing machine and dish washer may just as well work > while power is cheap. The electric car should also charge its > batteries on cheap power. ? > -> Add the example of power dynamic pricing that can be used > to regulate > -> the > operation of a set of devices in the home. We already have the "start-device-when-power-is-cheap" case. I'll add "stop= -device-when-power-is-expensive" case. This should be useful for air condit= ioning/climate control systems. > 7) Section 3.2 > " Most of these applications are mains powered and may thus provide > reliable routing resources." > I would suggest to reword the sentence. Indeed, a battery node may > still provide reliable routing but this is a constrained resource > (battery > operated) that the routing decision may want to avoid if an alternate > path exist. I will change to "Most of these applications are mains powered and are thus= ideal for providing reliable, always-on routing resources. Battery-powered= nodes, by comparison, are constrained routing resources and may only provi= de reliable routing under some circumstances." Giorgio - do you agree on this wording? Can we link this to a health care e= xample of reliable routing via battery-powered devices? 8) As written section 3.4 is about auto-conf rather than routing > (requires for auto-conf)? Would you want to slightly elaborate there? Inserted at the end of sec. 3.4: "Distribution of unique addresses is usually performed by a central control= ler. In this case, it must be possible to route the inclusion request from= the joining node to the central controller even before the joining node is= assigned a unique address." > 9) section 3.5: " ROLL resources" ? Why would the router have to wait > for some time ? Because you make the assumption of devices in deep > sleep mode? "ROLL resources" changed to "ROLL devices". The router only has to wait if the receiver is sleeping. An acknowledgment-= mechanism is needed to manage this, but that is beyond the scope if this I-= D. I'll clarify that the router has to wait _if_ the receiver is sleeping. > 10) Section 3.6 > S/ROLL devices/constrained devices or please define a "ROLL" > device in the terminology section I'll define a ROLL device as "A ROLL network node with constrained CPU and = memory resources; potentially constrained power resources." > 11) Could you elaborate on the routing requirements here: " A plethora > of applications could be developed for home alarm > system: most of them, most of the time, have prevention and monitoring > activity in which routing requirements are deterministic, but all of > them have an alarm state in which nodes may burst an aperiodic alarm. > " I will highly appreciate contributions here, Giorgio, you probably have som= e thought on this. Do you want to add something? > 12) Section 3.9: I guess that you meant " leaving only a few 100 bytes > of RAM powered during the deep sleep phase." I'll add "of RAM". > 13) Section 4.1: > " The routing protocol must provide the ability to route a packet > towards a single device (unicast), a set of devices (also referred to > as "groupcast" > in this document) or all devices (broadcast) in the house. > - Don't you mean to use a MUST here ? Will be changed to: "Broadcast and groupcast in home automation MAY be used to deliver the illu= sion that all recipients respond simultaneously. Distant recipients out of= direct range may not react to the (unacknowledged) groupcast. Acknowledge= d unicast delivery MUST be used subsequently." > - Please insert a section prior to this requirements on the definition > of Groupcast. I propose to add this section: "Groupcast, in the context of home automation, is defined as the ability to= simultaneously transmit a message to a group of recipients without prior i= nteraction with the group members (i.e. group setup). A use-case for groupc= ast is given in Section 3.1. " > 14) You wrote: " Alternatively, a companion specification SHOULD > define how to indirectly address a group of nodes on the application > layer via classic broadcast in the network layer; e.g. by use of a > bitmap in a header extension. " > But you cannot have a SHOULD in this document on a document defined > somewhere else. OK - that sentence will be removed. > 15) You wrote: > "[ABR NOTE: IETF-71 WG meeting indicated that the term "constrained" > has a very specific meaning in the routing community inside IETF. > What I understood was that the draft should be using the term > "metric-based routing"]" > I do not think so. The term "constrained based routing" used in this > document is appropriate if what you require is to have the ability the > compute the shortest path based on some metrics (there could be more > than one metrics) taking into account some link or node constraints. > If this is what you need, then you indeed refer to constrained based > routing. > Based on what you wrote > " Simple battery-powered nodes such as movement sensors on garage > doors and rain meters may not be able to assist in routing. Depending > on the node type, the node never listens at all, listens rarely or > makes contact on demand to a pre-configured target node. Attempting to > communicate to such nodes may require long time before getting a > response." > You do refer to constrained based routing. > 16) > "The routing protocol MUST support metric-based routing taking into > account node properties (CPU, memory, level of energy, sleep > intervals, safety/convenience of changing battery). " > S/metric-based routing/constrained based routing. > The metric-based routing refers to the ability to use different > metrics to compute the shortest path, which is a different requirement > ? > Is that needed for Home Automation ? > In your case you may either need: > 1) Constrained based routing: e.g. Avoid a node whose battery level < > X > 2) Multi-metric based routing: assign different metrics for a specific > link (for example, one metric to reflect the bandwidth, one metric to > reflect the propagation delay, ...). I agree with JPs taxonomy of routing types, and I believe that we need cons= traint-based routing. Multi-metric routing would be too complicated for a s= imple network. If there are no objections on the ML, we'll revert back to the term "constr= aint-based routing" instead of "metric-based routing". > 17) > " The routing protocol SHOULD make use of the fact that if not being > able to deliver a packet, it is most likely that the sending node > moved; rather than the rest of the network." > You may want to be more explicit on what this actually translate to > for the routing protocol. A non-responsive node can either be caused by 1) a failure in the node, 2) = a failed link on the path to the node or 3) a moved node. In the first two = cases, the node can be expected to reappear at roughly the same location in= the network, whereas it can return anywhere in the network in the latter c= ase. The search strategy in the routing protocol will behave differently de= pending on this expectation. > 18) Section 4.7. Please expand PAN when first used. OK > 19) " home PAN MUST provide a set of features including 0 > configuration of the routing protocol for a new node to be added to > the network. " > Do you really mean "0 configuration" ?? What about optional > configuration of timers ? We mean zero configuration, as defined by Giorgio: " From ROLL perspective, zero-configuration means only and above all, that = a node can obtain an address and join the network on its own, without human= intervention." I propose to add this definition and keep the 0 configuration requirement. > 20) " Furthermore, a failing node MUST NOT have a global impact on the > routing protocol. " > This is a very strong requirement ... Are you sure that this is what > you mean? I feel more comfortable about your second Agreed. I propose to delete the first requirement and make the second a MUS= T: "The routing protocol MUST support the ability to isolate a misbehaving nod= e thus preserving the correct operation the overall network." Giorgio has a very good comment on the unspecified impact of a central cont= roller failing. This case is important for sure, but not all ROLL networks = need to have a central controller, so I would propose to avoid discussing i= t here. > 21) It would be nice if you could elaborate a little bit on the > traffic pattern for the various use cases since health monitoring and > alarm significantly differs on that aspect. > Please provide some number of packet sizes, frequency at which packets > are sent out, ... I'll add some numbers for the home appliance remote control and motion sens= or cases. Perhaps Giorgio could add some data on a healthcare scenario? > 22) Could you flesh out the security requirements ? This is still not clear from our side either. I'll add some general guideli= nes, though. > 23) Acknolegment: list of people (if any) that you want to > thank for their contribution/feed-backs/... Good idea. > 24) Remove [I-D.culler-roll-routing-reqs] as informative reference. > OK. > Thanks. > > JP. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > -- Jakob Buron Software Engineer Zensys A/S Emdrupvej 26 DK-2100 Copenhagen O Phone : +45 39130043 www.zen-sys.com ------------------------------ Message: 2 Date: Mon, 23 Jun 2008 13:18:59 +0200 From: JP Vasseur Subject: [Roll] ROLL WG Agenda To: Message-ID: Content-Type: text/plain; charset=3D"us-ascii" Dear WG, The ROLL WG will meet in Dublin. The provisional agenda is: MONDAY, July 28, 2008 0800-1800 IETF Registration - Convention Lobby 0800-0900 Beverages - Convention Lobby 1130-1300 Break 1300-1500 Afternoon Session I Convention 1 INT l3vpn Layer 3 Virtual Private Networks WG Ballroom 2 INT csi Cga & Send maIntenance WG Conservatory IRTF hiprg Host Identity Protocol Newcastle OPS dime Diameter Maintenance and Extensions WG Convention 3 RAI speermint Session PEERing for Multimedia INTerconnect WG Newcastle RTG roll Routing Over Low power and Lossy networks WG Conservatory SEC krb-wg Kerberos WG Ballroom 1 SEC dkim Domain Keys Identified Mail WG Rathcoole TSV dccp Datagram Congestion Control Protocol WG If you need a slot, please let us know. JP. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 24 Jun 2008 01:22:10 +0900 From: Ryuji Wakikawa Subject: Re: [Roll] ROLL WG Agenda To: JP Vasseur Cc: roll@ietf.org Message-ID: <71C87420-99ED-4255-A045-94E1B483F9BF@gmail.com> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; delsp=3Dyes Hi JP, We want 15min slot for "In-Vehicle Routing Requirements". http://tools.ietf.org/html/draft-wakikawa-roll-invehicle-reqs-00 thanks ryuji On 2008/06/23, at 20:18, JP Vasseur wrote: > Dear WG, > > The ROLL WG will meet in Dublin. The provisional agenda is: > > MONDAY, July 28, 2008 > 0800-1800 IETF Registration - Convention Lobby > 0800-0900 Beverages - Convention Lobby > > 1130-1300 Break > 1300-1500 Afternoon Session I > Convention 1 INT l3vpn Layer 3 Virtual Private Networks WG > Ballroom 2 INT csi Cga & Send maIntenance WG > Conservatory IRTF hiprg Host Identity Protocol > Newcastle OPS dime Diameter Maintenance and Extensions WG > Convention 3 RAI speermint Session PEERing for Multimedia > INTerconnect WG > Newcastle RTG roll Routing Over Low power and Lossy > networks WG > Conservatory SEC krb-wg Kerberos WG > Ballroom 1 SEC dkim Domain Keys Identified Mail WG > Rathcoole TSV dccp Datagram Congestion Control Protocol WG > > If you need a slot, please let us know. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 5, Issue 14 *********************************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Thu Jun 26 23:46:33 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5AA33A684E; Thu, 26 Jun 2008 23:46:33 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060593A684E for ; Thu, 26 Jun 2008 23:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.828 X-Spam-Level: X-Spam-Status: No, score=0.828 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_53=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M5m4X2w6g7P for ; Thu, 26 Jun 2008 23:46:30 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 38BD33A6407 for ; Thu, 26 Jun 2008 23:46:29 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Jun 2008 08:46:32 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3EFC8096@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] R: Detailed comments on draft-ietf-roll-home-routing-reqs Thread-Index: AQHI12Tl19vyu1gwo0SaOrGyxIaL2Y4dWIlg X-Message-Flag: Follow up Reply-By: Fri, 27 Jun 2008 08:00:00 +0200 References: From: "Jakob Buron" To: Subject: Re: [Roll] R: Detailed comments on draft-ietf-roll-home-routing-reqs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org Dear Giorgio, WG, thanks a lot for the valuable comments! It looks like we agree on most of t= he points. = For the few remaining issues, I have a few follow-up questions below. > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = > Behalf Of Porcu Giorgio > Sent: 26. juni 2008 11:44 > To: roll@ietf.org > Subject: [Roll] R: Detailed comments on = > draft-ietf-roll-home-routing-reqs > = > Dear WG, > here there are a few comments about HA draft. > Welcome to Jakob and thank you for your help! > I wish we'll get a stable draft version before the Dublin meeting. > = > Anyway, my opinion is included in the discuss with JP, I'd = > like to see in the new revision some updates mainly in these part: > - 3.2 Energy conservation and optimizing energy consumption > - 3.9 Battery powered devices > - 4.2 Metric-based Routing > = > ---------------------- > Section 0. Abstract. > ---------------------- > >This document presents home control and automation application > > specific requirements for ROuting in Low power and Lossy networks > > (ROLL). > There is a typing error: > "ROuting" instead of "Routing" ;-) This is actually not a typo: The capital O is part of the ROLL acronym ;-) > = > ----------------- > Section 3.2 > ---------------- > > 6) Section 3.2 > >> -> Add the example of power dynamic pricing that can be used to = > >> -> regulate the operation of a set of devices in the home. > > We already have the "start-device-when-power-is-cheap" = > case. I'll add "stop-device-when-power-is-expensive" case. = > This should be useful for air conditioning/climate control systems. > IMHO, we have to consider two different aspects here. > Of course, as JP says, it's important to focus on the power = > dynamic pricing using the case study = > "stop-device-when-power-is-expensive" (I'm looking forward to = > read it!), but, at the same time, I think it useful to = > stress, in the "Energy conservation and optimizing energy = > consumption." part, that the energy of the nodes involved in = > routing must be optimized too. > I mean, for e.g., if an application must change a home-device = > to stand-by mode, of course it must spend less energy than = > that required by the stand-by mode. > It could be a very important application scenario, which can = > have relevant consequences on the routing process. > Let me know what do you think about it. I'm not sure I don't understand your example. Could you please clarify? Do you mean that the energy needed to transmit a command should be weighed = against the energy that turn-device-X-off command will save? > = > Jakob wrote: > >I will change to "Most of these applications are mains = > powered and are thus ideal for providing reliable, always-on = > routing resources. Battery-powered nodes, by comparison, are = > constrained routing >resources and may only provide reliable = > routing under some circumstances." > >Giorgio - do you agree on this wording? Can we link this to = > a health care example of reliable routing via battery-powered devices? > Sure! > Well done. > = > = > = > ---------------- > Section 3.8 > ---------------- > >> 11) Could you elaborate on the routing requirements here: " A = > >> plethora of applications could be developed for home alarm > >> system: most of them, most of the time, have prevention and = > >> monitoring activity in which routing requirements are = > deterministic, = > >> but all of them have an alarm state in which nodes may = > burst an aperiodic alarm. > >> " > >I will highly appreciate contributions here, Giorgio, you = > probably have some thought on this. Do you want to add something? > Yes! I'd like to introduce in this scenario the panic button = > application to explain it better. > You'll receive asap my contribution :) > = Great! Looking forward to it. > ---------------- > Section 3.9. > ---------------- > JP wrote: > >> 2. > >> 12) Section 3.9(Battery-powered devices) I guess that you meant " > >> leaving only a few 100 bytes of RAM powered during the deep sleep = > >> phase." > Jakob wrote: > >I'll add "of RAM". > This point isn't so clear for me. > In this section ("battery powered devices"), it seems a = > strong requirement (a few 100 byte of RAM powered). > Why RAM? Why "few 100 bytes"? > The main requirement is to save up as much as possible = > energy... but how and, above all, how much memory RAM I had = > to powered during the sleep phase seems a little extreme requirement.. > It means that I'm wrong if I use a NVRAM during this phase or not? > Sorry, maybe it is only a personal gap ... > = First: I agree with the main requirement is to save energy. Period. For me,= it is also fine not to specify size of the sleep-powered RAM. The example = of leaving only a small part of RAM powered is not a requirement, so it doe= s not disallow using e.g. non-volatile RAM instead. It is just an example o= f _one way_ to save energy. This example is highlighted because it affects = the routing requirements: Use as little routing state/memory as possible to= save energy. Is this sufficient to address your concern? Otherwise, we can= add a sentence to clarify this. > = > = > ---------------- > Section 4.1 > ---------------- > Jakob wrote: > >I propose to add this section: > >"Groupcast, in the context of home automation, is defined as = > the ability to simultaneously transmit a message to a group = > of recipients without prior interaction with the group = > members (i.e. group setup). A >use-case for groupcast is = > given in Section 3.1. " > It is ok for me! > = > ---------------- > Section 4.2 > ---------------- > Jakob wrote: > >I agree with JPs taxonomy of routing types, and I believe = > that we need constraint-based routing. Multi-metric routing = > would be too complicated for a simple network. > >If there are no objections on the ML, we'll revert back to = > the term "constraint-based routing" instead of "metric-based routing". > I agree with JPs taxonomy too but it's not only a question = > of terminology for me. > We could use "constraing-based routing" term as well, but I = > think it is of no help to remove the opportunity to choose = > between a bandwith metric and a power metric or (why not) an hybrid. > Sorry, maybe I've misunderstood the meaning of your comment... > = Good question to a very important topic! To my understanding, multi-metric and constraint-based routing are not mutu= ally exclusive. Constraint-based routing _can_ use several different metric= s (according to JPs comment 15). So we are not disallowing multi-metric bec= ause we require constraint-based. I am however convinced constraint-based i= s essential to avoid e.g. nodes with low battery, hence the MUST to constra= int-based. We could add "The routing protocol MAY support multi-metric-based routing w= here several metrics (bandwidth, latency, etc.) are assinged to each link a= nd used for route computation.", but if we are going to be that specific I = would like to see some use cases that would benefit from multi-metric routi= ng. If anyone has such a use case, please let me know. > = > ---------------- > Section 4.7 > ---------------- > Jakob wrote: > >" From ROLL perspective, zero-configuration means only and = > above all, that a node can obtain an address and join the = > network on its own, without human intervention." > >I propose to add this definition and keep the 0 = > configuration requirement. > = > ok. > = > = > Excuse me for my boring mail;) > = No need to excuse, it is not boring at all! /jakob > Regards > Giorgio > = > = > = > = > ______________________________________________________________ > ________________________ > = > = > --- > La vita =E8 come una commedia: non importa quanto =E8 lunga, ma = > come =E8 recitata. > (Seneca) > = > Men do not care how nobly they live, but only how long, = > although it is within the reach of every man to live nobly, = > but within no man's power to live long (Seneca the Younger) = > ________________________________________ > Da: roll-bounces@ietf.org [roll-bounces@ietf.org] per conto = > di roll-request@ietf.org [roll-request@ietf.org] > Inviato: luned=EC 23 giugno 2008 21.00 > A: roll@ietf.org > Oggetto: Roll Digest, Vol 5, Issue 14 > = > Send Roll mailing list submissions to > roll@ietf.org > = > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/roll > or, via email, send a message with subject or body 'help' to > roll-request@ietf.org > = > You can reach the person managing the list at > roll-owner@ietf.org > = > When replying, please edit your Subject line so it is more = > specific than "Re: Contents of Roll digest..." > = > = > Today's Topics: > = > 1. Re: Detailed comments on draft-ietf-roll-home-routing-reqs > (Jakob Buron) > 2. ROLL WG Agenda (JP Vasseur) > 3. Re: ROLL WG Agenda (Ryuji Wakikawa) > = > = > ---------------------------------------------------------------------- > = > Message: 1 > Date: Mon, 23 Jun 2008 10:30:54 +0200 > From: "Jakob Buron" > Subject: Re: [Roll] Detailed comments on > draft-ietf-roll-home-routing-reqs > To: > Message-ID: > <6D9687E95918C04A8B30A7D6DA805A3EFC8088@zensys17.zensys.local> > Content-Type: text/plain; charset=3D"iso-8859-1" > = > Dear WG, > = > a new revision of the home automation I-D based on JPs = > comments will be posted soon. Please see my inline comments = > for an overview of the proposed changes by Anders and myself. = > Do let me know if you have any feedback at this point. > = > Kind regards, > Jakob > = > > -----Original Message----- > > From: JP Vasseur > > Date: Wed, 04 Jun 2008 17:13:45 +0200 > > To: > > Subject: [Roll] Detailed comments on = > draft-ietf-roll-home-routing-reqs > > > > Dear WG, > > > > I made a detailed review of draft-ietf-roll-home-routing-reqs > > > > Here are my comments (not of equil importance): > > > > 1) idnits > > Checking nits according to http://www.ietf.org/ID-Checklist.html: > > > > -------------------------------------------------------------- > > -------------- > > > > ** There is 1 instance of too long lines in the document, the = > > longest one > > being 1 character in excess of 72. > > > Will fix. > = > > 2) Each acronym must be expanded the first time it is used = > (e.g. PANs = > > in section 2) > OK. > = > > 3) Remove reference to I-D.culler-roll-routing-reqs (ID has expired) > OK > = > > 4) Section 3.1 > > ?Some existing > > home automation solutions use a clever mix of a "subnet = > groupcast" > > message with no acknowledgement and no forwarding before sending > > acknowledged singlecast messages to each lighting device.? This = > > might be a good place to define the term ?groupcast? more carefully. > I'll add a definition of groupcast in Section 4.1. > = > > 5) Section 3.1 > > ? Thus, a solution is needed for addressing groups of nodes without = > > prior management of group membership in the receiving = > nodes. ? Is it a = > > ?must? or a MUST? > I'll remove this sentence since requirements should not = > appear in use cases. > = > > 6) Section 3.2 > > ? The power grid may experience periods where more wind-generated = > > power > > is produced than is needed. Typically this may happen = > during night > > hours. The washing machine and dish washer may just as well work > > while power is cheap. The electric car should also charge its = > > batteries on cheap power. ? > > -> Add the example of power dynamic pricing that can be used > > to regulate > > -> the > > operation of a set of devices in the home. > We already have the "start-device-when-power-is-cheap" case. = > I'll add "stop-device-when-power-is-expensive" case. This = > should be useful for air conditioning/climate control systems. > = > > 7) Section 3.2 > > " Most of these applications are mains powered and may thus provide = > > reliable routing resources." > > I would suggest to reword the sentence. Indeed, a battery node may = > > still provide reliable routing but this is a constrained resource = > > (battery > > operated) that the routing decision may want to avoid if an = > alternate = > > path exist. > I will change to "Most of these applications are mains = > powered and are thus ideal for providing reliable, always-on = > routing resources. Battery-powered nodes, by comparison, are = > constrained routing resources and may only provide reliable = > routing under some circumstances." > Giorgio - do you agree on this wording? Can we link this to a = > health care example of reliable routing via battery-powered devices? > = > 8) As written section 3.4 is about auto-conf rather than routing > > (requires for auto-conf)? Would you want to slightly = > elaborate there? > Inserted at the end of sec. 3.4: > "Distribution of unique addresses is usually performed by a = > central controller. In this case, it must be possible to = > route the inclusion request from the joining node to the = > central controller even before the joining node is assigned = > a unique address." > = > > 9) section 3.5: " ROLL resources" ? Why would the router = > have to wait = > > for some time ? Because you make the assumption of devices in deep = > > sleep mode? > "ROLL resources" changed to "ROLL devices". > The router only has to wait if the receiver is sleeping. An = > acknowledgment-mechanism is needed to manage this, but that = > is beyond the scope if this I-D. > I'll clarify that the router has to wait _if_ the receiver is = > sleeping. > = > > 10) Section 3.6 > > S/ROLL devices/constrained devices or please define a "ROLL" > > device in the terminology section > I'll define a ROLL device as "A ROLL network node with = > constrained CPU and memory resources; potentially = > constrained power resources." > = > > 11) Could you elaborate on the routing requirements here: " = > A plethora = > > of applications could be developed for home alarm > > system: most of them, most of the time, have prevention and = > monitoring = > > activity in which routing requirements are deterministic, = > but all of = > > them have an alarm state in which nodes may burst an = > aperiodic alarm. > > " > I will highly appreciate contributions here, Giorgio, you = > probably have some thought on this. Do you want to add something? > = > > 12) Section 3.9: I guess that you meant " leaving only a = > few 100 bytes = > > of RAM powered during the deep sleep phase." > I'll add "of RAM". > = > = > > 13) Section 4.1: > > " The routing protocol must provide the ability to route a packet = > > towards a single device (unicast), a set of devices (also = > referred to = > > as "groupcast" > > in this document) or all devices (broadcast) in the house. > > - Don't you mean to use a MUST here ? > Will be changed to: > "Broadcast and groupcast in home automation MAY be used to = > deliver the illusion that all recipients respond = > simultaneously. Distant recipients out of direct range may = > not react to the (unacknowledged) groupcast. Acknowledged = > unicast delivery MUST be used subsequently." > = > > - Please insert a section prior to this requirements on the = > definition = > > of Groupcast. > I propose to add this section: > "Groupcast, in the context of home automation, is defined as = > the ability to simultaneously transmit a message to a group = > of recipients without prior interaction with the group = > members (i.e. group setup). A use-case for groupcast is given = > in Section 3.1. " > = > > 14) You wrote: " Alternatively, a companion specification SHOULD = > > define how to indirectly address a group of nodes on the = > application = > > layer via classic broadcast in the network layer; e.g. by use of a = > > bitmap in a header extension. " > > But you cannot have a SHOULD in this document on a document defined = > > somewhere else. > OK - that sentence will be removed. > = > > 15) You wrote: > > "[ABR NOTE: IETF-71 WG meeting indicated that the term "constrained" > > has a very specific meaning in the routing community inside IETF. > > What I understood was that the draft should be using the term = > > "metric-based routing"]" > > I do not think so. The term "constrained based routing" = > used in this = > > document is appropriate if what you require is to have the = > ability the = > > compute the shortest path based on some metrics (there = > could be more = > > than one metrics) taking into account some link or node constraints. > > If this is what you need, then you indeed refer to = > constrained based = > > routing. > > Based on what you wrote > > " Simple battery-powered nodes such as movement sensors on garage = > > doors and rain meters may not be able to assist in routing. = > Depending = > > on the node type, the node never listens at all, listens rarely or = > > makes contact on demand to a pre-configured target node. = > Attempting to = > > communicate to such nodes may require long time before getting a = > > response." > > You do refer to constrained based routing. > > 16) > > "The routing protocol MUST support metric-based routing taking into = > > account node properties (CPU, memory, level of energy, sleep = > > intervals, safety/convenience of changing battery). " > > S/metric-based routing/constrained based routing. > > The metric-based routing refers to the ability to use different = > > metrics to compute the shortest path, which is a different = > requirement = > > ? > > Is that needed for Home Automation ? > > In your case you may either need: > > 1) Constrained based routing: e.g. Avoid a node whose = > battery level < = > > X > > 2) Multi-metric based routing: assign different metrics for = > a specific = > > link (for example, one metric to reflect the bandwidth, one = > metric to = > > reflect the propagation delay, ...). > I agree with JPs taxonomy of routing types, and I believe = > that we need constraint-based routing. Multi-metric routing = > would be too complicated for a simple network. > If there are no objections on the ML, we'll revert back to = > the term "constraint-based routing" instead of "metric-based routing". > = > > 17) > > " The routing protocol SHOULD make use of the fact that if = > not being = > > able to deliver a packet, it is most likely that the sending node = > > moved; rather than the rest of the network." > > You may want to be more explicit on what this actually translate to = > > for the routing protocol. > A non-responsive node can either be caused by 1) a failure in = > the node, 2) a failed link on the path to the node or 3) a = > moved node. In the first two cases, the node can be expected = > to reappear at roughly the same location in the network, = > whereas it can return anywhere in the network in the latter = > case. The search strategy in the routing protocol will behave = > differently depending on this expectation. > = > > 18) Section 4.7. Please expand PAN when first used. > OK > = > > 19) " home PAN MUST provide a set of features including 0 = > > configuration of the routing protocol for a new node to be added to = > > the network. " > > Do you really mean "0 configuration" ?? What about optional = > > configuration of timers ? > We mean zero configuration, as defined by Giorgio: > " From ROLL perspective, zero-configuration means only and = > above all, that a node can obtain an address and join the = > network on its own, without human intervention." > I propose to add this definition and keep the 0 configuration = > requirement. > = > > 20) " Furthermore, a failing node MUST NOT have a global = > impact on the = > > routing protocol. " > > This is a very strong requirement ... Are you sure that = > this is what = > > you mean? I feel more comfortable about your second > Agreed. I propose to delete the first requirement and make = > the second a MUST: > "The routing protocol MUST support the ability to isolate a = > misbehaving node thus preserving the correct operation the = > overall network." > Giorgio has a very good comment on the unspecified impact of = > a central controller failing. This case is important for = > sure, but not all ROLL networks need to have a central = > controller, so I would propose to avoid discussing it here. > = > > 21) It would be nice if you could elaborate a little bit on the = > > traffic pattern for the various use cases since health = > monitoring and = > > alarm significantly differs on that aspect. > > Please provide some number of packet sizes, frequency at = > which packets = > > are sent out, ... > I'll add some numbers for the home appliance remote control = > and motion sensor cases. Perhaps Giorgio could add some data = > on a healthcare scenario? > = > > 22) Could you flesh out the security requirements ? > This is still not clear from our side either. I'll add some = > general guidelines, though. > = > > 23) Acknolegment: list of people (if any) that you want to = > thank for = > > their contribution/feed-backs/... > Good idea. > = > > 24) Remove [I-D.culler-roll-routing-reqs] as informative reference. > > > OK. > = > = > > Thanks. > > > > JP. > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > = > -- > Jakob Buron > Software Engineer > Zensys A/S > Emdrupvej 26 > DK-2100 Copenhagen O > Phone : +45 39130043 > www.zen-sys.com > = > = > ------------------------------ > = > Message: 2 > Date: Mon, 23 Jun 2008 13:18:59 +0200 > From: JP Vasseur > Subject: [Roll] ROLL WG Agenda > To: > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" > = > Dear WG, > = > The ROLL WG will meet in Dublin. The provisional agenda is: > = > MONDAY, July 28, 2008 > 0800-1800 IETF Registration - Convention Lobby 0800-0900 = > Beverages - Convention Lobby > = > 1130-1300 Break > 1300-1500 Afternoon Session I > Convention 1 INT l3vpn Layer 3 Virtual Private Networks WG > Ballroom 2 INT csi Cga & Send maIntenance WG > Conservatory IRTF hiprg Host Identity Protocol > Newcastle OPS dime Diameter Maintenance and Extensions WG > Convention 3 RAI speermint Session PEERing for Multimedia > INTerconnect WG > Newcastle RTG roll Routing Over Low power and Lossy = > networks WG > Conservatory SEC krb-wg Kerberos WG > Ballroom 1 SEC dkim Domain Keys Identified Mail WG > Rathcoole TSV dccp Datagram Congestion Control Protocol WG > = > If you need a slot, please let us know. > = > JP. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: = > d51/attachment-0001.htm> > = > ------------------------------ > = > Message: 3 > Date: Tue, 24 Jun 2008 01:22:10 +0900 > From: Ryuji Wakikawa > Subject: Re: [Roll] ROLL WG Agenda > To: JP Vasseur > Cc: roll@ietf.org > Message-ID: <71C87420-99ED-4255-A045-94E1B483F9BF@gmail.com> > Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed; delsp=3Dyes > = > Hi JP, > = > We want 15min slot for "In-Vehicle Routing Requirements". > http://tools.ietf.org/html/draft-wakikawa-roll-invehicle-reqs-00 > = > thanks > ryuji > = > On 2008/06/23, at 20:18, JP Vasseur wrote: > = > > Dear WG, > > > > The ROLL WG will meet in Dublin. The provisional agenda is: > > > > MONDAY, July 28, 2008 > > 0800-1800 IETF Registration - Convention Lobby 0800-0900 = > Beverages - = > > Convention Lobby > > > > 1130-1300 Break > > 1300-1500 Afternoon Session I > > Convention 1 INT l3vpn Layer 3 Virtual Private Networks WG > > Ballroom 2 INT csi Cga & Send maIntenance WG > > Conservatory IRTF hiprg Host Identity Protocol > > Newcastle OPS dime Diameter Maintenance and Extensions WG > > Convention 3 RAI speermint Session PEERing for Multimedia > > INTerconnect WG > > Newcastle RTG roll Routing Over Low power and Lossy > > networks WG > > Conservatory SEC krb-wg Kerberos WG > > Ballroom 1 SEC dkim Domain Keys Identified Mail WG > > Rathcoole TSV dccp Datagram Congestion Control Protocol WG > > > > If you need a slot, please let us know. > > > > JP. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > = > = > = > ------------------------------ > = > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = > = > End of Roll Digest, Vol 5, Issue 14 > *********************************** > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > = _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From roll-bounces@ietf.org Fri Jun 27 04:55:01 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2461028C182; Fri, 27 Jun 2008 04:55:01 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E67E3A6ABB for ; Fri, 27 Jun 2008 04:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.052 X-Spam-Level: X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwajtE7xUEeE for ; Fri, 27 Jun 2008 04:54:58 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7EDC628C182 for ; Fri, 27 Jun 2008 04:54:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,715,1204520400"; d="scan'208,217";a="12435219" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 27 Jun 2008 07:55:02 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5RBt1P2009771 for ; Fri, 27 Jun 2008 07:55:01 -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.13.8/8.13.8) with ESMTP id m5RBt1FM001283 for ; Fri, 27 Jun 2008 11:55:01 GMT Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 07:55:01 -0400 Received: from 10.21.78.247 ([10.21.78.247]) by xmb-rtp-213.amer.cisco.com ([64.102.31.112]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Jun 2008 11:55:01 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Fri, 27 Jun 2008 13:55:00 +0200 From: JP Vasseur To: Message-ID: Thread-Topic: Provisional Agenda Thread-Index: AcjYTKBiNeqiKr4Ry0eoHVOgpZBcPw== Mime-version: 1.0 X-OriginalArrivalTime: 27 Jun 2008 11:55:01.0756 (UTC) FILETIME=[A16EB3C0:01C8D84C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1018; t=1214567701; x=1215431701; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jvasseur@cisco.com; z=From:=20JP=20Vasseur=20 |Subject:=20Provisional=20Agenda |Sender:=20 |To:=20; bh=D6BF1bQ8zFcXjeOahbte0hFzCTyCpNDjhWwhLRoGs1k=; b=mETyQPY3bO0rUPLmzBwZOrK7y43c+TJEljRlGfzDed8DVppYJSWoLJLlly SOn70DtNbTV8jV39TetqmFOmitYmMOVDecpJ1pncOtDokY8PgS8Fznhb8tTa LzOUlybaMx; Authentication-Results: rtp-dkim-1; header.From=jvasseur@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: [Roll] Provisional Agenda X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0289398315==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0289398315== Content-type: multipart/alternative; boundary="B_3297419701_13449828" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3297419701_13449828 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear WG, Please find the ROLL WG provisional agenda: http://www.ietf.org/proceedings/08jul/agenda/roll.txt Let me know if you have any comment or other request. Thanks. JP. --B_3297419701_13449828 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Provisional Agenda Dear WG,

Please find the ROLL WG provisional agenda: http://www.ietf.org/proceedings/08jul/agend= a/roll.txt

Let me know if you have any comment or other request.

Thanks.

JP. --B_3297419701_13449828-- --===============0289398315== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0289398315==-- From roll-bounces@ietf.org Fri Jun 27 08:12:51 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862FC3A6AC8; Fri, 27 Jun 2008 08:12:51 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF8C3A6AC8 for ; Fri, 27 Jun 2008 08:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH-KCR+tc-fG for ; Fri, 27 Jun 2008 08:12:49 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by core3.amsl.com (Postfix) with ESMTP id D86D93A68E8 for ; Fri, 27 Jun 2008 08:12:45 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX01.eud.schneider-electric.com with ESMTP id 2008062717124875-41311 ; Fri, 27 Jun 2008 17:12:48 +0200 From: nicolas.riou@fr.schneider-electric.com To: roll@ietf.org Message-ID: Date: Fri, 27 Jun 2008 17:12:40 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 27/06/2008 17:12:47, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 06/27/2008 05:12:48 PM, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 06/27/2008 05:12:56 PM, Serialize complete at 06/27/2008 05:12:56 PM Subject: [Roll] Out of the office auto reply X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0834478650==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============0834478650== Content-type: multipart/alternative; Boundary="0__=4EBBFEE6DFC009918f9e8a93df938690918c4EBBFEE6DFC00991" Content-Disposition: inline --0__=4EBBFEE6DFC009918f9e8a93df938690918c4EBBFEE6DFC00991 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Je serai absent(e) =E0 partir du 27/06/2008 de retour le 05/07/2008. I am on business trip until July 5th with limited access to my e-mails.= For urgent matters, please contact Jean-Pierre Desbenoit.= --0__=4EBBFEE6DFC009918f9e8a93df938690918c4EBBFEE6DFC00991 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Je serai absent(e) =E0 partir du 27/06/2008 de retour le 05/07/200= 8.

I am on business trip until July 5th with limited access to my e-mails.= For urgent matters, please contact Jean-Pierre Desbenoit.= --0__=4EBBFEE6DFC009918f9e8a93df938690918c4EBBFEE6DFC00991-- --===============0834478650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============0834478650==-- From roll-bounces@ietf.org Fri Jun 27 14:12:40 2008 Return-Path: X-Original-To: roll-archive@ietf.org Delivered-To: ietfarch-roll-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3490D3A6B63; Fri, 27 Jun 2008 14:12:40 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271B03A6921 for ; Fri, 27 Jun 2008 14:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH6XUZY4benw for ; Fri, 27 Jun 2008 14:12:38 -0700 (PDT) Received: from mailX01.eud.schneider-electric.com (mailx01.eud.schneider-electric.com [205.167.7.35]) by core3.amsl.com (Postfix) with ESMTP id 5B6EB3A6A5F for ; Fri, 27 Jun 2008 14:12:33 -0700 (PDT) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX01.eud.schneider-electric.com with ESMTP id 2008062723123762-43871 ; Fri, 27 Jun 2008 23:12:37 +0200 From: nicolas.riou@fr.schneider-electric.com To: roll@ietf.org Message-ID: Date: Fri, 27 Jun 2008 23:12:32 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 27/06/2008 23:12:38, Itemize by SMTP Server on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 06/27/2008 11:12:37 PM, Serialize by Router on AXEU1OUT.schneider-electric.com/X/SVR/SEIxtra at 06/27/2008 11:12:43 PM, Serialize complete at 06/27/2008 11:12:43 PM Subject: [Roll] Out of the office auto reply X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2016839880==" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org --===============2016839880== Content-type: multipart/alternative; Boundary="0__=4EBBFEE6DFE707858f9e8a93df938690918c4EBBFEE6DFE70785" Content-Disposition: inline --0__=4EBBFEE6DFE707858f9e8a93df938690918c4EBBFEE6DFE70785 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=ISO-8859-1 Je serai absent(e) =E0 partir du 27/06/2008 de retour le 05/07/2008. I am on business trip until July 5th with limited access to my e-mails.= For urgent matters, please contact Jean-Pierre Desbenoit.= --0__=4EBBFEE6DFE707858f9e8a93df938690918c4EBBFEE6DFE70785 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline

Je serai absent(e) =E0 partir du 27/06/2008 de retour le 05/07/200= 8.

I am on business trip until July 5th with limited access to my e-mails.= For urgent matters, please contact Jean-Pierre Desbenoit.= --0__=4EBBFEE6DFE707858f9e8a93df938690918c4EBBFEE6DFE70785-- --===============2016839880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --===============2016839880==--