From dromasca@avaya.com Sun Nov 1 01:51:22 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8E93A683E for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 01:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.163, 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 aspYON2t6ypz for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 01:51:21 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 794003A683A for <6lowapp@ietf.org>; Sun, 1 Nov 2009 01:51:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,661,1249272000"; d="scan'208";a="188791785" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Nov 2009 03:51:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Nov 2009 03:51:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Nov 2009 09:50:54 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Architecture Sketch in Charter Thread-Index: AcpaUXtuZ4UwOgsCQDaetxlZcNN6twAfRjoA References: From: "Romascanu, Dan (Dan)" To: "Cullen Jennings" , <6lowapp@ietf.org> Subject: Re: [6lowapp] Architecture Sketch in Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 08:51:22 -0000 =20 > -----Original Message----- > From: 6lowapp-bounces@ietf.org=20 > [mailto:6lowapp-bounces@ietf.org] On Behalf Of Cullen Jennings >=20 > 4) The OAM folks must be thinking, so how is this different=20 > from what we do every single day? >=20 I prefer the term 'OPS folks' :-) OAM is just one of the tools in our kit.=20 This is not completely new stuff for OPS. Actually we have already seen similar work done in other SDOs for various 'low-xxx' devices attached to networks. The typical challenges are the low resources on the device, the mapping and sometimes optimization of protocols on specific transports and the security model which usually offers less at the lower level than management or OAM protocols are used to. Solutions exist and they are not rocket science, but it is important to think about the operational model and about the way the network will be managed from the start. When operational and manageability aspects are left for a later stage there is always the risk that the management solution will be to expensive to implement and deploy, and this will impact interoperability and scalability of the overall technology. From this point of view I am concerned to see the item 'Mar 2012 - Ops & Management advice to IESG as Info' showing up almost two years later than the architecture requirements in the charter proposal. I think this item should be synchronized or come just a short delay after the core protocol requirements in the proposed WG scheduled.=20 From zach@sensinode.com Sun Nov 1 05:47:25 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 083EA3A67D8 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 05:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 2Wkx4qOh0apa for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 05:47:23 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 58E5D3A6358 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 05:47:21 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA1DlCcX032551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Nov 2009 15:47:13 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: Date: Sun, 1 Nov 2009 15:47:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8776E235-5C34-4CAB-B0FC-1C27AAC12C52@sensinode.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> To: Cullen Jennings X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 13:47:25 -0000 Hi Folks, Murphy's law of mailing lists - you always miss the 100 post thread =20 when off-line for a few days ;-) Great to see the list discussions! =20 Here are my summarized thoughts after reading the recent threads: * WG name I agree this WG should *not* be called 6lowapp - that was just a name =20= we made to get this interest group started... This is not IPv6 =20 specific, nor is it LoWPAN specific. I think we should call the WG the =20= same as the protocol/framework. In this case CoAP. Although I liked =20 LoAP better. And just think... LOw-power Application Framework =3D =20 LoAF ;-) * Architecture: Cullen and Lisa summarized this perfectly. We need a basic =20 architectural principle built into this charter. I do agree the =20 charter shouldn't go into too much detail. Cullen's proposal is really =20= only (trying to) say this about architecture: 1) This is a resource framework 2) This framework integrates a profile discovery mechanism 2) Integration with the HTTP web is a must 3) A proxy solution is used for integration with HTTP, caching etc. =20 along with other protocol translations. This is optional, and can be =20 located anywhere on the Internet. Some others may be defined in this =20 charter, or in future re-chartering. 4) Application layer security is an integral part of the framework In my opinion these basic architectural assumptions are a great start =20= for the requirements and applications are focusing on. I think we =20 should be more explicit that CoAP is part of the Internet web =20 architecture, and we are not inventing a completely new model. A proxy =20= is by no means required, it is just a means to integrate with HTTP, =20 perform caching, improve security etc. The scope of CoAP is by no means just a LoWPAN. The framework may be =20 used over an entire building network, parts of the smart grid, in =20 manufacturing facilities, across cellular networks etc. Proxies may be =20= located just about anywhere. So yes, we need to take the wider =20 Internet into account although CoAP will mainly be used in the =20 constrained network domain. We should also be specific that CoAP can =20 be used between devices directly, and doesn't require an infrastructure. Finally, I agree with Cullen that the REST paradigm is sufficient for =20= providing both simple variable manipulation, full resource =20 manipulation, and also RPC can of course be built on-top of REST just =20= as it can be with e.g. WS or XMPP today. I would say we should =20 explicitly target the REST model for the CoAP framework as well as it =20= is a good middle-ground. * Requirements vs. Objectives: I am in-line with Carsten and Jonathan that we need to call these =20 objectives and avoid the endless requirement trap. In addition to the =20= requirement drafts submitted to 6lowapp, and use cases available =20 elsewhere, I especially find the use cases produced in the ROLL WG =20 something we can also pull application requirements out of. * Proxy vs. Gateway: In my opinion we should definitely call this a proxy. The entity is =20 optional, basic features can be considered proxy features, even CoAP-=20 HTTP integration. Jonathan pointed out that you may also implement =20 Gateway type features. I agree, but those can be built on-top. =20 Features which are application specific (like aggregation) should be =20 out of scope I agree. CoAP would not require a gateway by any means - =20= we don't want to give that impression. Now on the question if you need a proxy? Yes, often you will need a =20 proxy but it should not be required. Proxies are a normal piece of the =20= web architecture. Just as with an HTTP proxy, a CoAP proxy could be =20 located anywhere so it doesn't necessarily add cost to the Smart =20 Energy HAN, but more likely is just a feature on some router/server. * Security It is important that we build application layer security into this =20 framework. Although some wireless mesh L2 technology has built-in =20 security such as AES in IEEE 802.15.4, that doesn't provide end-to-end =20= security, nor security outside that link. Obviously security is =20 optional, just as with HTTP today. * HTTP There has been talk about using "optimized HTTP", "constrained HTTP", =20= "compressed HTTP" on the list as a solution for this. The problem is, =20= after making those optimizations, it is no longer HTTP. Web-servers =20 speak HTTP/1.0 or HTTP/1.1 and will not be compatible both ways. The =20 same goes for the security features. You might as well call such a =20 thing Chopan, CoAP or whatever. Optimized HTTP would also need to be =20 proxied, just as in the proposed CoAP architecture. As pointed out by =20= several, even this kind of HTTP optimization may work for some =20 applications, but surely not all. HTTP is also bound to TCP with no =20 multicast support. The interaction model doesn't cover the =20 requirements seen. So we are back to what the charter says, we need a =20= protocol to achieve the objectives for applications over constrained =20 networks. The solution would surely will use parts of HTTP as a design =20= reference as seen in frank-6lowapp-chopan, and input from many other =20 protocols. Text vs. binary is just a design consideration... * TCP Don pointed out the low-power wireless mesh packet loss problems. In =20 addition I have big problems with TCP breaking from mobility (in e.g. =20= building asset management with LoWPANs, the IP address may change =20 often) and no multicast support. In M2M, the packet exchanges are =20 often very short (sometimes just one small payload), the TCP =20 connection model just doesn't make sense there. That said, I think we =20= should allow TCP to be used with CoAP, and I encourage future work on =20= reliable transport improvements. * Charter proposal So down to the text below. Again a great start. I think it needs to be =20= more specific on applications, use cases and the architecture. In =20 other places it is way too specific for example talking about sensors =20= and actuators - where in practice we are working with general embedded =20= devices. With a couple good editing rounds and taking list comments =20 into account, this is going to be good to go into the BOF with. Zach On Oct 29, 2009, at 8:42 , Cullen Jennings wrote: > > I've been talking to various folks about the how quickly they would =20= > like to get initial standards on this topic complete. To move =20 > quickly, I think we need an initial charter that is extremely =20 > focused and makes it clear what we are going to go do. After we meat =20= > the initial goals of the WG, we could expand the WG to explore into =20= > more area and extend the protocols to do more. I bounced some ideas =20= > around with Zack, Carsten, and Don and have put an initial draft of =20= > what I think of as a focused charter might look like below. > > It's just a straw man and it has some problems in it. I've been =20 > trying to merge all the various things different people have told me =20= > and organize them. I'm not promoting that I think this is the best =20 > plan - it just a plan that we can use as a baseline to talk about =20 > what we really want to do as group and if this charter reflects that =20= > or not. > > Please, read it. Think about, if the WG did this, could you live =20 > with that. If No, why and what requirements do you have this does =20 > not meet. If you could live with it but some changes would make it =20 > better, what are they. > > Thanks, Cullen > > ---------------------------------------- > > > > Applications are being developed for networks that have very limed =20 > packets sizes, have high degree of packet loss, and where a =20 > substantial number of devices that may be powered of at any point in =20= > time but periodically "wake up" for beef periods of time. These =20 > Networks are referred to as Constrained Networks (CNEets). Low-Power =20= > Wireless Personal Area Networks (LoWPANs) are an example of this =20 > type of network. These networks are becoming increasing important =20 > for applications such as home automation, energy management, and the =20= > Internet of Things. This working group will define a framework a =20 > limited class of applications that deal with manipulation of simple =20= > resources on devices on a CNet. This includes applications to =20 > monitor simple sensors such as a temperature gauge, light switch, or =20= > power meter and control an actuator such as a light switch, heating =20= > system, or door lock. Typical uses include power management and =20 > reporting, and home automation. > > The general architecture consists of nodes on the CNet, called =20 > Devices, that have one or more Resources that represent sensors and =20= > actuators. Devices send message to change and query resources on =20 > other devices. Devices can send notifications about changed resource =20= > values to subscribed Devices. In other words, the architecture =20 > requires push, pull and and a notify approach to manipulating =20 > resources. As part of the framework for building these applications, =20= > the WG will define a CNet Application Protocol (CoAP) for =20 > manipulation or Resources on Devices. The framework will also =20 > specify a way to define new interface profiles that can be defined =20 > by vendors and other standards bodies to define the particular =20 > Resources on a Device and what manipulation are possible. > > There are also nodes called PEPs (Performance Enhancing Proxy) that =20= > gateway between the protocols typically used by the applications on =20= > the Internet and the protocol used on the CNet. An application on =20 > the general network can use HTTP REST to communicate with the PEP =20 > which will use CoAP to manipulate the Resource on the Device. The WG =20= > will define a mapping on the PEP from the CoAP to the a HTTP REST =20 > API. Each interface profile will define the Resources on the device =20= > that application can manipulate and what manipulations are =20 > possible. This will determine the HTTP REST APIs on the PEPs and =20 > the CoAP protocol encoding to manipulate the Resources on the Device =20= > it will also specify an XML MINE type for each class of Device that =20= > can be used to described the Resource state in the the body of HTTP =20= > REST messages. The WG may also work on a mapping to SNMP on the PEP. =20= > It is worth noting that the PEP does not have to be deployed at the =20= > boundary of the CNet and the more general network but can be =20 > deployed at various location in the network. > > The PEP boxes can provide various forms of "caching". For example, =20 > if a temperature sensor is normally asleep but wakes up every five =20 > minutes and sends the current temperature to the a PEP that =20 > subscribed, when the PEP receives a request over HTTP for that =20 > temperature resource, it can respond with the last seen value =20 > instead of trying to query the Device which is currently asleep. The =20= > PEPs may also provide support for discovering devices that may not =20 > be currently responding as they are temporarily asleep. > > The initial work item of the WG are to define: > > 1) A requirements and architecture document that documents the high =20= > level boxes and arrows view of the protocol along with high level =20 > description of how the security, particular for commissioning of new =20= > devices into the network will work. The WG may also produce a =20 > document that describes various uses cases that help motivate the =20 > requirements. > > 2) Specification of the framework for defining interface profiles =20 > and the defining the CoAP. The CoAP will be able to set and query a =20= > resource on a Device. It will allow a device to publish a value or =20 > event to another Device. It will support a non-reliable multicast =20 > message to be sent to a group of devices to manipulate a resource on =20= > all the devices simultaneously (roughly within 50 ms of each other). =20= > The protocol will operate over UDP assuming a TBD byte payload and =20 > assume an underlying network bandwidth of approximately TBD kbps. =20 > The payload will be based on interface profile specific XML document =20= > compressed with EXI. > > 3) Specification on how to use the CoAP to discover Devices on the =20 > LoPAN and to interrogate them to find out which interface profiles =20 > they support. > > 4) Specification for the HTTP REST based API on the PEP to =20 > communicate with Devices. > > 4a) Possibly specify a separate specifications with mappings to =20 > SNMP. [[NOte: In the BOF it would be nice to figure out if this is =20 > in the charter or not.]] > > 5) A small set of basic interface profiles to illustrate how this is =20= > done. Interface profiles will be done for a power meter, a light and =20= > light switch, and temperature sensor. > > 6) A document with operation and management advice about running a =20 > network using these applications. > > Security, particularly keying of new Devices, is very challenging =20 > for these applications. On one hand this needs to support models =20 > where an end user can introduce a new device onto their network that =20= > may have no display or not input capability's. On the other end this =20= > may transport information about alarm systems or controlling door =20 > locks to a building over a wireless network. > > The CoAP protocol will support three commissioning methodologies. > > 1) Duckling mode. One device is put in a "mother duck" mode where it =20= > listens for broadcasts of Devices trying to imprint. Other Devices =20 > are put in a "duckling" mode where they broad cast to the "mother =20 > duck" Device then "imprint" by forming a new shared secret between =20 > the two Devices. Once this is complete the devices are taken out of =20= > this mode and can be use in a secure fashion. > > 2) Out of Band Key mode. Each device in manufactured with an initial =20= > symmetric key physically printed on the side in numeric and barcode =20= > form. Alternatively the device could have a barcode that forms a URL =20= > which when dereferenced with appropriate authorization provides a =20 > secure access to the key. A human can enter or scan this into a =20 > computer that can then be used form a secure connection with the =20 > Device. Once a secure connection is formed, the symmetric key can be =20= > changed. > > 3) Certificate mode. Each device is manufactured with a certificate =20= > with an asymmetric key. The fingerprint of the certificate is =20 > printed on a barcode. During commissioning, a computer can scan the =20= > barcode, the connect to the device and replace the certificate with =20= > a locally generated certificate that can be used for forming secure =20= > connections. > > Modes 1 and 2 are mandatory to implement but mode 3 is option. In =20 > all modes, once Device A and Device B have formed a secure =20 > connection with Device C, Device C can be used to transitively =20 > introduce A and B so now A and B have a secure connection with C. =20 > This transitive trust introduction can be used during commissioning =20= > even if A and B do not yet have network connectivity to each other. > > The CoAP will use CMS for object security. The WG will request the =20 > security area define a subset of CMS along with an EXI encoding =20 > instead of ASN.1 that is appropriate for a CNet network and for =20 > theses types of devices. It will have one mandatory to implement =20 > crytpo profile with no public key cryptograph to support modes 1 and =20= > 2 and additional crypto profile with public key cryptograph for =20 > support of mode 3. In mode 3, it will (or will not TBD) require =20 > support for Elliptical Curve Cryptograph (ECC). > > The WG will coordinate on requirements from TBD (other SDO and =20 > organizations). The WG will closing coordinate with other IETF WGs =20 > including ROLL 6LowPAN and appropriate groups in OAM and Security. > > Milestone: > > Jan 2010 - Select WG document for basis of CoAP protocol > > Jun 2010 - Requirements and Architecture to IESG as Info > > Dec 2010 - Core protocol specification to IESG as PS > > Dec 2010 - HTTP Rest API mapping to IESG as PS > > Mar 2011 - Discovery specification to IESG as PS > > Mar 2011 - Specifications of basic interface profiles to IESG as PS > > Mar 2012 - Ops & Management advice to IESG as Info > > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From zach@sensinode.com Sun Nov 1 05:51:42 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 007933A681C for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 05:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 O74ffGzykNFh for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 05:51:40 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 8475F3A67D8 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 05:51:40 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA1Dpsbk000327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Nov 2009 15:51:55 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <006c01ca5a88$6600eff0$3202cfd0$@sturek@att.net> Date: Sun, 1 Nov 2009 15:52:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <10FFF676-827B-4FBF-9814-C71ED48FE723@sensinode.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <4AE9A4C8.4030402@tkk.fi> <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> <006c01ca5a88$6600eff0$3202cfd0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 13:51:42 -0000 On Nov 1, 2009, at 2:15 , Don Sturek wrote: > Hi Cullen, > > One important use case to consider: > 1) Devices to manage are running on 6LowPAN (using some 6LowAPP =20 > defined > protocol). Controlling devices are running someplace on the wider > internet. This is common in building management and most M2M applications as well. > 2) Does this mean that the scope of protocol work in 6LowAPP needs to > identify this type of control as a valid use case? Definitely! However we don't need to require the controlling device to =20= speak CoAP (although it could). More likely there is a proxy somewhere =20= between. > 3) Does the use of 6LowAPP protocols on the wider internet need to =20= > then be > in the scope of 6LowAPP? Yes. This is IP, so the CoAP protocol can be used over any IP =20 networks. If you need a proxy, it can be located anywhere. We should =20 assume that CoAP will mainly be used in the constrained or application-=20= specific domain. Zach > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On =20= > Behalf > Of Cullen Jennings > Sent: Saturday, October 31, 2009 10:29 AM > To: Jukka Manner > Cc: Don Sturek; 6lowapp@ietf.org > Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > > On Oct 29, 2009, at 8:20 , Jukka Manner wrote: > >> 1. This seems to indicate that 6lowapp will not be tied to any >> existing work, it will work on its own goals, but in collaboration >> with others (which is somewhat open as what it means). I would have >> expected that 6lowapp would specifically look at existing work in >> related WGs and see how build on top of that. > > My mistake - I did not mean to imply that it was not layered on top of > closely related existing work. I think most people assumed that this > would run on top of a LoPAN but it seemed they also wanted it to be > able to run on top of a other things including a normal IP LAN and > WAN. Clearly this is all about same use cases as 6LoPAN and ties > closing with 6LoPAN and ROLL as well as work going on at many other > SDOs. However, I'm not sure what needs to be said. Are WG drafts with > use case / requirements from other WG that we should be referencing? > Give me ideas on what things you were thinking here. Clearly the IESG > would not be keen on chartering a new WG to do something another WG > was already charted to do - repeating work in two places seldom ends > well :-) Can you suggest some specific text for the charter that you > think would have fairly wide consent and captures what you are looking > for here? > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From d.sturek@att.net Sun Nov 1 05:54:57 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 104A93A689F for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 05:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 whzAX8n1rnoD for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 05:54:56 -0800 (PST) Received: from n12.bullet.mail.mud.yahoo.com (n12.bullet.mail.mud.yahoo.com [209.191.125.209]) by core3.amsl.com (Postfix) with SMTP id E936F3A67D8 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 05:54:55 -0800 (PST) Received: from [68.142.194.244] by n12.bullet.mail.mud.yahoo.com with NNFMP; 01 Nov 2009 13:55:13 -0000 Received: from [68.142.201.254] by t2.bullet.mud.yahoo.com with NNFMP; 01 Nov 2009 13:55:13 -0000 Received: from [127.0.0.1] by omp415.mail.mud.yahoo.com with NNFMP; 01 Nov 2009 13:55:13 -0000 X-Yahoo-Newman-Id: 5456.23457.bm@omp415.mail.mud.yahoo.com Received: (qmail 65849 invoked from network); 1 Nov 2009 13:55:12 -0000 Received: from adsl-69-225-120-101.dsl.sndg02.pacbell.net (d.sturek@69.225.120.101 with login) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 01 Nov 2009 05:55:12 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: upA.h88VM1n7pqGD2HjlSmo7XjMpZQ6VsblOBK0K5VLeDLskwc0V9DvseYcP3V7QAqtLEVufkvPFBnksKP24ZNpCSKAyM6m0vrf1S1EYEDDtQgUwBLQkjNc5VgiCX.BZ5trcojm3hDAlg_bv1zdmJKaiSNRQCdO65OPc0AQ8tbw8k6HBo4bltCq.TcwWQoJ4J8m1Rgf8T6K4LrbsGsPrT1Gm3CDuDAUVuSXC08JnASomzg8kJFfzoZyq4QFefP1Om0kNjqe28NKnwLq3MgitMAnGE5e.HBO1lrhPB_nggv4MGHg.AJJ10yRZ1KOUqn4JI4bV5zwISFYM8chm9MLXjVxNFnI0c70vanBenjGHG8ypsg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <4AE9A4C8.4030402@tkk.fi> <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> <006c01ca5a88$6600eff0$3202cfd0$@sturek@att.net> <10FFF676-827B-4FBF-9814-C71ED48FE723@sensinode.com> In-Reply-To: <10FFF676-827B-4FBF-9814-C71ED48FE723@sensinode.com> Date: Sun, 1 Nov 2009 05:55:10 -0800 Message-ID: <000801ca5afa$eddd2f20$c9978d60$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpa+nqtvhGHG8k4SBKIBy2NttlKTwAACDvQ Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 13:54:57 -0000 Hi Zach, I am still hoping we don't have a proxy (or gateway). Ideally, we can define at least an application transport protocol that can work natively in CoAp and be mainstream enough to be supported in the wider internet. As soon as we say there is a proxy or gateway required, we will get pushback from device manufacturers who don't want the added cost on their devices. Don -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Sunday, November 01, 2009 5:52 AM To: d.sturek@att.net Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF On Nov 1, 2009, at 2:15 , Don Sturek wrote: > Hi Cullen, > > One important use case to consider: > 1) Devices to manage are running on 6LowPAN (using some 6LowAPP > defined > protocol). Controlling devices are running someplace on the wider > internet. This is common in building management and most M2M applications as well. > 2) Does this mean that the scope of protocol work in 6LowAPP needs to > identify this type of control as a valid use case? Definitely! However we don't need to require the controlling device to speak CoAP (although it could). More likely there is a proxy somewhere between. > 3) Does the use of 6LowAPP protocols on the wider internet need to > then be > in the scope of 6LowAPP? Yes. This is IP, so the CoAP protocol can be used over any IP networks. If you need a proxy, it can be located anywhere. We should assume that CoAP will mainly be used in the constrained or application- specific domain. Zach > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf > Of Cullen Jennings > Sent: Saturday, October 31, 2009 10:29 AM > To: Jukka Manner > Cc: Don Sturek; 6lowapp@ietf.org > Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > > On Oct 29, 2009, at 8:20 , Jukka Manner wrote: > >> 1. This seems to indicate that 6lowapp will not be tied to any >> existing work, it will work on its own goals, but in collaboration >> with others (which is somewhat open as what it means). I would have >> expected that 6lowapp would specifically look at existing work in >> related WGs and see how build on top of that. > > My mistake - I did not mean to imply that it was not layered on top of > closely related existing work. I think most people assumed that this > would run on top of a LoPAN but it seemed they also wanted it to be > able to run on top of a other things including a normal IP LAN and > WAN. Clearly this is all about same use cases as 6LoPAN and ties > closing with 6LoPAN and ROLL as well as work going on at many other > SDOs. However, I'm not sure what needs to be said. Are WG drafts with > use case / requirements from other WG that we should be referencing? > Give me ideas on what things you were thinking here. Clearly the IESG > would not be keen on chartering a new WG to do something another WG > was already charted to do - repeating work in two places seldom ends > well :-) Can you suggest some specific text for the charter that you > think would have fairly wide consent and captures what you are looking > for here? > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From zach@sensinode.com Sun Nov 1 07:12:12 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E77F3A67F0 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 07:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8EqcN8lVs+Hc for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 07:12:11 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 199533A63D3 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 07:12:10 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA1FCLQb001711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Nov 2009 17:12:21 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <000801ca5afa$eddd2f20$c9978d60$@sturek@att.net> Date: Sun, 1 Nov 2009 17:12:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9175C900-B7C9-46B5-B85C-FB9F15ADBCFA@sensinode.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <4AE9A4C8.4030402@tkk.fi> <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> <006c01ca5a88$6600eff0$3202cfd0$@sturek@att.net> <10FFF676-827B-4FBF-9814-C71ED48FE723@sensinode.com> <000801ca5afa$eddd2f20$c9978d60$@sturek@att.net> To: X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 15:12:12 -0000 Hi, On Nov 1, 2009, at 15:55 , Don Sturek wrote: > Hi Zach, > > I am still hoping we don't have a proxy (or gateway). Ideally, we can > define at least an application transport protocol that can work =20 > natively in > CoAp and be mainstream enough to be supported in the wider internet. > I think we agree. The CoAP protocol (whatever it will be) could =20 definitely be used on the wider Internet. If your controlling device/=20 server speaks CoAP, then voi la. If we do our job well, and this =20 becomes standard for M2M use, then you will easily find CoAP support. > As soon as we say there is a proxy or gateway required, we will get =20= > pushback > from device manufacturers who don't want the added cost on their =20 > devices. This definitely should not require a proxy, but as pointed out in =20 other mails, there are reasons you may use proxy technology. Even if =20 you would implement this with plain HTTP/1.1 you would use a proxy in =20= most cases. But this isn't an issue for device manufacturers by any =20 means! As we are dealing with IP, a proxy may be located on the =20 backend network somewhere e.g. as a component on any application =20 server. On the flip-side, if we require embedded devices to speak directly =20 with unmodified HTTP/1.1 web servers, then we really will be adding =20 cost, if it even works at all. This is the situation today, and the =20 reason for so many proprietary protocol and field-bus solutions. It sounds like we basically agree here? Zach > > Don > > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: Sunday, November 01, 2009 5:52 AM > To: d.sturek@att.net > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > On Nov 1, 2009, at 2:15 , Don Sturek wrote: > >> Hi Cullen, >> >> One important use case to consider: >> 1) Devices to manage are running on 6LowPAN (using some 6LowAPP >> defined >> protocol). Controlling devices are running someplace on the wider >> internet. > > This is common in building management and most M2M applications as =20 > well. > >> 2) Does this mean that the scope of protocol work in 6LowAPP needs =20= >> to >> identify this type of control as a valid use case? > > Definitely! However we don't need to require the controlling device to > speak CoAP (although it could). More likely there is a proxy somewhere > between. > >> 3) Does the use of 6LowAPP protocols on the wider internet need to >> then be >> in the scope of 6LowAPP? > > Yes. This is IP, so the CoAP protocol can be used over any IP > networks. If you need a proxy, it can be located anywhere. We should > assume that CoAP will mainly be used in the constrained or =20 > application- > specific domain. > > Zach > >> >> Don >> >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> Behalf >> Of Cullen Jennings >> Sent: Saturday, October 31, 2009 10:29 AM >> To: Jukka Manner >> Cc: Don Sturek; 6lowapp@ietf.org >> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF >> >> >> On Oct 29, 2009, at 8:20 , Jukka Manner wrote: >> >>> 1. This seems to indicate that 6lowapp will not be tied to any >>> existing work, it will work on its own goals, but in collaboration >>> with others (which is somewhat open as what it means). I would have >>> expected that 6lowapp would specifically look at existing work in >>> related WGs and see how build on top of that. >> >> My mistake - I did not mean to imply that it was not layered on top =20= >> of >> closely related existing work. I think most people assumed that this >> would run on top of a LoPAN but it seemed they also wanted it to be >> able to run on top of a other things including a normal IP LAN and >> WAN. Clearly this is all about same use cases as 6LoPAN and ties >> closing with 6LoPAN and ROLL as well as work going on at many other >> SDOs. However, I'm not sure what needs to be said. Are WG drafts with >> use case / requirements from other WG that we should be referencing? >> Give me ideas on what things you were thinking here. Clearly the IESG >> would not be keen on chartering a new WG to do something another WG >> was already charted to do - repeating work in two places seldom ends >> well :-) Can you suggest some specific text for the charter that you >> think would have fairly wide consent and captures what you are =20 >> looking >> for here? >> >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system > without producing, distributing or retaining copies thereof. > > > > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From paduffy@cisco.com Sun Nov 1 09:22:53 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB3C3A68B4 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 09:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 glbkVaBnYhnt for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 09:22:52 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8F16F3A6896 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 09:22:52 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP9S7UpAZnwM/2dsb2JhbADCAIEaCAGVL4Q5BA X-IronPort-AV: E=Sophos;i="4.44,662,1249257600"; d="scan'208";a="65912267" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Nov 2009 17:23:11 +0000 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.14.3) with ESMTP id nA1HNBU0004974; Sun, 1 Nov 2009 17:23:11 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 12:23:11 -0500 Received: from [10.86.248.248] ([10.86.248.248]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 12:23:10 -0500 Message-ID: <4AEDC3FD.3040801@cisco.com> Date: Sun, 01 Nov 2009 12:23:09 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: d.sturek@att.net References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <005d01ca5a87$a4e004f0$eea00ed0$@sturek@att.net> In-Reply-To: <005d01ca5a87$a4e004f0$eea00ed0$@sturek@att.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2009 17:23:10.0594 (UTC) FILETIME=[FC21F620:01CA5B17] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 17:22:53 -0000 Hi Donn, > We welcome other suggestions like XMPP and SIP but we did look at those and > ruled them out for reasons like: > 1) Verboseness (using text string exchanges for devices with very small > transmit/receive packet sizes) > 2) Session management overhead > SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered intent. But XMPP gives me pause... - would not an EXI encoding go a long way to alleviate the verbosity issues? - RESTful HTTP is a fine choice, but there are requirements for more than just request/response messaging patterns in the Smart Grid HAN and NAN. XMPP would offer request/response (sensor reading), pub/sub (broadcast announcements), one way async (scheduled reads), presence for endpoint status, etc. - how is XMPP session management any more onerous that HTTP over TLS? This assuming of course that TCP is doable. Cheers > Don > > > > From trifa@inf.ethz.ch Sun Nov 1 09:29:34 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6545A3A6896 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 09:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 RfwXPK910UaN for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 09:29:33 -0800 (PST) Received: from gwse.ethz.ch (gwse.ethz.ch [129.132.178.238]) by core3.amsl.com (Postfix) with ESMTP id 582A93A687C for <6lowapp@ietf.org>; Sun, 1 Nov 2009 09:29:32 -0800 (PST) Received: from CAS02.d.ethz.ch (129.132.178.236) by gws01.d.ethz.ch (129.132.178.238) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 1 Nov 2009 18:29:51 +0100 Received: from 80-254-68-131.dynamic.monzoon.net (129.132.211.206) by mail.ethz.ch (129.132.178.227) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 1 Nov 2009 18:29:30 +0100 Message-ID: <923B3077-5FB0-4B8A-A83A-E76C51466ACE@inf.ethz.ch> From: Vlad Trifa To: In-Reply-To: <4AEDC3FD.3040801@cisco.com> Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (Apple Message framework v936) Date: Sun, 1 Nov 2009 18:29:22 +0100 References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <005d01ca5a87$a4e004f0$eea00ed0$@sturek@att.net> <4AEDC3FD.3040801@cisco.com> X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 17:29:34 -0000 Hello, I think for Web messaging there are very nice Web push patterns emerging (comet, pubsubhubbub, restms) that are worth considering. Sure, work is needed for reliability and security, but the entry barrier is much lower than xmpp, and its actually more suited for devices with similar features but less verbose which makes that solution appealing. I'm sending a paper to WWW about Web based messaging, hopefully I'll be able to share it with you soon (if I kick my butt enough to get back to work and finish it by tomorrow's deadline :) Vlad On Nov 1, 2009, at 6:23 PM, Paul Duffy wrote: > Hi Donn, > >> We welcome other suggestions like XMPP and SIP but we did look at >> those and >> ruled them out for reasons like: >> 1) Verboseness (using text string exchanges for devices with very >> small >> transmit/receive packet sizes) >> 2) Session management overhead >> > > > SIP in the Smart Grid HAN seems a fundamental misfit to SIPs > chartered intent. > > But XMPP gives me pause... > > - would not an EXI encoding go a long way to alleviate the verbosity > issues? > > - RESTful HTTP is a fine choice, but there are requirements for more > than just request/response messaging patterns in the Smart Grid HAN > and NAN. XMPP would offer request/response (sensor reading), pub/ > sub (broadcast announcements), one way async (scheduled reads), > presence for endpoint status, etc. > > - how is XMPP session management any more onerous that HTTP over > TLS? This assuming of course that TCP is doable. > > Cheers > > >> Don >> >> >> >> > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Sun Nov 1 09:50:42 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B49C93A6814 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 09:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.043 X-Spam-Level: X-Spam-Status: No, score=0.043 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 ABt8cIIhkfZh for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 09:50:42 -0800 (PST) Received: from smtp101.sbc.mail.gq1.yahoo.com (smtp101.sbc.mail.gq1.yahoo.com [67.195.15.60]) by core3.amsl.com (Postfix) with SMTP id 1180E3A67AB for <6lowapp@ietf.org>; Sun, 1 Nov 2009 09:50:42 -0800 (PST) Received: (qmail 32526 invoked from network); 1 Nov 2009 17:50:58 -0000 Received: from adsl-69-105-139-118.dsl.sndg02.pacbell.net (d.sturek@69.105.139.118 with login) by smtp101.sbc.mail.gq1.yahoo.com with SMTP; 01 Nov 2009 09:50:58 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: OHiyyGAVM1lXT1F7DAzjczz4b18I5OT6D3LYOJGyPWC.k5_RRyVCEMx1kjbtlQL2dmCMfwoabY.bRlJcGNwqX7JxxB4gaJYEZe9eka3g.770qFylXIu.vYym1H5us79ZlrOfOCJktmnS36Y56EMNac2b_tZMWAKEyqi.gdaGWRcmwd82x7cR7txIz.4mDj272RYIYCass9H7GnalO9devMaTGB8nYVOzRzwFSG385QAH8uyWtpTpB4jetuD0isn_Q5398zat_I.rCj2HSAQEKtzsb5esIb9ytOzb_yy_rrU2kxObVg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <005d01ca5a87$a4e004f0$eea00ed0$@sturek@att.net> <4AEDC3FD.3040801@cisco.com> In-Reply-To: <4AEDC3FD.3040801@cisco.com> Date: Sun, 1 Nov 2009 09:50:56 -0800 Message-ID: <001601ca5b1b$ddb917a0$992b46e0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpbF/xfIu8VcXawQK+VsXqpJxhDLQAA64iA Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 17:50:42 -0000 Hi Paul, Yes, XMPP would be quite interesting if the text exchange could be avoided. Can we add this possibility to our CoAp charter as a application transport possibility? Don -----Original Message----- From: Paul Duffy [mailto:paduffy@cisco.com] Sent: Sunday, November 01, 2009 9:23 AM To: d.sturek@att.net Cc: 'Cullen Jennings'; 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF Hi Donn, > We welcome other suggestions like XMPP and SIP but we did look at those and > ruled them out for reasons like: > 1) Verboseness (using text string exchanges for devices with very small > transmit/receive packet sizes) > 2) Session management overhead > SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered intent. But XMPP gives me pause... - would not an EXI encoding go a long way to alleviate the verbosity issues? - RESTful HTTP is a fine choice, but there are requirements for more than just request/response messaging patterns in the Smart Grid HAN and NAN. XMPP would offer request/response (sensor reading), pub/sub (broadcast announcements), one way async (scheduled reads), presence for endpoint status, etc. - how is XMPP session management any more onerous that HTTP over TLS? This assuming of course that TCP is doable. Cheers > Don > > > > From trifa@inf.ethz.ch Sun Nov 1 10:33:31 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC3193A68AB for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 10:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 mrKSRIwl-R0U for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 10:33:30 -0800 (PST) Received: from gwse.ethz.ch (gwse.ethz.ch [129.132.178.238]) by core3.amsl.com (Postfix) with ESMTP id F1C693A67CF for <6lowapp@ietf.org>; Sun, 1 Nov 2009 10:33:29 -0800 (PST) Received: from CAS02.d.ethz.ch (129.132.178.236) by gws01.d.ethz.ch (129.132.178.238) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 1 Nov 2009 19:33:47 +0100 Received: from 80-254-68-131.dynamic.monzoon.net (129.132.211.206) by mail.ethz.ch (129.132.178.227) with Microsoft SMTP Server (TLS) id 8.2.176.0; Sun, 1 Nov 2009 19:33:48 +0100 Message-ID: From: Vlad Trifa To: Zach Shelby In-Reply-To: <9175C900-B7C9-46B5-B85C-FB9F15ADBCFA@sensinode.com> Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (Apple Message framework v936) Date: Sun, 1 Nov 2009 19:33:44 +0100 References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <4AE9A4C8.4030402@tkk.fi> <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> <006c01ca5a88$6600eff0$3202cfd0$@sturek@att.net> <10FFF676-827B-4FBF-9814-C71ED48FE723@sensinode.com> <000801ca5afa$eddd2f20$c9978d60$@sturek@att.net> <9175C900-B7C9-46B5-B85C-FB9F15ADBCFA@sensinode.com> X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 18:33:31 -0000 Hi, >> As soon as we say there is a proxy or gateway required, we will get =20= >> pushback >> from device manufacturers who don't want the added cost on their =20 >> devices. > > This definitely should not require a proxy, but as pointed out in =20 > other mails, there are reasons you may use proxy technology. Even if =20= > you would implement this with plain HTTP/1.1 you would use a proxy =20 > in most cases. But this isn't an issue for device manufacturers by =20 > any means! As we are dealing with IP, a proxy may be located on the =20= > backend network somewhere e.g. as a component on any application =20 > server. I think we shouldn't oblige people to use gateways, and manufacturers =20= that want their device to plug-and-play should not need to hope for =20 gateway. In our work, we see gateways as good to have goodies that can =20= help adding nice features that shouldn't be supported at the device-=20 level (access control, caching, masking failures, request buffering =20 and caching). HTTP wouldn't necessarily mean UI - just API access. =20 Gateways could serve as simple intermediaries to enable more =20 meaningful interaction with device for end-users (think of home wifi =20 routers that could offer nice management and mobile control/access to =20= home networks, what nokia control center kind of does). On the other hand it's hard to think that "gateways" will hardly ever =20= disappear, if not for protocol translation at least for routing across =20= physical interfaces. If gateways can do some distributed processing =20 besides just routing packets, one could build more scalable =20 infrastructures. The thing for the proprietary protocols imho is that each manufacturer =20= wants a little part of the market pie but also due to constraints on =20 devices optimized solutions were needed for different solutions/apps, =20= just like IP on devices didn't make sense 7 years ago. As an =20 illustration more and more devices have already tiny web servers =20 nowadays, so not much would be needed to RESTify them. Based on our tests, I hardly see the functional limitations of http =20 for interacting with devices, other than extra verbosity/latency, =20 which in many scenarios doesn't have a huge impact on user experience =20= (especially, for many scenarios we're considering here, if we get data =20= in 0.5 seconds instead of 0.1 second doesn't hurt much). Please let me =20= know some counter examples you would have. Vlad > > On the flip-side, if we require embedded devices to speak directly =20 > with unmodified HTTP/1.1 web servers, then we really will be adding =20= > cost, if it even works at all. This is the situation today, and the =20= > reason for so many proprietary protocol and field-bus solutions. > > It sounds like we basically agree here? > > Zach > >> >> Don >> >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: Sunday, November 01, 2009 5:52 AM >> To: d.sturek@att.net >> Cc: 6lowapp@ietf.org >> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF >> >> On Nov 1, 2009, at 2:15 , Don Sturek wrote: >> >>> Hi Cullen, >>> >>> One important use case to consider: >>> 1) Devices to manage are running on 6LowPAN (using some 6LowAPP >>> defined >>> protocol). Controlling devices are running someplace on the wider >>> internet. >> >> This is common in building management and most M2M applications as =20= >> well. >> >>> 2) Does this mean that the scope of protocol work in 6LowAPP =20 >>> needs to >>> identify this type of control as a valid use case? >> >> Definitely! However we don't need to require the controlling device =20= >> to >> speak CoAP (although it could). More likely there is a proxy =20 >> somewhere >> between. >> >>> 3) Does the use of 6LowAPP protocols on the wider internet need to >>> then be >>> in the scope of 6LowAPP? >> >> Yes. This is IP, so the CoAP protocol can be used over any IP >> networks. If you need a proxy, it can be located anywhere. We should >> assume that CoAP will mainly be used in the constrained or =20 >> application- >> specific domain. >> >> Zach >> >>> >>> Don >>> >>> >>> -----Original Message----- >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >>> Behalf >>> Of Cullen Jennings >>> Sent: Saturday, October 31, 2009 10:29 AM >>> To: Jukka Manner >>> Cc: Don Sturek; 6lowapp@ietf.org >>> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF >>> >>> >>> On Oct 29, 2009, at 8:20 , Jukka Manner wrote: >>> >>>> 1. This seems to indicate that 6lowapp will not be tied to any >>>> existing work, it will work on its own goals, but in collaboration >>>> with others (which is somewhat open as what it means). I would have >>>> expected that 6lowapp would specifically look at existing work in >>>> related WGs and see how build on top of that. >>> >>> My mistake - I did not mean to imply that it was not layered on =20 >>> top of >>> closely related existing work. I think most people assumed that this >>> would run on top of a LoPAN but it seemed they also wanted it to be >>> able to run on top of a other things including a normal IP LAN and >>> WAN. Clearly this is all about same use cases as 6LoPAN and ties >>> closing with 6LoPAN and ROLL as well as work going on at many other >>> SDOs. However, I'm not sure what needs to be said. Are WG drafts =20 >>> with >>> use case / requirements from other WG that we should be referencing? >>> Give me ideas on what things you were thinking here. Clearly the =20 >>> IESG >>> would not be keen on chartering a new WG to do something another WG >>> was already charted to do - repeating work in two places seldom ends >>> well :-) Can you suggest some specific text for the charter that you >>> think would have fairly wide consent and captures what you are =20 >>> looking >>> for here? >>> >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >> >> --=20 >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may =20 >> contain >> legally privileged information. If you are not the intended =20 >> recipient, >> please contact the sender and delete the e-mail from your system >> without producing, distributing or retaining copies thereof. >> >> >> >> > > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may =20 > contain legally privileged information. If you are not the intended =20= > recipient, please contact the sender and delete the e-mail from your =20= > system without producing, distributing or retaining copies thereof. > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From zach@sensinode.com Sun Nov 1 12:43:58 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B41313A6902 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 12:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 h7RwR2rL9EX9 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 12:43:57 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5BAB13A6897 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 12:43:56 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA1Ki742007045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Nov 2009 22:44:08 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> Date: Sun, 1 Nov 2009 22:44:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B7542C2-1DBA-4BF2-82A6-D83719CCDD81@sensinode.com> References: <0D212BD466921646B58854FB79092CEC8E8644@XMB-AMS-106.cisco.com> To: Adriano Pezzuto (apezzuto) X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Really we need for HTTP on smart devices? X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 20:43:58 -0000 Adriano, On Oct 30, 2009, at 14:02 , Adriano Pezzuto (apezzuto) wrote: > Smart objects interact with the Internet as they like (and can) as > humans do. Humans type on a computer keyboard or play in front of the > iPhone camera while Things send sensing data or get commands to act on > the real world. Humans do not have an embedded HTTP server even if the > results of their actions (i.e. typing on a keyboard and playing in =20 > front > of a camera) are available as Web resources. In the same way, Things =20= > do > not need for an embedded HTTP server. Things interact with the =20 > Internet > using a lightweight protocol while the results of their interaction =20= > are > available on the Web as resources. It is a sort of "information =20 > shadow" > data that Things have on the Web. This data will be collected in a > suitable manner for the resource-constrained embedded devices and make > available as Web resource with HTTP and REST interfaces. This is basically what the current proposed charter is saying. Model =20 the embedded device features as resources, and make them available to =20= the HTTP world via REST interfaces. I do see the value of bringing the =20= REST features down to the devices themselves, in fact that is a very =20 useful paradigm and would allow for a transparent integration with the =20= web and the re-use of well-known design paradigms. This is one lesson =20= learned when realizing the SENSEI project, see: http://tools.ietf.org/html/draft-gold-6lowapp-sensei-00 Zach > > What do you think about it? > > Regards, > Adriano > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From zach@sensinode.com Sun Nov 1 13:03:34 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B69C3A6877 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZaFLjE541RlV for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:03:33 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 461023A67CF for <6lowapp@ietf.org>; Sun, 1 Nov 2009 13:03:32 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA1L3fI3007338 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Nov 2009 23:03:42 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <001601ca5b1b$ddb917a0$992b46e0$@sturek@att.net> Date: Sun, 1 Nov 2009 23:04:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <005d01ca5a87$a4e004f0$eea00ed0$@sturek@att.net> <4AEDC3FD.3040801@cisco.com> <001601ca5b1b$ddb917a0$992b46e0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 21:03:34 -0000 On Nov 1, 2009, at 19:50 , Don Sturek wrote: > Hi Paul, > > Yes, XMPP would be quite interesting if the text exchange could be =20 > avoided. I think it should be possible to use an encoded XMPP over CoAP (so in =20= the payload of CoAP). The XMPP model doesn't seem like an option for =20 CoAP itself, as it would a) require the same encoding for everything, =20= b) requires you to parse the whole thing to know what the heck it is =20 and c) assumes a stream and thus TCP. > Can we add this possibility to our CoAp charter as a application =20 > transport > possibility? I think the charter could mention XMPP as something that can be run =20 over the framework or be integrated with. The charter doesn't need to =20= say what the solution for CoAP is yet, but rather concentrate on what =20= it should achieve. As of now it is agnostic about that, which is good. There was an important point by Paul below that the interaction models =20= offered by HTTP are not sufficient, and I totally agree. CoAP can't be =20= limited to only request/response and unicast interactions. So is this =20= like REST+? Zach > > Don > > > -----Original Message----- > From: Paul Duffy [mailto:paduffy@cisco.com] > Sent: Sunday, November 01, 2009 9:23 AM > To: d.sturek@att.net > Cc: 'Cullen Jennings'; 6lowapp@ietf.org > Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > Hi Donn, > >> We welcome other suggestions like XMPP and SIP but we did look at =20 >> those > and >> ruled them out for reasons like: >> 1) Verboseness (using text string exchanges for devices with very =20= >> small >> transmit/receive packet sizes) >> 2) Session management overhead >> > > > SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered > intent. > > But XMPP gives me pause... > > - would not an EXI encoding go a long way to alleviate the verbosity =20= > issues? > > - RESTful HTTP is a fine choice, but there are requirements for more > than just request/response messaging patterns in the Smart Grid HAN =20= > and > NAN. XMPP would offer request/response (sensor reading), pub/sub > (broadcast announcements), one way async (scheduled reads), presence =20= > for > endpoint status, etc. > > - how is XMPP session management any more onerous that HTTP over TLS? > This assuming of course that TCP is doable. > > Cheers > > >> Don >> >> >> >> > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From arjunrc@gmail.com Sun Nov 1 13:07:13 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6847F28C12A for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_48=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 KOhD3xmV7KQE for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:07:12 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id D89E828C128 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 13:07:11 -0800 (PST) Received: by qyk41 with SMTP id 41so2332300qyk.29 for <6lowapp@ietf.org>; Sun, 01 Nov 2009 13:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=zF6hVcMUCyJNmMLlaVAYK8JZIXsNSyjoPl6DPd4YUrc=; b=W0G8ZynoFxH+2JpgBV1jD6pDP2i9gnDpaFvwMgHGGW2FNI8Ji7Zw1cIKyFCz4MWIJT 3Rsr8Zdv3ZutkGauusE0JvNi04ucnjKKdIicvZ5DeQ1JT73UX66TlAuz0omnLaCmQmIJ EipqFIULjX9Q7qtBNAxjxOAK3VgyS8tnu9v1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=dV6cqenuL1np9hFb2ZrrpH0/x7TxFhGEshTTuWiYo8Py/jZ5rPa2H2Dkt0gjT4HAOz I75qV55vfNMb+2xkeUIU89OQi3u5tsNqC+x2lBVaveSuK7qvb5XFQ2G+H5pz7sYhxBA+ Y1kBf8ATcFzwJ2G+ywkwWPVWbgF27hVYTFcfo= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.95.196 with SMTP id e4mr2421844qan.180.1257109646289; Sun, 01 Nov 2009 13:07:26 -0800 (PST) In-Reply-To: <71DDE42E-E6D4-49D7-8F2E-699FBBDBAC12@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <71DDE42E-E6D4-49D7-8F2E-699FBBDBAC12@cisco.com> From: Arjun Roychowdhury Date: Sun, 1 Nov 2009 16:07:03 -0500 X-Google-Sender-Auth: 5e188a19be033ec8 Message-ID: To: Cullen Jennings Content-Type: multipart/alternative; boundary=00c09f89942ee92e5c047755a5e8 Cc: Don Sturek , 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 21:07:13 -0000 --00c09f89942ee92e5c047755a5e8 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 31, 2009 at 12:29 PM, Cullen Jennings wrote: > > On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > > In order of complexity... > > > 1) simple set of fixed variables that could be controlled > > 2) a single flat list of dynamically changeable set of variables that can > can take on simple types (I might place IPFIX as being somewhat close to > this model) > > 3) a hierarchical list of variables that can be related (I'd place basic > usage SNMP roughly in this category but more advanced usage of SNMP probably > can do category 4) > > 4) a REST based approach (I'd place HTTP REST in this case) > > 5) a full RPC model (I'd place CORBA in this class) > > Every use case I have seen so far could be solved by 3, 4, or 5. I think > most people have expressed an opinion that about 4 looks about the right > level of flexibility for this. So the questions is, if there is pretty good > agreement on that, then I think we should just roll with it as tentative > decision and see what it starts looking like as a design evolves. As the > design evolves, one may find this was a bogus choice and need to revisit it. > If you think there is a strong argument for 3 or 5 or even 1 or 2, lets get > that info out on the list. ARC> Right. If every use case can be solved by 4, and if an HTTP UA stack is not an overkill for these devices, then I'd venture out to say that if the need exists, then we should have a protocol that serves that need. My argument is for something inbetween 4) and 5) - that is some session oriented protocol, if one believes there will be sessions and an offer answer needed. I mention SIP only because that is the one I know well. I am not religious about SIP, but I am particular about a need. And now, here is why some of us are putting across the fact that at the least SIP needs to be evaluated: (And I know you are well aware of SIP yourself, but I am putting some of these across for others who may not be) a) Size/Performance: Simply put, if an HTTP UA is ok, then a minimalistic SIP UA not being ok is highly suspect. I doubt folks making this statement have actually evaluated how much a session oriented protocol can be reduced when it comes to implementation. I've personally worked on SIP UAs that compress to 30K or less. How much of features you want to put in depends on the network. Given a network, you can feature compromise. This entire argument of verbosity vs. optimization is doubtful until you lay down specific #s that need to be met (and why those #s exist) b) Can SIP do everything HTTP can?: First, SIP can offer everything HTTP can. Payloads? check. URI addressing schemes and REST based services. Check. (http://myhome.com?remote=channel12 can be sip:remote@myhome.com;channel=12) etc. c) What can SIP do better than HTTP? c.1) Offer-Answer, capability, discovering the minimal feature set that works between two or more devices c.2) SIP works on more transport protocols than HTTP (yes, I am aware of HTTP over UDP, but if we look at live deployments, almost all HTTP systems use TCP. So if there is a communication needed from a non TCP network to your HAN, welcome gateways. Almost all SIP deployments I know of today do both TCP and UDP.) c.3) Routing & Reachability: SIP's architecture of loose routing, forking, etc. c.4) Concept of a 'session' & 'session control' - SIP establishes a session between one or more devices. These sessions can be transferred to any other entity if required, monitored, or modified. Basically, SIP is HTTP+Sessions and an architecture to manage sessions. 1) what other protocols mapping should we do? > > 2) Given some people want HTTP, can you live with the answer to HTTP being > yes and understanding that just because we said yes to HTTP does not mean we > are saying no to everything else? > > ARC> 1) SIP. 2) Yes. -- Arjun Roychowdhury --00c09f89942ee92e5c047755a5e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 31, 2009 at 12:29 PM, Cullen= Jennings <fluffy@= cisco.com> wrote:

On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:

In order of complexity...

1) simple set of fixed variables that could be controlled

2) a single flat list of dynamically changeable set of variables that can c= an take on simple types (I might place IPFIX as being somewhat close to thi= s model)

3) a hierarchical list of variables that can be related (I'd place basi= c usage SNMP roughly in this category but more advanced usage of SNMP proba= bly can do category 4)

4) a REST based approach (I'd place HTTP REST in this case)

5) a full RPC model (I'd place CORBA in this class)

Every use case I have seen so far could be solved by 3, 4, or 5. I think mo= st people have expressed an opinion that about 4 looks about the right leve= l of flexibility for this. So the questions is, if there is pretty good agr= eement on that, then I think we should just roll with it as tentative decis= ion and see what it starts looking like as a design evolves. As the design = evolves, one may find this was a bogus choice and need to revisit it. If yo= u think there is a strong argument for 3 or 5 or even 1 or 2, lets get that= info out on the list.

ARC> Right. If every use case can be solved by 4, an= d if an HTTP UA stack is not an overkill for these devices, then I'd ve= nture out to say that if the need exists, then we should have a protocol th= at serves that need. My argument is for something inbetween 4) and 5) - tha= t is some session oriented protocol, if one believes there will be sessions= and an offer answer needed. I mention SIP only because that is the one I k= now well. I am not religious about SIP, but I am particular about a need.= =A0

And now, here is why some of us are putting across the = fact that at the least SIP needs to be evaluated:
(And I know you= are well aware of SIP yourself, but I am putting some of these across for = others who may not be)

a) Size/Performance: Simply put, if an HTTP UA is ok, t= hen a minimalistic SIP UA not being ok is highly suspect. I doubt folks mak= ing this statement have actually evaluated how much a session oriented prot= ocol can be reduced when it comes to implementation. I've personally wo= rked on SIP UAs that compress to 30K or less. How much of features you want= to put in depends on the network. Given a network, you can feature comprom= ise. This entire argument of verbosity vs. optimization is doubtful until y= ou lay down specific #s that need to be met (and why those #s exist)

b) Can SIP do everything HTTP can?: First, SIP can offe= r everything HTTP can. Payloads? check. URI addressing schemes and REST bas= ed services. Check. (http:= //myhome.com?remote=3Dchannel12 can be sip:remote@myhome.com;channel=3D12) etc.
=A0
c) What can SIP do better than HTTP?
c.1) Offe= r-Answer, capability, discovering the minimal feature set that works betwee= n two or more devices

c.2) SIP works on more trans= port protocols than HTTP (yes, I am aware of HTTP over UDP, but if we look = at live deployments, almost all HTTP systems use TCP. So if there is a comm= unication needed from a non TCP network to your HAN, welcome gateways. Almo= st all SIP deployments I know of today do both TCP and UDP.)

c.3) Routing & Reachability: SIP's architecture= of loose routing, forking, etc.=A0

c.4) Concept o= f a 'session' & 'session control' - SIP establishes a s= ession between one or more devices. These sessions can be transferred to an= y other entity if required, monitored, or modified.

Basically, SIP is =A0HTTP+Sessions and an architecture = to manage sessions.

1) what other protocols mapping should we do?

2) Given some people want HTTP, can you live with the answer to HTTP being = yes and understanding that just because we said yes to HTTP does not mean w= e are saying no to everything else?


ARC> 1) SIP.=A0
2) Yes.=A0

<= /div>
--
Arjun Roychowdhury

--00c09f89942ee92e5c047755a5e8-- From arjunrc@gmail.com Sun Nov 1 13:12:48 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3505D3A6869 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.100, 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 4sDuxB6rzcjJ for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:12:47 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 5E1713A682B for <6lowapp@ietf.org>; Sun, 1 Nov 2009 13:12:47 -0800 (PST) Received: by qyk41 with SMTP id 41so2333442qyk.29 for <6lowapp@ietf.org>; Sun, 01 Nov 2009 13:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=cIc2Uxm8TFHgyNMiXSvG+OwCyvMElRey5+DBiBzDA+0=; b=xMNAnU4HX4AxVoR9qjnY9nytBquqLKcdHjDxoEAGJK/mPooJ/k/GQmaGw08Kdf87/L P2Md8QzR/qIP0+jeoAvz9QiyEBdnq6GSTPZTSwd0qAyGpbve+YzdVcS7wF1KSkfgnPH/ H6q9cTFFY4U93y13/eHpn6zf9PiV5vD3S00E0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=nywpxwjrzqBu890+ErfIqb9w1gj295QsHt1x5dY2BxfzlJYNcs4J4n7ZtY2fT/7tfD wUD+S6bMlqYNfeG+4ahoqZ7I62U6Td/VnlADVpIx3HRPe86Pz7ouF5/ptbDlKEnP4wuh 6sbXk6UXzLIEdOD9iU2yTmCrXKDHojXZdiR6k= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.117.12 with SMTP id o12mr2455408qaq.57.1257109984083; Sun, 01 Nov 2009 13:13:04 -0800 (PST) In-Reply-To: References: <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <4AEDC3FD.3040801@cisco.com> From: Arjun Roychowdhury Date: Sun, 1 Nov 2009 16:12:44 -0500 X-Google-Sender-Auth: e2f46f7acce21f31 Message-ID: To: paduffy@cisco.com Content-Type: multipart/alternative; boundary=000feaebb2ea0b7f21047755ba7d Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 21:12:48 -0000 --000feaebb2ea0b7f21047755ba7d Content-Type: text/plain; charset=ISO-8859-1 responding from my subscribed email id incase the previous one does not make it to this list: On Sun, Nov 1, 2009 at 4:09 PM, Arjun Roychowdhury wrote: > >> >> SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered >> intent. >> >> But XMPP gives me pause... >> >> > > ARC> Why is that so? SIP is a protocol to communicate between one or more entities. The fact that it was originally designed to communicate between users is much less important compared to the benefits its architecture brings in. If people use SIP to create a recvonly session with an IP camera in their house to monitor security from their IMS (SIP) enabled cell phone, how is that different from controlling any other device? -- Arjun Roychowdhury --000feaebb2ea0b7f21047755ba7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable responding from my subscribed email id incase the previous one does not mak= e it to this list:

On Sun, Nov 1, 2009 at= 4:09 PM, Arjun Roychowdhury <arjunrc@gmail.com> wrote:


SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered inte= nt.

But XMPP gives me pause...




ARC> Why is that so? SIP is a protocol to communicate b= etween one or more entities. The fact that it was originally designed to co= mmunicate between users is much less important compared to the benefits its= architecture brings in. If people use SIP to create a recvonly session wit= h an IP camera in their house to monitor security from their IMS (SIP) enab= led cell phone, how is that different from controlling any other device?
=A0



--
Arjun Roychowdhury
=
--000feaebb2ea0b7f21047755ba7d-- From shidan@gmail.com Sun Nov 1 13:43:48 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0BCC3A67F1 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 NbYTgZ0hUDZS for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:43:47 -0800 (PST) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id D6C363A679F for <6lowapp@ietf.org>; Sun, 1 Nov 2009 13:43:46 -0800 (PST) Received: by ewy18 with SMTP id 18so3949778ewy.43 for <6lowapp@ietf.org>; Sun, 01 Nov 2009 13:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=gOfwWBldB6KNMN0B2TwrQ+0ZP9IVRSS3PX0CB1YH8eI=; b=C6i+BlEPvefqnLSlkLTY6HKBPsB+/B85nOCBxC0KgTaO7XcjzLcCcDSOzxO0Cagprf QnQjAr2z2liyDYZ90EuJ5HGEdEwtiVYLPLv3dcwB8vCpLUcw2/uZcxC3oaEFqwyYBIu5 IqjEyijjkExnYqORbV7fXH0sF6gP6SvQVIp6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hz8LszzvokjgDwwfGtNtf4lBsvQ0ZRi6ryw8/nhogDdqiGTO4ElUYdGI+OEnFd2W1c 3UaV2rW9BykOG6H9HVKpEwgLHLfdM2E+nttA31whC6kKCv175DV8/mDOzPefeoGjEcE+ 9h7PhI+M2tiznqbirrolz6eHaeXGnDkIrT2Pk= MIME-Version: 1.0 Received: by 10.216.87.144 with SMTP id y16mr3494713wee.95.1257111842657; Sun, 01 Nov 2009 13:44:02 -0800 (PST) In-Reply-To: <923B3077-5FB0-4B8A-A83A-E76C51466ACE@inf.ethz.ch> References: <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <4AEDC3FD.3040801@cisco.com> <923B3077-5FB0-4B8A-A83A-E76C51466ACE@inf.ethz.ch> Date: Sun, 1 Nov 2009 17:44:02 -0400 Message-ID: <429b380e0911011344k2a7c823am6144ba536202fa86@mail.gmail.com> From: Shidan To: Vlad Trifa Content-Type: multipart/alternative; boundary=0016e6d7852ed316a10477562846 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 21:43:48 -0000 --0016e6d7852ed316a10477562846 Content-Type: text/plain; charset=ISO-8859-1 Hi Vlad, I think a good question to ask yourself is why all of these patterns are being created on the web, whether comet, Ajax, PubHubSub, or actually why there is a need by the web community and the IETF to create whole new protocols like WebSockets and Adobe Flash's TCP sockets. The reason is because this is how the web has evolved. If it wasn't for the business competition and related politics, I really doubt the evolution of the web browser to being a standardized OS would be the case, which is where we are headed. Thankfully, right now we don't have this problem with the "Internet of Things" and the truth is, this working group will be an important influencer of the IoT's evolution. If you choose to follow the architectures you specify, at some point it's going to look more like XMPP or SIP, the only difference being you will actually be defining all these things in the body and with more complicated call flows. This is why new trends of the real time web should not necessarily be a model for everything else for everything else in IT. So I think a good analogy is we can build a web browser in assembly language, but that wouldn't be the best route to building a good product. I think we have to realize, putting away the immense role it had for circumventing bad politics, the web's real technical contribution, and probably one of the most important, was a practical implementation of linked data and hyperlinks. I think this will remain a major enabler of any pervasive and global M2M application and this higher layer will not be in the scope of the IETF just as much a the DOM isn't. On Sun, Nov 1, 2009 at 1:29 PM, Vlad Trifa wrote: > Hello, > > I think for Web messaging there are very nice Web push patterns emerging > (comet, pubsubhubbub, restms) that are worth considering. Sure, work is > needed for reliability and security, but the entry barrier is much lower > than xmpp, and its actually more suited for devices with similar features > but less verbose which makes that solution appealing. I'm sending a paper to > WWW about Web based messaging, hopefully I'll be able to share it with you > soon (if I kick my butt enough to get back to work and finish it by > tomorrow's deadline :) > > Vlad > > > On Nov 1, 2009, at 6:23 PM, Paul Duffy wrote: > > Hi Donn, >> >> We welcome other suggestions like XMPP and SIP but we did look at those >>> and >>> ruled them out for reasons like: >>> 1) Verboseness (using text string exchanges for devices with very small >>> transmit/receive packet sizes) >>> 2) Session management overhead >>> >>> >> >> SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered >> intent. >> >> But XMPP gives me pause... >> >> - would not an EXI encoding go a long way to alleviate the verbosity >> issues? >> >> - RESTful HTTP is a fine choice, but there are requirements for more than >> just request/response messaging patterns in the Smart Grid HAN and NAN. >> XMPP would offer request/response (sensor reading), pub/sub (broadcast >> announcements), one way async (scheduled reads), presence for endpoint >> status, etc. >> >> - how is XMPP session management any more onerous that HTTP over TLS? >> This assuming of course that TCP is doable. >> >> Cheers >> >> >> Don >>> >>> >>> >>> >>> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --0016e6d7852ed316a10477562846 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Vlad, =A0I think a good question to ask yourself is why all of thes= e patterns are being created on the web, whether comet, Ajax, PubHubSub, or= actually why there is a need by the web community and the IETF to create w= hole new protocols like WebSockets and Adobe Flash's TCP sockets.

The reason is because this is how the web has evolved. = If it wasn't for the business competition and related politics, I reall= y doubt the evolution of the web browser to being a standardized OS would b= e the case, which is where we are headed.=A0Thankfully, right now we don= 9;t have this problem with the "Internet of Things" and the truth= is, this working group will be an important influencer of the IoT's ev= olution.
=A0
If you choose to follow the architectures you specify, a= t some point it's going to look more like XMPP or SIP, =A0the only diff= erence being you will actually be defining all these things in the body and= with more complicated call flows. This is why new trends of the real time = web should not necessarily be a model for everything else for everything el= se in IT.
So I think a good analogy is we can build a web browser in assembly la= nguage, but that wouldn't be the best route to building a good product.=

I think we have to realize, putting away the imme= nse role it had for circumventing bad politics, =A0the web's real techn= ical contribution, and probably one of the most important, was a practical = implementation of linked data and hyperlinks. I think this will remain a ma= jor enabler of any pervasive and global M2M application and this higher lay= er will not be in the scope of the IETF just as much a the DOM isn't.= =A0

On Sun, Nov 1, 2009 at 1:29 PM, Vlad Trifa <= span dir=3D"ltr"><trifa@inf.ethz.ch= > wrote:
Hello,

I think for Web messaging there are very nice Web push patterns emerging (c= omet, pubsubhubbub, restms) that are worth considering. Sure, work is neede= d for reliability and security, but the entry barrier is much lower than xm= pp, and its actually more suited for devices with similar features but less= verbose which makes that solution appealing. I'm sending a paper to WW= W about Web based messaging, hopefully I'll be able to share it with yo= u soon (if I kick my butt enough to get back to work and finish it by tomor= row's deadline :)

Vlad


On Nov 1, 2009, at 6:23 PM, Paul Duffy wrote:

Hi Donn,

We welcome other suggestions like XMPP and SIP but we did look at those and=
ruled them out for reasons like:
1) =A0Verboseness (using text string exchanges for devices with very small<= br> transmit/receive packet sizes)
2) =A0Session management overhead



SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered inte= nt.

But XMPP gives me pause...

- would not an EXI encoding go a long way to alleviate the verbosity issues= ?

- RESTful HTTP is a fine choice, but there are requirements for more than j= ust request/response messaging patterns in the Smart Grid HAN and NAN. =A0X= MPP would offer request/response (sensor reading), pub/sub (broadcast annou= ncements), one way async (scheduled reads), presence for endpoint status, e= tc.

- how is XMPP session management any more onerous that HTTP over TLS? =A0Th= is assuming of course that TCP is doable.

Cheers


Don





_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

--0016e6d7852ed316a10477562846-- From shidan@gmail.com Sun Nov 1 14:00:09 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C7C23A6839 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 14:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 DJKo8vwcNU3p for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 14:00:08 -0800 (PST) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id DA3093A6783 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 13:59:40 -0800 (PST) Received: by ewy18 with SMTP id 18so3955528ewy.43 for <6lowapp@ietf.org>; Sun, 01 Nov 2009 13:59:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hC8RYEVuWC2gg8SUe6alVZmH3VA+FKV0c8/2BMizp70=; b=Z/aV23FtxDCxM+XyyDfCNh6PIYkaXZWRhjSf6Dy5xBRTLMtK9wkJPfR0T95zU615aw AKFLHDvNSjVYale5W2waceje+qUNRbzvobmhKRd5EHOgUHkJq/nikuES83chTs939Lpi kvvwr2FEMyocjeyWmn9rjgrvstSKZvCti9ago= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dSLc5/7vC1Ra3AzoGAhuahiR6uf6zZ/hHLnoZ0lOQ3sqzlXDDDcuMYR7XlDzVjK/Rj 4EQiyQFByjmveGNhW9+WTnyDhvW1ey6rxtulUK+XKJzseU5iNGCjptVbtZzuz/ryEC/7 8RRcaBipluWbkg3ZL0RB9LbBa814AeHtYg7pc= MIME-Version: 1.0 Received: by 10.216.89.149 with SMTP id c21mr3448404wef.224.1257112796721; Sun, 01 Nov 2009 13:59:56 -0800 (PST) In-Reply-To: <4AEDC3FD.3040801@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <4AEDC3FD.3040801@cisco.com> Date: Sun, 1 Nov 2009 17:59:56 -0400 Message-ID: <429b380e0911011359g26b90748x1bd6bf74049162af@mail.gmail.com> From: Shidan To: paduffy@cisco.com Content-Type: multipart/alternative; boundary=0016e6d7eefab0f157047756610a Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 22:00:09 -0000 --0016e6d7eefab0f157047756610a Content-Type: text/plain; charset=ISO-8859-1 Hi Paul. XMPP definitely would be a great fit for this space and I would definitely be a backer of that. But can you expand on why you think SIP would be any less relevant for all those points you mention. I think what would be instructive is to have an actual concrete matrix of the proposed RESTful protocol, SIP and XMPP for just a couple of simple use cases and call flows see exactly where it is that XMPP and SIP, if they are binary encoded, don't meet the requirements of LoWPANs and actually see which ones are in fact the better choice. On Sun, Nov 1, 2009 at 1:23 PM, Paul Duffy wrote: > Hi Donn, > > > We welcome other suggestions like XMPP and SIP but we did look at those >> and >> ruled them out for reasons like: >> 1) Verboseness (using text string exchanges for devices with very small >> transmit/receive packet sizes) >> 2) Session management overhead >> >> > > > SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered > intent. > > But XMPP gives me pause... > > - would not an EXI encoding go a long way to alleviate the verbosity > issues? > > - RESTful HTTP is a fine choice, but there are requirements for more than > just request/response messaging patterns in the Smart Grid HAN and NAN. > XMPP would offer request/response (sensor reading), pub/sub (broadcast > announcements), one way async (scheduled reads), presence for endpoint > status, etc. > > - how is XMPP session management any more onerous that HTTP over TLS? This > assuming of course that TCP is doable. > > Cheers > > > > Don >> >> >> >> >> > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --0016e6d7eefab0f157047756610a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Paul. XMPP definitely would be a great fit for this space and I would de= finitely be a backer of that. But can you expand on why you think SIP would= be any less relevant for all those points you mention.=A0I think what woul= d be instructive is to have an actual concrete matrix of the proposed RESTf= ul protocol, SIP and XMPP for just a couple of simple use cases and call fl= ows see exactly where it is that XMPP and SIP, if they are binary encoded, = don't meet the requirements of LoWPANs =A0and actually see which ones a= re in fact the better choice.

On Sun, Nov 1, 2009 at 1:23 PM, Paul Du= ffy <paduffy@cisc= o.com> wrote:
Hi Donn,


We welcome other suggestions like XMPP and SIP but we did look at those and=
ruled them out for reasons like:
1) =A0Verboseness (using text string exchanges for devices with very small<= br> transmit/receive packet sizes)
2) =A0Session management overhead
=A0


SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered inte= nt.

But XMPP gives me pause...

- would not an EXI encoding go a long way to alleviate the verbosity issues= ?

- RESTful HTTP is a fine choice, but there are requirements for more than j= ust request/response messaging patterns in the Smart Grid HAN and NAN. =A0X= MPP would offer request/response (sensor reading), pub/sub (broadcast annou= ncements), one way async (scheduled reads), presence for endpoint status, e= tc.

- how is XMPP session management any more onerous that HTTP over TLS? =A0Th= is assuming of course that TCP is doable.

Cheers



Don



=A0

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

--0016e6d7eefab0f157047756610a-- From shidan@gmail.com Sun Nov 1 14:28:52 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E59E828C11A for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 14:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 tlKbFhWD8jrL for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 14:28:49 -0800 (PST) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id 079D33A67F1 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 14:28:48 -0800 (PST) Received: by ewy18 with SMTP id 18so3966087ewy.43 for <6lowapp@ietf.org>; Sun, 01 Nov 2009 14:29:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KBkPDbE43ciGzzAK/FyVbx93uiLQ/O93Rq6HYNDhlMU=; b=r0S+hZHCtuGEVaUvN2rlOAVTenCKLRLcpmOtSv3zkG3JcTh/U2FQlTuPocb1y2CbQP lUcITQqoimE2XbbbHQ3OokFROWZvdT8oxCTtibbJCqvZMm+H/OaZFXgSKfw41eIXdiVc 6IFuy+ybY4w8kU2NEctDf/VHXosElLheMeFmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sMRs6UUU1NIfa6PSoG/V4hfvzHaPAe2uvB7GII4RfjnBnwc6fol31wAnWuHij99R+D G9d1qiP/XyBaEhroI0AQhpYT/3qzDhSPyowfbmWsr6Q9RVd/xemzGN1Bk/46ZTJY82uU nlqpo8ZyzfzPNPBVGGrJtVa6JBBbvxjmE2M2U= MIME-Version: 1.0 Received: by 10.216.85.68 with SMTP id t46mr3627776wee.114.1257114544852; Sun, 01 Nov 2009 14:29:04 -0800 (PST) In-Reply-To: <-5154379632797214018@unknownmsgid> References: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> <-5154379632797214018@unknownmsgid> Date: Sun, 1 Nov 2009 18:29:04 -0400 Message-ID: <429b380e0911011429w524371d6ndf67b1b1c9e669b0@mail.gmail.com> From: Shidan To: d.sturek@att.net Content-Type: multipart/alternative; boundary=0016e6d645a8e3501f047756c91c Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 22:28:52 -0000 --0016e6d645a8e3501f047756c91c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Don, just the fact that ZigBee will move to IP is great progress and we have to consider that maybe its 802.15.4 and HomePlug today, but this will hopefully be something that opens up utilities and vendors to many other options. So I fully agree this has to be something that makes sense and works well on the net without gateways and proxies. This was significant hurdle in my eyes and seems to have been overcome by your work and this hopefully this WG for the utility HANs. I think there is sufficient time to examine the systems I have talked about and I think if one of those systems can be considered a base CoAp protocol and supported officially, in the not too distant future, by the energy industry, it would be a real benefit to how this technology evolves in general. On Sat, Oct 31, 2009 at 7:22 PM, Don Sturek wrote: > Hi Shidan, > > > > All of this sounds fantastic, however: > > 1) The Smart Metering work is not going to wait while we sort out > all of this and then figure out what standards we need. > > > > The reality is that early smart metering deployments need to start next > year. We need to figure out how to supply a =93Generation 1=94 solution = that > allows scalability. > > > > I have provided what we (the ZigBee and utility team) think is > possible/practical for us to deploy in the short term. If what is propos= ed > (RESTfull HTTP, Extensions to SLP for tokenization, W3C EXi, etc.) is not= a > good starting point, let=92s discuss. If what you wrote below builds on = what > is proposed for the near term then we are in alignment. If we have to w= ait > an extended time to finalize a series of new standards to redefine HAN > automation, then we will miss our window of relevance (at least in my > opinion). > > > Don > > > > > > *From:* 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] *On > Behalf Of *Shidan > *Sent:* Saturday, October 31, 2009 3:42 PM > *To:* Cullen Jennings > *Cc:* 6lowapp@ietf.org > *Subject:* Re: [6lowapp] Architecture Sketch in Charter > > > > Hi Fluffy, > > > > I definitely agree with your overall sentiment, but one thing that I alwa= ys > find dissapointing is when people give me the "turn on and off" garage > doors, thermostats, etc as the only examples of what a HAN should be abou= t. > I think this is part of the reason some, specially me, are a little confu= sed > by the WG. > > > > The truth is, I'm personally not looking for a X10, legacy 802.15.4, KNX, > etc replacement; they do a fine job of turning things on and off. Let me > list a few things I would like in my HAN: > > > > 1) I want a network that goes beyond enabling me to discover and control = a > device to one that enables devices to discover, control and communicate w= ith > each other and mixed groups of devices and people. > > > > 2) I want devices to do things based on time and other arbitrary policies > as part of the network > > > > 3) I want mobile & secure smart objects to take advantage of pervasive > global networks and objects that are location aware. > > > > 4) I want a system that can evolve so that when it makes economic sense, > the physical components of a smart appliance are "smart components" > themselves. I also see a day when people will be upgrading the features a= nd > functionality of their washing machine through a > > firmware upgrade.The last two are probably sound silly now, but they're > real considerations of how things can evolve. > > > > The truth of the matter is that even with X10 and gateways, except for > device mobility, most of this is possible. It's further true that the mos= t > difficult challenge of HANs is not the networking but end user > programmability and moving intelligence to the network will help in > developing these systems. > > > > Right now, the difficulty I'm having is that it almost seems, and this > could be a wrong interpretation I hope, that this working group is saying > "let's forget about addressing the greater problem of HANs through networ= k > intelligence and let's just focus on satisfying the bare minimum needs of > the energy industry so they can move to IP" and "then we will let the sys= tem > evolve." > > > > Another approach could be that this working group could start by > considering the HAN application layers like UPnP and see how they need to > evolve for pervasive access, where they have gone wrong for developers an= d > so on and then see how much of this better system you define can be broug= ht > down to LoPANs. This is something I think can be done in the time frames > this WG has proposed and anything that comes out of it would work great f= or > the energy industry as well. > > > > Of course, even better would be a general application layer framework for > LoPANS, but since this is technological limitation, I think looking at > requirements is absolutely necessary. > > > > A side note, I definitely think SIP and XMPP are relevant in this field > Cullen, there is a reason why so many M2M applications are using XMPP, > specially in BRIC countries. There is also a reason why the leading deman= d > response provider is using XMPP today, if you can take this all the way t= o > the home and on AMI networks then why not? There is also a reason why the > few MSOs and incumbents that I know of who are offering home media > management and media delivery to connected devices are switching to > SIP-DLNA gateways. Again, this is not even the real issue, who really car= es > what you name a protocol as long as it works and the proper requirements > have been considered. My concern above is much more important. > > > > Shidan Gouran > > > > On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings wrote= : > > > Right now the draft charter has a sketch of some of the key parts of the > architecture. I'd like to talk about the pro's and cons of putting this i= n a > charter. Typically charters don't have this. Many BOFs fail when all the > people in the room don't lave having a common idea of what the group will > do. Typically the architecture is developed in a draft and often can tak= e > considerable time however there's nothing stopping this type of informati= on > form being in a charter. Now this effort is a bit different from your > typically BOF. Let me list some differences: > > 1) This is not meant to run on normal networks. We've told the transport > folks, yah, we are going to have to make different assumptions than norma= l > application protocols make because there some special stuff going on here= . > That makes the Transport and INT people very nervous. > > 2) We told the security people, none of your off the shelf security > approaches will work for us because we have special requirements. We are = not > even 100% sure it is feasibly to simultaneously satisfy all the > requirements. That makes the Security people, uh, prickly. > > 3) Some people have suggest that SIP might be just the thing to build on > over for things like controlling a garage door opener. Many (but not all= ) > SIP folks feel that SIP is for User to User communications and often use = SIP > to control the garage door and the prototypical example of what should *n= ot* > be done with SIP. This makes the RAI people want to come and say "hi". I'= m > not saying we could not use SIP but I am saying the SIP people would want= to > come and talk about the issues before that decision got made. Hopefully t= hey > won't ask if any of this has any real time application properties or > infrastructure they could help with. > > 4) The OAM folks must be thinking, so how is this different from what we = do > every single day? > > 5) The INT and Routing guys want to know how this related to work they ar= e > doing. > > 6) I've had a few questions that loosely translated to "so what feature o= f > IPv6 are you using to guarantee that this will only work on a v6 network"= . > > If we told the DNS guys we were consider doing all our senor reading use > DNS so we could leverage the DNS caching we would have pretty much every > area "concerned". > > People have questions. Lots of questions. The challenge for a successful > BOF like this is to put together a coherent story of what the big picture > looks like and how it all hangs together. I believe we have a reasonable > chance of having a WG approved if we can show that there is a group of > people that have > > 1) a clear idea of what they want to build > > 2) the same common idea of what it is > > 3) it is an engineering project, and not science project requiring > invention of new techniques > > 4) it meets the type of requirements the IETF has for standards track wor= k > > The quickest way to do this would be to have in some document that we tak= e > into the BOF use cases, requirements, and a high level architecture. We h= ave > drafts with use case and requirements and we can refine theses int he sli= des > used in the BOF. If we can agree on an architecture, we can stuff that in > the charter. > > I'm probably a bit naive to think we can come up with a sketch of an > architecture and agree to it in the BOF. But if we do, we have a chance a= t > having the a protocol document finished before 2011. > > A more tried and true approach to this would be to work on the requiremen= t, > use case, and architecture in some ad-hoc meetings then go for a BOF. The > P2PSIP WG had problems similar to this WG in that they were going to have > some harder than average transport and security issues. They meant for > multiple hours at every IETF for multiple years *before* the WG was > approved. Lots of the meetings had around 100 people with pretty substant= ial > effort. > > Another approach would be to charter just to do requirements then rechart= er > to do the protocols. I'd bet anyone on odds of a bottle of beer to a bott= le > of scotch that would not finish before 2011 and even odds on a bottle of > scotch it would not finish before 2012. > > Many people have expressed that time is of the essence on this work and > something that delivers in 2012 will be of very little deployment value. = I'm > not in a good position to evaluate how quickly something is needed here b= ut > I'm happy to take everything people tell m at when this is needed at face > value. > > The sponsoring AD has read me the riot act on scope for the initial set o= f > work, make this a small bite size chunk that meets a reasonable set of ne= eds > and we can complete quickly. As that completes, I'm sure there would be n= o > problem re-charting to expand the scope for more things or forming other = WG > to take on related work. > > So bottom line, I'm trying to drive this to figure out what is small bite > size chunk that everyone could live with for the initial stuff to be work= ed > on. If we are lucky, we can end up agreeing on requirements, uses cases, = and > a high level sketch of the architecture without a long drawn out process. > If this fails, and I admit it very well could, well then we can just mov= e > back to some other way of dealing with this. > > A good charter is a plan for work as well as something that constrains th= e > number of possibilities a WG has to consider. Now clearly we can't constr= ain > things beyond what is needed. If we can mange to agree on a tight charter= , > the WG will be able to progress work very rapidly. If we fail to do this = in > the next few week, having tried will not set back the work in any > significant way. > > I hope this explains, I'm not trying to convince anyone the architecture > in the draft is the right one. I'm just trying to convince people to fix= it > before the BOF. > > Sorry for such a long email, > Cullen > > > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > > --0016e6d645a8e3501f047756c91c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Don, just the fact that ZigBee will move to IP is great progress and we = have to consider that maybe its 802.15.4 and HomePlug today, but this will = hopefully be something that opens up utilities and vendors to many other op= tions. So I fully agree this has to be something that makes sense and works= well on the net without gateways and proxies. This was=A0significant=A0hur= dle in my eyes and seems to have been overcome by your work and this hopefu= lly this WG for the utility HANs.

I think there is sufficient time to examine the systems I ha= ve talked about and I think if one of those systems can be considered a bas= e CoAp protocol and supported officially, in the not too distant future, by= the energy industry, it would be a real benefit to how this technology evo= lves in general.



On Sat, Oct 31, 2009= at 7:22 PM, Don Sturek <d.sturek@att.net> wrote:

Hi Sh= idan,

=A0

All o= f this sounds fantastic, however:

1)=A0=A0=A0=A0=A0 =A0The = Smart Metering work is not going to wait while we sort out all of this and then figure out what standards we need.

=A0

The r= eality is that early smart metering deployments need to start next year.=A0 We need to figure out how to supply a =93Generation 1=94 solu= tion that allows scalability.

=A0

I hav= e provided what we (the ZigBee and utility team) think is possible/practical for us to deploy in the short term.=A0 If what is propos= ed (RESTfull HTTP, Extensions to SLP for tokenization, W3C EXi, etc.) is not a good star= ting point, let=92s discuss. If what you wrote below=A0 builds on what is propos= ed for the near term then we are in alignment.=A0=A0 If we have to wait an extende= d time to finalize a series of new standards to redefine HAN automation, then we w= ill miss our window of relevance (at least in my opinion).


Don

=A0

=A0

From:= 6lowapp-bounc= es@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Shidan
Sent: Saturday, October 31, 2009 3:42 PM
To: Cullen Jennings
Cc: 6lowapp@ie= tf.org
Subject: Re: [6lowapp] Architecture Sketch in Charter

=A0

Hi Fluffy,=A0

=A0

I definitely agree with your overall sentiment, but = one thing that I always find dissapointing is when people give me the "tur= n on and off" garage doors, thermostats, etc as the only examples of what a= HAN should be about. I think this is part of the reason some, specially me, are= a little confused by the WG.

=A0

The truth is, I'm personally not looking for a X= 10, legacy 802.15.4, KNX, etc replacement; they do a fine job of turning things on and off. Let me list a few things I would like in my HAN:

=A0

1) I want a network that goes beyond enabling me to = discover and control a device to one that enables devices to discover, control and communicate with each other and mixed groups of devices and people.=A0

=A0

2) I want devices to do things based on time and oth= er arbitrary policies as part of the network

=A0

3) I want mobile & secure smart objects to take advantage of pervasive global networks and objects that are location aware.=

=A0

4) I want a system that can evolve so that when it m= akes economic sense, the physical components of a smart appliance are "smar= t components" themselves. I also see a day when people will be upgrading= the features and functionality of their washing machine through a

firmware upgrade.The last two are probably sound sil= ly now, but they're real considerations of how things can evolve.

=A0

The truth of the matter is that even with X10 and ga= teways, except for device mobility, most of this is possible. It's further true= that the most difficult challenge of HANs is not the networking but end user programmability and moving intelligence to the network will help in develop= ing these systems.

=A0

Right now, the difficulty I'm having is that it = almost seems, and this could be a wrong interpretation I hope, that this working g= roup is saying "let's forget about addressing the greater problem of HA= Ns through network intelligence and let's just focus on satisfying the bar= e minimum needs of the energy industry so they can move to IP" and "then we will let the system evolve."=A0

=A0

Another approach could be that this working group co= uld start by considering the HAN application layers like UPnP and see how they = need to evolve for pervasive access, where they have gone wrong for developers a= nd so on and then see how much of this better system you define can be brought down to LoPANs. This is something I think can be done in the time frames th= is WG has proposed and anything that comes out of it would work great for the energy industry as well.

=A0

Of course, even better would be a general applicatio= n layer framework for LoPANS, but since this is technological limitation, I think looking at requirements is absolutely necessary.=A0

=A0

A side note, I definitely think SIP and XMPP are rel= evant in this field Cullen, there is a reason why so many M2M applications are using XMPP, specially in BRIC countries. There is also a reason why the leading demand response provider is using XMPP today, if you can take this all the = way to the home and on AMI networks then why not? There is also a reason why th= e few MSOs and incumbents=A0that I know of who are offering home media management =A0and media delivery to connected devices are switching to SIP-DLNA gateways. Again, this is not even the real issue, who really cares what you name a protocol as long as it works and the proper requirements ha= ve been considered. My concern above is much more important.

=A0

Shidan Gouran

=A0

On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings <= ;fluffy@cisco.com= > wrote:


Right now the draft charter has a sketch of some of the key parts of the architecture. I'd like to talk about the pro's and cons of putting = this in a charter. Typically charters don't have this. Many BOFs fail when all th= e people in the room don't lave having a common idea of what the group will do. Typically =A0the architecture is developed in a draft and often can take considerable time however there's nothing stopping this type of informa= tion form being in a charter. Now this effort is a bit different from your typic= ally BOF. Let me list some differences:

1) This is not meant to run on normal networks. We've told the transpor= t folks, yah, we are going to have to make different assumptions than normal applica= tion protocols make because there some special stuff going on here. That makes t= he Transport and INT people very nervous.

2) We told the security people, none of your off the shelf security approac= hes will work for us because we have special requirements. We are not even 100% sure it is feasibly to simultaneously satisfy all the requirements. That ma= kes the Security people, uh, prickly.

3) Some people have suggest that SIP might be just the thing to build on ov= er for things like controlling a garage door opener. =A0Many (but not all) SIP folks feel that SIP is for User to User communications and often use SIP to control the garage door and the prototypical example of what should *not* b= e done with SIP. This makes the RAI people want to come and say "hi"= ;. I'm not saying we could not use SIP but I am saying the SIP people woul= d want to come and talk about the issues before that decision got made. Hopefully = they won't ask if any of this has any real time application properties or in= frastructure they could help with.

4) The OAM folks must be thinking, so how is this different from what we do every single day?

5) The INT and Routing guys want to know how this related to work they are doing.

6) I've had a few questions that loosely translated to "so what fe= ature of IPv6 are you using to guarantee that this will only work on a v6 network&qu= ot;.

If we told the DNS guys we were consider doing all our senor reading use DN= S so we could leverage the DNS caching we would have pretty much every area &quo= t;concerned".

People have questions. Lots of questions. The challenge for a successful BO= F like this is to put together a coherent story of what the big picture looks like and how it all hangs together. I believe we have a reasonable chance o= f having a WG approved if we can show that there is a group of people that ha= ve

1) a clear idea of what they want to build

2) the same common idea of what it is

3) it is an engineering project, and not science project requiring inventio= n of new techniques

4) it meets the type of requirements the IETF has for standards track work<= br>
The quickest way to do this would be to have in some document that we take = into the BOF use cases, requirements, and a high level architecture. We have dra= fts with use case and requirements and we can refine theses int he slides used = in the BOF. If we can agree on an architecture, we can stuff that in the chart= er.

I'm probably a bit naive to think we can come up with a sketch of an architecture and agree to it in the BOF. But if we do, we have a chance at having the a protocol document finished before 2011.

A more tried and true approach to this would be to work on the requirement,= use case, and architecture in some ad-hoc meetings then go for a BOF. The P2PSI= P WG had problems similar to this WG in that they were going to have some harder than average transport and security issues. They meant for multiple hours a= t every IETF for multiple years *before* the WG was approved. Lots of the meetings had around 100 people with pretty substantial effort.

Another approach would be to charter just to do requirements then recharter= to do the protocols. I'd bet anyone on odds of a bottle of beer to a bottl= e of scotch that would not finish before 2011 and even odds on a bottle of scotc= h it would not finish before 2012.

Many people have expressed that time is of the essence on this work and something that delivers in 2012 will be of very little deployment value. I&= #39;m not in a good position to evaluate how quickly something is needed here but= I'm happy to take everything people tell m at when this is needed at face value= .

The sponsoring AD has read me the riot act on scope for the initial set of work, make this a small bite size chunk that meets a reasonable set of need= s and we can complete quickly. As that completes, I'm sure there would be= no problem re-charting to expand the scope for more things or forming other WG= to take on related work.

So bottom line, I'm trying to drive this to figure out what is small bi= te size chunk that everyone could live with for the initial stuff to be worked on. = If we are lucky, we can end up agreeing on requirements, uses cases, and a hig= h level sketch of the architecture without a long drawn out process. =A0If this fails, and I admit it very well could, well then we can just move back= to some other way of dealing with this.

A good charter is a plan for work as well as something that constrains the number of possibilities a WG has to consider. Now clearly we can't cons= train things beyond what is needed. If we can mange to agree on a tight charter, = the WG will be able to progress work very rapidly. If we fail to do this in the next few week, having tried will not set back the work in any significant w= ay.

I hope this explains, I'm not =A0trying to convince anyone the architec= ture in the draft is the right one. =A0I'm just trying to convince people to= fix it before the BOF.

Sorry for such a long email,
Cullen





_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

=A0


--0016e6d645a8e3501f047756c91c-- From sanjsinh@cisco.com Sun Nov 1 20:56:03 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97F7C3A69A2 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 20:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=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 8NAYox5ZuUU1 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 20:56:02 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B58573A69A1 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 20:56:01 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAGr17UpAZnwM/2dsb2JhbACCJC6UWqsSljSCO4F+BA X-IronPort-AV: E=Sophos;i="4.44,663,1249257600"; d="scan'208,217";a="65907096" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Nov 2009 04:56:19 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.190]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA24uJIM012641; Mon, 2 Nov 2009 04:56:19 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 22:56:19 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5B78.D10211BD" x-cr-hashedpuzzle: AlTu Cfrh C2+a C/Nk FvlP HYme HbAb KWs6 O2+O Rqvt S1B/ Tk+t UMqV XDvF chsD hnRT; 3; NgBsAG8AdwBhAHAAcABAAGkAZQB0AGYALgBvAHIAZwA7AGEAcgBqAHUAbgAuAGwAaQBzAHQAcwBAAGgAcwBjAC4AYwBvAG0AOwBkAG8AbgBzAHQAdQByAGUAawBAAGcAcgBpAGQAMgBoAG8AbQBlAC4AYwBvAG0A; Sosha1_v1; 7; {C30A3280-748B-4F0E-B2F9-24C447476D48}; cwBhAG4AagBzAGkAbgBoAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 02 Nov 2009 04:56:09 GMT; UgBFADoAIABbADYAbABvAHcAYQBwAHAAXQAgAFAAcgBvAHAAbwBzAGUAZAAgAGMAaABhAHIAdABlAHIAIABmAG8AcgAgADYATABvAFcAQQBQAFAAIABCAE8ARgA= X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message x-cr-puzzleid: {C30A3280-748B-4F0E-B2F9-24C447476D48} Date: Sun, 1 Nov 2009 22:56:09 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA010443@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Proposed charter for 6LoWAPP BOF Thread-Index: AcpbN2SkjlwspJbyTZirqCvBdnXNcQAPo7Rg References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <71DDE42E-E6D4-49D7-8F2E-699FBBDBAC12@cisco.com> From: "Sanjay Sinha (sanjsinh)" To: , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 02 Nov 2009 04:56:19.0766 (UTC) FILETIME=[D135FD60:01CA5B78] Cc: Don Sturek , 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 04:56:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5B78.D10211BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are there any use cases which require session to be established between the devices? =20 I am new to this community, but from the discussions that I have seen so far, looks like most of the use cases require a request-response transaction and not a session between two devices or groups of devices. I am also not sure about real time properties that the applications in this space will have, for which SIP can be used. =20 I would think that SIP event notification mechanism can be used for things like monitoring the temperature, usage etc.=20 =20 I am not saying SIP can not be used and I do not have a very good knowledge of use cases, but I think a starting point would be to come up with some scenarios where session characteristics can be used. =20 Sanjay =20 =20 =20 From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Arjun Roychowdhury Sent: Monday, November 02, 2009 2:37 AM To: Cullen Jennings (fluffy) Cc: Don Sturek; 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF =20 =20 On Sat, Oct 31, 2009 at 12:29 PM, Cullen Jennings wrote: On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: In order of complexity... 1) simple set of fixed variables that could be controlled 2) a single flat list of dynamically changeable set of variables that can can take on simple types (I might place IPFIX as being somewhat close to this model) 3) a hierarchical list of variables that can be related (I'd place basic usage SNMP roughly in this category but more advanced usage of SNMP probably can do category 4) 4) a REST based approach (I'd place HTTP REST in this case) 5) a full RPC model (I'd place CORBA in this class) Every use case I have seen so far could be solved by 3, 4, or 5. I think most people have expressed an opinion that about 4 looks about the right level of flexibility for this. So the questions is, if there is pretty good agreement on that, then I think we should just roll with it as tentative decision and see what it starts looking like as a design evolves. As the design evolves, one may find this was a bogus choice and need to revisit it. If you think there is a strong argument for 3 or 5 or even 1 or 2, lets get that info out on the list. =20 ARC> Right. If every use case can be solved by 4, and if an HTTP UA stack is not an overkill for these devices, then I'd venture out to say that if the need exists, then we should have a protocol that serves that need. My argument is for something inbetween 4) and 5) - that is some session oriented protocol, if one believes there will be sessions and an offer answer needed. I mention SIP only because that is the one I know well. I am not religious about SIP, but I am particular about a need.=20 =20 And now, here is why some of us are putting across the fact that at the least SIP needs to be evaluated: (And I know you are well aware of SIP yourself, but I am putting some of these across for others who may not be) =20 a) Size/Performance: Simply put, if an HTTP UA is ok, then a minimalistic SIP UA not being ok is highly suspect. I doubt folks making this statement have actually evaluated how much a session oriented protocol can be reduced when it comes to implementation. I've personally worked on SIP UAs that compress to 30K or less. How much of features you want to put in depends on the network. Given a network, you can feature compromise. This entire argument of verbosity vs. optimization is doubtful until you lay down specific #s that need to be met (and why those #s exist) =20 b) Can SIP do everything HTTP can?: First, SIP can offer everything HTTP can. Payloads? check. URI addressing schemes and REST based services. Check. (http://myhome.com?remote=3Dchannel12 can be = sip:remote@myhome.com ;channel=3D12) etc. =20 c) What can SIP do better than HTTP? c.1) Offer-Answer, capability, discovering the minimal feature set that works between two or more devices =20 c.2) SIP works on more transport protocols than HTTP (yes, I am aware of HTTP over UDP, but if we look at live deployments, almost all HTTP systems use TCP. So if there is a communication needed from a non TCP network to your HAN, welcome gateways. Almost all SIP deployments I know of today do both TCP and UDP.) =20 c.3) Routing & Reachability: SIP's architecture of loose routing, forking, etc.=20 =20 c.4) Concept of a 'session' & 'session control' - SIP establishes a session between one or more devices. These sessions can be transferred to any other entity if required, monitored, or modified. =20 Basically, SIP is HTTP+Sessions and an architecture to manage sessions. =20 1) what other protocols mapping should we do? =09 2) Given some people want HTTP, can you live with the answer to HTTP being yes and understanding that just because we said yes to HTTP does not mean we are saying no to everything else? =20 =20 ARC> 1) SIP.=20 2) Yes.=20 =20 --=20 Arjun Roychowdhury ------_=_NextPart_001_01CA5B78.D10211BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are there any use cases which require session to be = established between the devices?

 

I am new to this community, but from the discussions that = I have seen so far, looks like most of the use cases require a request-response = transaction and not a session between two devices or groups of devices.  I am = also not sure about real time properties that the applications in this space will = have, for which SIP can be used.

 

I would think that SIP event notification mechanism can = be used for things like monitoring the temperature, usage etc. =

 

I am not saying SIP can not be used and I do not have a = very good knowledge of use cases, but I think a starting point would be to = come up with some scenarios where session characteristics can be = used.

 

Sanjay

         &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;         =

 

 

From:= 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf = Of Arjun Roychowdhury
Sent: Monday, November 02, 2009 2:37 AM
To: Cullen Jennings (fluffy)
Cc: Don Sturek; 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP = BOF

 

 

On Sat, Oct 31, 2009 at 12:29 PM, Cullen Jennings = <fluffy@cisco.com> = wrote:


On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:

In order of complexity...


1) simple set of fixed variables that could be controlled

2) a single flat list of dynamically changeable set of variables that = can can take on simple types (I might place IPFIX as being somewhat close to = this model)

3) a hierarchical list of variables that can be related (I'd place basic = usage SNMP roughly in this category but more advanced usage of SNMP probably = can do category 4)

4) a REST based approach (I'd place HTTP REST in this case)

5) a full RPC model (I'd place CORBA in this class)

Every use case I have seen so far could be solved by 3, 4, or 5. I think = most people have expressed an opinion that about 4 looks about the right = level of flexibility for this. So the questions is, if there is pretty good = agreement on that, then I think we should just roll with it as tentative decision and = see what it starts looking like as a design evolves. As the design evolves, = one may find this was a bogus choice and need to revisit it. If you think there = is a strong argument for 3 or 5 or even 1 or 2, lets get that info out on the = list.

 

ARC> Right. If every use case can be solved by = 4, and if an HTTP UA stack is not an overkill for these devices, then I'd venture = out to say that if the need exists, then we should have a protocol that serves = that need. My argument is for something inbetween 4) and 5) - that is some = session oriented protocol, if one believes there will be sessions and an offer = answer needed. I mention SIP only because that is the one I know well. I am not religious about SIP, but I am particular about a = need. 

 

And now, here is why some of us are putting across = the fact that at the least SIP needs to be evaluated:

(And I know you are well aware of SIP yourself, but = I am putting some of these across for others who may not be)

 

a) Size/Performance: Simply put, if an HTTP UA is = ok, then a minimalistic SIP UA not being ok is highly suspect. I doubt folks making = this statement have actually evaluated how much a session oriented protocol = can be reduced when it comes to implementation. I've personally worked on SIP = UAs that compress to 30K or less. How much of features you want to put in depends = on the network. Given a network, you can feature compromise. This entire = argument of verbosity vs. optimization is doubtful until you lay down specific #s = that need to be met (and why those #s exist)

 

b) Can SIP do everything HTTP can?: First, SIP can = offer everything HTTP can. Payloads? check. URI addressing schemes and REST = based services. Check. (http://myhome.com?remote=3D= channel12 can be sip:remote@myhome.com;channel= =3D12) etc.

 

c) What can SIP do better than HTTP?

c.1) Offer-Answer, capability, discovering the = minimal feature set that works between two or more devices

 

c.2) SIP works on more transport protocols than = HTTP (yes, I am aware of HTTP over UDP, but if we look at live deployments, almost = all HTTP systems use TCP. So if there is a communication needed from a non TCP = network to your HAN, welcome gateways. Almost all SIP deployments I know of = today do both TCP and UDP.)

 

c.3) Routing & Reachability: SIP's architecture = of loose routing, forking, etc. 

 

c.4) Concept of a 'session' & 'session control' = - SIP establishes a session between one or more devices. These sessions can be transferred to any other entity if required, monitored, or = modified.

 

Basically, SIP is  HTTP+Sessions and an = architecture to manage sessions.

 

1) what other protocols mapping should we = do?


2) Given some people want HTTP, can you live with the answer to HTTP = being yes and understanding that just because we said yes to HTTP does not mean we = are saying no to everything else?

 

 

ARC> 1) SIP. 

2) Yes. 

 

--
Arjun Roychowdhury

------_=_NextPart_001_01CA5B78.D10211BD-- From sanjsinh@cisco.com Sun Nov 1 21:00:18 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD4103A69A9 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 21:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MYn2zajKwszh for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 21:00:17 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 48CCB3A69AB for <6lowapp@ietf.org>; Sun, 1 Nov 2009 20:59:34 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAOL17UpAZnwM/2dsb2JhbACCJiy/bpY0hDkE X-IronPort-AV: E=Sophos;i="4.44,663,1249257600"; d="scan'208,217";a="65948338" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Nov 2009 04:59:53 +0000 Received: from xbh-rcd-102.cisco.com ([72.163.62.190]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA24xrHl014279; Mon, 2 Nov 2009 04:59:53 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Nov 2009 22:59:53 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5B79.5011B966" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Sun, 1 Nov 2009 22:59:51 -0600 Message-ID: <00FC4AA684E90E4DA2FF71021CD5A6CA010444@XMB-RCD-101.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Proposed charter for 6LoWAPP BOF Thread-Index: AcpbOB3O1WPpSqcxT/iI7o1j52HqSAAQLCOg References: <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com><2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com><4AEDC3FD.3040801@cisco.com> From: "Sanjay Sinha (sanjsinh)" To: , "Paul Duffy (paduffy)" X-OriginalArrivalTime: 02 Nov 2009 04:59:53.0049 (UTC) FILETIME=[50566490:01CA5B79] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 05:00:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5B79.5011B966 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think Paul is talking about verbose nature of SIP and also the parsing of headers and message body that is required and whether the processing cost fits into the requirement for low power embedded devices. =20 Sanjay=20 =20 From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Arjun Roychowdhury Sent: Monday, November 02, 2009 2:43 AM To: Paul Duffy (paduffy) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF =20 responding from my subscribed email id incase the previous one does not make it to this list: On Sun, Nov 1, 2009 at 4:09 PM, Arjun Roychowdhury wrote: =20 SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered intent. =09 But XMPP gives me pause... =20 =20 =20 ARC> Why is that so? SIP is a protocol to communicate between one or more entities. The fact that it was originally designed to communicate between users is much less important compared to the benefits its architecture brings in. If people use SIP to create a recvonly session with an IP camera in their house to monitor security from their IMS (SIP) enabled cell phone, how is that different from controlling any other device? =20 --=20 Arjun Roychowdhury ------_=_NextPart_001_01CA5B79.5011B966 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think Paul is talking about verbose nature of SIP and = also the parsing of headers and message body that is required and whether the = processing cost fits into the requirement for low power embedded = devices.

 

Sanjay

 

From:= 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf = Of Arjun Roychowdhury
Sent: Monday, November 02, 2009 2:43 AM
To: Paul Duffy (paduffy)
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP = BOF

 

responding from my = subscribed email id incase the previous one does not make it to this = list:

On Sun, Nov 1, 2009 at 4:09 PM, Arjun Roychowdhury = <arjunrc@gmail.com> = wrote:

 

SIP in the Smart = Grid HAN seems a fundamental misfit to SIPs chartered intent.

But XMPP gives me pause...

 

 

 

ARC> Why is that so? SIP is a protocol to = communicate between one or more entities. The fact that it was originally designed = to communicate between users is much less important compared to the = benefits its architecture brings in. If people use SIP to create a recvonly session = with an IP camera in their house to monitor security from their IMS (SIP) = enabled cell phone, how is that different from controlling any other = device?

 




--
Arjun Roychowdhury

------_=_NextPart_001_01CA5B79.5011B966-- From shidan@gmail.com Sun Nov 1 21:18:36 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A833A69A3 for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 21:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=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 UzB4pun+moHC for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 21:18:35 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id C3D193A68C2 for <6lowapp@ietf.org>; Sun, 1 Nov 2009 21:18:34 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so351996eya.51 for <6lowapp@ietf.org>; Sun, 01 Nov 2009 21:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2brNNa9FzeUcqwpx9y4ODbh4XYAmAoNGcmJO23+yNuM=; b=bQMpPZzeJMN9UpQT20xvGzXiUWuURZ0rwZskeA0/1FcPyQXJk2Tb0GMctAAlrjm0XW zvcd6QY08lQ68EtPtDnoHNRJJSRizKOa/CNd0r5d6pB2WOfZl9nl4CNtNwFjfW4nE7FB /Ale8FsZiJ0qGjIp6IEh39YNrvnGZRpxbNYAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AYiJYTffMeALq3dMUc1KiZrCk0bIr7eFKhvwBXCQdNy3SCWAfImo3omjvjbZ/ZJGGO UA8FCh7tih/lMc5JuXIB2O4EuzIPEPcZIG95W2GdnSX3WMKS3EvKwCgC9A5EUgZGLzyx Uaa0YHOPkxRR34vSDGjToa/WDLMvA5Y0KrB6I= MIME-Version: 1.0 Received: by 10.216.87.144 with SMTP id y16mr3877040wee.95.1257139131141; Sun, 01 Nov 2009 21:18:51 -0800 (PST) In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA010443@XMB-RCD-101.cisco.com> References: <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <71DDE42E-E6D4-49D7-8F2E-699FBBDBAC12@cisco.com> <00FC4AA684E90E4DA2FF71021CD5A6CA010443@XMB-RCD-101.cisco.com> Date: Mon, 2 Nov 2009 00:18:51 -0500 Message-ID: <429b380e0911012118u4eb458c7pfceff53a6fed6fd0@mail.gmail.com> From: Shidan To: "Sanjay Sinha (sanjsinh)" Content-Type: multipart/alternative; boundary=0016e6d7852e584f2d04775c83cb Cc: Don Sturek , 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 05:18:37 -0000 --0016e6d7852e584f2d04775c83cb Content-Type: text/plain; charset=ISO-8859-1 Yes, we actually have discussed in depth many use cases and something on both my plate and Arjun's is to share use cases and and a white paper with this group on benefits of using a binary SIP protocol. We will include a matrix of summarizing some of the concerns that members of this group have shown with real numbers, which is something I think is really needed. Hopefully this will be of help to the group in Hiroshima. "I think Paul is talking about verbose nature of SIP and also the parsing of headers and message body that is required and whether the processing cost fits into the requirement for low power embedded devices." This is valid a valid concern and I think after understanding the system we are proposing, you will be pleasantly surprised. --- Shidan Gouran On Sun, Nov 1, 2009 at 11:56 PM, Sanjay Sinha (sanjsinh) wrote: > Are there any use cases which require session to be established between > the devices? > > > > I am new to this community, but from the discussions that I have seen so > far, looks like most of the use cases require a request-response transaction > and not a session between two devices or groups of devices. I am also not > sure about real time properties that the applications in this space will > have, for which SIP can be used. > > > > I would think that SIP event notification mechanism can be used for things > like monitoring the temperature, usage etc. > > > > I am not saying SIP can not be used and I do not have a very good knowledge > of use cases, but I think a starting point would be to come up with some > scenarios where session characteristics can be used. > > > > Sanjay > > > > > > > > > *From:* 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] *On > Behalf Of *Arjun Roychowdhury > *Sent:* Monday, November 02, 2009 2:37 AM > *To:* Cullen Jennings (fluffy) > *Cc:* Don Sturek; 6lowapp@ietf.org > > *Subject:* Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > > > > > On Sat, Oct 31, 2009 at 12:29 PM, Cullen Jennings > wrote: > > > On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > > In order of complexity... > > > 1) simple set of fixed variables that could be controlled > > 2) a single flat list of dynamically changeable set of variables that can > can take on simple types (I might place IPFIX as being somewhat close to > this model) > > 3) a hierarchical list of variables that can be related (I'd place basic > usage SNMP roughly in this category but more advanced usage of SNMP probably > can do category 4) > > 4) a REST based approach (I'd place HTTP REST in this case) > > 5) a full RPC model (I'd place CORBA in this class) > > Every use case I have seen so far could be solved by 3, 4, or 5. I think > most people have expressed an opinion that about 4 looks about the right > level of flexibility for this. So the questions is, if there is pretty good > agreement on that, then I think we should just roll with it as tentative > decision and see what it starts looking like as a design evolves. As the > design evolves, one may find this was a bogus choice and need to revisit it. > If you think there is a strong argument for 3 or 5 or even 1 or 2, lets get > that info out on the list. > > > > ARC> Right. If every use case can be solved by 4, and if an HTTP UA stack > is not an overkill for these devices, then I'd venture out to say that if > the need exists, then we should have a protocol that serves that need. My > argument is for something inbetween 4) and 5) - that is some session > oriented protocol, if one believes there will be sessions and an offer > answer needed. I mention SIP only because that is the one I know well. I am > not religious about SIP, but I am particular about a need. > > > > And now, here is why some of us are putting across the fact that at the > least SIP needs to be evaluated: > > (And I know you are well aware of SIP yourself, but I am putting some of > these across for others who may not be) > > > > a) Size/Performance: Simply put, if an HTTP UA is ok, then a minimalistic > SIP UA not being ok is highly suspect. I doubt folks making this statement > have actually evaluated how much a session oriented protocol can be reduced > when it comes to implementation. I've personally worked on SIP UAs that > compress to 30K or less. How much of features you want to put in depends on > the network. Given a network, you can feature compromise. This entire > argument of verbosity vs. optimization is doubtful until you lay down > specific #s that need to be met (and why those #s exist) > > > > b) Can SIP do everything HTTP can?: First, SIP can offer everything HTTP > can. Payloads? check. URI addressing schemes and REST based services. Check. > (http://myhome.com?remote=channel12 can be sip:remote@myhome.com;channel=12) > etc. > > > > c) What can SIP do better than HTTP? > > c.1) Offer-Answer, capability, discovering the minimal feature set that > works between two or more devices > > > > c.2) SIP works on more transport protocols than HTTP (yes, I am aware of > HTTP over UDP, but if we look at live deployments, almost all HTTP systems > use TCP. So if there is a communication needed from a non TCP network to > your HAN, welcome gateways. Almost all SIP deployments I know of today do > both TCP and UDP.) > > > > c.3) Routing & Reachability: SIP's architecture of loose routing, forking, > etc. > > > > c.4) Concept of a 'session' & 'session control' - SIP establishes a session > between one or more devices. These sessions can be transferred to any other > entity if required, monitored, or modified. > > > > Basically, SIP is HTTP+Sessions and an architecture to manage sessions. > > > > 1) what other protocols mapping should we do? > > > 2) Given some people want HTTP, can you live with the answer to HTTP being > yes and understanding that just because we said yes to HTTP does not mean we > are saying no to everything else? > > > > > > ARC> 1) SIP. > > 2) Yes. > > > > -- > Arjun Roychowdhury > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > --0016e6d7852e584f2d04775c83cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, we actually have discussed in depth many use cases and something on bo= th my plate and Arjun's is to share use cases and and a white paper wit= h this group on benefits of using a binary SIP protocol. We will include a = matrix of summarizing some of the concerns that members of this group have = shown with real numbers, which is something I think is really needed. Hopef= ully this will be of help to the group in Hiroshima.

"I think Paul is talking about verbose nature of SIP and als= o the parsing of headers and message body that is required and whether the = processing cost fits into the requirement for low power embedded devices.&q= uot;

This is valid a valid concern and I think after under= standing the system we are proposing, you will be pleasantly surprised.

---
Shidan Gouran

On Sun, Nov 1, 2009 at 11:56 PM, Sanjay Sinha (sanjsinh) <sanjsinh@cisco.com> wrote:

Are t= here any use cases which require session to be established between the devices?

=A0

I am = new to this community, but from the discussions that I have seen so far, looks like most of the use cases require a request-response tr= ansaction and not a session between two devices or groups of devices. =A0I am also no= t sure about real time properties that the applications in this space will ha= ve, for which SIP can be used.

=A0

I wou= ld think that SIP event notification mechanism can be used for things like monitoring the temperature, usage etc.

=A0

I am = not saying SIP can not be used and I do not have a very good knowledge of use cases, but I think a starting point would be to come = up with some scenarios where session characteristics can be used.

=A0

Sanja= y

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=

=A0

=A0

From:= 6lowapp-bounc= es@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Arjun Roychowdhury
Sent: Monday, November 02, 2009 2:37 AM
To: Cullen Jennings (fluffy)
Cc: Don Sturek; 6lowapp@ietf.org


Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

=A0

=A0

On Sat, Oct 31, 2009 at 12:29 PM, Cullen Jennings &l= t;fluffy@cisco.com> wrote:


On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:

In order of complexity...


1) simple set of fixed variables that could be controlled

2) a single flat list of dynamically changeable set of variables that can c= an take on simple types (I might place IPFIX as being somewhat close to this model)

3) a hierarchical list of variables that can be related (I'd place basi= c usage SNMP roughly in this category but more advanced usage of SNMP probably can = do category 4)

4) a REST based approach (I'd place HTTP REST in this case)

5) a full RPC model (I'd place CORBA in this class)

Every use case I have seen so far could be solved by 3, 4, or 5. I think mo= st people have expressed an opinion that about 4 looks about the right level o= f flexibility for this. So the questions is, if there is pretty good agreemen= t on that, then I think we should just roll with it as tentative decision and se= e what it starts looking like as a design evolves. As the design evolves, one= may find this was a bogus choice and need to revisit it. If you think there is = a strong argument for 3 or 5 or even 1 or 2, lets get that info out on the li= st.

=A0

ARC> Right. If every use case can be solved by 4,= and if an HTTP UA stack is not an overkill for these devices, then I'd venture= out to say that if the need exists, then we should have a protocol that serves tha= t need. My argument is for something inbetween 4) and 5) - that is some sessi= on oriented protocol, if one believes there will be sessions and an offer answ= er needed. I mention SIP only because that is the one I know well. I am not religious about SIP, but I am particular about a need.=A0

=A0

And now, here is why some of us are putting across t= he fact that at the least SIP needs to be evaluated:

(And I know you are well aware of SIP yourself, but = I am putting some of these across for others who may not be)

=A0

a) Size/Performance: Simply put, if an HTTP UA is ok= , then a minimalistic SIP UA not being ok is highly suspect. I doubt folks making th= is statement have actually evaluated how much a session oriented protocol can = be reduced when it comes to implementation. I've personally worked on SIP = UAs that compress to 30K or less. How much of features you want to put in depends on= the network. Given a network, you can feature compromise. This entire argument = of verbosity vs. optimization is doubtful until you lay down specific #s that = need to be met (and why those #s exist)

=A0

=A0

c) What can SIP do better than HTTP?

c.1) Offer-Answer, capability, discovering the minim= al feature set that works between two or more devices

=A0

c.2) SIP works on more transport protocols than HTTP= (yes, I am aware of HTTP over UDP, but if we look at live deployments, almost all H= TTP systems use TCP. So if there is a communication needed from a non TCP netwo= rk to your HAN, welcome gateways. Almost all SIP deployments I know of today d= o both TCP and UDP.)

=A0

c.3) Routing & Reachability: SIP's architect= ure of loose routing, forking, etc.=A0

=A0

c.4) Concept of a 'session' & 'sessi= on control' - SIP establishes a session between one or more devices. These sessions can be transferred to any other entity if required, monitored, or modified.

=A0

Basically, SIP is =A0HTTP+Sessions and an architectu= re to manage sessions.

=A0

1) what other protocols mapping should we do?


2) Given some people want HTTP, can you live with the answer to HTTP being = yes and understanding that just because we said yes to HTTP does not mean we ar= e saying no to everything else?

=A0

=A0

ARC> 1) SIP.=A0

2) Yes.=A0

=A0

--
Arjun Roychowdhury


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp


--0016e6d7852e584f2d04775c83cb-- From jukka.manner@tkk.fi Mon Nov 2 01:22:07 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1993A69F9 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 01:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418, 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 mYkmlL7kfuba for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 01:22:06 -0800 (PST) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by core3.amsl.com (Postfix) with ESMTP id 782313A69F5 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 01:22:03 -0800 (PST) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id nA29MGEs009993; Mon, 2 Nov 2009 11:22:16 +0200 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 30412-352-3; Mon, 2 Nov 2009 11:22:16 +0200 (EET) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id nA29Kwin009720; Mon, 2 Nov 2009 11:20:58 +0200 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 6E9D61E140; Mon, 2 Nov 2009 11:20:58 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eKeAaH1xsQjw; Mon, 2 Nov 2009 11:20:54 +0200 (EET) Received: from mailsrv.netlab.hut.fi (mailsrv.netlab.hut.fi [130.233.154.190]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 058AC1E086; Mon, 2 Nov 2009 11:20:54 +0200 (EET) Received: from [130.233.154.59] (pc59.netlab.hut.fi [130.233.154.59]) by mailsrv.netlab.hut.fi (Postfix) with ESMTP id D023F120050; Mon, 2 Nov 2009 11:20:52 +0200 (EET) Message-ID: <4AEEA479.3080603@tkk.fi> Date: Mon, 02 Nov 2009 11:20:57 +0200 From: Jukka Manner User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Cullen Jennings References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <4AE9A4C8.4030402@tkk.fi> <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> In-Reply-To: <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> Content-Type: multipart/mixed; boundary="------------050305060308060807050406" X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Cc: Don Sturek , 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 09:22:07 -0000 This is a multi-part message in MIME format. --------------050305060308060807050406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My main point was that if you read the charter text as it is written, it seems to imply that the work will be something new, and not necessarily targeted to sensor networks, but more generic. I would have put into the charter something that directly ties the WG to existing work, e.g. "It is not the intention of 6lowapp to work on new transport and routing solutions [for sensor networks or whatever constraint environments]. The work is specifically tied to and intended to be layered on top of existing work done in the 6lowpan and Roll working groups, to name a few." cheers, Jukka Cullen Jennings wrote: > > On Oct 29, 2009, at 8:20 , Jukka Manner wrote: > >> 1. This seems to indicate that 6lowapp will not be tied to any >> existing work, it will work on its own goals, but in collaboration >> with others (which is somewhat open as what it means). I would have >> expected that 6lowapp would specifically look at existing work in >> related WGs and see how build on top of that. > > My mistake - I did not mean to imply that it was not layered on top of > closely related existing work. I think most people assumed that this > would run on top of a LoPAN but it seemed they also wanted it to be able > to run on top of a other things including a normal IP LAN and WAN. > Clearly this is all about same use cases as 6LoPAN and ties closing with > 6LoPAN and ROLL as well as work going on at many other SDOs. However, > I'm not sure what needs to be said. Are WG drafts with use case / > requirements from other WG that we should be referencing? Give me ideas > on what things you were thinking here. Clearly the IESG would not be > keen on chartering a new WG to do something another WG was already > charted to do - repeating work in two places seldom ends well :-) Can > you suggest some specific text for the charter that you think would have > fairly wide consent and captures what you are looking for here? > > --------------050305060308060807050406 Content-Type: text/x-vcard; charset=utf-8; name="jukka_manner.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="jukka_manner.vcf" begin:vcard fn:Jukka Manner n:Manner;Jukka org:Helsinki University of Technology (TKK);Department of Communications and Networking (Comnet) adr:(Visiting address: Otakaari 5 A);;P.O.Box 3000;TKK;;02015;Finland email;internet:jukka.manner@tkk.fi title:Professor, PhD. tel;work:+358-9-4512481 tel;fax:+358-9-4512474 tel;cell:+358-50-5112973 x-mozilla-html:FALSE url:http://comnet.tkk.fi version:2.1 end:vcard --------------050305060308060807050406-- From arjunrc@gmail.com Sun Nov 1 13:09:54 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A75228C11A for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 A03MClz8sNEN for <6lowapp@core3.amsl.com>; Sun, 1 Nov 2009 13:09:53 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 7E3583A682B for <6lowapp@ietf.org>; Sun, 1 Nov 2009 13:09:53 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so1167564qwb.31 for <6lowapp@ietf.org>; Sun, 01 Nov 2009 13:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=UiRrPzbXCSg61cjCgDIw8B/gcCchtOHkv/wHEXMs4sc=; b=dtO5yG09jhGkfJZ7OSPaJaZwV2QBTHewuTt6OPDtNcIPEi/c+b0S8X2kaYEwWiydNv t6uiy/4ev/qtZ7lwMgjSLi0gfTvyL7hXtTo2y0W30EjsdYEUQ84S8D09S/tPNQh80EuP fiEMPUfDbDfjw/cPfufCj2c5eIYawXdBJirm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=gTOykkEBjHvEBQNr+j5/jojErapu+YTeDHv3+Ireyehy1tqXOMHJPRrFQs0cNSffYW xakvz2cn8kKjjJoRKF/wcIXZxz71Kz5nhKcr5eW5TKQnw3Wsk+p0dq6mXwQ/9PmaW3Qf MQnuXE0Myhf3T5TzcUTMD3YrItJhp6iXBKro8= MIME-Version: 1.0 Received: by 10.224.48.4 with SMTP id p4mr2426061qaf.231.1257109809255; Sun, 01 Nov 2009 13:10:09 -0800 (PST) In-Reply-To: <4AEDC3FD.3040801@cisco.com> References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <4AEDC3FD.3040801@cisco.com> From: Arjun Roychowdhury Date: Sun, 1 Nov 2009 16:09:49 -0500 Message-ID: To: paduffy@cisco.com Content-Type: multipart/alternative; boundary=000fea892bfb9fd72c047755af61 X-Mailman-Approved-At: Mon, 02 Nov 2009 02:50:28 -0800 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2009 21:09:54 -0000 --000fea892bfb9fd72c047755af61 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 1, 2009 at 12:23 PM, Paul Duffy wrote: > Hi Donn, > > > We welcome other suggestions like XMPP and SIP but we did look at those >> and >> ruled them out for reasons like: >> 1) Verboseness (using text string exchanges for devices with very small >> transmit/receive packet sizes) >> 2) Session management overhead >> >> > > > SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered > intent. > > But XMPP gives me pause... > > ARC> Why is that so? SIP is a protocol to communicate between one or more entities. The fact that it was originally designed to communicate between users is much less important compared to the benefits its architecture brings in. If people use SIP to create a recvonly session with an IP camera in their house to monitor security from their IMS (SIP) enabled cell phone, how is that different from controlling any other device? --000fea892bfb9fd72c047755af61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Nov 1, 2009 at 12:23 PM, Paul Du= ffy <paduffy@cisc= o.com> wrote:
Hi Donn,


We welcome other suggestions like XMPP and SIP but we did look at those and=
ruled them out for reasons like:
1) =A0Verboseness (using text string exchanges for devices with very small<= br> transmit/receive packet sizes)
2) =A0Session management overhead
=A0


SIP in the Smart Grid HAN seems a fundamental misfit to SIPs chartered inte= nt.

But XMPP gives me pause...


ARC> Why is that so? SIP is a proto= col to communicate between one or more entities. The fact that it was origi= nally designed to communicate between users is much less important compared= to the benefits its architecture brings in. If people use SIP to create a = recvonly session with an IP camera in their house to monitor security from = their IMS (SIP) enabled cell phone, how is that different from controlling = any other device?


--000fea892bfb9fd72c047755af61-- From kerlyn2001@gmail.com Mon Nov 2 05:32:08 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3B03A6A2E for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 05:32:08 -0800 (PST) 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 9F-SkZHVgcCX for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 05:32:08 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id E449F3A69C0 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 05:32:07 -0800 (PST) Received: by bwz23 with SMTP id 23so6325073bwz.29 for <6lowapp@ietf.org>; Mon, 02 Nov 2009 05:32:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Jq0n74ae7bb6nyv0ztPT5+P/26wf1K5KqifbvRr3oCM=; b=a3k3e0W3FCRf7wUp54JF7UufcDX7cV4lP/seyg7XIJ4b4n1tSv3tl/XEh1AcP6e+iO iFneO1Vj3RuNoedFbsFFwkeaxDbkpV3mx6W5NuSN3ICjM8B0nkZe3XN3DO3nx5kZ8BMt GeGWp/BmFZr7y9ZyeCVb/7OjqqMlAQRTMlGuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kzb8txY+O4kbDB1mYYozd3r+t7EjezduATtj6fyxNKIdwkWXj6dMSjf653mFIYZrsH FCgkBPUwYXicli6VITWecfRL0DqbgUZsdGHgJA2Z6rg2CrHLWcv5a1/vfP1JbpvtW3DP duCm8Ix02xIEZLQSMxaeHMBn3/w498EdmTurM= MIME-Version: 1.0 Received: by 10.204.141.18 with SMTP id k18mr3894237bku.139.1257168742142; Mon, 02 Nov 2009 05:32:22 -0800 (PST) Date: Mon, 2 Nov 2009 08:32:22 -0500 Message-ID: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> From: Kerry Lynn To: 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 02 Nov 2009 06:05:28 -0800 Subject: [6lowapp] Newbie questions X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 13:38:38 -0000 Greetings, My name is Kerry Lynn and I hope to contribute to this effort remotely. I am an independent contractor working in the area of building automation and have worked previously in Cisco and Apple network engineering in addition to supporting university research into constrained devices. I hope you will bear with what may be foolish questions as I come up to speed: I tried to access the audio stream and jabber feed from yesterday's meeting but was unable to do so. Is IETF registration necessary? Is it the consensus of the group to support peer-to-peer as well as server-based configurations? The first is what I'd term the "one light, one switch" scenario while the latter would include DHCP, DNS, etc. and perhaps application proxy support. Has anyone considered something like T/TCP as a candidate for transaction support? I know it has been traditionally implemented as a superset of TCP but I suspect it could be much simpler than full TCP if used in a controlled environment such as local communication with a full TCP/HTTP/REST proxy. The security concerns could be addressed simultaneously. Has anyone proposed mDNS/DNS-SD as an alternative to SLP? Does anyone have a feeling for how one client implementation compares to the other in terms if complexity? Thanks, -K- From d.sturek@att.net Mon Nov 2 06:16:31 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D4B63A6806 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 06:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.052 X-Spam-Level: X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 sdJMvX7LBpIi for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 06:16:30 -0800 (PST) Received: from smtp105.sbc.mail.gq1.yahoo.com (smtp105.sbc.mail.gq1.yahoo.com [67.195.14.108]) by core3.amsl.com (Postfix) with SMTP id C4E103A659B for <6lowapp@ietf.org>; Mon, 2 Nov 2009 06:16:30 -0800 (PST) Received: (qmail 79610 invoked from network); 2 Nov 2009 14:16:48 -0000 Received: from adsl-69-225-120-220.dsl.sndg02.pacbell.net (d.sturek@69.225.120.220 with login) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 02 Nov 2009 06:16:47 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 7sLMTTsVM1nwPP_McC5f1OrjS3UkZGIRa.avVKc1WG92R0Rh4wr12Fo4EkgauwTeXFVdSQcPsyNjGu7O64I.7XiAu_LMsaDnMLhnbBZ2Y1UsV0MVD.Fpj75ORBtVbqIRKIRQR4tcQp2uQNRGNJAHXRHkdinGYFTXFMz5hxm.owZcFPmCMZ0icUMcqSNhSVqKJn7CeyWAqI7jvkBa9EdtUdSN8CYgypJyjhcDLINPF.3LUbFxHAPBrxQcpx8WWt3YqnzqCJK1q3diJVlJMfLCneImf2s4aB7IP845uTv45rDyMbesWr0- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Kerry Lynn'" , <6lowapp@ietf.org> References: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> In-Reply-To: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> Date: Mon, 2 Nov 2009 06:16:44 -0800 Message-ID: <00b501ca5bc7$1ba2bcf0$52e836d0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpbxZYxWWnZaBeQTvCVxNvs/OCQFwAADyrw Content-Language: en-us Subject: Re: [6lowapp] Newbie questions X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 14:16:31 -0000 Hi Kerry, Here is the big problem we keep coming up against in service discovery: 1) Most agent based solutions are deeply unpopular by HAN device manufacturers. Here is why: 1) Many different vendors contribute to devices in the home area network (HAN) 2) No vendor of device "X" wants to have to increase their storage and computing capacity to become the repository of service information for all other devices in the network. 3) HANs are not managed networks where some owning entity would place infrastructure devices Note what I wrote above is for the home area network (HAN). Building automation is another story as there is certainly a building control system in place there. The simplest solution for this for the HAN: Allow individual devices to hold their own service information and provide a unicast/multicast query system to allow for self description of service information. Allow for individual devices on the HAN to form their own queries and get direct responses back from devices matching those service requests. For the I-D I turned in for service discovery, I did use the SLP DA (Directory Agent, I believe) to hold the strings (URI plus service) and had the DA responsible for substituting those for tokens upon request. However, I had in mind that would be all the DA would do and all service discovery was UA (User Agent) based. For a building controls solution (commercial or industrial), the DA could be fully populated an used on the building control system...... Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Kerry Lynn Sent: Monday, November 02, 2009 5:32 AM To: 6lowapp@ietf.org Subject: [6lowapp] Newbie questions Greetings, My name is Kerry Lynn and I hope to contribute to this effort remotely. I am an independent contractor working in the area of building automation and have worked previously in Cisco and Apple network engineering in addition to supporting university research into constrained devices. I hope you will bear with what may be foolish questions as I come up to speed: I tried to access the audio stream and jabber feed from yesterday's meeting but was unable to do so. Is IETF registration necessary? Is it the consensus of the group to support peer-to-peer as well as server-based configurations? The first is what I'd term the "one light, one switch" scenario while the latter would include DHCP, DNS, etc. and perhaps application proxy support. Has anyone considered something like T/TCP as a candidate for transaction support? I know it has been traditionally implemented as a superset of TCP but I suspect it could be much simpler than full TCP if used in a controlled environment such as local communication with a full TCP/HTTP/REST proxy. The security concerns could be addressed simultaneously. Has anyone proposed mDNS/DNS-SD as an alternative to SLP? Does anyone have a feeling for how one client implementation compares to the other in terms if complexity? Thanks, -K- _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From paduffy@cisco.com Mon Nov 2 07:58:28 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2153A68F0 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 07:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 DuWRMVwoX-oe for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 07:58:27 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2C80C3A6A0D for <6lowapp@ietf.org>; Mon, 2 Nov 2009 07:58:27 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsGAJOQ7kqtJV2c/2dsb2JhbACPZbY2gRoIAZVBhDwE X-IronPort-AV: E=Sophos;i="4.44,667,1249257600"; d="scan'208";a="66024542" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 02 Nov 2009 15:58:46 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id nA2FwkXd007504; Mon, 2 Nov 2009 15:58:46 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 10:58:46 -0500 Received: from [161.44.65.115] ([161.44.65.115]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 10:58:45 -0500 Message-ID: <4AEF01B5.7020208@cisco.com> Date: Mon, 02 Nov 2009 10:58:45 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Sanjay Sinha (sanjsinh)" References: <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com><2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com><4AEDC3FD.3040801@cisco.com> <00FC4AA684E90E4DA2FF71021CD5A6CA010444@XMB-RCD-101.cisco.com> In-Reply-To: <00FC4AA684E90E4DA2FF71021CD5A6CA010444@XMB-RCD-101.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2009 15:58:45.0722 (UTC) FILETIME=[5BA593A0:01CA5BD5] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 15:58:28 -0000 Sanjay Sinha (sanjsinh) wrote: > > I think Paul is talking about verbose nature of SIP and also the > parsing of headers and message body that is required and whether the > processing cost fits into the requirement for low power embedded devices. > That's only part of the issue. HAN will need req/resp, pub/sub, async one way messaging patterns, etc.. Req/resp RPC starts to get pretty weird over SIP. Whereas it is a fully supported pattern in XMPP world. > > > Sanjay > > > > *From:* 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] *On > Behalf Of *Arjun Roychowdhury > *Sent:* Monday, November 02, 2009 2:43 AM > *To:* Paul Duffy (paduffy) > *Cc:* 6lowapp@ietf.org > *Subject:* Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > > > responding from my subscribed email id incase the previous one does > not make it to this list: > > On Sun, Nov 1, 2009 at 4:09 PM, Arjun Roychowdhury > wrote: > > > > SIP in the Smart Grid HAN seems a fundamental misfit to SIPs > chartered intent. > > But XMPP gives me pause... > > > > > > > > ARC> Why is that so? SIP is a protocol to communicate between one or > more entities. The fact that it was originally designed to communicate > between users is much less important compared to the benefits its > architecture brings in. If people use SIP to create a recvonly session > with an IP camera in their house to monitor security from their IMS > (SIP) enabled cell phone, how is that different from controlling any > other device? > > > > > > > -- > Arjun Roychowdhury > From arjunrc@gmail.com Mon Nov 2 08:17:06 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E443A680B for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 08:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.075, 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 SH7hppkzeHwR for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 08:17:06 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 0B39F3A67AF for <6lowapp@ietf.org>; Mon, 2 Nov 2009 08:17:05 -0800 (PST) Received: by qyk41 with SMTP id 41so2617792qyk.29 for <6lowapp@ietf.org>; Mon, 02 Nov 2009 08:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=/X2IbJzy+gZPrONnMRXGw5k3GHbYEfxyi8QUIFd/UnQ=; b=tI6a1prUUQSLySeVfrr3lQLsMbzB98ZbWSjoGSPP+1RoaxGIvhuQk40tQuSsIpb1Xm 0wqt2N67VAmp4Btz6vUKU7uWCFzouMPiOIEhR2OD9ItfR7xU+LvHHfi6z5nelDvh6uih YsolhVYE8MuNIUaeJ79aIPNw4EAlTir/2EEAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=x6oXwvxM5cAYRSLwuzvPGmT/QyIxj0dl6GTxutgIvVGJC/gp3tQkJcZD3aM4UseMEc mP5o/xt6x3DEjQ+9LrK1GuTvRYLVHRQ2CQ9MiGDl7jDwgS9t5MLZqy4obJtxSy1Pwl+d zh/aKJ9tP9auDBExxvd1sGYVr1wQ+Nqu1P7L0= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.96.100 with SMTP id g36mr2930730qan.384.1257178643277; Mon, 02 Nov 2009 08:17:23 -0800 (PST) In-Reply-To: <4AEF01B5.7020208@cisco.com> References: <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <6C14D98B-4B4D-44B8-B8A5-1BEA5A8F443C@cisco.com> <4AEDC3FD.3040801@cisco.com> <00FC4AA684E90E4DA2FF71021CD5A6CA010444@XMB-RCD-101.cisco.com> <4AEF01B5.7020208@cisco.com> From: Arjun Roychowdhury Date: Mon, 2 Nov 2009 11:17:03 -0500 X-Google-Sender-Auth: 9b5ffe6b847c97fb Message-ID: To: paduffy@cisco.com Content-Type: multipart/alternative; boundary=00c09f9c98fd73aec7047765b6e2 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 16:17:06 -0000 --00c09f9c98fd73aec7047765b6e2 Content-Type: text/plain; charset=ISO-8859-1 Some notes: HAN will need req/resp, ARC> SIP: MESSAGE/OK, OPTIONS/OK In addition, SIP can exchange these as part of a session, or out of it. pub/sub, ARC> SIP: SUBSCRIBE/NOTIFY/PUBLISH async one way messaging patterns, etc.. ARC> SIP: Implicit notifications (3GPP uses it, for example), but yes, specs do require an OK in response. I am interested in this part. When you mean one way, you mean no return acknowledgement from the peer at the application level? What sort of scenarios is that required for? Req/resp RPC starts to get pretty weird over SIP. Whereas it is a fully supported pattern in XMPP world. ARC> Only if you tag the word RPC after request response :) On the other hand if one views it as a SIP message with an XML payload, then it fits perfectly. regds arjun --00c09f9c98fd73aec7047765b6e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some notes:

HAN will need req/resp,=A0
<= div>
ARC> SIP: MESSAGE/OK, OPTIONS/OK
In additio= n, SIP can exchange these as part of a session, or out of it.

pub/sub,=A0

ARC> SIP:= SUBSCRIBE/NOTIFY/PUBLISH

async one way messaging = patterns, etc..=A0

ARC> SIP: Implicit notificat= ions (3GPP uses it, for example), but yes, specs do require an OK in respon= se. I am interested in this part. When you mean one way, you mean no return= acknowledgement from the peer at the application level? What sort of scena= rios is that required for?

=A0Req/resp RPC starts to get pretty weird over SIP. = =A0Whereas it is a fully supported pattern in XMPP world.

ARC> Only if you tag the word RPC after request response :) On t= he other hand if one views it as a SIP message with an XML payload, then it= fits perfectly.

regds
arjun


--00c09f9c98fd73aec7047765b6e2-- From lars.eggert@nokia.com Mon Nov 2 16:04:46 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9103A6867 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 16:04:46 -0800 (PST) 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=[AWL=0.000, 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 dFB+MODn7Jlm for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 16:04:46 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 689843A681F for <6lowapp@ietf.org>; Mon, 2 Nov 2009 16:04:21 -0800 (PST) Received: from [10.48.43.142] ([67.98.70.2]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA304NEK069802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 02:04:25 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-69--273420525; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> Date: Mon, 2 Nov 2009 16:04:13 -0800 Message-Id: <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 03 Nov 2009 02:04:26 +0200 (EET) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 00:04:46 -0000 --Apple-Mail-69--273420525 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-10-31, at 10:33, Cullen Jennings wrote: > I could go dig a 9600 baud modem out of my closet, set the MTU at 100, > and emulate 10% packet loss on server side and go try some things. I'm > relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all > work just fine. if by "work" you mean, "complete in some finite time", then yes mostly. (Mostly, because there are timeouts that may kick in when a connection is stalled for too long.) But my guess is that performance would be extremely horrible (as in orders of magnitude worse than with more reasonable loss rates <1%.) Lars --Apple-Mail-69--273420525 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzAwMDQxNFowIwYJKoZIhvcNAQkEMRYEFEKLjKrFH9BvSRS2MElpx0KZRIv6MIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAAssGioNrUn0jKUH7w8XeBxNjHuw9eJFN8pD8yECt3iPMVLfWshX2BIvk3IjMwydUd7BWh UM/G6IYPWBGXKsvPnes8lXI8V0q+QNwnHt0qASf61RuZczQSubQGCson0ZLHej2NhqvDtcVBPJTG HfUQO8+6lxeqPgZ5AtEWx2WNM8XVXZiH7KvvXrowyJm/MUAOF4MDNLJ+c5dNswuFEoapV0bLEli5 VOcf18xKh/g/P1huoi/pvYwnjB11PcZdr4Nz1mzy/LiFq8VizuZ5TJd9eGUS87LiS/d+zgCzPW63 Q4Rh0KoskFKZAbyyGDI5YehCRrDrblqwwtvBq7p2FdCnAAAAAAAA --Apple-Mail-69--273420525-- From lars.eggert@nokia.com Mon Nov 2 16:13:41 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC8128C141 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 16:13:41 -0800 (PST) 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 2PU3Qs1abg-f for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 16:13:40 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 9459A28C13F for <6lowapp@ietf.org>; Mon, 2 Nov 2009 16:13:40 -0800 (PST) Received: from [10.48.43.142] ([67.98.70.2]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA30Docd070398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 02:13:52 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-70--272854180; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> Date: Mon, 2 Nov 2009 16:13:39 -0800 Message-Id: <888AF4E5-9DE1-4A3A-8C9B-C498D2B30CE0@nokia.com> References: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> To: Kerry Lynn X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 03 Nov 2009 02:13:53 +0200 (EET) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Newbie questions X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 00:13:41 -0000 --Apple-Mail-70--272854180 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On 2009-11-2, at 5:32, Kerry Lynn wrote: > Has anyone considered something like T/TCP as a candidate for > transaction support? I know it has been traditionally implemented > as a superset of TCP but I suspect it could be much simpler than > full TCP if used in a controlled environment such as local > communication with a full TCP/HTTP/REST proxy. The security > concerns could be addressed simultaneously. T/TCP could be an option, if its security/DoS drawbacks are not considered to be an issue in these scenarios. Lars --Apple-Mail-70--272854180 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzAwMTM0MFowIwYJKoZIhvcNAQkEMRYEFCYEW4YQZe40LoT60Vnm/fOFgESBMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDNSFtulzDqAv4t1i8HSykNr7BxM1d3N3KaGWJrSlg9riZA20sRqxa5g0GDtjE+rBzmCUZa COD5JHNpeULZXY1MhtW/cSvUk7byGdga+k/0ucEDT29JPV2zaaTwugJBKiNROLlzlhPDOEd3SHkG za01QF2ELuuM7Lx1b2+2Vn6L9E39xKO0xwgrB69cuiUaiSRehDJ6dki8YNrsEVVAO7zcoTUbCjJ/ Y4a7yPTfdj0dZCSRigsmU1JhRUwW6Emo8N7SMMMFVQH2Fu2JpTSopaIsvBK88zlb55YFaIVw56q5 DBfAkhEuI/Rs1/0hZQP8dP1ZkX21Egiju+Aj5vOCtcp3AAAAAAAA --Apple-Mail-70--272854180-- From pister@eecs.berkeley.edu Mon Nov 2 17:10:56 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F70C3A6867 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 17:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.215 X-Spam-Level: X-Spam-Status: No, score=-6.215 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jaDAeJDi0GcQ for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 17:10:54 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 477383A6862 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 17:10:54 -0800 (PST) Received: from [128.32.32.46] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nA31B95I005224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Nov 2009 17:11:10 -0800 (PST) Message-ID: <4AEF832C.9050603@eecs.berkeley.edu> Date: Mon, 02 Nov 2009 17:11:08 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lars Eggert References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> In-Reply-To: <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> Content-Type: multipart/alternative; boundary="------------080406060101040906070507" Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 01:10:56 -0000 This is a multi-part message in MIME format. --------------080406060101040906070507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lars - What's the best way to judge if a protocol stack will support TCP? I assume that it's some combination of end-to-end reliability and latency, and the statistics that govern them. In the early days of sensor networks it was not uncommon to see end-to-end best-effort loss rates of 10% or more. I don't think that anyone tolerates that kind of performance anymore. With link-layer ACKs and path diversity in the routing layer I think that 99.9% for best-effort is now table stakes. Is that good enough for TCP? If it's not, how many nines do I need? What kind of constraints are there on the latency distribution? Clearly Adam and his students have gotten TCP to work over multi-hop, deeply duty-cycled 15.4 radios. I think that there are probably several others who have as well. Any feedback from people who have tried and failed? ksjp Lars Eggert wrote: > Hi, > > On 2009-10-31, at 10:33, Cullen Jennings wrote: >> I could go dig a 9600 baud modem out of my closet, set the MTU at 100, >> and emulate 10% packet loss on server side and go try some things. I'm >> relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all >> work just fine. > > if by "work" you mean, "complete in some finite time", then yes > mostly. (Mostly, because there are timeouts that may kick in when a > connection is stalled for too long.) But my guess is that performance > would be extremely horrible (as in orders of magnitude worse than with > more reasonable loss rates <1%.) > > Lars > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --------------080406060101040906070507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Lars -
 What's the best way to judge if a protocol stack will support TCP? I assume that it's some combination of end-to-end reliability and latency, and the statistics that govern them.
In the early days of sensor networks it was not uncommon to see end-to-end best-effort loss rates of 10% or more.  I don't think that anyone tolerates that kind of performance anymore.  With link-layer ACKs and path diversity in the routing layer I think that 99.9% for best-effort is now table stakes.  Is that good enough for TCP?  If it's not, how many nines do I need?  What kind of constraints are there on the latency distribution?

Clearly Adam and his students have gotten TCP to work over multi-hop, deeply duty-cycled 15.4 radios.  I think that there are probably several others who have as well.  Any feedback from people who have tried and failed?

ksjp

Lars Eggert wrote:
Hi,

On 2009-10-31, at 10:33, Cullen Jennings wrote:
I could go dig a 9600 baud modem out of my closet, set the MTU at 100,
and emulate 10% packet loss on server side and go try some things. I'm
relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all
work just fine.

if by "work" you mean, "complete in some finite time", then yes mostly. (Mostly, because there are timeouts that may kick in when a connection is stalled for too long.) But my guess is that performance would be extremely horrible (as in orders of magnitude worse than with more reasonable loss rates <1%.)

Lars

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
--------------080406060101040906070507-- From lars.eggert@nokia.com Mon Nov 2 17:40:58 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4797E3A6886 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 17:40:58 -0800 (PST) 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 sgu4at0zMqiT for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 17:40:57 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id AEDD93A6882 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 17:40:56 -0800 (PST) Received: from [10.48.43.142] ([67.98.70.2]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA31eY9Q076633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 03:40:36 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-74--267649933; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <4AEF832C.9050603@eecs.berkeley.edu> Date: Mon, 2 Nov 2009 17:40:24 -0800 Message-Id: <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> To: Kris Pister X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 03 Nov 2009 03:40:37 +0200 (EET) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 01:40:58 -0000 --Apple-Mail-74--267649933 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-11-2, at 17:11, Kris Pister wrote: > What's the best way to judge if a protocol stack will support TCP? I > assume that it's some combination of end-to-end reliability and > latency, and the statistics that govern them. yes. > In the early days of sensor networks it was not uncommon to see end- > to-end best-effort loss rates of 10% or more. I don't think that > anyone tolerates that kind of performance anymore. With link-layer > ACKs and path diversity in the routing layer I think that 99.9% for > best-effort is now table stakes. All that certainly helps, but I haven't seen much discussion on whether we all agree that we're only going to target scenarios for 6LOWAPP for which we can make the assumption that such techniques will be in use. > Is that good enough for TCP? If it's not, how many nines do I > need? What kind of constraints are there on the latency distribution? It's really difficult to predict this in general. Basically, the more your link/path looks like a wire, the better TCP will do. That means you want a relatively stable RTT, relatively stable available capacity and not too much (<1%?) loss. The PILC WG published a bunch of very relevant documents, for example, Advice for Internet Subnetwork Designers http://tools.ietf.org/html/rfc3819 End-to-end Performance Implications of Links with Errors http://tools.ietf.org/html/rfc3155 Advice to link designers on link Automatic Repeat reQuest (ARQ) http://tools.ietf.org/html/rfc3366 End-to-end Performance Implications of Slow Links http://tools.ietf.org/html/rfc3150 > Clearly Adam and his students have gotten TCP to work over multi- > hop, deeply duty-cycled 15.4 radios. I think that there are > probably several others who have as well. Any feedback from people > who have tried and failed? I'm not saying that it can't be done in some scenarios - far from it. But there clearly are many scenarios where TCP won't work well. Lars --Apple-Mail-74--267649933 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzAxNDAyNFowIwYJKoZIhvcNAQkEMRYEFEqvEcirDwLhZsgGDVj5McCQTC6JMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQDksTfruTWYqVK2epGr64Llp1IEph0igv5Mws1cK2zp57r1BzK3otPS7tMO0t9iql/lcVtV B/bJKEd4kgq0TQViWlEetsSaGfF2qtkrPbHlEcX3jhcsDQjcakGVPHA4OYJv2Hi/4VQsLVwYWZKc 89cxyUjFC75Fxk8hluKpMYRD9VZ2K4C02lvysBRJibGT531yiSFssUnJnhkygrA0L4FB9VNLd/rH KcKqAKR5iP6RkzSHz8624NEaKo+AkmcI2kO88fFnvSP7+Djw7LXMpwuIM4O184Y47ko61WFt017t U5p2coORZyQ7xqojZTnTt62quZQ+4kfCZnX+iVr3S148AAAAAAAA --Apple-Mail-74--267649933-- From jhui@archrock.com Mon Nov 2 18:23:47 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180533A6961 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 18:23:47 -0800 (PST) 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=[AWL=0.000, 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 2X15oGQ+RapC for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 18:23:46 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 51E493A688D for <6lowapp@ietf.org>; Mon, 2 Nov 2009 18:23:46 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 9CE2CAF83E; Mon, 2 Nov 2009 18:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Um7617SFwTa; Mon, 2 Nov 2009 18:24:02 -0800 (PST) Received: from [10.0.1.199] (adsl-71-142-89-42.dsl.pltn13.pacbell.net [71.142.89.42]) by mail.sf.archrock.com (Postfix) with ESMTP id C4CCAAF838; Mon, 2 Nov 2009 18:24:01 -0800 (PST) Message-Id: <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> From: Jonathan Hui To: Lars Eggert In-Reply-To: <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 18:24:00 -0800 References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> X-Mailer: Apple Mail (2.936) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 02:23:47 -0000 On Nov 2, 2009, at 5:40 PM, Lars Eggert wrote: >> In the early days of sensor networks it was not uncommon to see end- >> to-end best-effort loss rates of 10% or more. I don't think that >> anyone tolerates that kind of performance anymore. With link-layer >> ACKs and path diversity in the routing layer I think that 99.9% for >> best-effort is now table stakes. > > All that certainly helps, but I haven't seen much discussion on > whether we all agree that we're only going to target scenarios for > 6LOWAPP for which we can make the assumption that such techniques > will be in use. There seems to be an implicit assumption that the target link technologies will be similar, if not identical, to those targeted by ROLL. For those networks, Kris is right that providing >99.9% end-to- end success rates with <1% duty cycle for both hosts *and* routers is yesterday's problem. But, yes, we need to be more explicit about what link technologies we are targeting. >> Clearly Adam and his students have gotten TCP to work over multi- >> hop, deeply duty-cycled 15.4 radios. I think that there are >> probably several others who have as well. Any feedback from people >> who have tried and failed? > > I'm not saying that it can't be done in some scenarios - far from > it. But there clearly are many scenarios where TCP won't work well. ... and to decide whether or not TCP will work, we need to flip this thread to a top-down approach and first agree on the application requirements/use cases. I have no doubt we can get TCP to work on a mesh of low-power, lossy links. But are TCP's services/constraints appropriate for the application? I can think of a variety of LLN applications that work just fine with TCP and others that could stand to use something else to improve latency, message efficiency, non p2p flows, multihoming, mobility, etc. -- Jonathan Hui From lars.eggert@nokia.com Mon Nov 2 18:38:52 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C05A3A6884 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 18:38:52 -0800 (PST) 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 dkSHS+-B914h for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 18:38:51 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id D48273A687E for <6lowapp@ietf.org>; Mon, 2 Nov 2009 18:38:50 -0800 (PST) Received: from [172.20.100.59] ([66.201.48.54]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA32co1U083673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 04:38:52 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-75--264149447; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> Date: Mon, 2 Nov 2009 18:38:44 -0800 Message-Id: <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 03 Nov 2009 04:38:54 +0200 (EET) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 02:38:52 -0000 --Apple-Mail-75--264149447 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-11-2, at 18:24, Jonathan Hui wrote: > On Nov 2, 2009, at 5:40 PM, Lars Eggert wrote: > There seems to be an implicit assumption that the target link > technologies will be similar, if not identical, to those targeted by > ROLL. For those networks, Kris is right that providing >99.9% end-to- > end success rates with <1% duty cycle for both hosts *and* routers is > yesterday's problem. But, yes, we need to be more explicit about what > link technologies we are targeting. I also should have mentioned that packet reordering is an issue. TCP basically treats a reordered packet as a loss, so you want that ration to be at most in the same ballpark as your loss ratio. >>> Clearly Adam and his students have gotten TCP to work over multi- >>> hop, deeply duty-cycled 15.4 radios. I think that there are >>> probably several others who have as well. Any feedback from people >>> who have tried and failed? >> >> I'm not saying that it can't be done in some scenarios - far from >> it. But there clearly are many scenarios where TCP won't work well. > > ... and to decide whether or not TCP will work, we need to flip this > thread to a top-down approach and first agree on the application > requirements/use cases. I'm not sure this can work. Sure, we have a set of applications identified now that we can guesstimate the requirements of. But the thing with a network is that once you build it, new apps will come. But there certainly is no harm in thinking about currently identified apps. > I have no doubt we can get TCP to work on a > mesh of low-power, lossy links. I wouldn't agree in to this generic statement. But I do believe that if you make some strong assumptions on radio technologies, routing, etc. that it can be made to work *under those conditions*. > But are TCP's services/constraints > appropriate for the application? I can think of a variety of LLN > applications that work just fine with TCP and others that could stand > to use something else to improve latency, message efficiency, non p2p > flows, multihoming, mobility, etc. That's another question, yes. But I'd see building new transport layer functions for 6LOWAPPs as an activity that would need some very strong ties to the TSV area, if it wouldn't be hosted there in the first place. Lars --Apple-Mail-75--264149447 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzAyMzg0NVowIwYJKoZIhvcNAQkEMRYEFOpvRQx7QZzA2BEHrrsckzsY5jrPMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQAEJa7UWw/CfyMkWMT7u1MG4Rw3236mKtTMJMinIrZvO7V9Bp5YvaWBD3ovX8XQ3YGqSxP4 i/Vqi9kcglY65iCtqDYoNCWVSAsJUhPNatoH3tSXy0wigco7Yat3qFLnpNPD3ZT3v0YIFkfMIkkk b44HYF08oAWqHrmVA9h/CjqIdoK+NnfJg7raxWFu/U1GO+DUaFzXx06BRFfBWQTHyCBF/DWDKkme F770A7G5+8EXhzeDtHyj9UgiYrTLdrFDaXyWFJwtbiIpWt1bAPzFBHKFrTVAL70i8kth34zJIE4v vesd59dZ0px22p0J4ZyXMqBx6qNHamLv/SJMEyrUz0LlAAAAAAAA --Apple-Mail-75--264149447-- From jhui@archrock.com Mon Nov 2 19:14:56 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 591983A67AA for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 19:14:56 -0800 (PST) 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 fgtLRYh8MyhB for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 19:14:55 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 677D03A63EC for <6lowapp@ietf.org>; Mon, 2 Nov 2009 19:14:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id D19DEAF849; Mon, 2 Nov 2009 19:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNHy8PomrsRm; Mon, 2 Nov 2009 19:15:11 -0800 (PST) Received: from [10.0.1.199] (adsl-71-142-89-42.dsl.pltn13.pacbell.net [71.142.89.42]) by mail.sf.archrock.com (Postfix) with ESMTP id B9AC1AF836; Mon, 2 Nov 2009 19:15:10 -0800 (PST) Message-Id: From: Jonathan Hui To: Lars Eggert In-Reply-To: <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 19:15:08 -0800 References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> X-Mailer: Apple Mail (2.936) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 03:14:56 -0000 On Nov 2, 2009, at 6:38 PM, Lars Eggert wrote: > I also should have mentioned that packet reordering is an issue. TCP > basically treats a reordered packet as a loss, so you want that > ration to be at most in the same ballpark as your loss ratio. Of course. There are ways to manage reordering but, as you said, requires making certain assumptions. >> ... and to decide whether or not TCP will work, we need to flip this >> thread to a top-down approach and first agree on the application >> requirements/use cases. > > I'm not sure this can work. Sure, we have a set of applications > identified now that we can guesstimate the requirements of. But the > thing with a network is that once you build it, new apps will come. > But there certainly is no harm in thinking about currently > identified apps. In the general sense, I agree. I was suggesting this as an approach to answering this thread's subject line. Indeed, the question of "will TCP work?" is a harder question. >> I have no doubt we can get TCP to work on a >> mesh of low-power, lossy links. > > I wouldn't agree in to this generic statement. But I do believe that > if you make some strong assumptions on radio technologies, routing, > etc. that it can be made to work *under those conditions*. I agree with you from a strict layering perspective with minimal assumptions about the lower layers. I guess I come from a world where many of the applicable links (802.15.4, PLC, etc.) are still being specified in IEEE (15.4e, 15.4g) and IETF (6lowpan). Members of those groups want to minimize complexity in their respective layers, of course. But some layer has to deal with some of the hard problems. If pushing them into the lower layers is the right long term solution, then I say we guide the current efforts that way. But if we're going to deal with all the hard problems at higher layers, then there's little incentive to do so at the lower layers. >> But are TCP's services/constraints >> appropriate for the application? I can think of a variety of LLN >> applications that work just fine with TCP and others that could stand >> to use something else to improve latency, message efficiency, non p2p >> flows, multihoming, mobility, etc. > > That's another question, yes. But I'd see building new transport > layer functions for 6LOWAPPs as an activity that would need some > very strong ties to the TSV area, if it wouldn't be hosted there in > the first place. Agreed. Though the line seems to be a bit blurred because some suggest building transport-like mechanisms in whatever "app-level" protocol we're working on. -- Jonathan Hui From lars.eggert@nokia.com Mon Nov 2 19:46:48 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE203A6966 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 19:46:48 -0800 (PST) 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=[AWL=0.000, 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 KlXYnmNn+x2V for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 19:46:48 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 7FA4A3A67E3 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 19:46:47 -0800 (PST) Received: from [172.20.100.59] ([66.201.48.54]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA33kgq8087612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 05:46:44 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-76--260077328; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Mon, 2 Nov 2009 19:46:36 -0800 Message-Id: References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 03 Nov 2009 05:46:50 +0200 (EET) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 03:46:49 -0000 --Apple-Mail-76--260077328 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, one quick follow-up. On 2009-11-2, at 19:15, Jonathan Hui wrote: > On Nov 2, 2009, at 6:38 PM, Lars Eggert wrote: >>> I have no doubt we can get TCP to work on a >>> mesh of low-power, lossy links. >> >> I wouldn't agree in to this generic statement. But I do believe that >> if you make some strong assumptions on radio technologies, routing, >> etc. that it can be made to work *under those conditions*. > > I agree with you from a strict layering perspective with minimal > assumptions about the lower layers. I guess I come from a world where > many of the applicable links (802.15.4, PLC, etc.) are still being > specified in IEEE (15.4e, 15.4g) and IETF (6lowpan). Members of those > groups want to minimize complexity in their respective layers, of > course. But some layer has to deal with some of the hard problems. Of course. And currently, because there is more or less a single TCP standard for all deployment cases, a network needs to have certain properties in order for TCP to work well, so that the apps on top of it work well. This so far has meant that lower layers need to implement some functionality that results in a path that approximates the characteristics that TCP expects. (See the PILC documents.) > If pushing them into the lower layers is the right long term solution, > then I say we guide the current efforts that way. But if we're going > to deal with all the hard problems at higher layers, then there's > little incentive to do so at the lower layers. It's definitely debatable whether the approach that we've so far followed (making links and lower-layer network technologies implement stuff so that TCP/IP runs OK) is the One True Answer. As we expand IP into environments that are very different from the "normal" Internet, it's not fully clear (to me at least) whether this approach will continue to be efficient. At the bar BOF in Stockholm, I made a strawman proposal that for 6LOWAPPs, we might instead start thinking about giving up on TCP and implementing a set of end-to-end transport functions that apps can pick & choose from, depending on their needs (reliability, uni/multicast, error protection, loss protection/FEC, flow control, etc.) Those functions may not need to be provided by a separate protocol with a header and a layer in the stack; we might make them available as a common library that apps link against, for example. Lars --Apple-Mail-76--260077328 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzAzNDYzN1owIwYJKoZIhvcNAQkEMRYEFAIf0FBi8hwu8TXoKBpWHo+cnmzhMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQB0sLPr0qcIzIoqasOmkRBeB2efBO0TXcxA4krxtTY8L/1AW0dzFJ8Q5umHRzzJquY98muW 3ThzwU6MPuD/uWFK+M79fT/SlPoeYIeVUUf5MCK0+y29tPt6pczuEF0TLFPoslM54RUyWJzS21F4 IhH85hVsA2bFomo03BmirZc6S3M1RI8CwRUi7F+lrDxtYXG17W6dgYPWcaib13UCa3UpkxC6oNdG GUjstXw6gaQlmQk+h3VwaHhOiT3QlWNp6xNGtEf0exsG1KoIgAuA4Xlg8KY1JCD0H8tPOGvDYL3n HCrqNABZGJMndvYUcSb0EGYPjtAQzi0lqibK3NGCA2I5AAAAAAAA --Apple-Mail-76--260077328-- From jhui@archrock.com Mon Nov 2 20:21:41 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16D83A6843 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 20:21:41 -0800 (PST) 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 vCEPlQP8+d80 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 20:21:41 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 01AD03A672E for <6lowapp@ietf.org>; Mon, 2 Nov 2009 20:21:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id CA713AF8E7; Mon, 2 Nov 2009 20:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGevU5b8TUX0; Mon, 2 Nov 2009 20:21:56 -0800 (PST) Received: from [10.0.1.199] (adsl-71-142-89-42.dsl.pltn13.pacbell.net [71.142.89.42]) by mail.sf.archrock.com (Postfix) with ESMTP id BA901AF836; Mon, 2 Nov 2009 20:21:55 -0800 (PST) Message-Id: <50D02497-17A6-4EF2-AC6E-FE783E48E071@archrock.com> From: Jonathan Hui To: Lars Eggert In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 20:21:53 -0800 References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> X-Mailer: Apple Mail (2.936) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 04:21:41 -0000 On Nov 2, 2009, at 7:46 PM, Lars Eggert wrote: > It's definitely debatable whether the approach that we've so far > followed (making links and lower-layer network technologies > implement stuff so that TCP/IP runs OK) is the One True Answer. Yes. > As we expand IP into environments that are very different from the > "normal" Internet, it's not fully clear (to me at least) whether > this approach will continue to be efficient. At the bar BOF in > Stockholm, I made a strawman proposal that for 6LOWAPPs, we might > instead start thinking about giving up on TCP and implementing a set > of end-to-end transport functions that apps can pick & choose from, > depending on their needs (reliability, uni/multicast, error > protection, loss protection/FEC, flow control, etc.) Those functions > may not need to be provided by a separate protocol with a header and > a layer in the stack; we might make them available as a common > library that apps link against, for example. Certainly sounds like an interesting idea and it would be a breath of fresh air not to be encumbered by TCP. So can we afford to sacrifice interoperability with TCP-based tools/infrastructure? There are clearly people on both sides and it's not clear to me how to come to closure except to recognize both sides for the time being. -- Jonathan Hui From fluffy@cisco.com Mon Nov 2 21:43:59 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2CF23A6948 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 21:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 B8FBev-OmNKB for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 21:43:58 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0732F3A6876 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 21:43:58 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALNR70qrR7Ht/2dsb2JhbADFIJc3hD0E X-IronPort-AV: E=Sophos;i="4.44,672,1249257600"; d="scan'208";a="265234472" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 03 Nov 2009 05:44:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA35iIjb016155; Tue, 3 Nov 2009 05:44:18 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 21:44:18 -0800 Received: from [192.168.4.177] ([10.99.9.18]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 21:44:17 -0800 From: Cullen Jennings To: Jukka Manner , Cullen Jennings In-Reply-To: <4AEEA479.3080603@tkk.fi> Impp: xmpp:cullenfluffyjennings@jabber.org References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <25465_1256798603_ZZ0KS9006DTK09O4.00_C93E77B9-349F-451C-BAED-273555EEE5DE@cisco.com> <4AE9A4C8.4030402@tkk.fi> <241682EE-2552-412D-975E-ED533FDED68D@cisco.com> <4AEEA479.3080603@tkk.fi> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 22:44:16 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 05:44:18.0057 (UTC) FILETIME=[AF381790:01CA5C48] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 05:44:00 -0000 On Nov 2, 2009, at 2:20 AM, Jukka Manner wrote: > "It is not the intention of 6lowapp to work on new transport and > routing solutions [for sensor networks or whatever constraint > environments]. The work is specifically tied to and intended to be > layered on top of existing work done in the 6lowpan and Roll working > groups, to name a few." Great text. That's what I was sort of thinking but failed to say. Let's get that in the next version. From fluffy@cisco.com Mon Nov 2 21:46:15 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513893A68CB for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 21:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0jNF+dAnIb8M for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 21:46:14 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7D6B13A6876 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 21:46:14 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABtT70qrRN+K/2dsb2JhbADFKZc4hD0E X-IronPort-AV: E=Sophos;i="4.44,672,1249257600"; d="scan'208";a="220550906" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2009 05:46:35 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nA35kZE8016029; Tue, 3 Nov 2009 05:46:35 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 21:46:34 -0800 Received: from [192.168.4.177] ([10.99.9.18]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 21:46:34 -0800 From: Cullen Jennings To: Shidan , Cullen Jennings In-Reply-To: <429b380e0910311133k784f8fe8w878f81560fc28800@mail.gmail.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <184E130A-881A-4E1F-8408-FB03A7849A82@sensinode.com> <843F0B9E-8C62-47A6-AFEC-4BE31D62CDB5@cisco.com> <2AA1E2A3-9EA9-4B94-85BA-834C66826A85@tzi.org> <71DDE42E-E6D4-49D7-8F2E-699FBBDBAC12@cisco.com> <429b380e0910311133k784f8fe8w878f81560fc28800@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 22:46:33 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 05:46:34.0731 (UTC) FILETIME=[00AEE3B0:01CA5C49] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 05:46:15 -0000 On Oct 31, 2009, at 12:33 PM, Shidan wrote: > Hi Cullen, I would check the motivational draft Arjun and I > submitted for SIP. > > OK - The way I want to try and derive us towards a decision here is > get a list of candidate protocols then for each one ask the yes/no > is the their agreement that we should do a mapping to that > protocol. The protocols I have heard so far are HTTP, SNMP, SMTP. > So two questions > > 1) what other protocols mapping should we do? > > In general there are many practical applications which are using SIP > and XMPP for M2M communications. This should be a consideration. there seem a fair amount of agreement on this - will add to the list. From fluffy@cisco.com Mon Nov 2 21:46:59 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C56A3A698F for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 21:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 0rbIf7ozPhW7 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 21:46:57 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B8C8D3A698C for <6lowapp@ietf.org>; Mon, 2 Nov 2009 21:46:57 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABtT70qrR7Ht/2dsb2JhbADFKZc4hD0EgWI X-IronPort-AV: E=Sophos;i="4.44,672,1249257600"; d="scan'208";a="423444016" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2009 05:47:17 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA35lISm017967; Tue, 3 Nov 2009 05:47:18 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 21:47:18 -0800 Received: from [192.168.4.177] ([10.99.9.18]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 21:47:16 -0800 From: Cullen Jennings To: Shidan In-Reply-To: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 22:47:15 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 05:47:16.0856 (UTC) FILETIME=[19CAA780:01CA5C49] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 05:46:59 -0000 All these things sound great, but pealing away the excitement how do we find some protocols, that if we define them, would enable the type of exciting intelligent network you are are thinking about. For example, much of what made things like gmail and facebook possible are a handful of technologies: JavaScript, HTML, HTTP, TLS, TCP, DNS, IP and routing. How can we find a few simple technologies that when implemented in standardized ways between vendors would enable the stuff you are talking about. What's missing? What do we need. I'm trying to drag this back to an engineering task. PS - On topic of XMPP and SIP. No argument from me that these are not important protocols for real time applications. I'm perfectly happy to see them includes as things to consider. On Oct 31, 2009, at 4:41 PM, Shidan wrote: > Hi Fluffy, > > I definitely agree with your overall sentiment, but one thing that I > always find dissapointing is when people give me the "turn on and > off" garage doors, thermostats, etc as the only examples of what a > HAN should be about. I think this is part of the reason some, > specially me, are a little confused by the WG. > > The truth is, I'm personally not looking for a X10, legacy 802.15.4, > KNX, etc replacement; they do a fine job of turning things on and > off. Let me list a few things I would like in my HAN: > > 1) I want a network that goes beyond enabling me to discover and > control a device to one that enables devices to discover, control > and communicate with each other and mixed groups of devices and > people. > > 2) I want devices to do things based on time and other arbitrary > policies as part of the network > > 3) I want mobile & secure smart objects to take advantage of > pervasive global networks and objects that are location aware. > > 4) I want a system that can evolve so that when it makes economic > sense, the physical components of a smart appliance are "smart > components" themselves. I also see a day when people will be > upgrading the features and functionality of their washing machine > through a > firmware upgrade.The last two are probably sound silly now, but > they're real considerations of how things can evolve. > > The truth of the matter is that even with X10 and gateways, except > for device mobility, most of this is possible. It's further true > that the most difficult challenge of HANs is not the networking but > end user programmability and moving intelligence to the network will > help in developing these systems. > > Right now, the difficulty I'm having is that it almost seems, and > this could be a wrong interpretation I hope, that this working group > is saying "let's forget about addressing the greater problem of HANs > through network intelligence and let's just focus on satisfying the > bare minimum needs of the energy industry so they can move to IP" > and "then we will let the system evolve." > > Another approach could be that this working group could start by > considering the HAN application layers like UPnP and see how they > need to evolve for pervasive access, where they have gone wrong for > developers and so on and then see how much of this better system you > define can be brought down to LoPANs. This is something I think can > be done in the time frames this WG has proposed and anything that > comes out of it would work great for the energy industry as well. > > Of course, even better would be a general application layer > framework for LoPANS, but since this is technological limitation, I > think looking at requirements is absolutely necessary. > > A side note, I definitely think SIP and XMPP are relevant in this > field Cullen, there is a reason why so many M2M applications are > using XMPP, specially in BRIC countries. There is also a reason why > the leading demand response provider is using XMPP today, if you can > take this all the way to the home and on AMI networks then why not? > There is also a reason why the few MSOs and incumbents that I know > of who are offering home media management and media delivery to > connected devices are switching to SIP-DLNA gateways. Again, this is > not even the real issue, who really cares what you name a protocol > as long as it works and the proper requirements have been > considered. My concern above is much more important. > > Shidan Gouran > > On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings > wrote: > > Right now the draft charter has a sketch of some of the key parts of > the architecture. I'd like to talk about the pro's and cons of > putting this in a charter. Typically charters don't have this. Many > BOFs fail when all the people in the room don't lave having a common > idea of what the group will do. Typically the architecture is > developed in a draft and often can take considerable time however > there's nothing stopping this type of information form being in a > charter. Now this effort is a bit different from your typically BOF. > Let me list some differences: > > 1) This is not meant to run on normal networks. We've told the > transport folks, yah, we are going to have to make different > assumptions than normal application protocols make because there > some special stuff going on here. That makes the Transport and INT > people very nervous. > > 2) We told the security people, none of your off the shelf security > approaches will work for us because we have special requirements. We > are not even 100% sure it is feasibly to simultaneously satisfy all > the requirements. That makes the Security people, uh, prickly. > > 3) Some people have suggest that SIP might be just the thing to > build on over for things like controlling a garage door opener. > Many (but not all) SIP folks feel that SIP is for User to User > communications and often use SIP to control the garage door and the > prototypical example of what should *not* be done with SIP. This > makes the RAI people want to come and say "hi". I'm not saying we > could not use SIP but I am saying the SIP people would want to come > and talk about the issues before that decision got made. Hopefully > they won't ask if any of this has any real time application > properties or infrastructure they could help with. > > 4) The OAM folks must be thinking, so how is this different from > what we do every single day? > > 5) The INT and Routing guys want to know how this related to work > they are doing. > > 6) I've had a few questions that loosely translated to "so what > feature of IPv6 are you using to guarantee that this will only work > on a v6 network". > > If we told the DNS guys we were consider doing all our senor reading > use DNS so we could leverage the DNS caching we would have pretty > much every area "concerned". > > People have questions. Lots of questions. The challenge for a > successful BOF like this is to put together a coherent story of what > the big picture looks like and how it all hangs together. I believe > we have a reasonable chance of having a WG approved if we can show > that there is a group of people that have > > 1) a clear idea of what they want to build > > 2) the same common idea of what it is > > 3) it is an engineering project, and not science project requiring > invention of new techniques > > 4) it meets the type of requirements the IETF has for standards > track work > > The quickest way to do this would be to have in some document that > we take into the BOF use cases, requirements, and a high level > architecture. We have drafts with use case and requirements and we > can refine theses int he slides used in the BOF. If we can agree on > an architecture, we can stuff that in the charter. > > I'm probably a bit naive to think we can come up with a sketch of an > architecture and agree to it in the BOF. But if we do, we have a > chance at having the a protocol document finished before 2011. > > A more tried and true approach to this would be to work on the > requirement, use case, and architecture in some ad-hoc meetings then > go for a BOF. The P2PSIP WG had problems similar to this WG in that > they were going to have some harder than average transport and > security issues. They meant for multiple hours at every IETF for > multiple years *before* the WG was approved. Lots of the meetings > had around 100 people with pretty substantial effort. > > Another approach would be to charter just to do requirements then > recharter to do the protocols. I'd bet anyone on odds of a bottle of > beer to a bottle of scotch that would not finish before 2011 and > even odds on a bottle of scotch it would not finish before 2012. > > Many people have expressed that time is of the essence on this work > and something that delivers in 2012 will be of very little > deployment value. I'm not in a good position to evaluate how quickly > something is needed here but I'm happy to take everything people > tell m at when this is needed at face value. > > The sponsoring AD has read me the riot act on scope for the initial > set of work, make this a small bite size chunk that meets a > reasonable set of needs and we can complete quickly. As that > completes, I'm sure there would be no problem re-charting to expand > the scope for more things or forming other WG to take on related work. > > So bottom line, I'm trying to drive this to figure out what is small > bite size chunk that everyone could live with for the initial stuff > to be worked on. If we are lucky, we can end up agreeing on > requirements, uses cases, and a high level sketch of the > architecture without a long drawn out process. If this fails, and I > admit it very well could, well then we can just move back to some > other way of dealing with this. > > A good charter is a plan for work as well as something that > constrains the number of possibilities a WG has to consider. Now > clearly we can't constrain things beyond what is needed. If we can > mange to agree on a tight charter, the WG will be able to progress > work very rapidly. If we fail to do this in the next few week, > having tried will not set back the work in any significant way. > > I hope this explains, I'm not trying to convince anyone the > architecture in the draft is the right one. I'm just trying to > convince people to fix it before the BOF. > > Sorry for such a long email, > Cullen > > > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From fluffy@cisco.com Mon Nov 2 22:01:53 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAAD43A6989 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 22:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 YEvObkFTmidn for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 22:01:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A2D203A697A for <6lowapp@ietf.org>; Mon, 2 Nov 2009 22:01:52 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJ9W70qrRN+K/2dsb2JhbADFHpc6hD0EgWI X-IronPort-AV: E=Sophos;i="4.44,672,1249257600"; d="scan'208";a="423451699" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2009 06:02:13 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nA362Dkl020488; Tue, 3 Nov 2009 06:02:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:02:13 -0800 Received: from [192.168.4.177] ([10.99.9.18]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:02:10 -0800 From: Cullen Jennings To: d.sturek@att.net In-Reply-To: <005b01ca5a82$e8039e40$b80adac0$@sturek@att.net> Impp: xmpp:cullenfluffyjennings@jabber.org References: <671E1ECE-D232-47B0-B8B0-DF354A7514EB@cisco.com> <005b01ca5a82$e8039e40$b80adac0$@sturek@att.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 23:02:09 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 06:02:11.0769 (UTC) FILETIME=[2F338A90:01CA5C4B] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Security and Commissioning X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 06:01:53 -0000 On Oct 31, 2009, at 5:35 PM, Don Sturek wrote: > Hi Cullen, > > I think I could easily outline the options for this type of > commissioning. > About half that I know of are patented. > > Is this really something 6LowAPP would address though? Good question - that's really up to the participants that want to do the work. I suspect that something is needed or it will not be possible to have interoperable equipment for many of the uses cases but again, I may be way off base there. As a FYI for folks less familiar with the IETF on the on the topic of patents, the WG can choose between technologies - they might choose one that is somewhat technically inferior to get better patent licensing terms or less patents. The IETF process gets a fairly wide range of choice to the WGs on this. Some area of the IETF heavily avoid patents, others publish RFC that are encumbered with many patents. The one things the IETF does insist on is if people are participating in the discussion of an idea that they know is patents, that they do inform people that there may be IPR on it. This is so that the WG can try and make rational decisions about if they should choose that path or not. My description here is a bit hand wavy but it is all covered in detail in BCP 79 (http://tools.ietf.org/html/bcp79). > > Don > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf > Of Cullen Jennings > Sent: Saturday, October 31, 2009 10:34 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Security and Commissioning > > > Consider one of the use cases several people have discussed. You > install a new light. You install a new light switch. Now, how do you > bind them together in the type of deployments where you want security? > > One way or another we need to meet the requirements of BCP 61. For > many BOFs, how they will BCP 61 is fairly obvious and no one worries > about it. However, for this BOF, it is not obvious. To get to a WG, I > think we need to have enough of a sketch of how we are going to do the > security that we can convince the security folks that we are not > insane and that we will be able to meet the requirements of BCP 61 in > the protocols developed. This duckling imprint approach was a stawman > approach to this but it may be totally useless and not what we want > to in which case we should promptly eject it from the charter. > > The question is, what are we going to do? Ideas? Can someone sketch > out at the back of a cocktail napkin level enough of an idea on the > one or more ways we want to deal wit this? If we agree on that I can > do my best to figure out how to get that into the charter in a way > that convinces the security people that they don't have to show up and > say No. > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From fluffy@cisco.com Mon Nov 2 22:06:02 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939B33A697A for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 22:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 AyryHiKk7fsO for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 22:06:01 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E635D3A67D2 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 22:06:01 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMpX70qrR7H+/2dsb2JhbADFIJc7hD0E X-IronPort-AV: E=Sophos;i="4.44,672,1249257600"; d="scan'208";a="220554648" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2009 06:06:21 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA366L4t029507; Tue, 3 Nov 2009 06:06:21 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:06:21 -0800 Received: from [192.168.4.177] ([10.99.9.18]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:06:21 -0800 From: Cullen Jennings To: Kerry Lynn In-Reply-To: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 23:06:19 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 06:06:21.0199 (UTC) FILETIME=[C3DF89F0:01CA5C4B] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Newbie questions X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 06:06:02 -0000 On Nov 2, 2009, at 6:32 AM, Kerry Lynn wrote: > I tried to access the audio stream and jabber feed from yesterday's > meeting but was unable to do so. Is IETF registration necessary? Hi Kerry, All the IETF meeting should be open and you can join them and we welcome your participation. There's really no such thing as "member" of the IETF, just individuals that participate. I could be confused, but I don't think there was a meeting yesterday. If there was any sort of official IETF meeting, you should have been able to join it. Cullen From fluffy@cisco.com Mon Nov 2 22:06:34 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61AE3A697A for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 22:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 DnPHfOoXcwb4 for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 22:06:33 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id C99BB3A67D2 for <6lowapp@ietf.org>; Mon, 2 Nov 2009 22:06:33 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMpX70qrR7Ht/2dsb2JhbADFIJc7hD0E X-IronPort-AV: E=Sophos;i="4.44,672,1249257600"; d="scan'208";a="220554835" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 03 Nov 2009 06:06:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA366sdG003042; Tue, 3 Nov 2009 06:06:54 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:06:54 -0800 Received: from [192.168.4.177] ([10.99.9.18]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Nov 2009 22:06:52 -0800 From: Cullen Jennings To: In-Reply-To: <005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net> Impp: xmpp:cullenfluffyjennings@jabber.org References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Nov 2009 23:06:51 -0700 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 06:06:53.0199 (UTC) FILETIME=[D6F259F0:01CA5C4B] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 06:06:35 -0000 Makes sense, but I suspect that solving this type of problem is a bit outside of something we would do in the Apps area - seems like a an issues where you would want the type of expertise of a a WG in the transport area. Would it make sense to say something like today we need to run over TCP (and/or UDP) and in the future needs to be able to run over new transport protocols? On Oct 31, 2009, at 6:02 PM, Don Sturek wrote: > Hi Cullen, > > Sorry, I meant to provide some references on this issue. Basically, > here is > the problem: > 1) TCP was written back in the day when Ethernet was the primary > transport. > One key assumption made in TCP was that packet timeout was related to > congestion. TCP reacts to packet timeouts by adjusting the transmit > timing > and using back off. > 2) Wireless networks (especially mesh topologies) experience packet > loss as > a result of failure of the RF link. Note that IEEE 802.11 does not > typically exhibit this type of loss. The reason is that for IEEE > 802.11 > (actually WiFi) the last hop wireless link from the AP can be > guaranteed via > MAC level acknowledges and retries. The trouble with mesh links is > that > link errors are not propagated and, even if they are, result in route > re-establishment which violates the TCP timeout on the far end and > starts > the "congestion management" procedure in TCP (which actually makes the > problem worse as some of the links below indicate). > > I am not saying categorically that TCP does not work for wireless > links. I > am saying that for many wireless links, TCP does not work well (and > in some > extreme cases, at all). Here are some examples from the IETF > archives and > other industry trials...... > > http://www.rfc-editor.org/rfc/rfc4653.txt > http://www.sics.se/~adam/ewsn2004.pdf > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=686057 > > I used to have a more exhaustive reference list but I think if you > do a > search you will see this is a long standing problem.... > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf > Of Cullen Jennings > Sent: Saturday, October 31, 2009 10:33 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Where does TCP not work > > > Multiple people have told me that TCP won't work on some of the types > of networks we want to run on. Anyway I'd like to understand a bit > more on why this is. > > I could go dig a 9600 baud modem out of my closet, set the MTU at 100, > and emulate 10% packet loss on server side and go try some things. I'm > relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all > work just fine. > > So, what are the network conditions that we think are going to cause a > problem for TCP? and, what might one do to make something that worked > better than TCP in these cases. > > Thanks, Cullen > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From kerlyn2001@gmail.com Mon Nov 2 14:07:33 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4B8C28C15B for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 14:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 huNMO4L0q3Qd for <6lowapp@core3.amsl.com>; Mon, 2 Nov 2009 14:07:33 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 6BB9628C13C for <6lowapp@ietf.org>; Mon, 2 Nov 2009 14:07:32 -0800 (PST) Received: by bwz23 with SMTP id 23so6874075bwz.29 for <6lowapp@ietf.org>; Mon, 02 Nov 2009 14:07:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=72TxZDC7lCEIIxwl8ipbwQMuAVRqOZIE4IRX5QxUwPY=; b=VLv8EpAwBbjI3qlv84Iw1VR4gJGWZnZpm2KOe0M/PXIVYL6SLfSmM8rLREphWA3ilh cFW5GE1P89sKyN1azjM1G1iCkif0fD+rE/GHBum9jegKIVshScYvifjkylfLx0ajc3t2 Ea3vbzS2+wbbGQrJksml+nCM398mV+AoIW3CA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=c5rDZepzXxi4uwcLPbbVeEicLV3B9lfUVHvln7/sj4d1ZCIsXi07YgqJ3e6p3vBHe0 p07N/z51EhtuI2ekfy+fketTcCjsQaoHYXcYTZ6qxhSgG5tzNYQ0tlhVXZ6n0GiCmOvG jdlOM52YEqMlDb1IlpzQLd1hl1npU9rm/GGXU= MIME-Version: 1.0 Received: by 10.204.24.69 with SMTP id u5mr395025bkb.1.1257199669142; Mon, 02 Nov 2009 14:07:49 -0800 (PST) Date: Mon, 2 Nov 2009 17:07:49 -0500 Message-ID: <3fe58b590911021407r40d5384ej5a0399172bb92831@mail.gmail.com> From: Kerry Lynn To: 6lowapp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 02 Nov 2009 23:12:16 -0800 Subject: Re: [6lowapp] Newbie questions X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 22:07:34 -0000 Thanks for your replies. BTW, I did figure out that I was a week early for the 6LowApp meeting. I am wondering whether anyone has done a comparison of different approaches to service discovery. If not, perhaps this is an area where I can contribute. I am more familiar with Apple's Bonjour (ZeroConf) approach than I am with SLP. Is it generally felt that SLP offers a richer semantics with its URI-based approach? Or is there a bias because SLP is further along with respect to standardization? It seems an important property of end devices is the ability to operate in the absence of a server (DA) but to interoperate with one should it be present. At least in the case of DNS, this doesn't seem beyond the capilities of current set-top boxes or home routers to provide. OTOH, one could argue that an agent-based approach is overkill in HAN environments as long as link-local multicast is available. -K- From zach@sensinode.com Tue Nov 3 00:00:52 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FD823A67B2 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 00:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 j9ioV2If+M1I for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 00:00:46 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3DC733A6405 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 00:00:45 -0800 (PST) Received: from [192.168.0.22] (82-128-196-163-Torikatu-TR1.suomi.net [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA380RiF028009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 10:01:01 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <00b501ca5bc7$1ba2bcf0$52e836d0$@sturek@att.net> Date: Tue, 3 Nov 2009 08:18:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> <00b501ca5bc7$1ba2bcf0$52e836d0$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Discovery X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 08:00:52 -0000 Hi, (New thread title) With regards to service discovery and CoAP, the question is do we need =20= full-blown service discovery at all for such constrained networks and =20= devices in this WG? Looking at the requirements and discussions so far, the conclusion we =20= had is that the same CoAP protocol can easily be used for exchanging =20 service information (profiles) in a distributed manner, but allowing =20 for a DA-like entity to exist if needed. DPWS uses a similar approach. The current proposed CoAP charter text takes this simple approach. =20 Define a discovery interface and a simple profile format using the =20 same protocol. For constrained nodes this makes sense, no requirement =20= to implement a separate protocol. This is also extensible for vendors =20= or other standards (e.g. DPWS, oBIX) to extend profiles. I am not saying that general service discovery mechanisms are not =20 useful some day (SLP, mDNS, UPnP etc.). There could be a future spin-=20 off or re-charter for this work. But looking at the current =20 applications and requirements on the table - what the charter is =20 suggesting is good enough and will demand the least effort. Thoughts? Zach On Nov 2, 2009, at 16:16 , Don Sturek wrote: > Hi Kerry, > > Here is the big problem we keep coming up against in service =20 > discovery: > 1) Most agent based solutions are deeply unpopular by HAN device > manufacturers. > > Here is why: > 1) Many different vendors contribute to devices in the home area =20 > network > (HAN) > 2) No vendor of device "X" wants to have to increase their storage =20= > and > computing capacity to become the repository of service information =20 > for all > other devices in the network. > 3) HANs are not managed networks where some owning entity would place > infrastructure devices > > Note what I wrote above is for the home area network (HAN). Building > automation is another story as there is certainly a building control =20= > system > in place there. > > The simplest solution for this for the HAN: Allow individual =20 > devices to > hold their own service information and provide a unicast/multicast =20 > query > system to allow for self description of service information. Allow =20= > for > individual devices on the HAN to form their own queries and get direct > responses back from devices matching those service requests. > > For the I-D I turned in for service discovery, I did use the SLP DA > (Directory Agent, I believe) to hold the strings (URI plus service) =20= > and had > the DA responsible for substituting those for tokens upon request. =20= > However, > I had in mind that would be all the DA would do and all service =20 > discovery > was UA (User Agent) based. > > For a building controls solution (commercial or industrial), the DA =20= > could be > fully populated an used on the building control system...... > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On =20= > Behalf > Of Kerry Lynn > Sent: Monday, November 02, 2009 5:32 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Newbie questions > > Greetings, > > My name is Kerry Lynn and I hope to contribute to this effort =20 > remotely. I > am an independent contractor working in the area of building =20 > automation > and have worked previously in Cisco and Apple network engineering in > addition to supporting university research into constrained =20 > devices. I > hope you will bear with what may be foolish questions as I come up to > speed: > > I tried to access the audio stream and jabber feed from yesterday's > meeting but was unable to do so. Is IETF registration necessary? > > Is it the consensus of the group to support peer-to-peer as well as > server-based configurations? The first is what I'd term the "one =20 > light, > one switch" scenario while the latter would include DHCP, DNS, etc. > and perhaps application proxy support. > > Has anyone considered something like T/TCP as a candidate for > transaction support? I know it has been traditionally implemented > as a superset of TCP but I suspect it could be much simpler than > full TCP if used in a controlled environment such as local > communication with a full TCP/HTTP/REST proxy. The security > concerns could be addressed simultaneously. > > Has anyone proposed mDNS/DNS-SD as an alternative to SLP? > Does anyone have a feeling for how one client implementation > compares to the other in terms if complexity? > > Thanks, -K- > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From zach@sensinode.com Tue Nov 3 01:22:34 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0B83A680F for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 01:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 KmqA3LxOJrEy for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 01:22:33 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id CEA7B28C185 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 01:22:31 -0800 (PST) Received: from [192.168.0.22] (82-128-196-163-Torikatu-TR1.suomi.net [82.128.196.163]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA380RiE028009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 10:01:00 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: Date: Tue, 3 Nov 2009 08:06:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> To: Jonathan Hui X-Mailer: Apple Mail (2.1076) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 09:22:34 -0000 Hi, (New thread title) So to me the answer seems to be that TCP will work for some =20 configurations, but obviously not for all networks, and not for all =20 requirements (e.g. multicast). On Nov 3, 2009, at 5:15 , Jonathan Hui wrote: > >>> But are TCP's services/constraints >>> appropriate for the application? I can think of a variety of LLN >>> applications that work just fine with TCP and others that could =20 >>> stand >>> to use something else to improve latency, message efficiency, non =20= >>> p2p >>> flows, multihoming, mobility, etc. >> >> That's another question, yes. But I'd see building new transport =20 >> layer functions for 6LOWAPPs as an activity that would need some =20 >> very strong ties to the TSV area, if it wouldn't be hosted there in =20= >> the first place. > > Agreed. Though the line seems to be a bit blurred because some =20 > suggest building transport-like mechanisms in whatever "app-level" =20 > protocol we're working on. In the Stockholm BarBof, Lars had a very good explanation on this one. =20= We very well may start TSV area work on transport improvements - but =20 that is a long-term effort and won't happen in time for CoAP. I do =20 think we should aim at starting that work eventually, but let's get =20 CoAP started first. Obviously UDP is something we will need to support as a transport for =20= CoAP, and I argue that we also need to allow the use of CoAP over TCP =20= as this is useful for some applications. When using UDP, some simple =20 mechanism for reliability (e.g. stop-and-wait) would of course be =20 needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). =20 When doing this we should of course cooperate with TSV people. So this brings us to the next question, what should we say in the CoAP =20= charter about transports? Right now it says "The protocol will operate over UDP...". I would suggest it says something more like: "The protocol will operate over UDP by default, and should define an =20 alternative binding to TCP or another suitable reliable transport =20 layer." What do you think? Zach > > -- > Jonathan Hui > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From pthubert@cisco.com Tue Nov 3 02:03:24 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645703A69D6 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 02:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.648 X-Spam-Level: X-Spam-Status: No, score=-9.648 tagged_above=-999 required=5 tests=[AWL=0.951, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 mBRV+DlODWci for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 02:03:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0A26D3A698E for <6lowapp@ietf.org>; Tue, 3 Nov 2009 02:03:22 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcAAKiO70qQ/uCWe2dsb2JhbACbVQEBCwskBqkjl1WEPQSBZA X-IronPort-AV: E=Sophos;i="4.44,673,1249257600"; d="scan'208";a="53472710" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 10:03:42 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3A3gdI016922; Tue, 3 Nov 2009 10:03:42 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 11:03:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 11:03:37 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8DFDD6@XMB-AMS-107.cisco.com> In-Reply-To: <50D02497-17A6-4EF2-AC6E-FE783E48E071@archrock.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Where does TCP not work Thread-Index: AcpcPU6dYfy5hn/iSeu70t2Q9GuTFwALZuDQ References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com><5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com><4AEF832C.9050603@eecs.berkeley.edu><3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com><66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com><72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <50D02497-17A6-4EF2-AC6E-FE783E48E071@archrock.com> From: "Pascal Thubert (pthubert)" To: "Jonathan Hui" , "Lars Eggert" X-OriginalArrivalTime: 03 Nov 2009 10:03:42.0440 (UTC) FILETIME=[EC507680:01CA5C6C] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 10:03:24 -0000 Hi Jonathan: We went around that same question of transport at ISA100.11a. We ended up using a form of DTLS (over UDP) that 6LoWPAN actually compresses efficiently. Why did we end up with this? - every app seemed to have very different requirement on transport. The common ground was reduced to a secured datagram service. - we resolved to use the CCM provided by the chipset crypto engines (same as used at L2) to save power. - ISA100 (client-server) apps that need ack usually have app layer ack that carries some data back. Transport layer ack is there a costly and unwanted operation. - Most of the data (buffered, eg readings repeated over and over) do not require retries anyway=20 - packet loss during TCP start can delay the connection for too long (that's what started reliable UDP to pass dial numbers that later became SCTP) - we considered other transports like DCCP but for a number of reasons that include those middle boxes that know only TCP and UDP, we resolved to stay with UDP with ECN passed up to the app layer. Cheers, Pascal >-----Original Message----- >From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Jonathan Hui >Sent: mardi 3 novembre 2009 05:22 >To: Lars Eggert >Cc: 6lowapp@ietf.org >Subject: Re: [6lowapp] Where does TCP not work > > >On Nov 2, 2009, at 7:46 PM, Lars Eggert wrote: > >> It's definitely debatable whether the approach that we've so far >> followed (making links and lower-layer network technologies >> implement stuff so that TCP/IP runs OK) is the One True Answer. > >Yes. > >> As we expand IP into environments that are very different from the >> "normal" Internet, it's not fully clear (to me at least) whether >> this approach will continue to be efficient. At the bar BOF in >> Stockholm, I made a strawman proposal that for 6LOWAPPs, we might >> instead start thinking about giving up on TCP and implementing a set >> of end-to-end transport functions that apps can pick & choose from, >> depending on their needs (reliability, uni/multicast, error >> protection, loss protection/FEC, flow control, etc.) Those functions >> may not need to be provided by a separate protocol with a header and >> a layer in the stack; we might make them available as a common >> library that apps link against, for example. > >Certainly sounds like an interesting idea and it would be a breath of >fresh air not to be encumbered by TCP. So can we afford to sacrifice >interoperability with TCP-based tools/infrastructure? There are >clearly people on both sides and it's not clear to me how to come to >closure except to recognize both sides for the time being. > >-- >Jonathan Hui > >_______________________________________________ >6lowapp mailing list >6lowapp@ietf.org >https://www.ietf.org/mailman/listinfo/6lowapp From pister@eecs.berkeley.edu Tue Nov 3 02:32:21 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15AB93A69B8 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 02:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 GDTIHytOWHjS for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 02:32:20 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 194693A6966 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 02:32:20 -0800 (PST) Received: from [192.168.1.100] (c-24-4-148-227.hsd1.ca.comcast.net [24.4.148.227]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nA3AWUvq009506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 02:32:31 -0800 (PST) Message-ID: <4AF006B9.3050101@eecs.berkeley.edu> Date: Tue, 03 Nov 2009 02:32:25 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <50D02497-17A6-4EF2-AC6E-FE783E48E071@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5D8DFDD6@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D8DFDD6@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 10:32:21 -0000 Pascal - I think that these choices in isa100 were good ones, for the reasons that you listed. I'd summarize as "the legacy protocols in industrial automation aren't built around TCP". Do you believe that this will be true in 6lowapp? My opinion is that almost by definition (the "6" in the name), that TCP will be an important part of that future. I'm 100% sure that we'll find other ways of doing things as well, but it makes me nervous when it looks like we're trying to reinvent every protocol from bottom to top, and still call it IP. ksjp Pascal Thubert (pthubert) wrote: > Hi Jonathan: > > We went around that same question of transport at ISA100.11a. > > We ended up using a form of DTLS (over UDP) that 6LoWPAN actually > compresses efficiently. > > Why did we end up with this? > > - every app seemed to have very different requirement on transport. The > common ground was reduced to a secured datagram service. > > - we resolved to use the CCM provided by the chipset crypto engines > (same as used at L2) to save power. > > - ISA100 (client-server) apps that need ack usually have app layer ack > that carries some data back. Transport layer ack is there a costly and > unwanted operation. > > - Most of the data (buffered, eg readings repeated over and over) do not > require retries anyway > > - packet loss during TCP start can delay the connection for too long > (that's what started reliable UDP to pass dial numbers that later became > SCTP) > > - we considered other transports like DCCP but for a number of reasons > that include those middle boxes that know only TCP and UDP, we resolved > to stay with UDP with ECN passed up to the app layer. > > Cheers, > > Pascal > > >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> > Behalf Of Jonathan Hui > >> Sent: mardi 3 novembre 2009 05:22 >> To: Lars Eggert >> Cc: 6lowapp@ietf.org >> Subject: Re: [6lowapp] Where does TCP not work >> >> >> On Nov 2, 2009, at 7:46 PM, Lars Eggert wrote: >> >> >>> It's definitely debatable whether the approach that we've so far >>> followed (making links and lower-layer network technologies >>> implement stuff so that TCP/IP runs OK) is the One True Answer. >>> >> Yes. >> >> >>> As we expand IP into environments that are very different from the >>> "normal" Internet, it's not fully clear (to me at least) whether >>> this approach will continue to be efficient. At the bar BOF in >>> Stockholm, I made a strawman proposal that for 6LOWAPPs, we might >>> instead start thinking about giving up on TCP and implementing a set >>> of end-to-end transport functions that apps can pick & choose from, >>> depending on their needs (reliability, uni/multicast, error >>> protection, loss protection/FEC, flow control, etc.) Those functions >>> may not need to be provided by a separate protocol with a header and >>> a layer in the stack; we might make them available as a common >>> library that apps link against, for example. >>> >> Certainly sounds like an interesting idea and it would be a breath of >> fresh air not to be encumbered by TCP. So can we afford to sacrifice >> interoperability with TCP-based tools/infrastructure? There are >> clearly people on both sides and it's not clear to me how to come to >> closure except to recognize both sides for the time being. >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From pister@eecs.berkeley.edu Tue Nov 3 03:19:46 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4775328C0D8 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 03:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 3+Ob0bwyysSs for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 03:19:45 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 317693A69F6 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 03:19:45 -0800 (PST) Received: from [192.168.1.100] (c-24-4-148-227.hsd1.ca.comcast.net [24.4.148.227]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nA3BJLwe009733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 03:19:23 -0800 (PST) Message-ID: <4AF011B4.6070602@eecs.berkeley.edu> Date: Tue, 03 Nov 2009 03:19:16 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: d.sturek@att.net References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <005c01ca5a86$9a3f2ef0$cebd8cd0$%sturek@att.net> In-Reply-To: <005c01ca5a86$9a3f2ef0$cebd8cd0$%sturek@att.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 11:19:46 -0000 Don - I like the WiFi example. Clearly it's possible to make TCP work over wireless links. If there had been a separate industry consortium based on 802.11 pushing DumbFi, a standard that didn't use L2 ARQ, then there would have been a group in the IETF trying to figure out a new transport protocol to use for these lossy links. Do you believe that there is a fundamental reason why WiFi can work and 15.4 radios can't? I don't see any evidence that this is true. Some of the early protocols in sensor networks were not well thought out, and the result is that there's a perception that 15.4 can't be as reliable as WiFi. The reality is that 15.4 can be quite a bit *more* reliable than WiFi. >> The trouble with mesh links is that link errors are not propagated and, even if they are, >> result in route re-establishment which violates the TCP timeout on the far end This remains the case with naive routing protocols, but it is *not* a general truth about mesh links. ksjp Don Sturek wrote: > Hi Cullen, > > Sorry, I meant to provide some references on this issue. Basically, here is > the problem: > 1) TCP was written back in the day when Ethernet was the primary transport. > One key assumption made in TCP was that packet timeout was related to > congestion. TCP reacts to packet timeouts by adjusting the transmit timing > and using back off. > 2) Wireless networks (especially mesh topologies) experience packet loss as > a result of failure of the RF link. Note that IEEE 802.11 does not > typically exhibit this type of loss. The reason is that for IEEE 802.11 > (actually WiFi) the last hop wireless link from the AP can be guaranteed via > MAC level acknowledges and retries. The trouble with mesh links is that > link errors are not propagated and, even if they are, result in route > re-establishment which violates the TCP timeout on the far end and starts > the "congestion management" procedure in TCP (which actually makes the > problem worse as some of the links below indicate). > > I am not saying categorically that TCP does not work for wireless links. I > am saying that for many wireless links, TCP does not work well (and in some > extreme cases, at all). Here are some examples from the IETF archives and > other industry trials...... > > http://www.rfc-editor.org/rfc/rfc4653.txt > http://www.sics.se/~adam/ewsn2004.pdf > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=686057 > > I used to have a more exhaustive reference list but I think if you do a > search you will see this is a long standing problem.... > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Saturday, October 31, 2009 10:33 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Where does TCP not work > > > Multiple people have told me that TCP won't work on some of the types > of networks we want to run on. Anyway I'd like to understand a bit > more on why this is. > > I could go dig a 9600 baud modem out of my closet, set the MTU at 100, > and emulate 10% packet loss on server side and go try some things. I'm > relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all > work just fine. > > So, what are the network conditions that we think are going to cause a > problem for TCP? and, what might one do to make something that worked > better than TCP in these cases. > > Thanks, Cullen > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From d.sturek@att.net Tue Nov 3 05:59:43 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DADC3A67FD for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 05:59:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 ojH18gMMDBkz for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 05:59:42 -0800 (PST) Received: from smtp110.sbc.mail.gq1.yahoo.com (smtp110.sbc.mail.gq1.yahoo.com [67.195.14.95]) by core3.amsl.com (Postfix) with SMTP id E79053A693B for <6lowapp@ietf.org>; Tue, 3 Nov 2009 05:59:41 -0800 (PST) Received: (qmail 66226 invoked from network); 3 Nov 2009 14:00:02 -0000 Received: from adsl-69-225-120-110.dsl.sndg02.pacbell.net (d.sturek@69.225.120.110 with login) by smtp110.sbc.mail.gq1.yahoo.com with SMTP; 03 Nov 2009 06:00:02 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 2QqlhrUVM1mgRsZLx4qZmILvLitFWvDVyLUxKreEN78bLxPi9Zlq4BzR8Q2AuLGB2hAhKc0dXoo7JJK9LP0DyPHvme7SciQzC4uIIPFpBUcwp42DfjuYTltSfLPzRBpH3HQKAWiBebZb3PCKFCXNhCGQcMEw5cb.OtcNeG2PPn013amXbMWeMfMRf.Hm2sek8fW0CkDncaW6hQLSr9QO4pqG98ZGU9pgZ1dju4BQPTNOAnKucA8WSQftZcUpOEDjpvlbrdxS2_8eM0RkX4WsXzV5VxEste6T4AAUAVOo8ZTTwHbTdw-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Kris Pister'" References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <005c01ca5a86$9a3f2ef0$cebd8cd0$%sturek@att.net> <4AF011B4.6070602@eecs.berkeley.edu> In-Reply-To: <4AF011B4.6070602@eecs.berkeley.edu> Date: Tue, 3 Nov 2009 05:59:59 -0800 Message-ID: <01d201ca5c8d$ef1d7630$cd586290$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpcd39LhiMMdiLDTFqOVYz1TEvq4AAFVlsw Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 13:59:43 -0000 Hi Kris, Yes, there is a fundamental reason WiFi works well with TCP and other wireless links don't: the architecture of WiFi has been to have an access point with a set of single wireless hops where data link acknowledges and retries are employed AND where these operations can occur, where needed, within the congestion time window TCP uses. Have a look at an old RFC called TCP-SAT for an example where that time window is violated. Also, I think many of the references Lars supplied are good as well. As you can tell, I agree with Lars on this (having worked with TCP over many data link medium dating from the 1980's to present): If you run TCP over small networks or in very short time windows where the wireless link exhibits behavior consistent with TCPs operating assumptions, you won't see any issues. If you operate TCP over a wireless link where the timeout windows in TCP are invoked, you will see a slow degradation of operation over time to where TCP is nearly unusable (all due to assumptions in TCP around retry, in general.....) Don -----Original Message----- From: Kris Pister [mailto:pister@eecs.berkeley.edu] Sent: Tuesday, November 03, 2009 3:19 AM To: d.sturek@att.net Cc: 'Cullen Jennings'; 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work Don - I like the WiFi example. Clearly it's possible to make TCP work over wireless links. If there had been a separate industry consortium based on 802.11 pushing DumbFi, a standard that didn't use L2 ARQ, then there would have been a group in the IETF trying to figure out a new transport protocol to use for these lossy links. Do you believe that there is a fundamental reason why WiFi can work and 15.4 radios can't? I don't see any evidence that this is true. Some of the early protocols in sensor networks were not well thought out, and the result is that there's a perception that 15.4 can't be as reliable as WiFi. The reality is that 15.4 can be quite a bit *more* reliable than WiFi. >> The trouble with mesh links is that link errors are not propagated and, even if they are, >> result in route re-establishment which violates the TCP timeout on the far end This remains the case with naive routing protocols, but it is *not* a general truth about mesh links. ksjp Don Sturek wrote: > Hi Cullen, > > Sorry, I meant to provide some references on this issue. Basically, here is > the problem: > 1) TCP was written back in the day when Ethernet was the primary transport. > One key assumption made in TCP was that packet timeout was related to > congestion. TCP reacts to packet timeouts by adjusting the transmit timing > and using back off. > 2) Wireless networks (especially mesh topologies) experience packet loss as > a result of failure of the RF link. Note that IEEE 802.11 does not > typically exhibit this type of loss. The reason is that for IEEE 802.11 > (actually WiFi) the last hop wireless link from the AP can be guaranteed via > MAC level acknowledges and retries. The trouble with mesh links is that > link errors are not propagated and, even if they are, result in route > re-establishment which violates the TCP timeout on the far end and starts > the "congestion management" procedure in TCP (which actually makes the > problem worse as some of the links below indicate). > > I am not saying categorically that TCP does not work for wireless links. I > am saying that for many wireless links, TCP does not work well (and in some > extreme cases, at all). Here are some examples from the IETF archives and > other industry trials...... > > http://www.rfc-editor.org/rfc/rfc4653.txt > http://www.sics.se/~adam/ewsn2004.pdf > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=686057 > > I used to have a more exhaustive reference list but I think if you do a > search you will see this is a long standing problem.... > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Saturday, October 31, 2009 10:33 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Where does TCP not work > > > Multiple people have told me that TCP won't work on some of the types > of networks we want to run on. Anyway I'd like to understand a bit > more on why this is. > > I could go dig a 9600 baud modem out of my closet, set the MTU at 100, > and emulate 10% packet loss on server side and go try some things. I'm > relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all > work just fine. > > So, what are the network conditions that we think are going to cause a > problem for TCP? and, what might one do to make something that worked > better than TCP in these cases. > > Thanks, Cullen > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From d.sturek@att.net Tue Nov 3 06:08:39 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E5E3A6932 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 06:08:39 -0800 (PST) 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.322, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 qe74kK9B9Ocj for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 06:08:38 -0800 (PST) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.104]) by core3.amsl.com (Postfix) with SMTP id 151933A6A1D for <6lowapp@ietf.org>; Tue, 3 Nov 2009 06:08:38 -0800 (PST) Received: (qmail 99971 invoked from network); 3 Nov 2009 14:08:55 -0000 Received: from adsl-69-225-120-110.dsl.sndg02.pacbell.net (d.sturek@69.225.120.110 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 03 Nov 2009 06:08:55 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: j32.Tr8VM1nq6izWznfV6vNi0bTAZ5fbm8nhJPblSbuuZeaPMHRwj_fhjpVSOO0ytSMnu0PEfFGSjN3aBR71.rpRtR4G0eB6vS079gpyC7MswIFD.JsXX6mDzHN5Dl7e5GxBGSLjk3t0zx19OkbGrpG_5sqlvROVwzZwSqoicqV8VnYO.XS4IwGiyx.gSkzQjJd_InBOsJ9wb6.RXLau2rjy5Kd4iL_ZOJtvarpc9xgucF3PokeweOkGMG3uk76nvTkdTDkxJ0vAMBSIGDLhXifciMWlL6CRgBpvY0f00F78jssW06b9JuyevTYSqyb7fjAJtcmhGojev2JalOWVpR7qixDLHgnPYfmzriHKDvr5Mzz0spbC.nHfB4TfVLHRUrNoKfLvCY.U0HJKjyE3yXjxzTOIgZxIQNz9URwian8kTrhUEHyyuIfPvH_1A89DVYQ.Fh82 X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" , "'Jonathan Hui'" References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> In-Reply-To: <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> Date: Tue, 3 Nov 2009 06:08:52 -0800 Message-ID: <01d401ca5c8f$2c7b5780$85720680$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpcZzyBGGT0o6ImQ22e9/pqUBEKcwAJ4GvQ Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:08:39 -0000 I would like to see the issue of transport added to the charter. For smart energy, we plan to start with TCP, hoping that our relatively small networks and ROLL don't violate the TCP congestion control timeout threshold and that the code size of TCP are not too much for our small devices. This said, we would like a back-up plan. We need to have UDP as that plan but not using TCP removes many of the interesting applications that rely on TCP. I do think long term having transport in the charter for 6LowAPP/CoAp is a necessary thing. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Monday, November 02, 2009 10:07 PM To: Jonathan Hui Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports Hi, (New thread title) So to me the answer seems to be that TCP will work for some configurations, but obviously not for all networks, and not for all requirements (e.g. multicast). On Nov 3, 2009, at 5:15 , Jonathan Hui wrote: > >>> But are TCP's services/constraints >>> appropriate for the application? I can think of a variety of LLN >>> applications that work just fine with TCP and others that could >>> stand >>> to use something else to improve latency, message efficiency, non >>> p2p >>> flows, multihoming, mobility, etc. >> >> That's another question, yes. But I'd see building new transport >> layer functions for 6LOWAPPs as an activity that would need some >> very strong ties to the TSV area, if it wouldn't be hosted there in >> the first place. > > Agreed. Though the line seems to be a bit blurred because some > suggest building transport-like mechanisms in whatever "app-level" > protocol we're working on. In the Stockholm BarBof, Lars had a very good explanation on this one. We very well may start TSV area work on transport improvements - but that is a long-term effort and won't happen in time for CoAP. I do think we should aim at starting that work eventually, but let's get CoAP started first. Obviously UDP is something we will need to support as a transport for CoAP, and I argue that we also need to allow the use of CoAP over TCP as this is useful for some applications. When using UDP, some simple mechanism for reliability (e.g. stop-and-wait) would of course be needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). When doing this we should of course cooperate with TSV people. So this brings us to the next question, what should we say in the CoAP charter about transports? Right now it says "The protocol will operate over UDP...". I would suggest it says something more like: "The protocol will operate over UDP by default, and should define an alternative binding to TCP or another suitable reliable transport layer." What do you think? Zach > > -- > Jonathan Hui > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From d.sturek@att.net Tue Nov 3 06:16:05 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193EA3A6A16 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 06:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 4SalFtrVK1ih for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 06:16:04 -0800 (PST) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.105]) by core3.amsl.com (Postfix) with SMTP id CC9DE3A68A2 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 06:16:03 -0800 (PST) Received: (qmail 47628 invoked from network); 3 Nov 2009 14:16:22 -0000 Received: from adsl-69-225-120-110.dsl.sndg02.pacbell.net (d.sturek@69.225.120.110 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 03 Nov 2009 06:16:21 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: lmuWJx0VM1lP_BGaJ2b_Ry_1l8BFZOOUvzW4qS2iPhqgXB2cca3.3FbPNLx.E6yq0Aat2iYU_ZAdR70ln4KyDOnB1u9GH.dg28MlM7FFP9fjtl.679NkP00rMvXghH41v8hSmfHbERmPr2o9dHX_f6CgGcdO8KBVpAYt4D2q.7aFjgWjzhaxHR7sFVncR6rrJ82fJiM3_cJe5yBOgmwEuCA7X6oMNEG_0D8eDW6mXsM3yDQda1UvBAceALDCo7HIBgaNIqu_qrrLp9prpOkVFFA9dcbMrijoW4ZuOlB_G80MinNoAYuOuREbfB5yfkHbZ9ZnPNcszIVskA7OhS4uDPd9jZIyOJKZH_OdnplE6Kbt.RnqEMdXjQECUlVQYUkQKutcj6QCW3SY.Gcy7_oOyuXGtw3HDjrValXL4GIz6w.fa7uIsyJGVLnQvLn80OSYQKFRhy9DmjuKbFFVTIGU3_6oBBG8y_WAWrdocjI.JB6pmV.gqFnV5Y2mFfB17AFt4FjYCJwAfp3CVJe5ClelZxt8wjkFYoUA2w-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" References: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> <00b501ca5bc7$1ba2bcf0$52e836d0$@sturek@att.net> In-Reply-To: Date: Tue, 3 Nov 2009 06:16:18 -0800 Message-ID: <01d701ca5c90$36ba5e70$a42f1b50$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpcW8m/VSVQs8IFTpewhgCgWPPwIAANAFHQ Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Discovery X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:16:05 -0000 Hi Zach, I haven't yet seen a service discovery solution that is usable for small footprint devices (SSDP, SLP, DPWS, etc.). All use text strings (which will translated to multiple packets) or directory agents in the network which are not popular in unmanaged networks Do you have any other references? Is there something I missed with one of these technologies? I see service discovery as a hard requirement in unattended networks. Don -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Monday, November 02, 2009 10:19 PM To: d.sturek@att.net Cc: 'Kerry Lynn'; 6lowapp@ietf.org Subject: Re: [6lowapp] Discovery Hi, (New thread title) With regards to service discovery and CoAP, the question is do we need full-blown service discovery at all for such constrained networks and devices in this WG? Looking at the requirements and discussions so far, the conclusion we had is that the same CoAP protocol can easily be used for exchanging service information (profiles) in a distributed manner, but allowing for a DA-like entity to exist if needed. DPWS uses a similar approach. The current proposed CoAP charter text takes this simple approach. Define a discovery interface and a simple profile format using the same protocol. For constrained nodes this makes sense, no requirement to implement a separate protocol. This is also extensible for vendors or other standards (e.g. DPWS, oBIX) to extend profiles. I am not saying that general service discovery mechanisms are not useful some day (SLP, mDNS, UPnP etc.). There could be a future spin- off or re-charter for this work. But looking at the current applications and requirements on the table - what the charter is suggesting is good enough and will demand the least effort. Thoughts? Zach On Nov 2, 2009, at 16:16 , Don Sturek wrote: > Hi Kerry, > > Here is the big problem we keep coming up against in service > discovery: > 1) Most agent based solutions are deeply unpopular by HAN device > manufacturers. > > Here is why: > 1) Many different vendors contribute to devices in the home area > network > (HAN) > 2) No vendor of device "X" wants to have to increase their storage > and > computing capacity to become the repository of service information > for all > other devices in the network. > 3) HANs are not managed networks where some owning entity would place > infrastructure devices > > Note what I wrote above is for the home area network (HAN). Building > automation is another story as there is certainly a building control > system > in place there. > > The simplest solution for this for the HAN: Allow individual > devices to > hold their own service information and provide a unicast/multicast > query > system to allow for self description of service information. Allow > for > individual devices on the HAN to form their own queries and get direct > responses back from devices matching those service requests. > > For the I-D I turned in for service discovery, I did use the SLP DA > (Directory Agent, I believe) to hold the strings (URI plus service) > and had > the DA responsible for substituting those for tokens upon request. > However, > I had in mind that would be all the DA would do and all service > discovery > was UA (User Agent) based. > > For a building controls solution (commercial or industrial), the DA > could be > fully populated an used on the building control system...... > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf > Of Kerry Lynn > Sent: Monday, November 02, 2009 5:32 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Newbie questions > > Greetings, > > My name is Kerry Lynn and I hope to contribute to this effort > remotely. I > am an independent contractor working in the area of building > automation > and have worked previously in Cisco and Apple network engineering in > addition to supporting university research into constrained > devices. I > hope you will bear with what may be foolish questions as I come up to > speed: > > I tried to access the audio stream and jabber feed from yesterday's > meeting but was unable to do so. Is IETF registration necessary? > > Is it the consensus of the group to support peer-to-peer as well as > server-based configurations? The first is what I'd term the "one > light, > one switch" scenario while the latter would include DHCP, DNS, etc. > and perhaps application proxy support. > > Has anyone considered something like T/TCP as a candidate for > transaction support? I know it has been traditionally implemented > as a superset of TCP but I suspect it could be much simpler than > full TCP if used in a controlled environment such as local > communication with a full TCP/HTTP/REST proxy. The security > concerns could be addressed simultaneously. > > Has anyone proposed mDNS/DNS-SD as an alternative to SLP? > Does anyone have a feeling for how one client implementation > compares to the other in terms if complexity? > > Thanks, -K- > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From d.sturek@att.net Tue Nov 3 06:19:45 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01EA828C0EC for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 06:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.04 X-Spam-Level: * X-Spam-Status: No, score=1.04 tagged_above=-999 required=5 tests=[AWL=1.855, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 jZeRUKrbb4mm for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 06:19:44 -0800 (PST) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 0E1413A68A2 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 06:19:44 -0800 (PST) Received: (qmail 79109 invoked from network); 3 Nov 2009 14:20:02 -0000 Received: from adsl-69-225-120-110.dsl.sndg02.pacbell.net (d.sturek@69.225.120.110 with login) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 03 Nov 2009 06:20:02 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 1i6rSncVM1m7UyTM9xootrXIK5Yz_h9ttuo2z4RTHBE1.RgCamOwi8tLcHTswypEvs3CoNvLKhx_WfDfpBwFXzd_.qm7MYeAs8oy.rhoBtJVDZ.TdQgDJziYJVgOTv1OVxK1jiI0RkrOMRFNnVPRbpM4oPrcKjJL2nqE.UGTPuM2fVOdCgX1x7x_49CBrkgTn77jdSb8ieGSTmtpkvi8_dv.kT47JV7B3EmkrVhNJrTTPY3QbSjVf0Oj12d8UICKZkWiEFJ22coIMpI56AZcIVy_AlxILxEjzF3EJ63w01O0KnQ_MA-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Cullen Jennings'" References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net> In-Reply-To: Date: Tue, 3 Nov 2009 06:19:59 -0800 Message-ID: <01d801ca5c90$ba1031f0$2e3095d0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpcS+Bd/e+tJOqGTBKezdZpdhK5gQARKBGw Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 14:19:45 -0000 Hi Cullen, This makes sense. I think there is a Smart Grid bar BOF in Hiroshima. This is probably in response to the NIST Smart Grid roadmap and "Priority Action Plan" activity (IETF is involved in priority action plan #1, IP for Smart Grid). This might be the place to suggest work on this topic in the Transport area. Don -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Monday, November 02, 2009 10:07 PM To: d.sturek@att.net Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work Makes sense, but I suspect that solving this type of problem is a bit outside of something we would do in the Apps area - seems like a an issues where you would want the type of expertise of a a WG in the transport area. Would it make sense to say something like today we need to run over TCP (and/or UDP) and in the future needs to be able to run over new transport protocols? On Oct 31, 2009, at 6:02 PM, Don Sturek wrote: > Hi Cullen, > > Sorry, I meant to provide some references on this issue. Basically, > here is > the problem: > 1) TCP was written back in the day when Ethernet was the primary > transport. > One key assumption made in TCP was that packet timeout was related to > congestion. TCP reacts to packet timeouts by adjusting the transmit > timing > and using back off. > 2) Wireless networks (especially mesh topologies) experience packet > loss as > a result of failure of the RF link. Note that IEEE 802.11 does not > typically exhibit this type of loss. The reason is that for IEEE > 802.11 > (actually WiFi) the last hop wireless link from the AP can be > guaranteed via > MAC level acknowledges and retries. The trouble with mesh links is > that > link errors are not propagated and, even if they are, result in route > re-establishment which violates the TCP timeout on the far end and > starts > the "congestion management" procedure in TCP (which actually makes the > problem worse as some of the links below indicate). > > I am not saying categorically that TCP does not work for wireless > links. I > am saying that for many wireless links, TCP does not work well (and > in some > extreme cases, at all). Here are some examples from the IETF > archives and > other industry trials...... > > http://www.rfc-editor.org/rfc/rfc4653.txt > http://www.sics.se/~adam/ewsn2004.pdf > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=686057 > > I used to have a more exhaustive reference list but I think if you > do a > search you will see this is a long standing problem.... > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf > Of Cullen Jennings > Sent: Saturday, October 31, 2009 10:33 AM > To: 6lowapp@ietf.org > Subject: [6lowapp] Where does TCP not work > > > Multiple people have told me that TCP won't work on some of the types > of networks we want to run on. Anyway I'd like to understand a bit > more on why this is. > > I could go dig a 9600 baud modem out of my closet, set the MTU at 100, > and emulate 10% packet loss on server side and go try some things. I'm > relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all > work just fine. > > So, what are the network conditions that we think are going to cause a > problem for TCP? and, what might one do to make something that worked > better than TCP in these cases. > > Thanks, Cullen > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From richard.kelsey@ember.com Tue Nov 3 07:30:03 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D31B73A67E4 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 07:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, 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 EdMCqNKcnjgi for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 07:30:03 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D69FF3A67D9 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 07:30:02 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 10:31:41 -0500 Date: Tue, 03 Nov 2009 10:27:29 -0500 Message-Id: <87ocnj6332.fsf@kelsey-ws.hq.ember.com> To: Kris Pister In-reply-to: <4AF006B9.3050101@eecs.berkeley.edu> (message from Kris Pister on Tue, 03 Nov 2009 02:32:25 -0800) From: Richard Kelsey References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <50D02497-17A6-4EF2-AC6E-FE783E48E071@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5D8DFDD6@XMB-AMS-107.cisco.com> <4AF006B9.3050101@eecs.berkeley.edu> X-OriginalArrivalTime: 03 Nov 2009 15:31:41.0091 (UTC) FILETIME=[BDB44F30:01CA5C9A] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:30:03 -0000 Date: Tue, 03 Nov 2009 02:32:25 -0800 From: Kris Pister My opinion is that almost by definition (the "6" in the name), that TCP will be an important part of that future. I'm 100% sure that we'll find other ways of doing things as well, but it makes me nervous when it looks like we're trying to reinvent every protocol from bottom to top, and still call it IP. Kris, I hope we don't end up reinventing anything. If we get the layering right we can add a new protocols as needed and still have everyone agree that the result is IP. In particular if 6LoWPAN and ROLL get their parts right, then TCP will work out to the nodes and will be used when it is appropriate. I think that this thread is somewhat missing the point. The question isn't just whether TCP will fail to get data delivered in this or that situation, but also, in the larger picture, whether using TCP out to the nodes is a cost-effective way to get the job done. If someone has 10k water meters sending one short packet a day, they may not want to invest in the infrastructure needed to keep 10k TCP connections open. At some point in the process their data will be available via TCP, but that doesn't require an end-to-end TCP connnection down to each meter. The great thing about IP is that you get enormous flexibility in how to structure networks and applications. We cannot create a whole new protocol stack with a gateway to convert between IP and our new stack. What we can do is provide alternatives where appropriate and take advantage of the layering to allow people to choose which protocols they use and, most importantly, when and where they want to do any conversions. -Richard Kelsey From pthubert@cisco.com Tue Nov 3 07:44:22 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315AA3A67E4 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 07:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.672 X-Spam-Level: X-Spam-Status: No, score=-9.672 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 PxmlRHPeuHBY for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 07:44:20 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 37F693A68FB for <6lowapp@ietf.org>; Tue, 3 Nov 2009 07:44:20 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcAAFTe70qQ/uCWe2dsb2JhbACbVQEBFiQGqnSYBYQ9BItm X-IronPort-AV: E=Sophos;i="4.44,674,1249257600"; d="scan'208";a="53516030" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 15:44:39 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3FidUE012761; Tue, 3 Nov 2009 15:44:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 16:44:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 16:44:39 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8E00E3@XMB-AMS-107.cisco.com> In-Reply-To: <01d201ca5c8d$ef1d7630$cd586290$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Where does TCP not work Thread-Index: Acpcd39LhiMMdiLDTFqOVYz1TEvq4AAFVlswAAEkXoA= References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com><005c01ca5a86$9a3f2ef0$cebd8cd0$%sturek@att.net><4AF011B4.6070602@eecs.berkeley.edu> <01d201ca5c8d$ef1d7630$cd586290$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , "Kris Pister" X-OriginalArrivalTime: 03 Nov 2009 15:44:39.0701 (UTC) FILETIME=[8DCAC450:01CA5C9C] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 15:44:22 -0000 Hi Don: Another aspect of this is that there little room in the LoWPAN for queuing packets so congestion should be avoided proactively when possible; one way of doing that is to model the sensor data the way voice calls are in larger network and perform some call admission control / reservation.=20 This is fine for regular sensor output but falls short for file transfers, unless the transport is able to control its output rate. There has been interesting protocols that used a rate-based flow control, for instance IBM's RTP (HPR). Rate-based outperforms window-based when dealing with very large TTL / very large network countenance, such as deep space... and sensor networks. But like Cullen said, we might need a 6Lowtrans or something to work that out :) Pascal >-----Original Message----- >From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Don Sturek >Sent: mardi 3 novembre 2009 15:00 >To: 'Kris Pister' >Cc: 6lowapp@ietf.org >Subject: Re: [6lowapp] Where does TCP not work > >Hi Kris, > >Yes, there is a fundamental reason WiFi works well with TCP and other >wireless links don't: the architecture of WiFi has been to have an access >point with a set of single wireless hops where data link acknowledges and >retries are employed AND where these operations can occur, where needed, >within the congestion time window TCP uses. > >Have a look at an old RFC called TCP-SAT for an example where that time >window is violated. > >Also, I think many of the references Lars supplied are good as well. > >As you can tell, I agree with Lars on this (having worked with TCP over many >data link medium dating from the 1980's to present): If you run TCP over >small networks or in very short time windows where the wireless link >exhibits behavior consistent with TCPs operating assumptions, you won't see >any issues. If you operate TCP over a wireless link where the timeout >windows in TCP are invoked, you will see a slow degradation of operation >over time to where TCP is nearly unusable (all due to assumptions in TCP >around retry, in general.....) > >Don > > >-----Original Message----- >From: Kris Pister [mailto:pister@eecs.berkeley.edu] >Sent: Tuesday, November 03, 2009 3:19 AM >To: d.sturek@att.net >Cc: 'Cullen Jennings'; 6lowapp@ietf.org >Subject: Re: [6lowapp] Where does TCP not work > >Don - I like the WiFi example. Clearly it's possible to make TCP work >over wireless links. >If there had been a separate industry consortium based on 802.11 pushing >DumbFi, a standard that didn't use L2 ARQ, then there would have been a >group in the IETF trying to figure out a new transport protocol to use >for these lossy links. > >Do you believe that there is a fundamental reason why WiFi can work and >15.4 radios can't? I don't see any evidence that this is true. Some of >the early protocols in sensor networks were not well thought out, and >the result is that there's a perception that 15.4 can't be as reliable >as WiFi. The reality is that 15.4 can be quite a bit *more* reliable >than WiFi. > > >> The trouble with mesh links is that link errors are not propagated >and, even if they are, > >> result in route re-establishment which violates the TCP timeout on >the far end >This remains the case with naive routing protocols, but it is *not* a >general truth about mesh links. > >ksjp > >Don Sturek wrote: >> Hi Cullen, >> >> Sorry, I meant to provide some references on this issue. Basically, here >is >> the problem: >> 1) TCP was written back in the day when Ethernet was the primary >transport. >> One key assumption made in TCP was that packet timeout was related to >> congestion. TCP reacts to packet timeouts by adjusting the transmit >timing >> and using back off. >> 2) Wireless networks (especially mesh topologies) experience packet loss >as >> a result of failure of the RF link. Note that IEEE 802.11 does not >> typically exhibit this type of loss. The reason is that for IEEE 802.11 >> (actually WiFi) the last hop wireless link from the AP can be guaranteed >via >> MAC level acknowledges and retries. The trouble with mesh links is that >> link errors are not propagated and, even if they are, result in route >> re-establishment which violates the TCP timeout on the far end and starts >> the "congestion management" procedure in TCP (which actually makes the >> problem worse as some of the links below indicate). >> >> I am not saying categorically that TCP does not work for wireless links. >I >> am saying that for many wireless links, TCP does not work well (and in >some >> extreme cases, at all). Here are some examples from the IETF archives and >> other industry trials...... >> >> http://www.rfc-editor.org/rfc/rfc4653.txt >> http://www.sics.se/~adam/ewsn2004.pdf >> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=3D686057 >> >> I used to have a more exhaustive reference list but I think if you do a >> search you will see this is a long standing problem.... >> >> Don >> >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf >> Of Cullen Jennings >> Sent: Saturday, October 31, 2009 10:33 AM >> To: 6lowapp@ietf.org >> Subject: [6lowapp] Where does TCP not work >> >> >> Multiple people have told me that TCP won't work on some of the types >> of networks we want to run on. Anyway I'd like to understand a bit >> more on why this is. >> >> I could go dig a 9600 baud modem out of my closet, set the MTU at 100, >> and emulate 10% packet loss on server side and go try some things. I'm >> relatively confidently TCP, HTTP, pop, imap, SSH, and TLS will all >> work just fine. >> >> So, what are the network conditions that we think are going to cause a >> problem for TCP? and, what might one do to make something that worked >> better than TCP in these cases. >> >> Thanks, Cullen >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > >_______________________________________________ >6lowapp mailing list >6lowapp@ietf.org >https://www.ietf.org/mailman/listinfo/6lowapp From lisa.dusseault@gmail.com Tue Nov 3 08:39:42 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B791A3A68A8 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 08:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.705 X-Spam-Level: X-Spam-Status: No, score=-2.705 tagged_above=-999 required=5 tests=[AWL=-0.107, 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 0smI-Ax0l345 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 08:39:41 -0800 (PST) Received: from mail-vw0-f193.google.com (mail-vw0-f193.google.com [209.85.212.193]) by core3.amsl.com (Postfix) with ESMTP id 1D5733A689F for <6lowapp@ietf.org>; Tue, 3 Nov 2009 08:39:41 -0800 (PST) Received: by vws31 with SMTP id 31so1824364vws.29 for <6lowapp@ietf.org>; Tue, 03 Nov 2009 08:39:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dZYcRvo/Mc3mG5PpLfNJT6FCj2eiDt9KYFgp7f9BJuU=; b=D/4uuW+A83sNqS+sCGXcDt+w06ZX6wBynzy6WPaNS4S2n7O7nt6SkVZKOkHLuaWVLI uPkszZDoXlJXlMrK23uM7OE1p+f9zT4yy5XWq43j2vb1bUVSITeNxsKMBVMUcGwOLuml 3EUXTpcV8QiiRSY464O0Q9DL43z/M5Uf7jHyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LMV3pZGlUB7x7YFOsTGhiBZTIZqeHyJWBh90NyjkpIzxktNi6+l/FDhW0xGwYK3aJm 8jt3+Ha1LZGFz+FHa6HSekp2qXOYO+odqGvNMXWgvHuhyszguDCZhgQilptjQGXU0VUf Gv41UdX6A72x9snGGMcvO6Yg5gowkMseXaiVs= MIME-Version: 1.0 Received: by 10.220.123.228 with SMTP id q36mr125548vcr.118.1257266399109; Tue, 03 Nov 2009 08:39:59 -0800 (PST) In-Reply-To: <921972845143124766@unknownmsgid> References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> <921972845143124766@unknownmsgid> Date: Tue, 3 Nov 2009 08:39:59 -0800 Message-ID: From: Lisa Dusseault To: d.sturek@att.net Content-Type: multipart/alternative; boundary=001636ed67c41b614404777a255f Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:39:42 -0000 --001636ed67c41b614404777a255f Content-Type: text/plain; charset=ISO-8859-1 I hope you could live with transport issues in another WG's charter. As the Areas in the IETF are currently organized, I assure you Lars as Transport Area director knows much more about TCP and other transports than I do; conversely I hope I am a pretty fair HTTP expert. Anyway, that's probably the default way that IETF oldtimers would think of splitting up the work, but we could always try to do something unusual. Lisa On Tue, Nov 3, 2009 at 6:08 AM, Don Sturek wrote: > I would like to see the issue of transport added to the charter. > > For smart energy, we plan to start with TCP, hoping that our relatively > small networks and ROLL don't violate the TCP congestion control timeout > threshold and that the code size of TCP are not too much for our small > devices. > > This said, we would like a back-up plan. We need to have UDP as that plan > but not using TCP removes many of the interesting applications that rely on > TCP. > > I do think long term having transport in the charter for 6LowAPP/CoAp is a > necessary thing. > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf > Of Zach Shelby > Sent: Monday, November 02, 2009 10:07 PM > To: Jonathan Hui > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Charter and transports > > Hi, > > (New thread title) > > So to me the answer seems to be that TCP will work for some > configurations, but obviously not for all networks, and not for all > requirements (e.g. multicast). > > On Nov 3, 2009, at 5:15 , Jonathan Hui wrote: > > > >>> But are TCP's services/constraints > >>> appropriate for the application? I can think of a variety of LLN > >>> applications that work just fine with TCP and others that could > >>> stand > >>> to use something else to improve latency, message efficiency, non > >>> p2p > >>> flows, multihoming, mobility, etc. > >> > >> That's another question, yes. But I'd see building new transport > >> layer functions for 6LOWAPPs as an activity that would need some > >> very strong ties to the TSV area, if it wouldn't be hosted there in > >> the first place. > > > > Agreed. Though the line seems to be a bit blurred because some > > suggest building transport-like mechanisms in whatever "app-level" > > protocol we're working on. > > In the Stockholm BarBof, Lars had a very good explanation on this one. > We very well may start TSV area work on transport improvements - but > that is a long-term effort and won't happen in time for CoAP. I do > think we should aim at starting that work eventually, but let's get > CoAP started first. > > Obviously UDP is something we will need to support as a transport for > CoAP, and I argue that we also need to allow the use of CoAP over TCP > as this is useful for some applications. When using UDP, some simple > mechanism for reliability (e.g. stop-and-wait) would of course be > needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). > When doing this we should of course cooperate with TSV people. > > So this brings us to the next question, what should we say in the CoAP > charter about transports? Right now it says > > "The protocol will operate over UDP...". > > I would suggest it says something more like: > > "The protocol will operate over UDP by default, and should define an > alternative binding to TCP or another suitable reliable transport > layer." > > What do you think? > > Zach > > > > > -- > > Jonathan Hui > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system > without producing, distributing or retaining copies thereof. > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --001636ed67c41b614404777a255f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I hope you could live with transport issues in another WG's charter.=A0= As the Areas in the IETF are currently organized, I assure you Lars as Tra= nsport Area director knows much more about TCP and other transports than I = do; conversely I hope I am a pretty fair HTTP expert.

Anyway, that's probably the default way that IETF oldtimers would t= hink of splitting up the work, but we could always try to do something unus= ual.

Lisa

On Tue, Nov 3, 2009 at 6= :08 AM, Don Sturek <d.sturek@att.net> wrote:
I would like to s= ee the issue of transport added to the charter.

For smart energy, we plan to start with TCP, hoping that our relatively
small networks and ROLL don't violate the TCP congestion control timeou= t
threshold and that the code size of TCP are not too much for our small
devices.

This said, we would like a back-up plan. =A0We need to have UDP as that pla= n
but not using TCP removes many of the interesting applications that rely on=
TCP.

I do think long term having transport in the charter for 6LowAPP/CoAp is a<= br> necessary thing.

Don


-----Original Message-----
From: 6lowapp-bounces@ietf.org<= /a> [mailto:6lowapp-bounces@iet= f.org] On Behalf
Of Zach Shelby
Sent: Monday, November 02, 2009 10:07 PM
To: Jonathan Hui
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Charter and transports

Hi,

(New thread title)

So to me the answer seems to be that TCP will work for some
configurations, but obviously not for all networks, and not for all
requirements (e.g. multicast).

On Nov 3, 2009, at 5:15 , Jonathan Hui wrote:
>
>>> But are TCP's services/constraints
>>> appropriate for the application? =A0I can think of a variety o= f LLN
>>> applications that work just fine with TCP and others that coul= d
>>> stand
>>> to use something else to improve latency, message efficiency, = non
>>> p2p
>>> flows, multihoming, mobility, =A0etc.
>>
>> That's another question, yes. But I'd see building new tra= nsport
>> layer functions for 6LOWAPPs as an activity that would need some >> very strong ties to the TSV area, if it wouldn't be hosted the= re in
>> the first place.
>
> Agreed. =A0Though the line seems to be a bit blurred because some
> suggest building transport-like mechanisms in whatever "app-level= "
> protocol we're working on.

In the Stockholm BarBof, Lars had a very good explanation on this one.
We very well may start TSV area work on transport improvements - but
that is a long-term effort and won't happen in time for CoAP. I do
think we should aim at starting that work eventually, but let's get
CoAP started first.

Obviously UDP is something we will need to support as a transport for
CoAP, and I argue that we also need to allow the use of CoAP over TCP
as this is useful for some applications. When using UDP, some simple
mechanism for reliability (e.g. stop-and-wait) would of course be
needed along with a transaction ID (see e.g. 6lowapp-frank-chopan).
When doing this we should of course cooperate with TSV people.

So this brings us to the next question, what should we say in the CoAP
charter about transports? Right now it says

"The protocol will operate over UDP...".

I would suggest it says something more like:

"The protocol will operate over UDP by default, and should define an alternative binding to TCP or another suitable reliable transport
layer."

What do you think?

Zach

>
> --
> Jonathan Hui
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp

--
http://www.sensinode= .com
http://zachshelby.org - My blog "On the Internet of Things"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain
legally privileged information. If you are not the intended recipient,
please contact the sender and delete the e-mail from your system
without producing, distributing or retaining copies thereof.



_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

--001636ed67c41b614404777a255f-- From d.sturek@att.net Tue Nov 3 08:52:44 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB5AD28C0FD for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 08:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.891 X-Spam-Level: X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 HutXNS89UK0k for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 08:52:36 -0800 (PST) Received: from n12a.bullet.mail.mud.yahoo.com (n12a.bullet.mail.mud.yahoo.com [209.191.125.177]) by core3.amsl.com (Postfix) with SMTP id 744D33A682E for <6lowapp@ietf.org>; Tue, 3 Nov 2009 08:52:36 -0800 (PST) Received: from [68.142.194.243] by n12.bullet.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 16:52:55 -0000 Received: from [68.142.201.253] by t1.bullet.mud.yahoo.com with NNFMP; 03 Nov 2009 16:52:55 -0000 Received: from [127.0.0.1] by omp414.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 16:52:55 -0000 X-Yahoo-Newman-Id: 755071.7108.bm@omp414.mail.mud.yahoo.com Received: (qmail 4332 invoked from network); 3 Nov 2009 16:52:55 -0000 Received: from adsl-69-225-120-110.dsl.sndg02.pacbell.net (d.sturek@69.225.120.110 with login) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 03 Nov 2009 08:52:54 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Ramgk2oVM1naDahkkw3_kY.qzOWpIJ1wvk1sE4djMweXI.p_xv_ScrE90NvPEzUVH5wST.VsDpJ8b2ts.5oErOnRgOoM0V_exzfxM1jpBxnWM_zBAdKT1mlqM6WJ.xH9o98Z4Xhj7QkbdQYJl0t28tqxUUDAx2u8wfHEGvOx_ruamitKe0JDFvrrIgJV0GaQIlIeXMwN9nlWndDShCYVC6muGixaQ92gxdy0aeAJradgva2OKLyQtIjDZMfi2Fj1EoytjhRiTxu54s_43QemBNV_Pbs5wDaCILKqXl8kjUnBmhIqCw-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Lisa Dusseault'" References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> <921972845143124766@unknownmsgid> In-Reply-To: Date: Tue, 3 Nov 2009 08:52:50 -0800 Message-ID: <025b01ca5ca6$147d4140$3d77c3c0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025C_01CA5C63.065A0140" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpcpElwxAFUeXuETc29nh5TNF8ELQAALPMw Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:52:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_025C_01CA5C63.065A0140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Lisa, Yes, I was expecting to work with multiple WGs to get all of this work done. I didn't know Lars was Transport Area director but I am happy to know that given he obviously knows the challenges of TCP in non-ethernet type deployments. I am pretty familiar with IETF (mostly from before the mid-1990s) so I was expecting to see a division of work. I do like to explain the overall reasons for some of these requests and appreciate that the explanation probably crosses WG boundaries. Don From: Lisa Dusseault [mailto:lisa.dusseault@gmail.com] Sent: Tuesday, November 03, 2009 8:40 AM To: d.sturek@att.net Cc: Zach Shelby; Jonathan Hui; 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports I hope you could live with transport issues in another WG's charter. As the Areas in the IETF are currently organized, I assure you Lars as Transport Area director knows much more about TCP and other transports than I do; conversely I hope I am a pretty fair HTTP expert. Anyway, that's probably the default way that IETF oldtimers would think of splitting up the work, but we could always try to do something unusual. Lisa On Tue, Nov 3, 2009 at 6:08 AM, Don Sturek wrote: I would like to see the issue of transport added to the charter. For smart energy, we plan to start with TCP, hoping that our relatively small networks and ROLL don't violate the TCP congestion control timeout threshold and that the code size of TCP are not too much for our small devices. This said, we would like a back-up plan. We need to have UDP as that plan but not using TCP removes many of the interesting applications that rely on TCP. I do think long term having transport in the charter for 6LowAPP/CoAp is a necessary thing. Don -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Monday, November 02, 2009 10:07 PM To: Jonathan Hui Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports Hi, (New thread title) So to me the answer seems to be that TCP will work for some configurations, but obviously not for all networks, and not for all requirements (e.g. multicast). On Nov 3, 2009, at 5:15 , Jonathan Hui wrote: > >>> But are TCP's services/constraints >>> appropriate for the application? I can think of a variety of LLN >>> applications that work just fine with TCP and others that could >>> stand >>> to use something else to improve latency, message efficiency, non >>> p2p >>> flows, multihoming, mobility, etc. >> >> That's another question, yes. But I'd see building new transport >> layer functions for 6LOWAPPs as an activity that would need some >> very strong ties to the TSV area, if it wouldn't be hosted there in >> the first place. > > Agreed. Though the line seems to be a bit blurred because some > suggest building transport-like mechanisms in whatever "app-level" > protocol we're working on. In the Stockholm BarBof, Lars had a very good explanation on this one. We very well may start TSV area work on transport improvements - but that is a long-term effort and won't happen in time for CoAP. I do think we should aim at starting that work eventually, but let's get CoAP started first. Obviously UDP is something we will need to support as a transport for CoAP, and I argue that we also need to allow the use of CoAP over TCP as this is useful for some applications. When using UDP, some simple mechanism for reliability (e.g. stop-and-wait) would of course be needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). When doing this we should of course cooperate with TSV people. So this brings us to the next question, what should we say in the CoAP charter about transports? Right now it says "The protocol will operate over UDP...". I would suggest it says something more like: "The protocol will operate over UDP by default, and should define an alternative binding to TCP or another suitable reliable transport layer." What do you think? Zach > > -- > Jonathan Hui > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp ------=_NextPart_000_025C_01CA5C63.065A0140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Lisa,

 

Yes, I was expecting to work with multiple WGs to get all = of this work done.  I didn’t know Lars was Transport Area = director but I am happy to know that given he obviously knows the challenges of TCP = in non-ethernet type deployments.

 

I am pretty familiar with IETF (mostly from before the = mid-1990s) so I was expecting to see a division of work.  I do like to explain = the overall reasons for some of these requests and appreciate that the = explanation probably crosses WG boundaries.


Don

 

 

From:= Lisa = Dusseault [mailto:lisa.dusseault@gmail.com]
Sent: Tuesday, November 03, 2009 8:40 AM
To: d.sturek@att.net
Cc: Zach Shelby; Jonathan Hui; 6lowapp@ietf.org
Subject: Re: [6lowapp] Charter and = transports

 

I hope you could = live with transport issues in another WG's charter.  As the Areas in the IETF = are currently organized, I assure you Lars as Transport Area director knows = much more about TCP and other transports than I do; conversely I hope I am a = pretty fair HTTP expert.

Anyway, that's probably the default way that IETF oldtimers would think = of splitting up the work, but we could always try to do something = unusual.

Lisa

On Tue, Nov 3, 2009 at 6:08 AM, Don Sturek <d.sturek@att.net> = wrote:

I would like to see the issue of transport added to = the charter.

For smart energy, we plan to start with TCP, hoping that our = relatively
small networks and ROLL don't violate the TCP congestion control = timeout
threshold and that the code size of TCP are not too much for our = small
devices.

This said, we would like a back-up plan.  We need to have UDP as = that plan
but not using TCP removes many of the interesting applications that rely = on
TCP.

I do think long term having transport in the charter for 6LowAPP/CoAp is = a
necessary thing.

Don



-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf
Of Zach Shelby
Sent: Monday, November 02, 2009 10:07 PM
To: Jonathan Hui
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Charter and transports

Hi,

(New thread title)

So to me the answer seems to be that TCP will work for some
configurations, but obviously not for all networks, and not for all
requirements (e.g. multicast).

On Nov 3, 2009, at 5:15 , Jonathan Hui wrote:
>
>>> But are TCP's services/constraints
>>> appropriate for the application?  I can think of a = variety of LLN
>>> applications that work just fine with TCP and others that = could
>>> stand
>>> to use something else to improve latency, message = efficiency, non
>>> p2p
>>> flows, multihoming, mobility,  etc.
>>
>> That's another question, yes. But I'd see building new = transport
>> layer functions for 6LOWAPPs as an activity that would need = some
>> very strong ties to the TSV area, if it wouldn't be hosted = there in
>> the first place.
>
> Agreed.  Though the line seems to be a bit blurred because = some
> suggest building transport-like mechanisms in whatever "app-level"
> protocol we're working on.

In the Stockholm BarBof, Lars had a very good explanation on this = one.
We very well may start TSV area work on transport improvements - but
that is a long-term effort and won't happen in time for CoAP. I do
think we should aim at starting that work eventually, but let's get
CoAP started first.

Obviously UDP is something we will need to support as a transport = for
CoAP, and I argue that we also need to allow the use of CoAP over = TCP
as this is useful for some applications. When using UDP, some simple
mechanism for reliability (e.g. stop-and-wait) would of course be
needed along with a transaction ID (see e.g. 6lowapp-frank-chopan).
When doing this we should of course cooperate with TSV people.

So this brings us to the next question, what should we say in the = CoAP
charter about transports? Right now it says

"The protocol will operate over UDP...".

I would suggest it says something more like:

"The protocol will operate over UDP by default, and should define = an
alternative binding to TCP or another suitable reliable transport
layer."

What do you think?

Zach

>
> --
> Jonathan Hui
>
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp

--
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may = contain
legally privileged information. If you are not the intended = recipient,
please contact the sender and delete the e-mail from your system
without producing, distributing or retaining copies thereof.



_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<= /o:p>

 

------=_NextPart_000_025C_01CA5C63.065A0140-- From L.Wood@surrey.ac.uk Tue Nov 3 08:56:56 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E1A3A691D for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 08:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Wic13gZB9os7 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 08:56:55 -0800 (PST) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with SMTP id BD0C23A680C for <6lowapp@ietf.org>; Tue, 3 Nov 2009 08:56:54 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-2.tower-82.messagelabs.com!1257267434!71764385!1 X-StarScan-Version: 6.1.3; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 26254 invoked from network); 3 Nov 2009 16:57:14 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-2.tower-82.messagelabs.com with SMTP; 3 Nov 2009 16:57:14 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 16:57:14 +0000 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 16:57:14 +0000 Message-Id: <261EF2B6-82AF-4FBD-AC71-609617E7A7CE@surrey.ac.uk> From: Lloyd Wood To: 6lowapp@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 16:57:13 +0000 References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> <921972845143124766@unknownmsgid> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 16:57:14.0142 (UTC) FILETIME=[B13DBBE0:01CA5CA6] Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 16:56:56 -0000 > Obviously UDP is something we will need to support as a transport for > CoAP, and I argue that we also need to allow the use of CoAP over TCP > as this is useful for some applications. When using UDP, some simple > mechanism for reliability (e.g. stop-and-wait) would of course be > needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). > When doing this we should of course cooperate with TSV people. http://tools.ietf.org/html/draft-wood-tsvwg-saratoga is such a protocol, providing reliability and IDs. L. DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ From pthubert@cisco.com Tue Nov 3 09:02:43 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A173A6960 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 09:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.716 X-Spam-Level: X-Spam-Status: No, score=-7.716 tagged_above=-999 required=5 tests=[AWL=-1.117, 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 jTpC6Mq+dzDT for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 09:02:43 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EE9C13A691D for <6lowapp@ietf.org>; Tue, 3 Nov 2009 09:02:42 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE/x70qrR7Hu/2dsb2JhbADHJ5gNhD0Ei2Y X-IronPort-AV: E=Sophos;i="4.44,675,1249257600"; d="scan'208";a="423865498" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 03 Nov 2009 17:02:57 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nA3H2oDT026045; Tue, 3 Nov 2009 17:02:57 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 18:02:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 18:02:50 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8E01D2@XMB-AMS-107.cisco.com> In-Reply-To: <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Where does TCP not work Thread-Index: AcpcJtCyD68MD/XATNCVCoI+rBxfggAfzcPQ References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com><5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com><4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> From: "Pascal Thubert (pthubert)" To: "Lars Eggert" , "Kris Pister" X-OriginalArrivalTime: 03 Nov 2009 17:02:56.0354 (UTC) FILETIME=[7D372420:01CA5CA7] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:02:43 -0000 Hi Lars and Kris: >> In the early days of sensor networks it was not uncommon to see end- >> to-end best-effort loss rates of 10% or more. I don't think that >> anyone tolerates that kind of performance anymore. With link-layer >> ACKs and path diversity in the routing layer I think that 99.9% for >> best-effort is now table stakes. > >All that certainly helps, but I haven't seen much discussion on whether we all agree that we're only going to >target scenarios for 6LOWAPP for which we can make the assumption that such techniques will be in use. And path diversity when applied to TCP flows can have very adverse effects, if the packets are actually balanced over paths of very different latencies. A packet that is not lost but delayed in an alternate path will trigger fast recovery and cause the congestion window to drop.=20 Add a very long TTL to the mixture and you get a recipe for a very low throughput with packet duplication. MPTCP might offer some benefits if the subflows were routed on a given path each, but that's not what we are doing here so I'm not too hopeful though I'd like to dig more. Pascal From pthubert@cisco.com Tue Nov 3 09:09:48 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC313A691D for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 09:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.69 X-Spam-Level: X-Spam-Status: No, score=-9.69 tagged_above=-999 required=5 tests=[AWL=0.909, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 P3iLwivgglRc for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 09:09:47 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B974228C11F for <6lowapp@ietf.org>; Tue, 3 Nov 2009 09:09:43 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcAAELy70qQ/uCWe2dsb2JhbACbVQEBFiQGqwaYFYQ9BItm X-IronPort-AV: E=Sophos;i="4.44,675,1249257600"; d="scan'208";a="53525573" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2009 17:10:03 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA3HA3a8009764; Tue, 3 Nov 2009 17:10:03 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 18:10:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2009 18:09:59 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8E01DD@XMB-AMS-107.cisco.com> In-Reply-To: <261EF2B6-82AF-4FBD-AC71-609617E7A7CE@surrey.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Charter and transports Thread-Index: AcpcprrK21Aa5NvtRRCrTml7lyZuHgAAVt/g References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com><5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com><4AEF832C.9050603@eecs.berkeley.edu><3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com><66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com><72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com><0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com><921972845143124766@unknownmsgid> <261EF2B6-82AF-4FBD-AC71-609617E7A7CE@surrey.ac.uk> From: "Pascal Thubert (pthubert)" To: "Lloyd Wood" , <6lowapp@ietf.org> X-OriginalArrivalTime: 03 Nov 2009 17:10:03.0365 (UTC) FILETIME=[7BBBD950:01CA5CA8] Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:09:48 -0000 Hi Lloyd, Glad you mention it. Is there a way to see Saratoga without the 'DTN' piece?=20 Could you elaborate a bit on how flow control is done in Saratoga? Cheers, Pascal >-----Original Message----- >From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Lloyd Wood >Sent: mardi 3 novembre 2009 17:57 >To: 6lowapp@ietf.org >Subject: Re: [6lowapp] Charter and transports > >> Obviously UDP is something we will need to support as a transport for >> CoAP, and I argue that we also need to allow the use of CoAP over TCP >> as this is useful for some applications. When using UDP, some simple >> mechanism for reliability (e.g. stop-and-wait) would of course be >> needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). >> When doing this we should of course cooperate with TSV people. > >http://tools.ietf.org/html/draft-wood-tsvwg-saratoga > >is such a protocol, providing reliability and IDs. > >L. > >DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ > > > > > > > > >_______________________________________________ >6lowapp mailing list >6lowapp@ietf.org >https://www.ietf.org/mailman/listinfo/6lowapp From L.Wood@surrey.ac.uk Tue Nov 3 09:26:27 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7FA328C118 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 09:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 6i0ZHG2zvj41 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 09:26:26 -0800 (PST) Received: from mail80.messagelabs.com (mail80.messagelabs.com [195.245.230.163]) by core3.amsl.com (Postfix) with SMTP id 55CD728C114 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 09:26:25 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-5.tower-80.messagelabs.com!1257269205!74997955!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.102.140] Received: (qmail 21870 invoked from network); 3 Nov 2009 17:26:45 -0000 Received: from ads40.surrey.ac.uk (HELO ads40.surrey.ac.uk) (131.227.102.140) by server-5.tower-80.messagelabs.com with SMTP; 3 Nov 2009 17:26:45 -0000 Received: from ads31.surrey.ac.uk ([131.227.120.131]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 17:26:43 +0000 Received: from [192.168.1.209] ([86.3.114.249]) by ads31.surrey.ac.uk over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Nov 2009 17:26:43 +0000 Message-Id: <0562912A-A163-4938-9146-6E6DC6D2B316@surrey.ac.uk> From: Lloyd Wood To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D8E01DD@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Nov 2009 17:26:42 +0000 References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com><5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com><4AEF832C.9050603@eecs.berkeley.edu><3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com><66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com><72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com><0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com><921972845143124766@unknownmsgid> <261EF2B6-82AF-4FBD-AC71-609617E7A7CE@surrey.ac.uk> <6A2A459175DABE4BB11DE2026AA50A5D8E01DD@XMB-AMS-107.cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Nov 2009 17:26:43.0585 (UTC) FILETIME=[CFE94F10:01CA5CAA] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 17:26:27 -0000 On 3 Nov 2009, at 17:09, Pascal Thubert (pthubert) wrote: > Hi Lloyd, > > Glad you mention it. > > Is there a way to see Saratoga without the 'DTN' piece? The DTNRG bundle support is specified in a separate DTNRG draft, which can be ignored entirely, along with the single bit saying 'carrying bundles'. That's unimportant. http://tools.ietf.org/html/draft-wood-tsvwg-saratoga specifies only Saratoga and how it does file delivery and streaming. (As an aside, I'm not convinced by the utility of DTN bundling; doing HTTP over a variety of transports including TCP to make it useful for unusual environments seems promising, though.) > Could you elaborate a bit on how flow control is done in Saratoga? If you mean congestion sensitivity, it's entirely open. There's sufficient information flowing between sender and receiver for a variety of schemes to be implemented, as http://tools.ietf.org/html/draft-wood-tsvwg-saratoga mentions - LEDBAT, TCP friendliness, etc. Pick a scheme that suits; in many private dedicated links where link utilization is a concern, and losses are due to channel errors and not congestion, one might choose to run at link rate for fast transfers. Otherwise - HOLESTOFILL packets are sent by the receiver or requested by the sender, and include necessary selective negative acknowledgement (SNACK) information for reliable file transfer or reliable streaming. L. > > Cheers, > > Pascal > >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf Of Lloyd Wood >> Sent: mardi 3 novembre 2009 17:57 >> To: 6lowapp@ietf.org >> Subject: Re: [6lowapp] Charter and transports >> >>> Obviously UDP is something we will need to support as a transport >>> for >>> CoAP, and I argue that we also need to allow the use of CoAP over >>> TCP >>> as this is useful for some applications. When using UDP, some simple >>> mechanism for reliability (e.g. stop-and-wait) would of course be >>> needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). >>> When doing this we should of course cooperate with TSV people. >> >> http://tools.ietf.org/html/draft-wood-tsvwg-saratoga >> >> is such a protocol, providing reliability and IDs. >> >> L. >> >> DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/ >> >> From zach@sensinode.com Tue Nov 3 12:35:13 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965CA3A69E8 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 12:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ewoSXpseVrXf for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 12:35:12 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id EEE403A6807 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 12:35:11 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA3KZMFZ025587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 22:35:23 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <01d401ca5c8f$2c7b5780$85720680$@sturek@att.net> Date: Tue, 3 Nov 2009 22:35:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18FFC87C-715D-4090-826C-353A066398BE@sensinode.com> References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> <01d401ca5c8f$2c7b5780$85720680$@sturek@att.net> To: X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:35:13 -0000 On Nov 3, 2009, at 16:08 , Don Sturek wrote: > I would like to see the issue of transport added to the charter. > Down below I suggested the text: > "The protocol will operate over UDP by default, and should define an > alternative binding to TCP or another suitable reliable transport > layer." Is that suitable for you? It allows for binding to future transports =20 as well. > For smart energy, we plan to start with TCP, hoping that our =20 > relatively > small networks and ROLL don't violate the TCP congestion control =20 > timeout > threshold and that the code size of TCP are not too much for our small > devices. > > This said, we would like a back-up plan. We need to have UDP as =20 > that plan > but not using TCP removes many of the interesting applications that =20= > rely on > TCP. > > I do think long term having transport in the charter for 6LowAPP/=20 > CoAp is a > necessary thing. We can't do real transport work (TCP improvements e.g.) in CoAP or the =20= APP area as Lisa pointed out. The goal is however that this group (the =20= 6lowapp interest group in general) can spin off a new working group =20 (or general activity) in the transport area for this purpose in the =20 future. I think that makes sense. It would be best to first get some =20 experience with CoAP and see where the real requirements and problems =20= with TCP are. Zach > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On =20= > Behalf > Of Zach Shelby > Sent: Monday, November 02, 2009 10:07 PM > To: Jonathan Hui > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Charter and transports > > Hi, > > (New thread title) > > So to me the answer seems to be that TCP will work for some > configurations, but obviously not for all networks, and not for all > requirements (e.g. multicast). > > On Nov 3, 2009, at 5:15 , Jonathan Hui wrote: >> >>>> But are TCP's services/constraints >>>> appropriate for the application? I can think of a variety of LLN >>>> applications that work just fine with TCP and others that could >>>> stand >>>> to use something else to improve latency, message efficiency, non >>>> p2p >>>> flows, multihoming, mobility, etc. >>> >>> That's another question, yes. But I'd see building new transport >>> layer functions for 6LOWAPPs as an activity that would need some >>> very strong ties to the TSV area, if it wouldn't be hosted there in >>> the first place. >> >> Agreed. Though the line seems to be a bit blurred because some >> suggest building transport-like mechanisms in whatever "app-level" >> protocol we're working on. > > In the Stockholm BarBof, Lars had a very good explanation on this one. > We very well may start TSV area work on transport improvements - but > that is a long-term effort and won't happen in time for CoAP. I do > think we should aim at starting that work eventually, but let's get > CoAP started first. > > Obviously UDP is something we will need to support as a transport for > CoAP, and I argue that we also need to allow the use of CoAP over TCP > as this is useful for some applications. When using UDP, some simple > mechanism for reliability (e.g. stop-and-wait) would of course be > needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). > When doing this we should of course cooperate with TSV people. > > So this brings us to the next question, what should we say in the CoAP > charter about transports? Right now it says > > "The protocol will operate over UDP...". > > I would suggest it says something more like: > > "The protocol will operate over UDP by default, and should define an > alternative binding to TCP or another suitable reliable transport > layer." > > What do you think? > > Zach > >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system > without producing, distributing or retaining copies thereof. > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From d.sturek@att.net Tue Nov 3 12:41:41 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65723A67D3 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 12:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 EhD3ryeuRiFD for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 12:41:40 -0800 (PST) Received: from n20.bullet.mail.mud.yahoo.com (n20.bullet.mail.mud.yahoo.com [68.142.206.147]) by core3.amsl.com (Postfix) with SMTP id E0B5828C178 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 12:41:39 -0800 (PST) Received: from [209.191.108.97] by n20.bullet.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 20:41:58 -0000 Received: from [68.142.201.64] by t4.bullet.mud.yahoo.com with NNFMP; 03 Nov 2009 20:41:58 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 20:41:58 -0000 X-Yahoo-Newman-Id: 857702.47140.bm@omp416.mail.mud.yahoo.com Received: (qmail 73213 invoked from network); 3 Nov 2009 20:41:58 -0000 Received: from adsl-69-225-120-110.dsl.sndg02.pacbell.net (d.sturek@69.225.120.110 with login) by smtp105.sbc.mail.sp1.yahoo.com with SMTP; 03 Nov 2009 12:41:58 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: HD5f84wVM1lvHXVN3bSjIzTkGhbiR8ts2rkOqMLoSQqDS9LM_.tZaRYjNx9xeKUO46V7L6Jy3Uc0uwEkI_NYKSdg6bN2Egqxo9SkceeWsP6NIHTv_nqpl8OtdnCKkTrugVtRnMuCoK3upHdRy8hlcB2_E8IiE0guPcTS48T2eqaTah44oia0QFouaMrGz82XDD3z_GCzlrzqJ_EXAJpwOPScO1co_5yQCT07aXazxIWDrwXbLkgw4AIS08L6AVEwTiQWc3n5xGxcQPjktDIo2cgY37EkJ9rID9jFF6ECK.BWSnyLWg-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Zach Shelby'" References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <0D347129-430F-4902-B7AA-05D7B3360C2F@sensinode.com> <01d401ca5c8f$2c7b5780$85720680$@sturek@att.net> <18FFC87C-715D-4090-826C-353A066398BE@sensinode.com> In-Reply-To: <18FFC87C-715D-4090-826C-353A066398BE@sensinode.com> Date: Tue, 3 Nov 2009 12:41:55 -0800 Message-ID: <007801ca5cc6$1501f410$3f05dc30$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpcxTAsCoOgBAcJSuevA4tHh0JEZQAAMR0w Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 20:41:41 -0000 Hi Zach, Yes, what you wrote below is all good. The part on transport is exactly what I was expecting. We need to leave it in the charter but expect it to be spun off into transport if real work is needed. Don -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com] Sent: Tuesday, November 03, 2009 12:35 PM To: d.sturek@att.net Cc: 'Jonathan Hui'; 6lowapp@ietf.org Subject: Re: [6lowapp] Charter and transports On Nov 3, 2009, at 16:08 , Don Sturek wrote: > I would like to see the issue of transport added to the charter. > Down below I suggested the text: > "The protocol will operate over UDP by default, and should define an > alternative binding to TCP or another suitable reliable transport > layer." Is that suitable for you? It allows for binding to future transports as well. > For smart energy, we plan to start with TCP, hoping that our > relatively > small networks and ROLL don't violate the TCP congestion control > timeout > threshold and that the code size of TCP are not too much for our small > devices. > > This said, we would like a back-up plan. We need to have UDP as > that plan > but not using TCP removes many of the interesting applications that > rely on > TCP. > > I do think long term having transport in the charter for 6LowAPP/ > CoAp is a > necessary thing. We can't do real transport work (TCP improvements e.g.) in CoAP or the APP area as Lisa pointed out. The goal is however that this group (the 6lowapp interest group in general) can spin off a new working group (or general activity) in the transport area for this purpose in the future. I think that makes sense. It would be best to first get some experience with CoAP and see where the real requirements and problems with TCP are. Zach > > Don > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf > Of Zach Shelby > Sent: Monday, November 02, 2009 10:07 PM > To: Jonathan Hui > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Charter and transports > > Hi, > > (New thread title) > > So to me the answer seems to be that TCP will work for some > configurations, but obviously not for all networks, and not for all > requirements (e.g. multicast). > > On Nov 3, 2009, at 5:15 , Jonathan Hui wrote: >> >>>> But are TCP's services/constraints >>>> appropriate for the application? I can think of a variety of LLN >>>> applications that work just fine with TCP and others that could >>>> stand >>>> to use something else to improve latency, message efficiency, non >>>> p2p >>>> flows, multihoming, mobility, etc. >>> >>> That's another question, yes. But I'd see building new transport >>> layer functions for 6LOWAPPs as an activity that would need some >>> very strong ties to the TSV area, if it wouldn't be hosted there in >>> the first place. >> >> Agreed. Though the line seems to be a bit blurred because some >> suggest building transport-like mechanisms in whatever "app-level" >> protocol we're working on. > > In the Stockholm BarBof, Lars had a very good explanation on this one. > We very well may start TSV area work on transport improvements - but > that is a long-term effort and won't happen in time for CoAP. I do > think we should aim at starting that work eventually, but let's get > CoAP started first. > > Obviously UDP is something we will need to support as a transport for > CoAP, and I argue that we also need to allow the use of CoAP over TCP > as this is useful for some applications. When using UDP, some simple > mechanism for reliability (e.g. stop-and-wait) would of course be > needed along with a transaction ID (see e.g. 6lowapp-frank-chopan). > When doing this we should of course cooperate with TSV people. > > So this brings us to the next question, what should we say in the CoAP > charter about transports? Right now it says > > "The protocol will operate over UDP...". > > I would suggest it says something more like: > > "The protocol will operate over UDP by default, and should define an > alternative binding to TCP or another suitable reliable transport > layer." > > What do you think? > > Zach > >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system > without producing, distributing or retaining copies thereof. > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > -- http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. From zach@sensinode.com Tue Nov 3 13:33:14 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88C063A6925 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 13:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 MGUQ3IfxVogP for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 13:33:13 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id BAB153A6767 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 13:33:12 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA3LXP9m026642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Nov 2009 23:33:26 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <01d701ca5c90$36ba5e70$a42f1b50$@sturek@att.net> Date: Tue, 3 Nov 2009 23:33:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> <00b501ca5bc7$1ba2bcf0$52e836d0$@sturek@att.net> <01d701ca5c90$36ba5e70$a42f1b50$@sturek@att.net> To: X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Discovery X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:33:14 -0000 On Nov 3, 2009, at 16:16 , Don Sturek wrote: > Hi Zach, > > I haven't yet seen a service discovery solution that is usable for =20 > small > footprint devices (SSDP, SLP, DPWS, etc.). All use text strings =20 > (which will > translated to multiple packets) or directory agents in the network =20 > which are > not popular in unmanaged networks Agreed. What I am saying is that a much simpler discovery mechanism is enough =20= to fulfill the requirements I have seen. We don't need a full-blown =20 discovery of anything using any protocol for any device now. We just =20 need a built-in discovery mechanism for what interfaces are available =20= for this protocol, and optionally extra meta-info about those =20 interfaces or the device. > > Do you have any other references? Is there something I missed with =20= > one of > these technologies? A few examples: - DPWS has a model of using the application protocol (HTTP or SOAP-=20 over-UDP) to offer device profiles. Discovery could be supported in a =20= similar way, but much simpler in CoAP. - Web interfaces can be described in many standard ways already, e.g. =20= WADL or WSDL. And of course the URL itself already describes a lot. - It is normal practice to make these web interface descriptions =20 available on a well-known interface, so that they can be used. For =20 example REST designers often make the WADL description available on /=20 wadl. - The SENSEI project has implemented a mechanism like this (draft-=20 gold-6lowapp-sensei). - Tons of other protocols have simple built-in interface discovery. We don't have to decide exactly how to do it now, but I don't see it =20 being a hard problem. > > I see service discovery as a hard requirement in unattended networks. I totally agree. But by just defining a couple REST interfaces and a generic, compact =20 format for e.g. URL and interface desc info, you can build that into =20 the protocol (as a well-known interface) just as is normal practice on =20= the web. This is basically what the charter says right now, define a simple =20 discovery mechanism using the CoAP protocol supporting profiles. We =20 don' t have to decide exactly how to do it, but we should have the =20 general goals in there (unattended, peer-to-peer, no DA required, =20 profiles extensible). General service discovery could be future work for re-chartering? Zach > > Don > > > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: Monday, November 02, 2009 10:19 PM > To: d.sturek@att.net > Cc: 'Kerry Lynn'; 6lowapp@ietf.org > Subject: Re: [6lowapp] Discovery > > Hi, > > (New thread title) > > With regards to service discovery and CoAP, the question is do we need > full-blown service discovery at all for such constrained networks and > devices in this WG? > > Looking at the requirements and discussions so far, the conclusion we > had is that the same CoAP protocol can easily be used for exchanging > service information (profiles) in a distributed manner, but allowing > for a DA-like entity to exist if needed. DPWS uses a similar approach. > > The current proposed CoAP charter text takes this simple approach. > Define a discovery interface and a simple profile format using the > same protocol. For constrained nodes this makes sense, no requirement > to implement a separate protocol. This is also extensible for vendors > or other standards (e.g. DPWS, oBIX) to extend profiles. > > I am not saying that general service discovery mechanisms are not > useful some day (SLP, mDNS, UPnP etc.). There could be a future spin- > off or re-charter for this work. But looking at the current > applications and requirements on the table - what the charter is > suggesting is good enough and will demand the least effort. > > Thoughts? > > Zach > > On Nov 2, 2009, at 16:16 , Don Sturek wrote: > >> Hi Kerry, >> >> Here is the big problem we keep coming up against in service >> discovery: >> 1) Most agent based solutions are deeply unpopular by HAN device >> manufacturers. >> >> Here is why: >> 1) Many different vendors contribute to devices in the home area >> network >> (HAN) >> 2) No vendor of device "X" wants to have to increase their storage >> and >> computing capacity to become the repository of service information >> for all >> other devices in the network. >> 3) HANs are not managed networks where some owning entity would =20 >> place >> infrastructure devices >> >> Note what I wrote above is for the home area network (HAN). Building >> automation is another story as there is certainly a building control >> system >> in place there. >> >> The simplest solution for this for the HAN: Allow individual >> devices to >> hold their own service information and provide a unicast/multicast >> query >> system to allow for self description of service information. Allow >> for >> individual devices on the HAN to form their own queries and get =20 >> direct >> responses back from devices matching those service requests. >> >> For the I-D I turned in for service discovery, I did use the SLP DA >> (Directory Agent, I believe) to hold the strings (URI plus service) >> and had >> the DA responsible for substituting those for tokens upon request. >> However, >> I had in mind that would be all the DA would do and all service >> discovery >> was UA (User Agent) based. >> >> For a building controls solution (commercial or industrial), the DA >> could be >> fully populated an used on the building control system...... >> >> Don >> >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> Behalf >> Of Kerry Lynn >> Sent: Monday, November 02, 2009 5:32 AM >> To: 6lowapp@ietf.org >> Subject: [6lowapp] Newbie questions >> >> Greetings, >> >> My name is Kerry Lynn and I hope to contribute to this effort >> remotely. I >> am an independent contractor working in the area of building >> automation >> and have worked previously in Cisco and Apple network engineering in >> addition to supporting university research into constrained >> devices. I >> hope you will bear with what may be foolish questions as I come up to >> speed: >> >> I tried to access the audio stream and jabber feed from yesterday's >> meeting but was unable to do so. Is IETF registration necessary? >> >> Is it the consensus of the group to support peer-to-peer as well as >> server-based configurations? The first is what I'd term the "one >> light, >> one switch" scenario while the latter would include DHCP, DNS, etc. >> and perhaps application proxy support. >> >> Has anyone considered something like T/TCP as a candidate for >> transaction support? I know it has been traditionally implemented >> as a superset of TCP but I suspect it could be much simpler than >> full TCP if used in a controlled environment such as local >> communication with a full TCP/HTTP/REST proxy. The security >> concerns could be addressed simultaneously. >> >> Has anyone proposed mDNS/DNS-SD as an alternative to SLP? >> Does anyone have a feeling for how one client implementation >> compares to the other in terms if complexity? >> >> Thanks, -K- >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system > without producing, distributing or retaining copies thereof. > > > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From lars.eggert@nokia.com Tue Nov 3 13:39:16 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2702E28C17C for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 13:39:16 -0800 (PST) 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 bUufr10NujwM for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 13:39:15 -0800 (PST) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 24EE93A6A57 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 13:39:14 -0800 (PST) Received: from [192.168.1.47] ([12.162.0.169]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id nA3LdJFf061532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 3 Nov 2009 23:39:22 +0200 (EET) (envelope-from lars.eggert@nokia.com) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/signed; boundary=Apple-Mail-12--195724806; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: <01d801ca5c90$ba1031f0$2e3095d0$@sturek@att.net> Date: Tue, 3 Nov 2009 13:39:09 -0800 Message-Id: References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net> <01d801ca5c90$ba1031f0$2e3095d0$@sturek@att.net> To: "d.sturek@att.net" X-Mailer: Apple Mail (2.1076) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [195.148.124.194]); Tue, 03 Nov 2009 23:39:24 +0200 (EET) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:39:16 -0000 --Apple-Mail-12--195724806 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, On 2009-11-3, at 6:19, Don Sturek wrote: > I think there is a Smart Grid bar BOF in Hiroshima. This is > probably in > response to the NIST Smart Grid roadmap and "Priority Action Plan" > activity > (IETF is involved in priority action plan #1, IP for Smart Grid). > This > might be the place to suggest work on this topic in the Transport > area. that's a reasonable idea, but I think you've all been hanging around the IETF long enough to realize that any such effort will need to be driven by folks who want a solution. In other words, saying that "the TSV area should solve this" and then hoping that someone else will produce a solution isn't going to happen. We need the folks who need a solution put their cycles into designing one (in TSV, if that's where it'll fit, or wherever). Lars --Apple-Mail-12--195724806 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGbDCCAyUw ggKOoAMCAQICEAdjk36sXKbnVn15S0/qUp0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDYxNTExMjYxNFoXDTEwMDYxNTExMjYx NFowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA7mR8A+Pn0/FsUkMX6Pyjw+FL3IFcJk8GaKV5VJ40TMI0Wh8oq20cqA9X uqnVDW9WztKwH+o+msJenLwWpprbpJm4TImYGbnUJxYyN8gb81aiX1Bw2xCpJ5z3H2+8DsReJLuY Rdl4bVvaIxLIL4odmfsRwzPyNkOK8LRtfl6OPcaDOlFWzbikULfIVGGu7BqK4lxQSpYwwpZkOMOB 6nnBSfUOtBEmqO+qZG/nL/JxWFV5vxQgg4XHbsMMTxFf6+ji18BD09BUIfDLTuJoCzFmQhrM9vLT VuRhHWSL20LoafGjXv6mPt3i9IGJHpVb2dMQUgOgRyWHTKiUJVU/rUTdWwIDAQABo14wXDAqBgUr ZQEEAQQhMB8CAQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCAGA1UdEQQZMBeBFWxhcnMu ZWdnZXJ0QG5va2lhLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADUx+67n98wt I1vydB90HeSZP4Y64VCxxb0NxGGFvfc2+JdVKeHJ/xT+l+ygYKsWNwJJprkPi4WZ5G0crkq4VK1H 5drEJIztpSPVfWI05vPidaaGuuuCR+6MvJMtOTEYEvc/6eovBnkrzRf9x5x5EyuJXAWTeuBADg80 QI3vQ1tZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIG A1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjEL MAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNV BAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAK MNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7 n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAw QwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJl ZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9M Ibj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAq BgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAHY5N+rFym51Z9eUtP 6lKdMAkGBSsOAwIaBQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTA5MTEwMzIxMzkwOVowIwYJKoZIhvcNAQkEMRYEFJgKrhrawPtR2RsU9F9jnu9o6RTuMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQB2OTfqxcpudWfXlLT+pSnTCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQB2OTfqxcpudWfXlLT+pSnTANBgkqhkiG9w0BAQEF AASCAQCDwFVHqitP+K+z9YXwt4gT+BgqIC7HnH62cQBOM2aVSqyIo0+vDQJkz0rONKX4kI3S3Xid 3BoSwi42gGLHnD90J18sH39plnfNhDrHqwRHE4RLsMmX5jgGVk94TaK7cEI+dzfbb12cbT3nCNgV g/a7S7GZQBiahH0Imvn3DdHuqPDU1iLOt4gagJXUoaJy2Jy/lCeXQ9FLl87aVULfiKEBXRPooxKm wXLp4ajU53wZFAfCNPRCNInR0UVaIG1k99TVguvLnsVktXwRXIagQ4ToF95zzY4Z9u6pIkExU/am Q7z82IZclgdZrg8oJObzQ+c6VtsXKZ3WdwK3OeGCzSszAAAAAAAA --Apple-Mail-12--195724806-- From d.sturek@att.net Tue Nov 3 13:44:20 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A325F28C0EB for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 13:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.272 X-Spam-Level: X-Spam-Status: No, score=0.272 tagged_above=-999 required=5 tests=[AWL=-0.993, BAYES_40=-0.185, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 C17FrnR1Vufn for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 13:44:15 -0800 (PST) Received: from n15.bullet.mail.mud.yahoo.com (n15.bullet.mail.mud.yahoo.com [68.142.206.42]) by core3.amsl.com (Postfix) with SMTP id 31E143A67E2 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 13:44:12 -0800 (PST) Received: from [68.142.200.225] by n15.bullet.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 21:44:31 -0000 Received: from [68.142.201.251] by t6.bullet.mud.yahoo.com with NNFMP; 03 Nov 2009 21:44:31 -0000 Received: from [127.0.0.1] by omp412.mail.mud.yahoo.com with NNFMP; 03 Nov 2009 21:44:31 -0000 X-Yahoo-Newman-Id: 522085.33551.bm@omp412.mail.mud.yahoo.com Received: (qmail 38014 invoked from network); 3 Nov 2009 21:44:31 -0000 Received: from adsl-69-225-120-110.dsl.sndg02.pacbell.net (d.sturek@69.225.120.110 with login) by smtp102.sbc.mail.sp1.yahoo.com with SMTP; 03 Nov 2009 13:44:30 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: ZuKRdEQVM1nTUrUt0kZbq2GYARNniuP7WHQHgLxtv3iRzK81fEKqBVX6pzddI9fY3sjVoJ9MkN3p2gHRGfzvMI6BxpTfyq9Z.Y9ad3CiaXyXXrB6EdX9eYBM4Hpnhfu6yafkUutmSiooqIAfd2eskcWYNhULxAEoG1swEoCqT7BbyQNlD0NmuLZQeSHIuMGkN3udHS9goJSiQW8MuK6Z7kO1xH4q9UUGzTawFI.WY.QvvQwg9KacvTd2.gtgefR0jwa6cGMf1nD_7AFm1mPCiymX3DW9iTD67UNt.__dZsPy5Adxiw-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Lars Eggert'" References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net> <01d801ca5c90$ba1031f0$2e3095d0$@sturek@att.net> In-Reply-To: Date: Tue, 3 Nov 2009 13:44:28 -0800 Message-ID: <00a801ca5cce$d1ba5b30$752f1190$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpcziBlamEVxnJ2QZSTHuFLv9zvuAAAD9gA Content-Language: en-us Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:44:20 -0000 Hi Lars, Yes, I would expect that someone who needs this feature will help sponsor it via I-Ds and participation. Could be ZigBee Smart Energy depending on how our interop is going and what issues come up. Don -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Tuesday, November 03, 2009 1:39 PM To: d.sturek@att.net Cc: 'Cullen Jennings'; 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work Hi, On 2009-11-3, at 6:19, Don Sturek wrote: > I think there is a Smart Grid bar BOF in Hiroshima. This is > probably in > response to the NIST Smart Grid roadmap and "Priority Action Plan" > activity > (IETF is involved in priority action plan #1, IP for Smart Grid). > This > might be the place to suggest work on this topic in the Transport > area. that's a reasonable idea, but I think you've all been hanging around the IETF long enough to realize that any such effort will need to be driven by folks who want a solution. In other words, saying that "the TSV area should solve this" and then hoping that someone else will produce a solution isn't going to happen. We need the folks who need a solution put their cycles into designing one (in TSV, if that's where it'll fit, or wherever). Lars From shidan@gmail.com Tue Nov 3 13:48:36 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C250D3A692B for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 13:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.321, 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 Z1oCJFggYV8v for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 13:48:35 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id B2FC728C0CE for <6lowapp@ietf.org>; Tue, 3 Nov 2009 13:48:34 -0800 (PST) Received: by ewy3 with SMTP id 3so2464960ewy.37 for <6lowapp@ietf.org>; Tue, 03 Nov 2009 13:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lwanb0jiJJbgCPuNlA7RbUVappzNOIVd32Sc6GjS8Xw=; b=Qr1edvBcHdiu/CSI4u4CAJBkaen3cWE62Qw9XZP4jzjBBstOQnAv2ke3VjYDuzmlRo tSU4kBHjbpEhiVchFZcnILaLbBhn0W16w9nX2pX5eT4E9O0iXkIrQEp9nlEJo46FdUF6 jRd/cJUqF1LIaVI7SFapAvd2cP+8dJa6O79pg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=A4NXne9Jzjv0c5FZKVufWBIv1XJ+ANS6Gx0ZPUuiWeViHwJPC0OogENkTMo70liG5o wEXTUrSRNU4xqvWjwbcCqRol96LXeN4LReuZp/pw7aVy1EVr3J1Jx4/JOrVDaHuUxYno 4SQTUYSz8ZJnB6b2DVCMyxpAt1dDfKEoyhB0o= MIME-Version: 1.0 Received: by 10.216.86.201 with SMTP id w51mr198556wee.8.1257284929599; Tue, 03 Nov 2009 13:48:49 -0800 (PST) In-Reply-To: References: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> Date: Tue, 3 Nov 2009 16:48:49 -0500 Message-ID: <429b380e0911031348x4c9985a8sd554f5c322836c24@mail.gmail.com> From: Shidan To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 21:48:36 -0000 Hi Cullen, this is actually part of my point. HTML, HTTP and DNS make a great distributed database. On the other hand web browsers are evolving beyond this and web patterns are emerging to meet the needs of a standardized OS. But, using Gmail as an example, if we could have avoided compiling Java to JavaScript and HTML(GWT), three layers of virtual machines and expanding the underlying technologies of the web just to make a network accessible email client possible, we would have seen much more exciting products by now. Don't get me wrong, given the circumstances, it's great that people have been able to innovate and that the browser is evolving to meet the need for a standardized OS. Now that we have a clean slate and since no one is encumbered by product decisions based on business competition and politics, and lessons learned from those same web applications you mention, I think these are some things we want implemented in a standardized manner in CoApp: 1) Everything the Web and HTTP offers for a distributed database / linked d= ata 2) Presence 3) Addressing groups & forking 4) Pub/Sub 5) Offer/Answer Exchange 6) Rendevouz 7) Everything the Web has to offer for messaging & extensibility I think this sort of HTTP+ or RESTfull+ would be a better start to meet the needs of things like home automation, energy management and home health care and as I mentioned we are working on a more detailed paper for this. On Tue, Nov 3, 2009 at 12:47 AM, Cullen Jennings wrote: > > All these things sound great, but pealing away the excitement how do we f= ind some protocols, that if we define them, would enable the type of exciti= ng intelligent network you are are thinking about. For example, much of wha= t made things like gmail and facebook possible are a handful of technologie= s: JavaScript, HTML, HTTP, TLS, TCP, DNS, IP and routing. How can we find a= few simple technologies that when implemented in standardized ways between= vendors would enable the stuff you are talking about. What's missing? What= do we need. I'm trying to drag this back to an engineering task. > > PS - On topic of XMPP and SIP. No argument from me that these are not imp= ortant protocols for real time applications. I'm perfectly happy to see the= m includes as things to consider. > > On Oct 31, 2009, at 4:41 PM, Shidan wrote: > >> Hi Fluffy, >> >> I definitely agree with your overall sentiment, but one thing that I alw= ays find dissapointing is when people give me the "turn on and off" garage = doors, thermostats, etc as the only examples of what a HAN should be about.= I think this is part of the reason some, specially me, are a little confus= ed by the WG. >> >> The truth is, I'm personally not looking for a X10, legacy 802.15.4, KNX= , etc replacement; they do a fine job of turning things on and off. Let me = list a few things I would like in my HAN: >> >> 1) I want a network that goes beyond enabling me to discover and control= a device to one that enables devices to discover, control and communicate = with each other and mixed groups of devices and people. >> >> 2) I want devices to do things based on time and other arbitrary policie= s as part of the network >> >> 3) I want mobile & secure smart objects to take advantage of pervasive g= lobal networks and objects that are location aware. >> >> 4) I want a system that can evolve so that when it makes economic sense,= the physical components of a smart appliance are "smart components" themse= lves. I also see a day when people will be upgrading the features and funct= ionality of their washing machine through a >> firmware upgrade.The last two are probably sound silly now, but they're = real considerations of how things can evolve. >> >> The truth of the matter is that even with X10 and gateways, except for d= evice mobility, most of this is possible. It's further true that the most d= ifficult challenge of HANs is not the networking but end user programmabili= ty and moving intelligence to the network will help in developing these sys= tems. >> >> Right now, the difficulty I'm having is that it almost seems, and this c= ould be a wrong interpretation I hope, that this working group is saying "l= et's forget about addressing the greater problem of HANs through network in= telligence and let's just focus on satisfying the bare minimum needs of the= energy industry so they can move to IP" and "then we will let the system e= volve." >> >> Another approach could be that this working group could start by conside= ring the HAN application layers like UPnP and see how they need to evolve f= or pervasive access, where they have gone wrong for developers and so on an= d then see how much of this better system you define can be brought down to= LoPANs. This is something I think can be done in the time frames this WG h= as proposed and anything that comes out of it would work great for the ener= gy industry as well. >> >> Of course, even better would be a general application layer framework fo= r LoPANS, but since this is technological limitation, I think looking at re= quirements is absolutely necessary. >> >> A side note, I definitely think SIP and XMPP are relevant in this field = Cullen, there is a reason why so many M2M applications are using XMPP, spec= ially in BRIC countries. There is also a reason why the leading demand resp= onse provider is using XMPP today, if you can take this all the way to the = home and on AMI networks then why not? There is also a reason why the few M= SOs and incumbents that I know of who are offering home media management = =A0and media delivery to connected devices are switching to SIP-DLNA gatewa= ys. Again, this is not even the real issue, who really cares what you name = a protocol as long as it works and the proper requirements have been consid= ered. My concern above is much more important. >> >> Shidan Gouran >> >> On Sat, Oct 31, 2009 at 1:42 PM, Cullen Jennings wrot= e: >> >> Right now the draft charter has a sketch of some of the key parts of the= architecture. I'd like to talk about the pro's and cons of putting this in= a charter. Typically charters don't have this. Many BOFs fail when all the= people in the room don't lave having a common idea of what the group will = do. Typically =A0the architecture is developed in a draft and often can tak= e considerable time however there's nothing stopping this type of informati= on form being in a charter. Now this effort is a bit different from your ty= pically BOF. Let me list some differences: >> >> 1) This is not meant to run on normal networks. We've told the transport= folks, yah, we are going to have to make different assumptions than normal= application protocols make because there some special stuff going on here.= That makes the Transport and INT people very nervous. >> >> 2) We told the security people, none of your off the shelf security appr= oaches will work for us because we have special requirements. We are not ev= en 100% sure it is feasibly to simultaneously satisfy all the requirements.= That makes the Security people, uh, prickly. >> >> 3) Some people have suggest that SIP might be just the thing to build on= over for things like controlling a garage door opener. =A0Many (but not al= l) SIP folks feel that SIP is for User to User communications and often use= SIP to control the garage door and the prototypical example of what should= *not* be done with SIP. This makes the RAI people want to come and say "hi= ". I'm not saying we could not use SIP but I am saying the SIP people would= want to come and talk about the issues before that decision got made. Hope= fully they won't ask if any of this has any real time application propertie= s or infrastructure they could help with. >> >> 4) The OAM folks must be thinking, so how is this different from what we= do every single day? >> >> 5) The INT and Routing guys want to know how this related to work they a= re doing. >> >> 6) I've had a few questions that loosely translated to "so what feature = of IPv6 are you using to guarantee that this will only work on a v6 network= ". >> >> If we told the DNS guys we were consider doing all our senor reading use= DNS so we could leverage the DNS caching we would have pretty much every a= rea "concerned". >> >> People have questions. Lots of questions. The challenge for a successful= BOF like this is to put together a coherent story of what the big picture = looks like and how it all hangs together. I believe we have a reasonable ch= ance of having a WG approved if we can show that there is a group of people= that have >> >> 1) a clear idea of what they want to build >> >> 2) the same common idea of what it is >> >> 3) it is an engineering project, and not science project requiring inven= tion of new techniques >> >> 4) it meets the type of requirements the IETF has for standards track wo= rk >> >> The quickest way to do this would be to have in some document that we ta= ke into the BOF use cases, requirements, and a high level architecture. We = have drafts with use case and requirements and we can refine theses int he = slides used in the BOF. If we can agree on an architecture, we can stuff th= at in the charter. >> >> I'm probably a bit naive to think we can come up with a sketch of an arc= hitecture and agree to it in the BOF. But if we do, we have a chance at hav= ing the a protocol document finished before 2011. >> >> A more tried and true approach to this would be to work on the requireme= nt, use case, and architecture in some ad-hoc meetings then go for a BOF. T= he P2PSIP WG had problems similar to this WG in that they were going to hav= e some harder than average transport and security issues. They meant for mu= ltiple hours at every IETF for multiple years *before* the WG was approved.= Lots of the meetings had around 100 people with pretty substantial effort. >> >> Another approach would be to charter just to do requirements then rechar= ter to do the protocols. I'd bet anyone on odds of a bottle of beer to a bo= ttle of scotch that would not finish before 2011 and even odds on a bottle = of scotch it would not finish before 2012. >> >> Many people have expressed that time is of the essence on this work and = something that delivers in 2012 will be of very little deployment value. I'= m not in a good position to evaluate how quickly something is needed here b= ut I'm happy to take everything people tell m at when this is needed at fac= e value. >> >> The sponsoring AD has read me the riot act on scope for the initial set = of work, make this a small bite size chunk that meets a reasonable set of n= eeds and we can complete quickly. As that completes, I'm sure there would b= e no problem re-charting to expand the scope for more things or forming oth= er WG to take on related work. >> >> So bottom line, I'm trying to drive this to figure out what is small bit= e size chunk that everyone could live with for the initial stuff to be work= ed on. If we are lucky, we can end up agreeing on requirements, uses cases,= and a high level sketch of the architecture without a long drawn out proce= ss. =A0If this fails, and I admit it very well could, well then we can just= move back to some other way of dealing with this. >> >> A good charter is a plan for work as well as something that constrains t= he number of possibilities a WG has to consider. Now clearly we can't const= rain things beyond what is needed. If we can mange to agree on a tight char= ter, the WG will be able to progress work very rapidly. If we fail to do th= is in the next few week, having tried will not set back the work in any sig= nificant way. >> >> I hope this explains, I'm not =A0trying to convince anyone the architect= ure in the draft is the right one. =A0I'm just trying to convince people to= fix it before the BOF. >> >> Sorry for such a long email, >> Cullen >> >> >> >> >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > From cabo@tzi.org Tue Nov 3 14:19:02 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FEBA3A6822 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 14:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 N6A5HMnq8HSV for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 14:19:01 -0800 (PST) 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 868733A67A2 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 14:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nA3MIUbU008623; Tue, 3 Nov 2009 23:18:31 +0100 (CET) Received: from [192.168.217.101] (p5489FD7F.dip.t-dialin.net [84.137.253.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id CCA0CB194; Tue, 3 Nov 2009 23:18:29 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Carsten Bormann In-Reply-To: <429b380e0911031348x4c9985a8sd554f5c322836c24@mail.gmail.com> Date: Tue, 3 Nov 2009 23:18:27 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> <429b380e0911031348x4c9985a8sd554f5c322836c24@mail.gmail.com> To: Shidan X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:19:02 -0000 On Nov 3, 2009, at 22:48, Shidan wrote: > Everything The idea behind CoAP (Constrained-node/network Application Protocol) is to have something very simple, very basic, that can be used to run applications that involve constrained IP nodes on constrained networks. "Everything" is not the first word that comes to my mind here. I'd prefer "Do the simplest thing that could possibly work". (That is actually a googleable phrase.) Gruesse, Carsten From shidan@gmail.com Tue Nov 3 14:55:52 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7720C28C0F8 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 14:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.209, 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 yIqG5mKh6Hgc for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 14:55:51 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 78C2328C0E1 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 14:55:51 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so773142eya.51 for <6lowapp@ietf.org>; Tue, 03 Nov 2009 14:56:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ctSXfq/f9e3UUxYBLtbcal7ejV+bbNJKxWm993I4/CI=; b=CXQRWPtCbh8UDFXmejKQi3tTv8ctB9wehqFQwVNQ9Wfag3cogn9Zo0jMno6T7A+53f DxeiID3XeWoRttkh0R/wa0p9KObbkIxMkSCcfHTOptbQJff+gXuETw9FxbIJI2GD5e99 XIx7M474JpivfWGzuVllfv52tlXq2GEDY2b+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cmIvsyzKNspqA7kaf1XISTotfgzvu2H9Zbzen+rHbj6PIJK8AITgG2wB6yivlc6Pc2 hzrsqHJprq6YJKLQIUQRa3yR+C6YgqN+RPGKzR/4iwJb1fwWfU6YneWKsHkMcDKVgLvG tlFGA4EM1naPQyebgtrmTtZ5lSgFs6UuCecDI= MIME-Version: 1.0 Received: by 10.216.87.79 with SMTP id x57mr245602wee.83.1257288967624; Tue, 03 Nov 2009 14:56:07 -0800 (PST) In-Reply-To: References: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> <429b380e0911031348x4c9985a8sd554f5c322836c24@mail.gmail.com> Date: Tue, 3 Nov 2009 17:56:07 -0500 Message-ID: <429b380e0911031456y67a2e95cx1151de4403a5eda5@mail.gmail.com> From: Shidan To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e6d7dfa74b98f904777f664c Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:55:52 -0000 --0016e6d7dfa74b98f904777f664c Content-Type: text/plain; charset=ISO-8859-1 Hi Carsten, I definitely agree and thats an interesting Google search. But we should do no less than is required as well. Also, if we can avoid creating something from scratch, that in itself is doing the simplest thing that could possibly work. Shidan Gouran On Tue, Nov 3, 2009 at 5:18 PM, Carsten Bormann wrote: > On Nov 3, 2009, at 22:48, Shidan wrote: > > Everything >> > > The idea behind CoAP (Constrained-node/network Application Protocol) is to > have something very simple, very basic, that can be used to run applications > that involve constrained IP nodes on constrained networks. "Everything" is > not the first word that comes to my mind here. I'd prefer "Do the simplest > thing that could possibly work". (That is actually a googleable phrase.) > > Gruesse, Carsten > > --0016e6d7dfa74b98f904777f664c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carsten, I definitely agree and thats an interesting Google search. But = we should do no less than is required as well. Also, if we can avoid creati= ng something from scratch, that in itself is doing the simplest thing that = could possibly work.=A0

Shidan Gouran

On Tue, Nov = 3, 2009 at 5:18 PM, Carsten Bormann <cabo@tzi.org> wrote:
On Nov 3, 2009, at 22:48, Shidan wrote:

Everything

The idea behind CoAP (Constrained-node/network Application Protocol) is to = have something very simple, very basic, that can be used to run application= s that involve constrained IP nodes on constrained networks. =A0"Every= thing" is not the first word that comes to my mind here. =A0I'd pr= efer "Do the simplest thing that could possibly work". =A0(That i= s actually a googleable phrase.)

Gruesse, Carsten


--0016e6d7dfa74b98f904777f664c-- From shidan@gmail.com Tue Nov 3 14:57:55 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA91B3A68F3 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 14:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.274, 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 m3GJZlHPsD8X for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 14:57:54 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 7E8813A6897 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 14:57:54 -0800 (PST) Received: by ewy3 with SMTP id 3so2534473ewy.37 for <6lowapp@ietf.org>; Tue, 03 Nov 2009 14:58:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ECGy7oD5iz5Jlk0RzT1yjWJqoHzdCuR7UuDzVFSgPt8=; b=h7dadlAsAMVEKdlAOFFLw7/Y0+M1BAD7seAzS4R1xAYaIUGxF38JkwMQ5LBs2QiPFv ARr1ZchrIVulnQ35I9pA8rz4zwWViDBLspOOoM7kw0bYN3LLyJOesjBwmjd0jRz/DBAB 5s/oSB5ev1GV5Q9FG5awVb5cne/iASGVqpYRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=taye8yY1cbUk/ym11gtIHbu0pETtLYRzJdX6AryEpG4qKvlSyBWznoC5mkKcWIjbhD czRG4z2ZlLfw3HyGk2M2lUT7rvnsC5YJd6ntGBcmNTxVJklaG5Hp9wOgKmvzYMNhkH/r ttte/NJSMp+ZBhbbhlNGnItyj0xOuoqLJW5qM= MIME-Version: 1.0 Received: by 10.216.86.201 with SMTP id w51mr221537wee.8.1257289092260; Tue, 03 Nov 2009 14:58:12 -0800 (PST) In-Reply-To: <429b380e0911031456y67a2e95cx1151de4403a5eda5@mail.gmail.com> References: <429b380e0910311541ve2666fcjdc27d63aaddb696@mail.gmail.com> <429b380e0911031348x4c9985a8sd554f5c322836c24@mail.gmail.com> <429b380e0911031456y67a2e95cx1151de4403a5eda5@mail.gmail.com> Date: Tue, 3 Nov 2009 17:58:12 -0500 Message-ID: <429b380e0911031458m5695fef9id013c885c41fc21@mail.gmail.com> From: Shidan To: Carsten Bormann Content-Type: multipart/alternative; boundary=0016e6d99d05b9626f04777f6dab Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Architecture Sketch in Charter X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 22:57:55 -0000 --0016e6d99d05b9626f04777f6dab Content-Type: text/plain; charset=ISO-8859-1 "Also, if we can avoid creating something from scratch, that in itself is doing the simplest thing that could possibly work." Or I should say could be, not is. On Tue, Nov 3, 2009 at 5:56 PM, Shidan wrote: > Hi Carsten, I definitely agree and thats an interesting Google search. But > we should do no less than is required as well. Also, if we can avoid > creating something from scratch, that in itself is doing the simplest thing > that could possibly work. > > Shidan Gouran > > > On Tue, Nov 3, 2009 at 5:18 PM, Carsten Bormann wrote: > >> On Nov 3, 2009, at 22:48, Shidan wrote: >> >> Everything >>> >> >> The idea behind CoAP (Constrained-node/network Application Protocol) is to >> have something very simple, very basic, that can be used to run applications >> that involve constrained IP nodes on constrained networks. "Everything" is >> not the first word that comes to my mind here. I'd prefer "Do the simplest >> thing that could possibly work". (That is actually a googleable phrase.) >> >> Gruesse, Carsten >> >> > --0016e6d99d05b9626f04777f6dab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable "Also, if we can avoid creating something from scratch, that in itself= is doing the simplest thing that could possibly work."

=
Or I should say could be, not is.

On= Tue, Nov 3, 2009 at 5:56 PM, Shidan <shidan@gmail.com> wrote:
Hi Carsten, I definitely agree and thats an= interesting Google search. But we should do no less than is required as we= ll. Also, if we can avoid creating something from scratch, that in itself i= s doing the simplest thing that could possibly work.=A0

Shidan Gouran
=


On Tue, Nov 3, 2009 at= 5:18 PM, Carsten Bormann <cabo@tzi.org> wrote:
On Nov 3, 2009, at 22:48, Shidan wrote:

Everything

The idea behind CoAP (Constrained-node/network Application Protocol) is to = have something very simple, very basic, that can be used to run application= s that involve constrained IP nodes on constrained networks. =A0"Every= thing" is not the first word that comes to my mind here. =A0I'd pr= efer "Do the simplest thing that could possibly work". =A0(That i= s actually a googleable phrase.)

Gruesse, Carsten



--0016e6d99d05b9626f04777f6dab-- From nicolas.riou@fr.schneider-electric.com Tue Nov 3 15:29:09 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E065F28C0E9 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 15:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 eAFNYGEfd41Q for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 15:29:09 -0800 (PST) Received: from mailX03.eud.schneider-electric.com (mailx03.eud.schneider-electric.com [205.167.7.41]) by core3.amsl.com (Postfix) with ESMTP id E5B7B28C0E1 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 15:29:08 -0800 (PST) Received: from ATEUI01.schneider-electric.com ([10.198.14.9]) by mailX03.eud.schneider-electric.com with ESMTP id 2009110400285936-134072 ; Wed, 4 Nov 2009 00:28:59 +0100 To: 6lowapp@ietf.org MIME-Version: 1.0 X-KeepSent: 164C5409:51429B82-C1257663:007E96BE; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: nicolas.riou@fr.schneider-electric.com Date: Wed, 4 Nov 2009 00:18:46 +0100 X-MIMETrack: Serialize by Router on ATEUI01.Schneider-Electric.com/T/SVR/Schneider at 04/11/2009 00:29:28, Serialize complete at 04/11/2009 00:29:28, Itemize by SMTP Server on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 11/04/2009 12:28:59 AM, Serialize by Router on AXEU3OUT.schneider-electric.com/X/SVR/SEIxtra at 11/04/2009 12:29:01 AM, Serialize complete at 11/04/2009 12:29:01 AM Content-Type: multipart/alternative; boundary="=_alternative 008109C0C1257663_=" Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2009 23:29:10 -0000 Message en plusieurs parties au format MIME --=_alternative 008109C0C1257663_= Content-Type: text/plain; charset="US-ASCII" Hi Cullen, >----- Message de Cullen Jennings sur Sat, 31 Oct 2009 11:29:41 -0600 ----- >Pour: arjun.lists@hsc.com >cc: Don Sturek , 6lowapp@ietf.org >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > > ... >OK - The way I want to try and derive us towards a decision here is >get a list of candidate protocols then for each one ask the yes/no is >the their agreement that we should do a mapping to that protocol. The >protocols I have heard so far are HTTP, SNMP, SMTP. So two questions > >1) what other protocols mapping should we do? The charter has significantly changed these days and I would like to re-state the need for seamless interfacing between 6lowapp and the DPWS world. DPWS is a low cost SOA solution at device level and will play a major role in future Building and Industrial Automation systems (embedded in zone controllers, Automation servers, industrial PLCs...). Besides, in some cases, native support of DPWS in VISTA and Windows 7 network explorer might help in simplifying discovery and commissioning of devices. The HTTP REST model proposed in the new charter is sufficient for simple get/set operations but I join Vlad Trifa when saying that there are requirements for more than just request/response messaging patterns like e.g. publish/subscribe (multicast). IMO seamless interfacing with WS_* (at least straightforward proxying) must be provided to ensure efficient integration of 6lowpan networks in upcoming architectures. Regards. Nicolas --=_alternative 008109C0C1257663_= Content-Type: text/html; charset="US-ASCII"
Hi Cullen,

    >----- Message de Cullen Jennings <fluffy@cisco.com> sur Sat, 31 Oct 2009 11:29:41 -0600 -----
    >Pour:        arjun.lists@hsc.com
    >cc:        Don Sturek <donsturek@grid2home.com>, 6lowapp@ietf.org
    >Objet:        Re: [6lowapp] Proposed charter for 6LoWAPP BOF
    >
    >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:
    >
    > ...
    >OK - The way I want to try and derive us towards a decision here is  
    >get a list of candidate protocols then for each one ask the yes/no is  
    >the their agreement that we should do a mapping to that protocol.  The  
    >protocols I have heard so far are HTTP, SNMP,  SMTP. So two questions
    >
    >1) what other protocols mapping should we do?

The charter has significantly changed these days and I would like to re-state the need for
seamless interfacing between 6lowapp and the DPWS world. DPWS is a low cost SOA solution at
device level and will play a major role in future Building and Industrial Automation systems
(embedded in zone controllers, Automation servers, industrial PLCs...). Besides, in some
cases, native support of DPWS in VISTA and Windows 7 network explorer might help in simplifying
discovery and commissioning of devices.
The HTTP REST model proposed in the new charter is sufficient for simple get/set operations but
I join Vlad Trifa when saying that there are requirements for more than just request/response
messaging patterns like e.g. publish/subscribe (multicast). IMO seamless interfacing with WS_*
(at least straightforward proxying) must be provided to ensure efficient integration of 6lowpan networks
in upcoming architectures.

Regards.
Nicolas
 --=_alternative 008109C0C1257663_=-- From pister@eecs.berkeley.edu Tue Nov 3 22:17:23 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FF7A28C1C1 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 22:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 vjxq9dx1Szq5 for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 22:17:22 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 1C7CB28C142 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 22:17:22 -0800 (PST) Received: from [192.168.1.100] (c-24-4-148-227.hsd1.ca.comcast.net [24.4.148.227]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nA46HDkC025580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 22:17:14 -0800 (PST) Message-ID: <4AF11C63.7080807@eecs.berkeley.edu> Date: Tue, 03 Nov 2009 22:17:07 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <6A2A459175DABE4BB11DE2026AA50A5D8E01D2@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D8E01D2@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 06:17:23 -0000 Pascal - I assume that we would only have path diversity inside the WPAN, and that the purpose of diversity would be to reduce latency, rather than increase it (e.g. RoLL, siblings when parents are having problems, etc.). If you can't get the packet through to your preferred parent in a timely way, you try someone else in the hopes that you can still hit your latency target. Yes? Anyway, the goal of my original question was to understand what kinds of latency distributions would work. I agree that it is easy to find distributions that will bring TCP to it's knees. I'm hopeful that we can find some ways to make our meshes TCP-friendly under those circumstances when it is advantageous. Under other circumstances (e.g. the ISA100 use cases that you presented) it's neither necessary nor efficient. ksjp Pascal Thubert (pthubert) wrote: > Hi Lars and Kris: > > >>> In the early days of sensor networks it was not uncommon to see end- >>> to-end best-effort loss rates of 10% or more. I don't think that >>> anyone tolerates that kind of performance anymore. With link-layer >>> ACKs and path diversity in the routing layer I think that 99.9% for >>> best-effort is now table stakes. >>> >> All that certainly helps, but I haven't seen much discussion on whether >> > we all agree that we're only going to > >> target scenarios for 6LOWAPP for which we can make the assumption that >> > such techniques will be in use. > > And path diversity when applied to TCP flows can have very adverse > effects, if the packets are actually balanced over paths of very > different latencies. A packet that is not lost but delayed in an > alternate path will trigger fast recovery and cause the congestion > window to drop. > > Add a very long TTL to the mixture and you get a recipe for a very low > throughput with packet duplication. > > MPTCP might offer some benefits if the subflows were routed on a given > path each, but that's not what we are doing here so I'm not too hopeful > though I'd like to dig more. > > > Pascal > From pister@eecs.berkeley.edu Tue Nov 3 22:25:59 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C0028C1CE for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 22:25:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Wy4jcJ8dx5wM for <6lowapp@core3.amsl.com>; Tue, 3 Nov 2009 22:25:58 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 0805228C142 for <6lowapp@ietf.org>; Tue, 3 Nov 2009 22:25:58 -0800 (PST) Received: from [192.168.1.100] (c-24-4-148-227.hsd1.ca.comcast.net [24.4.148.227]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nA46QEkB025647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Nov 2009 22:26:15 -0800 (PST) Message-ID: <4AF11E81.80107@eecs.berkeley.edu> Date: Tue, 03 Nov 2009 22:26:09 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Kelsey References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <66D8B4F0-8106-47C2-8CC1-936791195D22@archrock.com> <72876869-927E-45B6-A9D9-1A7E5A22E196@nokia.com> <50D02497-17A6-4EF2-AC6E-FE783E48E071@archrock.com> <6A2A459175DABE4BB11DE2026AA50A5D8DFDD6@XMB-AMS-107.cisco.com> <4AF006B9.3050101@eecs.berkeley.edu> <87ocnj6332.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87ocnj6332.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 06:25:59 -0000 Completely agree that TCP doesn't make any sense if you're sending one packet per mote per day. Maybe I misread the intent, or I'm thinking about different apps. I'm not saying that we should use TCP for everything - quite the contrary, I agree with Pascal's reasons why we didn't use it in isa100. Having said that, I am always surprised by the strong negative reactions that arise when TCP is mentioned in a wireless context. I realize that there have been many good and painful lessons learned in the past, but it also seems quite clear that TCP can run successfully on low power multi-hop 15.4 meshes as well. Many/most applications won't need this, but for at least a few it will be perfect. Yes? ksjp Richard Kelsey wrote: > Date: Tue, 03 Nov 2009 02:32:25 -0800 > From: Kris Pister > > My opinion is that almost by definition (the "6" in the name), that TCP > will be an important part of that future. I'm 100% sure that we'll find > other ways of doing things as well, but it makes me nervous when it > looks like we're trying to reinvent every protocol from bottom to top, > and still call it IP. > > Kris, > > I hope we don't end up reinventing anything. If we get the > layering right we can add a new protocols as needed and > still have everyone agree that the result is IP. In > particular if 6LoWPAN and ROLL get their parts right, then > TCP will work out to the nodes and will be used when it is > appropriate. > > I think that this thread is somewhat missing the point. The > question isn't just whether TCP will fail to get data > delivered in this or that situation, but also, in the larger > picture, whether using TCP out to the nodes is a > cost-effective way to get the job done. If someone has 10k > water meters sending one short packet a day, they may not > want to invest in the infrastructure needed to keep 10k TCP > connections open. At some point in the process their data > will be available via TCP, but that doesn't require an > end-to-end TCP connnection down to each meter. The great > thing about IP is that you get enormous flexibility in how > to structure networks and applications. > > We cannot create a whole new protocol stack with a gateway > to convert between IP and our new stack. What we can do is > provide alternatives where appropriate and take advantage of > the layering to allow people to choose which protocols they > use and, most importantly, when and where they want to do > any conversions. > -Richard Kelsey > From zach@sensinode.com Wed Nov 4 01:03:45 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34CE63A68BA for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 01:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ttmj1wEp+XOS for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 01:03:44 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id C01023A67B2 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 01:03:43 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA493xgj020258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Nov 2009 11:04:00 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: Date: Wed, 4 Nov 2009 11:04:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <85BCBB91-0C20-4354-9EA1-4F055E4D186A@sensinode.com> References: To: nicolas.riou@fr.schneider-electric.com X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 09:03:45 -0000 Nicolas, On Nov 4, 2009, at 1:18 , nicolas.riou@fr.schneider-electric.com wrote: > > Hi Cullen, > > >----- Message de Cullen Jennings sur Sat, 31 =20= > Oct 2009 11:29:41 -0600 ----- > >Pour: arjun.lists@hsc.com > >cc: Don Sturek , 6lowapp@ietf.org > >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > > >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > > > > ... > >OK - The way I want to try and derive us towards a decision =20 > here is > >get a list of candidate protocols then for each one ask the yes/=20= > no is > >the their agreement that we should do a mapping to that =20 > protocol. The > >protocols I have heard so far are HTTP, SNMP, SMTP. So two =20 > questions > > > >1) what other protocols mapping should we do? > > The charter has significantly changed these days and I would like to =20= > re-state the need for > seamless interfacing between 6lowapp and the DPWS world. DPWS is a =20 > low cost SOA solution at > device level and will play a major role in future Building and =20 > Industrial Automation systems > (embedded in zone controllers, Automation servers, industrial =20 > PLCs...). Besides, in some > cases, native support of DPWS in VISTA and Windows 7 network =20 > explorer might help in simplifying > discovery and commissioning of devices. I totally agree that we should interface seamlessly with DPWS. Cullen =20= is in the process of re-writing the charter, this is the reason it got =20= left out temporarily (we had it in earlier). In fact the discovery =20 mechanism is meant to be compatible with DPWS thinking, or at least =20 useable with a subset of DPWS profiles if someone wants. > The HTTP REST model proposed in the new charter is sufficient for =20 > simple get/set operations but > I join Vlad Trifa when saying that there are requirements for more =20 > than just request/response > messaging patterns like e.g. publish/subscribe (multicast). IMO =20 > seamless interfacing with WS_* > (at least straightforward proxying) must be provided to ensure =20 > efficient integration of 6lowpan networks > in upcoming architectures. The charter is actually saying that REST alone is not sufficient. =20 Multicast is listed (or should be better listed). It will also be =20 possible to realize RPC over CoAP, and thus someone could even use =20 this for WS_* messaging if they wanted to. Just as it works with HTTP. =20= Do you have some specific text changes in mind to make that more =20 clear? Now it lists multicast, push, pull and notification. Thanks, Zach > > Regards. > Nicolas > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From trifa@inf.ethz.ch Wed Nov 4 01:18:58 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32ECE3A6A9B for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 01:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 oKn1-TuJxtJv for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 01:18:56 -0800 (PST) Received: from gwse.ethz.ch (gwse.ethz.ch [129.132.178.237]) by core3.amsl.com (Postfix) with ESMTP id 136423A699A for <6lowapp@ietf.org>; Wed, 4 Nov 2009 01:18:55 -0800 (PST) Received: from CAS01.d.ethz.ch (129.132.178.235) by gws00.d.ethz.ch (129.132.178.237) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 10:19:14 +0100 Received: from 80-254-68-122.dynamic.monzoon.net (129.132.208.114) by mail.ethz.ch (129.132.178.227) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 4 Nov 2009 10:18:52 +0100 Message-ID: From: Vlad Trifa To: Zach Shelby In-Reply-To: Content-Type: text/plain; charset="WINDOWS-1252"; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Nov 2009 10:18:51 +0100 References: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> <00b501ca5bc7$1ba2bcf0$52e836d0$@sturek@att.net> <01d701ca5c90$36ba5e70$a42f1b50$@sturek@att.net> X-Mailer: Apple Mail (2.936) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Discovery X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 09:18:58 -0000 Hello, just my thoughts about the discovery. Wouldn't it make sense to =20 somewhat decouple the physical (network-level) discovery (eg.ws-=20 discovery, bonjour) from the actual use of the device and the =20 semantics describing the device API in possible high-level format =20 (WADL, etc)? This allows to offer different more or less elaborate =20 description of how to use devices, and having a transparent discovery =20= mechanism (I doubt it's difficult to oblige manufacturers to implement =20= a single discovery standard). In particular, this would allow to find/=20= understand/use devices that do not have a network discovery mechanism, =20= for example by entering it's wadl url in an application manually. Another comment, I think that attaching semantics to urls (ie. hard-=20 wiring commands as tags in the URL, with /wadl as Zach proposed) is =20 not the best way to go, because it's a little against the REST design =20= principle (because this basically defines a protocol on top of REST =20 that all devices shall adopt - nothing wrong with that inherently and =20= it would work - but requires to push such a standard based on uri =20 schemas for all devices, which might be a bitter pill to swallow :) Vlad On Nov 3, 2009, at 10:33 PM, Zach Shelby wrote: > > On Nov 3, 2009, at 16:16 , Don Sturek wrote: > >> Hi Zach, >> >> I haven't yet seen a service discovery solution that is usable for =20= >> small >> footprint devices (SSDP, SLP, DPWS, etc.). All use text strings =20 >> (which will >> translated to multiple packets) or directory agents in the network =20= >> which are >> not popular in unmanaged networks > > Agreed. > > What I am saying is that a much simpler discovery mechanism is =20 > enough to fulfill the requirements I have seen. We don't need a full-=20= > blown discovery of anything using any protocol for any device now. =20 > We just need a built-in discovery mechanism for what interfaces are =20= > available for this protocol, and optionally extra meta-info about =20 > those interfaces or the device. > >> >> Do you have any other references? Is there something I missed with =20= >> one of >> these technologies? > > A few examples: > - DPWS has a model of using the application protocol (HTTP or SOAP-=20 > over-UDP) to offer device profiles. Discovery could be supported in =20= > a similar way, but much simpler in CoAP. > - Web interfaces can be described in many standard ways already, =20 > e.g. WADL or WSDL. And of course the URL itself already describes a =20= > lot. > - It is normal practice to make these web interface descriptions =20 > available on a well-known interface, so that they can be used. For =20 > example REST designers often make the WADL description available on /=20= > wadl. > - The SENSEI project has implemented a mechanism like this (draft-=20 > gold-6lowapp-sensei). > - Tons of other protocols have simple built-in interface discovery. > > We don't have to decide exactly how to do it now, but I don't see it =20= > being a hard problem. > >> >> I see service discovery as a hard requirement in unattended networks. > > I totally agree. > > But by just defining a couple REST interfaces and a generic, compact =20= > format for e.g. URL and interface desc info, you can build that into =20= > the protocol (as a well-known interface) just as is normal practice =20= > on the web. > > This is basically what the charter says right now, define a simple =20 > discovery mechanism using the CoAP protocol supporting profiles. We =20= > don' t have to decide exactly how to do it, but we should have the =20 > general goals in there (unattended, peer-to-peer, no DA required, =20 > profiles extensible). > > General service discovery could be future work for re-chartering? > > Zach > >> >> Don >> >> >> -----Original Message----- >> From: Zach Shelby [mailto:zach@sensinode.com] >> Sent: Monday, November 02, 2009 10:19 PM >> To: d.sturek@att.net >> Cc: 'Kerry Lynn'; 6lowapp@ietf.org >> Subject: Re: [6lowapp] Discovery >> >> Hi, >> >> (New thread title) >> >> With regards to service discovery and CoAP, the question is do we =20 >> need >> full-blown service discovery at all for such constrained networks and >> devices in this WG? >> >> Looking at the requirements and discussions so far, the conclusion we >> had is that the same CoAP protocol can easily be used for exchanging >> service information (profiles) in a distributed manner, but allowing >> for a DA-like entity to exist if needed. DPWS uses a similar =20 >> approach. >> >> The current proposed CoAP charter text takes this simple approach. >> Define a discovery interface and a simple profile format using the >> same protocol. For constrained nodes this makes sense, no requirement >> to implement a separate protocol. This is also extensible for vendors >> or other standards (e.g. DPWS, oBIX) to extend profiles. >> >> I am not saying that general service discovery mechanisms are not >> useful some day (SLP, mDNS, UPnP etc.). There could be a future spin- >> off or re-charter for this work. But looking at the current >> applications and requirements on the table - what the charter is >> suggesting is good enough and will demand the least effort. >> >> Thoughts? >> >> Zach >> >> On Nov 2, 2009, at 16:16 , Don Sturek wrote: >> >>> Hi Kerry, >>> >>> Here is the big problem we keep coming up against in service >>> discovery: >>> 1) Most agent based solutions are deeply unpopular by HAN device >>> manufacturers. >>> >>> Here is why: >>> 1) Many different vendors contribute to devices in the home area >>> network >>> (HAN) >>> 2) No vendor of device "X" wants to have to increase their storage >>> and >>> computing capacity to become the repository of service information >>> for all >>> other devices in the network. >>> 3) HANs are not managed networks where some owning entity would =20 >>> place >>> infrastructure devices >>> >>> Note what I wrote above is for the home area network (HAN). =20 >>> Building >>> automation is another story as there is certainly a building control >>> system >>> in place there. >>> >>> The simplest solution for this for the HAN: Allow individual >>> devices to >>> hold their own service information and provide a unicast/multicast >>> query >>> system to allow for self description of service information. Allow >>> for >>> individual devices on the HAN to form their own queries and get =20 >>> direct >>> responses back from devices matching those service requests. >>> >>> For the I-D I turned in for service discovery, I did use the SLP DA >>> (Directory Agent, I believe) to hold the strings (URI plus service) >>> and had >>> the DA responsible for substituting those for tokens upon request. >>> However, >>> I had in mind that would be all the DA would do and all service >>> discovery >>> was UA (User Agent) based. >>> >>> For a building controls solution (commercial or industrial), the DA >>> could be >>> fully populated an used on the building control system...... >>> >>> Don >>> >>> >>> -----Original Message----- >>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >>> Behalf >>> Of Kerry Lynn >>> Sent: Monday, November 02, 2009 5:32 AM >>> To: 6lowapp@ietf.org >>> Subject: [6lowapp] Newbie questions >>> >>> Greetings, >>> >>> My name is Kerry Lynn and I hope to contribute to this effort >>> remotely. I >>> am an independent contractor working in the area of building >>> automation >>> and have worked previously in Cisco and Apple network engineering in >>> addition to supporting university research into constrained >>> devices. I >>> hope you will bear with what may be foolish questions as I come up =20= >>> to >>> speed: >>> >>> I tried to access the audio stream and jabber feed from yesterday's >>> meeting but was unable to do so. Is IETF registration necessary? >>> >>> Is it the consensus of the group to support peer-to-peer as well as >>> server-based configurations? The first is what I'd term the "one >>> light, >>> one switch" scenario while the latter would include DHCP, DNS, etc. >>> and perhaps application proxy support. >>> >>> Has anyone considered something like T/TCP as a candidate for >>> transaction support? I know it has been traditionally implemented >>> as a superset of TCP but I suspect it could be much simpler than >>> full TCP if used in a controlled environment such as local >>> communication with a full TCP/HTTP/REST proxy. The security >>> concerns could be addressed simultaneously. >>> >>> Has anyone proposed mDNS/DNS-SD as an alternative to SLP? >>> Does anyone have a feeling for how one client implementation >>> compares to the other in terms if complexity? >>> >>> Thanks, -K- >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >> >> --=20 >> http://www.sensinode.com >> http://zachshelby.org - My blog "On the Internet of Things" >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may =20 >> contain >> legally privileged information. If you are not the intended =20 >> recipient, >> please contact the sender and delete the e-mail from your system >> without producing, distributing or retaining copies thereof. >> >> >> > > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may =20 > contain legally privileged information. If you are not the intended =20= > recipient, please contact the sender and delete the e-mail from your =20= > system without producing, distributing or retaining copies thereof. > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From zach@sensinode.com Wed Nov 4 01:33:13 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E85928C158 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 01:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gEAE4GoLOvFa for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 01:33:11 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id D52293A683B for <6lowapp@ietf.org>; Wed, 4 Nov 2009 01:33:10 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA49XQW1023873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Nov 2009 11:33:26 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: Date: Wed, 4 Nov 2009 11:33:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3fe58b590911020532w57049a23n6d64853ec8fbf891@mail.gmail.com> <00b501ca5bc7$1ba2bcf0$52e836d0$@sturek@att.net> <01d701ca5c90$36ba5e70$a42f1b50$@sturek@att.net> To: Vlad Trifa X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Discovery X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 09:33:13 -0000 Hi Vlad, On Nov 4, 2009, at 11:18 , Vlad Trifa wrote: > Hello, > > just my thoughts about the discovery. Wouldn't it make sense to =20 > somewhat decouple the physical (network-level) discovery (eg.ws-=20 > discovery, bonjour) from the actual use of the device and the =20 > semantics describing the device API in possible high-level format =20 > (WADL, etc)? This allows to offer different more or less elaborate =20 > description of how to use devices, and having a transparent =20 > discovery mechanism (I doubt it's difficult to oblige manufacturers =20= > to implement a single discovery standard). In particular, this would =20= > allow to find/understand/use devices that do not have a network =20 > discovery mechanism, for example by entering it's wadl url in an =20 > application manually. Yep, that is the idea here. > > Another comment, I think that attaching semantics to urls (ie. hard-=20= > wiring commands as tags in the URL, with /wadl as Zach proposed) is =20= > not the best way to go, because it's a little against the REST =20 > design principle (because this basically defines a protocol on top =20 > of REST that all devices shall adopt - nothing wrong with that =20 > inherently and it would work - but requires to push such a standard =20= > based on uri schemas for all devices, which might be a bitter pill =20 > to swallow :) Just an example of how some people do it. It doesn't matter when the =20 exact solution is yet. Now we just need the charter to give he =20 guidelines of what we are working on. I think we agree that we do not need general service discovery here =20 yet, just an interface discovery technique? Zach > > Vlad > > > On Nov 3, 2009, at 10:33 PM, Zach Shelby wrote: > >> >> On Nov 3, 2009, at 16:16 , Don Sturek wrote: >> >>> Hi Zach, >>> >>> I haven't yet seen a service discovery solution that is usable for =20= >>> small >>> footprint devices (SSDP, SLP, DPWS, etc.). All use text strings =20 >>> (which will >>> translated to multiple packets) or directory agents in the network =20= >>> which are >>> not popular in unmanaged networks >> >> Agreed. >> >> What I am saying is that a much simpler discovery mechanism is =20 >> enough to fulfill the requirements I have seen. We don't need a =20 >> full-blown discovery of anything using any protocol for any device =20= >> now. We just need a built-in discovery mechanism for what =20 >> interfaces are available for this protocol, and optionally extra =20 >> meta-info about those interfaces or the device. >> >>> >>> Do you have any other references? Is there something I missed =20 >>> with one of >>> these technologies? >> >> A few examples: >> - DPWS has a model of using the application protocol (HTTP or SOAP-=20= >> over-UDP) to offer device profiles. Discovery could be supported in =20= >> a similar way, but much simpler in CoAP. >> - Web interfaces can be described in many standard ways already, =20 >> e.g. WADL or WSDL. And of course the URL itself already describes a =20= >> lot. >> - It is normal practice to make these web interface descriptions =20 >> available on a well-known interface, so that they can be used. For =20= >> example REST designers often make the WADL description available =20 >> on /wadl. >> - The SENSEI project has implemented a mechanism like this (draft-=20 >> gold-6lowapp-sensei). >> - Tons of other protocols have simple built-in interface discovery. >> >> We don't have to decide exactly how to do it now, but I don't see =20 >> it being a hard problem. >> >>> >>> I see service discovery as a hard requirement in unattended =20 >>> networks. >> >> I totally agree. >> >> But by just defining a couple REST interfaces and a generic, =20 >> compact format for e.g. URL and interface desc info, you can build =20= >> that into the protocol (as a well-known interface) just as is =20 >> normal practice on the web. >> >> This is basically what the charter says right now, define a simple =20= >> discovery mechanism using the CoAP protocol supporting profiles. We =20= >> don' t have to decide exactly how to do it, but we should have the =20= >> general goals in there (unattended, peer-to-peer, no DA required, =20 >> profiles extensible). >> >> General service discovery could be future work for re-chartering? >> >> Zach >> >>> >>> Don >>> >>> >>> -----Original Message----- >>> From: Zach Shelby [mailto:zach@sensinode.com] >>> Sent: Monday, November 02, 2009 10:19 PM >>> To: d.sturek@att.net >>> Cc: 'Kerry Lynn'; 6lowapp@ietf.org >>> Subject: Re: [6lowapp] Discovery >>> >>> Hi, >>> >>> (New thread title) >>> >>> With regards to service discovery and CoAP, the question is do we =20= >>> need >>> full-blown service discovery at all for such constrained networks =20= >>> and >>> devices in this WG? >>> >>> Looking at the requirements and discussions so far, the conclusion =20= >>> we >>> had is that the same CoAP protocol can easily be used for exchanging >>> service information (profiles) in a distributed manner, but allowing >>> for a DA-like entity to exist if needed. DPWS uses a similar =20 >>> approach. >>> >>> The current proposed CoAP charter text takes this simple approach. >>> Define a discovery interface and a simple profile format using the >>> same protocol. For constrained nodes this makes sense, no =20 >>> requirement >>> to implement a separate protocol. This is also extensible for =20 >>> vendors >>> or other standards (e.g. DPWS, oBIX) to extend profiles. >>> >>> I am not saying that general service discovery mechanisms are not >>> useful some day (SLP, mDNS, UPnP etc.). There could be a future =20 >>> spin- >>> off or re-charter for this work. But looking at the current >>> applications and requirements on the table - what the charter is >>> suggesting is good enough and will demand the least effort. >>> >>> Thoughts? >>> >>> Zach >>> >>> On Nov 2, 2009, at 16:16 , Don Sturek wrote: >>> >>>> Hi Kerry, >>>> >>>> Here is the big problem we keep coming up against in service >>>> discovery: >>>> 1) Most agent based solutions are deeply unpopular by HAN device >>>> manufacturers. >>>> >>>> Here is why: >>>> 1) Many different vendors contribute to devices in the home area >>>> network >>>> (HAN) >>>> 2) No vendor of device "X" wants to have to increase their storage >>>> and >>>> computing capacity to become the repository of service information >>>> for all >>>> other devices in the network. >>>> 3) HANs are not managed networks where some owning entity would =20= >>>> place >>>> infrastructure devices >>>> >>>> Note what I wrote above is for the home area network (HAN). =20 >>>> Building >>>> automation is another story as there is certainly a building =20 >>>> control >>>> system >>>> in place there. >>>> >>>> The simplest solution for this for the HAN: Allow individual >>>> devices to >>>> hold their own service information and provide a unicast/multicast >>>> query >>>> system to allow for self description of service information. Allow >>>> for >>>> individual devices on the HAN to form their own queries and get =20 >>>> direct >>>> responses back from devices matching those service requests. >>>> >>>> For the I-D I turned in for service discovery, I did use the SLP DA >>>> (Directory Agent, I believe) to hold the strings (URI plus service) >>>> and had >>>> the DA responsible for substituting those for tokens upon request. >>>> However, >>>> I had in mind that would be all the DA would do and all service >>>> discovery >>>> was UA (User Agent) based. >>>> >>>> For a building controls solution (commercial or industrial), the DA >>>> could be >>>> fully populated an used on the building control system...... >>>> >>>> Don >>>> >>>> >>>> -----Original Message----- >>>> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >>>> Behalf >>>> Of Kerry Lynn >>>> Sent: Monday, November 02, 2009 5:32 AM >>>> To: 6lowapp@ietf.org >>>> Subject: [6lowapp] Newbie questions >>>> >>>> Greetings, >>>> >>>> My name is Kerry Lynn and I hope to contribute to this effort >>>> remotely. I >>>> am an independent contractor working in the area of building >>>> automation >>>> and have worked previously in Cisco and Apple network engineering =20= >>>> in >>>> addition to supporting university research into constrained >>>> devices. I >>>> hope you will bear with what may be foolish questions as I come =20 >>>> up to >>>> speed: >>>> >>>> I tried to access the audio stream and jabber feed from yesterday's >>>> meeting but was unable to do so. Is IETF registration necessary? >>>> >>>> Is it the consensus of the group to support peer-to-peer as well as >>>> server-based configurations? The first is what I'd term the "one >>>> light, >>>> one switch" scenario while the latter would include DHCP, DNS, etc. >>>> and perhaps application proxy support. >>>> >>>> Has anyone considered something like T/TCP as a candidate for >>>> transaction support? I know it has been traditionally implemented >>>> as a superset of TCP but I suspect it could be much simpler than >>>> full TCP if used in a controlled environment such as local >>>> communication with a full TCP/HTTP/REST proxy. The security >>>> concerns could be addressed simultaneously. >>>> >>>> Has anyone proposed mDNS/DNS-SD as an alternative to SLP? >>>> Does anyone have a feeling for how one client implementation >>>> compares to the other in terms if complexity? >>>> >>>> Thanks, -K- >>>> _______________________________________________ >>>> 6lowapp mailing list >>>> 6lowapp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowapp >>>> >>>> _______________________________________________ >>>> 6lowapp mailing list >>>> 6lowapp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >>> --=20 >>> http://www.sensinode.com >>> http://zachshelby.org - My blog "On the Internet of Things" >>> Mobile: +358 40 7796297 >>> >>> Zach Shelby >>> Head of Research >>> Sensinode Ltd. >>> Kidekuja 2 >>> 88610 Vuokatti, FINLAND >>> >>> This e-mail and all attached material are confidential and may =20 >>> contain >>> legally privileged information. If you are not the intended =20 >>> recipient, >>> please contact the sender and delete the e-mail from your system >>> without producing, distributing or retaining copies thereof. >>> >>> >>> >> >> --=20 >> http://www.sensinode.com >> http://zachshelby.org - My blog =93On the Internet of Things=94 >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may =20 >> contain legally privileged information. If you are not the intended =20= >> recipient, please contact the sender and delete the e-mail from =20 >> your system without producing, distributing or retaining copies =20 >> thereof. >> >> >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From pthubert@cisco.com Wed Nov 4 02:26:36 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27A63A683A for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 02:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.711 X-Spam-Level: X-Spam-Status: No, score=-9.711 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GLl39aW1Cwo5 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 02:26:36 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 910B03A698F for <6lowapp@ietf.org>; Wed, 4 Nov 2009 02:26:35 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMAAP/l8EqQ/uCWe2dsb2JhbACbVwEBFiQGqHSYP4Iugg8E X-IronPort-AV: E=Sophos;i="4.44,679,1249257600"; d="scan'208";a="53582855" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2009 10:26:56 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA4AQtbK014702; Wed, 4 Nov 2009 10:26:56 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 11:26:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 11:26:52 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8E04B3@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Where does TCP not work Thread-Index: AcpczkKZaIWnuXJOQda3xd2E2rnh3QAYmKbw References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com><005c01ca5a86$9a3f2ef0$cebd8cd0$@sturek@att.net><01d801ca5c90$ba1031f0$2e3095d0$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: "Lars Eggert" , X-OriginalArrivalTime: 04 Nov 2009 10:26:56.0108 (UTC) FILETIME=[556B12C0:01CA5D39] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 10:26:36 -0000 Great :) I'm certainly willing to help out here. =20 For the problem of routing in that environment (at ROLL) we produced no less than 4 requirements drafts, and that certainly helped a lot figuring what was left to be done. This is because wireless (even Low Power) is so diverse in its usages and constraints. Following those tracks we could: * go back to the requirements we have on transports for the flows we know of * see which ones can be accommodated with existing transports and flow control techniques - produce BCP there -=20 * and then see if additional work is needed to accommodate real world constraints like very femtomatic buffer capacity in the intermediate routers, and randomized path diversity. Maybe we could organize a BAR BOF in Anaheim? Pascal >-----Original Message----- >From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Lars Eggert >Sent: mardi 3 novembre 2009 22:39 >To: d.sturek@att.net >Cc: 6lowapp@ietf.org >Subject: Re: [6lowapp] Where does TCP not work > >Hi, > >On 2009-11-3, at 6:19, Don Sturek wrote: >> I think there is a Smart Grid bar BOF in Hiroshima. This is probably >> in response to the NIST Smart Grid roadmap and "Priority Action Plan" >> activity >> (IETF is involved in priority action plan #1, IP for Smart Grid). >> This >> might be the place to suggest work on this topic in the Transport >> area. > >that's a reasonable idea, but I think you've all been hanging around the IETF long enough to realize that any >such effort will need to be driven by folks who want a solution. In other words, saying that "the TSV area >should solve this" and then hoping that someone else will produce a solution isn't going to happen. We need >the folks who need a solution put their cycles into designing one (in TSV, if that's where it'll fit, or >wherever). > >Lars From pthubert@cisco.com Wed Nov 4 02:51:29 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDDA83A683A for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 02:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.73 X-Spam-Level: X-Spam-Status: No, score=-7.73 tagged_above=-999 required=5 tests=[AWL=-1.131, 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 jn+JpL+Dh06A for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 02:51:29 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EC1A63A66B4 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 02:51:28 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACfr8EqrR7Ht/2dsb2JhbADFEZg9hD0EgWWKAw X-IronPort-AV: E=Sophos;i="4.44,679,1249257600"; d="scan'208";a="424494414" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 04 Nov 2009 10:51:50 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA4ApAqs019114; Wed, 4 Nov 2009 10:51:50 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 11:51:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 11:51:20 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D8E04E6@XMB-AMS-107.cisco.com> In-Reply-To: <4AF11C63.7080807@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Where does TCP not work Thread-Index: AcpdFosm/ihWeR0CRHGdW+bGZGjuewAIs0zg References: <5A85AE5A-4C5D-4A0F-8CDF-BEB4C69FF002@cisco.com> <5572F86E-C14F-48E6-922D-EABBB957EE22@nokia.com> <4AEF832C.9050603@eecs.berkeley.edu> <3C5BAF7D-CD31-434B-9AE2-BB8ED6C4B0E0@nokia.com> <6A2A459175DABE4BB11DE2026AA50A5D8E01D2@XMB-AMS-107.cisco.com> <4AF11C63.7080807@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "Kris Pister" X-OriginalArrivalTime: 04 Nov 2009 10:51:25.0314 (UTC) FILETIME=[C1221E20:01CA5D3C] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Where does TCP not work X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 10:51:29 -0000 Hi Kris: The long and correct answer is in RFC 5681 section 3.2.=20 The short and partial one is that packets arriving out of order cause additional churn (acks). 3 duplicate acks (still waiting for a same delayed segment) will trigger a fast retransmission of that delayed segment and temporarily reduce the number of outstanding segments (congestion window). TCP can live with long latencies but what it will not like too much is if we spread packets over paths of different latencies for the reasons above. I'm not so anxious about the effect on the congestion window as I am about the energy and bandwidth cost from the additional acks and retries being generated for nothing. At the core, the problem goes beyond this. I think that our buffers cannot properly accommodate a window-based mechanism. The large TAT that we experience in those networks only makes things worse. All this calls for rate-based, something like a SARATOGA, with a Committed Information Rate mechanism that would use IP ECN bit the way FR uses FECNs and BECNs, and some reservation/CAC mechanism in the radio fringe to proactively obtain the required resources. Cheers, Pascal >-----Original Message----- >From: Kris Pister [mailto:pister@eecs.berkeley.edu] >Sent: mercredi 4 novembre 2009 07:17 >To: Pascal Thubert (pthubert) >Cc: Lars Eggert; 6lowapp@ietf.org >Subject: Re: [6lowapp] Where does TCP not work > >Pascal - I assume that we would only have path diversity inside the >WPAN, and that the purpose of diversity would be to reduce latency, >rather than increase it (e.g. RoLL, siblings when parents are having >problems, etc.). If you can't get the packet through to your preferred >parent in a timely way, you try someone else in the hopes that you can >still hit your latency target. Yes? > >Anyway, the goal of my original question was to understand what kinds of >latency distributions would work. I agree that it is easy to find >distributions that will bring TCP to it's knees. I'm hopeful that we >can find some ways to make our meshes TCP-friendly under those >circumstances when it is advantageous. Under other circumstances (e.g. >the ISA100 use cases that you presented) it's neither necessary nor >efficient. > >ksjp > >Pascal Thubert (pthubert) wrote: >> Hi Lars and Kris: >> >> >>>> In the early days of sensor networks it was not uncommon to see end- >>>> to-end best-effort loss rates of 10% or more. I don't think that >>>> anyone tolerates that kind of performance anymore. With link-layer >>>> ACKs and path diversity in the routing layer I think that 99.9% for >>>> best-effort is now table stakes. >>>> >>> All that certainly helps, but I haven't seen much discussion on whether >>> >> we all agree that we're only going to >> >>> target scenarios for 6LOWAPP for which we can make the assumption that >>> >> such techniques will be in use. >> >> And path diversity when applied to TCP flows can have very adverse >> effects, if the packets are actually balanced over paths of very >> different latencies. A packet that is not lost but delayed in an >> alternate path will trigger fast recovery and cause the congestion >> window to drop. >> >> Add a very long TTL to the mixture and you get a recipe for a very low >> throughput with packet duplication. >> >> MPTCP might offer some benefits if the subflows were routed on a given >> path each, but that's not what we are doing here so I'm not too hopeful >> though I'd like to dig more. >> >> >> Pascal >> From paduffy@cisco.com Wed Nov 4 04:50:07 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807BE3A68AF for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 04:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 YozotSIJQl19 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 04:50:06 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 92B2C3A67A7 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 04:50:06 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEcH8UqrR7Hu/2dsb2JhbADFKYEaCAGXF4Q9BIUI X-IronPort-AV: E=Sophos;i="4.44,680,1249257600"; d="scan'208";a="424565248" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 04 Nov 2009 12:50:27 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nA4CoS1x015001; Wed, 4 Nov 2009 12:50:28 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 07:50:27 -0500 Received: from [10.86.251.40] ([10.86.251.40]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 07:50:27 -0500 Message-ID: <4AF17892.8040108@cisco.com> Date: Wed, 04 Nov 2009 07:50:26 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: nicolas.riou@fr.schneider-electric.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2009 12:50:27.0534 (UTC) FILETIME=[623A66E0:01CA5D4D] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 12:50:07 -0000 I agree there is a need for more than request/response messaging, but WS_* gives me pause for constrained devices and links. It is probably the most compute intensive, bandwidth hungry way to interface HAN-like endpoints. > > Hi Cullen, > > >----- Message de Cullen Jennings sur Sat, 31 > Oct 2009 11:29:41 -0600 ----- > >Pour: arjun.lists@hsc.com > >cc: Don Sturek , 6lowapp@ietf.org > >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > > >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > > > > ... > >OK - The way I want to try and derive us towards a decision here > is > >get a list of candidate protocols then for each one ask the > yes/no is > >the their agreement that we should do a mapping to that protocol. > The > >protocols I have heard so far are HTTP, SNMP, SMTP. So two > questions > > > >1) what other protocols mapping should we do? > > The charter has significantly changed these days and I would like to > re-state the need for > seamless interfacing between 6lowapp and the DPWS world. DPWS is a low > cost SOA solution at > device level and will play a major role in future Building and > Industrial Automation systems > (embedded in zone controllers, Automation servers, industrial > PLCs...). Besides, in some > cases, native support of DPWS in VISTA and Windows 7 network explorer > might help in simplifying > discovery and commissioning of devices. > The HTTP REST model proposed in the new charter is sufficient for > simple get/set operations but > I join Vlad Trifa when saying that there are requirements for more > than just request/response > messaging patterns like e.g. publish/subscribe (multicast). IMO > seamless interfacing with WS_* > (at least straightforward proxying) must be provided to ensure > efficient integration of 6lowpan networks > in upcoming architectures. > > Regards. > Nicolas > ------------------------------------------------------------------------ > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From j.schoenwaelder@jacobs-university.de Wed Nov 4 06:35:46 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 994F33A6956 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 06:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 rLn3Lu9aOvPr for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 06:35:41 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B512E3A6852 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 06:35:40 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 04014C003F; Wed, 4 Nov 2009 15:36:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1a-HVJsBr9Fl; Wed, 4 Nov 2009 15:36:01 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E4901C0026; Wed, 4 Nov 2009 15:36:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 88E0BDA1A54; Wed, 4 Nov 2009 15:36:00 +0100 (CET) Date: Wed, 4 Nov 2009 15:36:00 +0100 From: Juergen Schoenwaelder To: Zach Shelby Message-ID: <20091104143600.GA8772@elstar.local> Mail-Followup-To: Zach Shelby , "6lowapp@ietf.org" <6lowapp@ietf.org> References: <85BCBB91-0C20-4354-9EA1-4F055E4D186A@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <85BCBB91-0C20-4354-9EA1-4F055E4D186A@sensinode.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 14:35:46 -0000 On Wed, Nov 04, 2009 at 10:04:01AM +0100, Zach Shelby wrote: > The charter is actually saying that REST alone is not sufficient. > Multicast is listed (or should be better listed). It will also be > possible to realize RPC over CoAP, and thus someone could even use > this for WS_* messaging if they wanted to. Just as it works with HTTP. > Do you have some specific text changes in mind to make that more > clear? Now it lists multicast, push, pull and notification. I have been following this discussion silently and it seems there are pretty diverging opinions of the applications targeted by CoAP. Some people apparently just want to read simple meters from lots of truely resource constrained (thus cheap) devices and do very limited control actions. Others seem to see a need for a rather complex^Hcomplete middleware instrastructure to be developed, including new transports to support it (and not much discussion of the necessary security infrastructure needed to support it has yet been seen here). Some poeple might believe there is a magic silver bullet to support all application scenarios equally well - I personally have some doubts about the existance of it or that it can be found quickly. This goes to the expectation that all the new protocols will be worked out and standardized fast enough to meet aggressive industry consortia deadlines of "tomorrow". In my experience, the IETF is working best by breaking things down in manageable pieces and assigning priorities to them. I believe this needs to be done sooner rather than later here as well. Building a long wishlist of things CoAP is expected to nicely interface with seems like moving into the wrong direction (except you take a rather liberal interpretation of "interfacing nicely" - the hard stuff is often in the detailed semantics and their mismatches). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From apezzuto@cisco.com Wed Nov 4 07:12:10 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C44D13A6890 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 07:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.932 X-Spam-Level: X-Spam-Status: No, score=-9.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 0-P-Fjov-hKv for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 07:12:09 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5B0DD3A67B1 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 07:12:09 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUAANAo8UqQ/uCWe2dsb2JhbACbXAEBFiQGqWeYGIQ9BIUI X-IronPort-AV: E=Sophos;i="4.44,680,1249257600"; d="scan'208";a="53618488" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2009 15:12:29 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA4FCTAR023843; Wed, 4 Nov 2009 15:12:29 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 16:12:29 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Nov 2009 16:12:30 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> In-reply-to: <4AF17892.8040108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Proposed charter for 6LoWAPP BOF Thread-Index: AcpdTWbftY5Y9eNvTua0/dcrKv87dwAB7NoQ References: <4AF17892.8040108@cisco.com> From: "Adriano Pezzuto (apezzuto)" To: "Paul Duffy (paduffy)" , X-OriginalArrivalTime: 04 Nov 2009 15:12:29.0570 (UTC) FILETIME=[39C1E620:01CA5D61] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 15:12:10 -0000 Hello, I don't get one point here. Help me to understand. Are we searching for a well known protocol to use as CoAP for 6lowPAN = and WSN networks or are we searching for a "model" to use for? I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the = plate. Each of these protocols have been developed for a specific = purpose keeping in mind specific constraints and requirements and each = of them is a valid choice for the respective domain. On the other side, = each of them have some drawbacks for 6lowPAN and WSN networks and I see = a lot of diverged opinions here. Why we fear for define a new application protocol especially designed = for 6lowPAN and WSN networks? I'm a newbie for 6lowPAN but my feeling is that a simple lightweight = protocol (I also prefer LoAP instead of CoAP) with a minimal set of = primitives (e.g. SET/SET-Reply, GET/GET-Reply and Event/Ack) is = sufficient to cover the most part of the use cases and interaction = models for 6lowPAN and WSN networks. Other items can be further added on = the plate like security, service discovery, nodes and network = management, and so on .. but all they can be solved with the same = minimal approach keeping in mind the real nature and the scope of = 6lowPAN networks. At the end of day, we are talking about CSMA/CA radio = networks with high lossy and few kilobytes of useful throughput. Also = the nodes spend most part of their time sleeping down to save power or = can be inactive for days (or months). I've some doubts that complex = protocols/frameworks (developed for other scopes than 6lowPAN) can run = efficiently on our small poor devices. But that's only the feeling of a = newbie .... Adriano -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Paul Duffy (paduffy) Sent: mercoled=EC 4 novembre 2009 13.50 To: nicolas.riou@fr.schneider-electric.com Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF I agree there is a need for more than request/response messaging, but=20 WS_* gives me pause for constrained devices and links. It is probably=20 the most compute intensive, bandwidth hungry way to interface HAN-like=20 endpoints. > > Hi Cullen, > > >----- Message de Cullen Jennings sur Sat, 31=20 > Oct 2009 11:29:41 -0600 ----- > >Pour: arjun.lists@hsc.com > >cc: Don Sturek , 6lowapp@ietf.org > >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > > >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > > > > ... > >OK - The way I want to try and derive us towards a decision here=20 > is =20 > >get a list of candidate protocols then for each one ask the=20 > yes/no is =20 > >the their agreement that we should do a mapping to that protocol. = > The =20 > >protocols I have heard so far are HTTP, SNMP, SMTP. So two=20 > questions > > > >1) what other protocols mapping should we do? > > The charter has significantly changed these days and I would like to=20 > re-state the need for > seamless interfacing between 6lowapp and the DPWS world. DPWS is a low = > cost SOA solution at > device level and will play a major role in future Building and=20 > Industrial Automation systems > (embedded in zone controllers, Automation servers, industrial=20 > PLCs...). Besides, in some > cases, native support of DPWS in VISTA and Windows 7 network explorer=20 > might help in simplifying > discovery and commissioning of devices. > The HTTP REST model proposed in the new charter is sufficient for=20 > simple get/set operations but > I join Vlad Trifa when saying that there are requirements for more=20 > than just request/response > messaging patterns like e.g. publish/subscribe (multicast). IMO=20 > seamless interfacing with WS_* > (at least straightforward proxying) must be provided to ensure=20 > efficient integration of 6lowpan networks > in upcoming architectures. > > Regards. > Nicolas > = ------------------------------------------------------------------------ > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > =20 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From fluffy@cisco.com Wed Nov 4 07:46:40 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7182A3A697C for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 07:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.381 X-Spam-Level: X-Spam-Status: No, score=-106.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KU5431QKTdU9 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 07:46:39 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C08033A67D4 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 07:46:39 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAP8w8UqrR7Hu/2dsb2JhbADGPZgYhD0E X-IronPort-AV: E=Sophos;i="4.44,680,1249257600"; d="scan'208";a="201111200" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 04 Nov 2009 15:47:01 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nA4Fl0eB010299 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 15:47:01 GMT Message-Id: <4EDB0058-5EBB-417E-88B5-43A750B97796@cisco.com> From: Cullen Jennings To: 6lowapp@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Nov 2009 08:47:00 -0700 X-Mailer: Apple Mail (2.936) Subject: [6lowapp] Updated Draft Agenda X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 15:46:40 -0000 Current Agenda: (Updated Nov 4) 5 min Agenda bashing Chairs 10 min Goal and purpose of the BOF Chairs 10 min Description of the problem/problem space Carsten Bormann draft-bormann-6lowpan-6lowapp-problem-01 20 min 6lowapp WG charter proposal: part 1 Zach Shelby Draft charter at http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp 10 min Building Objectives Peter Van Der Stok draft-gold-6lowapp-sensei-00 draft-martocci-6lowapp-building-applications-00 10 min Smart energy Objectives Don Sturek draft-sturek-6lowapp-smartenergy-00 10 min 6lowapp WG charter proposal: part 2 Zach Shelby 30 min Open Discussion All 10 min Calling the questions ADs Other drafts on interest: draft-frank-6lowapp-chopan-00 draft-manner-6lowapp-sdnd-00 draft-roychowdhury-6lowappsip-00 draft-ryanpitt-6lowapp-xpl-00 draft-schmitt-6lowapp-ipfix-ws-00 draft-shelby-6lowapp-encoding-00 draft-struik-6lowapp-security-considerations-00 draft-sturek-6lowapp-servicediscovery-00 draft-ietf-roll-home-routing-reqs-08 draft-ietf-roll-building-routing-reqs From jhui@archrock.com Wed Nov 4 07:54:13 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C91A63A67D9 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 07:54:13 -0800 (PST) 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=[AWL=0.000, 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 wK0-GDYPD01m for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 07:54:13 -0800 (PST) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id D5D863A67D4 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 07:54:12 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 7FBACAF92E; Wed, 4 Nov 2009 07:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U31oQdzSSRVm; Wed, 4 Nov 2009 07:54:29 -0800 (PST) Received: from [192.168.7.72] (69-12-164-134.sfo.archrock.com [69.12.164.134]) by mail.sf.archrock.com (Postfix) with ESMTP id 445CCAF92C; Wed, 4 Nov 2009 07:54:29 -0800 (PST) Message-Id: From: Jonathan Hui To: Juergen Schoenwaelder In-Reply-To: <20091104143600.GA8772@elstar.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 4 Nov 2009 07:54:27 -0800 References: <85BCBB91-0C20-4354-9EA1-4F055E4D186A@sensinode.com> <20091104143600.GA8772@elstar.local> X-Mailer: Apple Mail (2.936) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 15:54:13 -0000 On Nov 4, 2009, at 6:36 AM, Juergen Schoenwaelder wrote: > On Wed, Nov 04, 2009 at 10:04:01AM +0100, Zach Shelby wrote: > > I have been following this discussion silently and it seems there are > pretty diverging opinions of the applications targeted by CoAP. Some > people apparently just want to read simple meters from lots of truely > resource constrained (thus cheap) devices and do very limited control > actions. Others seem to see a need for a rather complex^Hcomplete > middleware instrastructure to be developed, including new transports > to support it (and not much discussion of the necessary security > infrastructure needed to support it has yet been seen here). Some > poeple might believe there is a magic silver bullet to support all > application scenarios equally well - I personally have some doubts > about the existance of it or that it can be found quickly. This goes > to the expectation that all the new protocols will be worked out and > standardized fast enough to meet aggressive industry consortia > deadlines of "tomorrow". > > In my experience, the IETF is working best by breaking things down in > manageable pieces and assigning priorities to them. I believe this > needs to be done sooner rather than later here as well. Building a > long wishlist of things CoAP is expected to nicely interface with > seems like moving into the wrong direction (except you take a rather > liberal interpretation of "interfacing nicely" - the hard stuff is > often in the detailed semantics and their mismatches). Exactly! I have been advocating this and I'm glad others are bumping into the same problem. If we want to make quick forward progress, we need to explicitly call out target applications (and probably use cases) in the charter. SE 2 and Building Management applications seems like a good starting list and I would be satisfied if we only focused on those two for the time being. -- Jonathan Hui From zach@sensinode.com Wed Nov 4 08:01:07 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882733A67E4 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 L3GRZaCK19jj for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:01:06 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 31E183A67D9 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 08:01:05 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA4G1Hxq010520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Nov 2009 18:01:17 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: Date: Wed, 4 Nov 2009 18:01:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <85BCBB91-0C20-4354-9EA1-4F055E4D186A@sensinode.com> <20091104143600.GA8772@elstar.local> To: Jonathan Hui X-Mailer: Apple Mail (2.1076) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:01:07 -0000 On Nov 4, 2009, at 17:54 , Jonathan Hui wrote: > On Nov 4, 2009, at 6:36 AM, Juergen Schoenwaelder wrote: >> >> >> In my experience, the IETF is working best by breaking things down in >> manageable pieces and assigning priorities to them. I believe this >> needs to be done sooner rather than later here as well. Building a >> long wishlist of things CoAP is expected to nicely interface with >> seems like moving into the wrong direction (except you take a rather >> liberal interpretation of "interfacing nicely" - the hard stuff is >> often in the detailed semantics and their mismatches). > > > Exactly! I have been advocating this and I'm glad others are =20 > bumping into the same problem. If we want to make quick forward =20 > progress, we need to explicitly call out target applications (and =20 > probably use cases) in the charter. > > SE 2 and Building Management applications seems like a good starting =20= > list and I would be satisfied if we only focused on those two for =20 > the time being. > +1! We do need to specify which protocol we need to assume we can proxy =20 with. I am satisfied with HTTP REST as the charter states now as a =20 starting place as it covers those applications well. Others can come =20 in the future as needed. We should though specifically list which =20 standards organizations we will work with, and OASIS (e.g. oBIX, DPWS) =20= is important there in addition to SE2 related organizations. Zach > -- > Jonathan Hui > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From paduffy@cisco.com Wed Nov 4 08:03:38 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304763A67E4 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LQPDwcTBtdL6 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:03:36 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B0DC93A69D7 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 08:03:36 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIk08UpAZnwN/2dsb2JhbADGK4EaCAGWdIQ9BA X-IronPort-AV: E=Sophos;i="4.44,680,1249257600"; d="scan'208";a="66353822" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Nov 2009 16:03:58 +0000 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.14.3) with ESMTP id nA4G3wup009029; Wed, 4 Nov 2009 16:03:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 11:03:57 -0500 Received: from [161.44.65.115] ([161.44.65.115]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 11:03:57 -0500 Message-ID: <4AF1A5ED.8070303@cisco.com> Date: Wed, 04 Nov 2009 11:03:57 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Hui References: <85BCBB91-0C20-4354-9EA1-4F055E4D186A@sensinode.com> <20091104143600.GA8772@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2009 16:03:57.0615 (UTC) FILETIME=[6A602BF0:01CA5D68] Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: paduffy@cisco.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:03:38 -0000 +1 on scoping for SE 2.x and Building Management > > > Exactly! I have been advocating this and I'm glad others are bumping > into the same problem. If we want to make quick forward progress, we > need to explicitly call out target applications (and probably use > cases) in the charter. > > SE 2 and Building Management applications seems like a good starting > list and I would be satisfied if we only focused on those two for the > time being. > > -- > Jonathan Hui > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From robert.cragie@gridmerge.com Wed Nov 4 08:35:21 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 947F43A67E7 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 xx9qDcb3Ansv for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:35:11 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 9E11B3A6927 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 08:35:10 -0800 (PST) Received: from client-82-3-91-195.manc.adsl.virginmedia.com ([82.3.91.195] helo=[192.168.1.65]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) id 1N5ipV-0001JK-DC; Wed, 04 Nov 2009 16:35:30 +0000 Message-ID: <4AF1AD4C.5080908@gridmerge.com> Date: Wed, 04 Nov 2009 16:35:24 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Adriano Pezzuto (apezzuto)" References: <4AF17892.8040108@cisco.com> <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020102040908070204080705" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:35:21 -0000 This is a cryptographically signed message in MIME format. --------------ms020102040908070204080705 Content-Type: multipart/alternative; boundary="------------050808010207040008000407" This is a multi-part message in MIME format. --------------050808010207040008000407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Not considering specific use cases, I see two general requirements=20 coming out here: 1. The requirement for a universal application protocol which can work across the wider internet all the way from head-end to edge devices 2. The requirement for an application protocol specific to low-power, resource constrained nodes (CoAP) (1) pushes from the wider Internet to the edge devices. (2) pushes from the edge devices to the wider Internet. The utopian aim would be to find the intersection of these requirements, = if it exists. Then the Internet of Things truly becomes feasible.=20 Considering (1) further: The most feasible solution to run over the=20 wider Internet and into the home is likely to be RESTful HTTP over TCP=20 as it is so universally used now and is likely to persist well into the=20 future. One important reason for this argument is that so much existing=20 infrastructure supports this. For example, many small office and home=20 systems use IPv4 and NAT gateways/routers. This is itself puts some=20 imposition on the ability for true end-to-end IP routing as it stands=20 due to the use of TCP/UDP ports. Indeed, the protocol stack 'waist' can=20 almost be considered to be HTTP (80/tcp) these days, not IP at layer 3. Considering (2) further: If we ignored the wider Internet as a whole,=20 there is no doubt that a simple, efficient, low bandwidth application=20 protocol would be developed which is oriented towards CNets. Indeed, one = could argue that ZigBee satisfies that requirement very well. This sort=20 of network is also already capable of being connected to the wider=20 Internet through an application level gateway providing translation and=20 also proxying and buffering for low bandwidth and sleepy devices. The=20 fundamental problem with this approach is that the bridging is not=20 occurring at the 'waist' but at the 'chest'. The maintenance of all the=20 translations for the numerous networks could become a burden. This is=20 also counter to routing IP at layer 3. Therefore I see three ways of proceeding: 1. Define an application protocol which uses RESTful HTTP over TCP extending to the edge devices and try to find a solution to the problems of TCP over lossy links 2. Define an application protocol based on a universal transaction and transport which is flexible enough for all media and takes into consideration the underlying properties of the medium through cross-layer controls. However the scope of this work is probably beyond CoAP and assumes that IPv6 would become pervasive enough not to cause problems with existing infrastructure 3. Define new application, transaction and transport protocols oriented towards CNets and define a proxy model for extension into the wider Internet Note these are not mutually exclusive. If (1) were done, (3) could still = be a solution for devices which do not meet the criteria to satisfy the=20 use of TCP. If (2) were done there would probably be no point in doing=20 (1) or (3). (3) could be done now but does not solve the requirement for = "end-to-end", although there are a number of possibilities there if you=20 split the application layer into the three layers defined in OSI, but=20 that's another debate. Regards, Robert Adriano Pezzuto (apezzuto) wrote: > Hello, > I don't get one point here. Help me to understand. > Are we searching for a well known protocol to use as CoAP for 6lowPAN a= nd WSN networks or are we searching for a "model" to use for? > > I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the pla= te. Each of these protocols have been developed for a specific purpose ke= eping in mind specific constraints and requirements and each of them is a= valid choice for the respective domain. On the other side, each of them = have some drawbacks for 6lowPAN and WSN networks and I see a lot of diver= ged opinions here. > > Why we fear for define a new application protocol especially designed f= or 6lowPAN and WSN networks? > > I'm a newbie for 6lowPAN but my feeling is that a simple lightweight pr= otocol (I also prefer LoAP instead of CoAP) with a minimal set of primiti= ves (e.g. SET/SET-Reply, GET/GET-Reply and Event/Ack) is sufficient to co= ver the most part of the use cases and interaction models for 6lowPAN and= WSN networks. Other items can be further added on the plate like securit= y, service discovery, nodes and network management, and so on .. but all = they can be solved with the same minimal approach keeping in mind the rea= l nature and the scope of 6lowPAN networks. At the end of day, we are tal= king about CSMA/CA radio networks with high lossy and few kilobytes of us= eful throughput. Also the nodes spend most part of their time sleeping do= wn to save power or can be inactive for days (or months). I've some doubt= s that complex protocols/frameworks (developed for other scopes than 6low= PAN) can run efficiently on our small poor devices. But that's only the f= eeling of a newbie .... > > Adriano > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Beh= alf Of Paul Duffy (paduffy) > Sent: mercoled=EC 4 novembre 2009 13.50 > To: nicolas.riou@fr.schneider-electric.com > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > I agree there is a need for more than request/response messaging, but=20 > WS_* gives me pause for constrained devices and links. It is probably = > the most compute intensive, bandwidth hungry way to interface HAN-like = > endpoints. > > > =20 >> Hi Cullen, >> >> >----- Message de Cullen Jennings sur Sat, 31=20 >> Oct 2009 11:29:41 -0600 ----- >> >Pour: arjun.lists@hsc.com >> >cc: Don Sturek , 6lowapp@ietf.org= >> >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF >> > >> >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: >> > >> > ... >> >OK - The way I want to try and derive us towards a decision here = >> is =20 >> >get a list of candidate protocols then for each one ask the=20 >> yes/no is =20 >> >the their agreement that we should do a mapping to that protocol.= =20 >> The =20 >> >protocols I have heard so far are HTTP, SNMP, SMTP. So two=20 >> questions >> > >> >1) what other protocols mapping should we do? >> >> The charter has significantly changed these days and I would like to=20 >> re-state the need for >> seamless interfacing between 6lowapp and the DPWS world. DPWS is a low= =20 >> cost SOA solution at >> device level and will play a major role in future Building and=20 >> Industrial Automation systems >> (embedded in zone controllers, Automation servers, industrial=20 >> PLCs...). Besides, in some >> cases, native support of DPWS in VISTA and Windows 7 network explorer = >> might help in simplifying >> discovery and commissioning of devices. >> The HTTP REST model proposed in the new charter is sufficient for=20 >> simple get/set operations but >> I join Vlad Trifa when saying that there are requirements for more=20 >> than just request/response >> messaging patterns like e.g. publish/subscribe (multicast). IMO=20 >> seamless interfacing with WS_* >> (at least straightforward proxying) must be provided to ensure=20 >> efficient integration of 6lowpan networks >> in upcoming architectures. >> >> Regards. >> Nicolas >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> =20 >> =20 > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > =20 --------------050808010207040008000407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Not considering specific use cases, I see two general requirements coming out here:
  1. The requirement for a universal application protocol  which can work across the wider internet all the way from head-end to edge devices
  2. The requirement for an application protocol specific to low-power, resource constrained nodes (CoAP)
(1) pushes from the wider Internet to the edge devices.
(2) pushes from the edge devices to the wider Internet.

The utopian aim would be to find the intersection of these requirements, if it exists. Then the Internet of Things truly becomes feasible. 

Considering (1) further: The most feasible solution to run over the wider Internet and into the home is likely to be RESTful HTTP over TCP as it is so universally used now and is likely to persist well into the future. One important reason for this argument is that so much existing infrastructure supports this. For example, many small office and home systems use IPv4 and NAT gateways/routers. This is itself puts some imposition on the ability for true end-to-end IP routing as it stands due to the use of TCP/UDP ports. Indeed, the protocol stack ‘waist’ can almost be considered to be HTTP (80/tcp) these days, not IP at layer 3.

Considering (2) further: If we ignored the wider Internet as a whole, there is no doubt that a simple, efficient, low bandwidth application protocol would be developed which is oriented towards CNets. Indeed, one could argue that ZigBee satisfies that requirement very well. This sort of network is also already capable of being connected to the wider Internet through an application level gateway providing translation and also proxying and buffering for low bandwidth and sleepy devices. The fundamental problem with this approach is that the bridging is not occurring at the ‘waist’ but at the ‘chest’. The maintenance of all the translations for the numerous networks could become a burden. This is also counter to routing IP at layer 3.

Therefore I see three ways of proceeding:
  1. Define an application protocol which uses RESTful HTTP over TCP extending to the edge devices and try to find a solution to the problems of TCP over lossy links
  2. Define an application protocol based on a universal transaction and transport which is flexible enough for all media and takes into consideration the underlying properties of the medium through cross-layer controls. However the scope of this work is probably beyond CoAP and assumes that IPv6 would become pervasive enough not to cause problems with existing infrastructure
  3. Define new application, transaction and transport protocols oriented towards CNets and define a proxy model for extension into the wider Internet
Note these are not mutually exclusive. If (1) were done, (3) could still be a solution for devices which do not meet the criteria to satisfy the use of TCP. If (2) were done there would probably be no point in doing (1) or (3). (3) could be done now but does not solve the requirement for "end-to-end", although there are a number of possibilities there if you split the application layer into the three layers defined in OSI, but that's another debate.

Regards,

Robert

Adriano Pezzuto (apezzuto) wrote: 
Hello,
I don't get one point here. Help me to understand.
Are we searching for a well known protocol to use as CoAP for 6lowPAN and WSN networks or are we searching for a "model" to use for?

I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the plate. Each of these protocols have been developed for a specific purpose keeping in mind specific constraints and requirements and each of them is a valid choice for the respective domain. On the other side, each of them have some drawbacks for 6lowPAN and WSN networks and I see a lot of diverged opinions here.

Why we fear for define a new application protocol especially designed for 6lowPAN and WSN networks?

I'm a newbie for 6lowPAN but my feeling is that a simple lightweight protocol (I also prefer LoAP instead of CoAP) with a minimal set of primitives (e.g. SET/SET-Reply, GET/GET-Reply and Event/Ack) is sufficient to cover the most part of the use cases and interaction models for 6lowPAN and WSN networks. Other items can be further added on the plate like security, service discovery, nodes and network management, and so on .. but all they can be solved with the same minimal approach keeping in mind the real nature and the scope of 6lowPAN networks. At the end of day, we are talking about CSMA/CA radio networks with high lossy and few kilobytes of useful throughput. Also the nodes spend most part of their time sleeping down to save power or can be inactive for days (or months). I've some doubts that complex protocols/frameworks (developed for other scopes than 6lowPAN) can run efficiently on our small poor devices. But that's only the feeling of a newbie ....

Adriano

-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy)
Sent: mercoledì 4 novembre 2009 13.50
To: nicolas.riou@fr.schneider-electric.com
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

I agree there is a need for more than request/response messaging, but 
WS_*  gives me pause for constrained devices and links. It is probably 
the most compute intensive, bandwidth hungry way to interface HAN-like 
endpoints.


  
Hi Cullen,

    >----- Message de Cullen Jennings <fluffy@cisco.com> sur Sat, 31 
Oct 2009 11:29:41 -0600 -----
    >Pour:        arjun.lists@hsc.com
    >cc:        Don Sturek <donsturek@grid2home.com>, 6lowapp@ietf.org
    >Objet:        Re: [6lowapp] Proposed charter for 6LoWAPP BOF
    >
    >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:
    >
    > ...
    >OK - The way I want to try and derive us towards a decision here 
is  
    >get a list of candidate protocols then for each one ask the 
yes/no is  
    >the their agreement that we should do a mapping to that protocol. 
 The  
    >protocols I have heard so far are HTTP, SNMP,  SMTP. So two 
questions
    >
    >1) what other protocols mapping should we do?

The charter has significantly changed these days and I would like to 
re-state the need for
seamless interfacing between 6lowapp and the DPWS world. DPWS is a low 
cost SOA solution at
device level and will play a major role in future Building and 
Industrial Automation systems
(embedded in zone controllers, Automation servers, industrial 
PLCs...). Besides, in some
cases, native support of DPWS in VISTA and Windows 7 network explorer 
might help in simplifying
discovery and commissioning of devices.
The HTTP REST model proposed in the new charter is sufficient for 
simple get/set operations but
I join Vlad Trifa when saying that there are requirements for more 
than just request/response
messaging patterns like e.g. publish/subscribe (multicast). IMO 
seamless interfacing with WS_*
(at least straightforward proxying) must be provided to ensure 
efficient integration of 6lowpan networks
in upcoming architectures.

Regards.
Nicolas
------------------------------------------------------------------------

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
  
    

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
--------------050808010207040008000407-- --------------ms020102040908070204080705 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEx MDQxNjM1MjRaMCMGCSqGSIb3DQEJBDEWBBQHyBnUMCVFEkBAXJqbkum865d+9zBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAFIuYsK5Q8qEefwOCSfqckufnyBp/9EocQpZgtmgbTjg+1s69bkuzerua9Si/t/LNF0U wEAz56YXmnB9ymoSQFf1u3nChPyjEP5hy4u0RuLD7X6qpyP6ECjxqTM4vu4dkmNowUsxRHjh 5TvPmRAXfDt1xBIrCzaF68x92B/8xRjbfssfMUvVOlbAsSzGN+wn/1wLd4x5vDWh8coVEnaK gtwnhXAJHCb8QkpxCteSkg9IA2llzYUWGTAuwFHIdbfLzGKVJYkIHSZYR2tCvSddc13OMmzp nD8PRYzvj1l7znfsc649OActCPd9jiH6fo5pxswCOMfmBwONEg0HDeSCapkAAAAAAAA= --------------ms020102040908070204080705-- From shidan@gmail.com Wed Nov 4 08:43:58 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FF728C0FE for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.240, 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 5I3WoQEducS0 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:43:56 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 23A4428C0E6 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 08:43:55 -0800 (PST) Received: by ewy3 with SMTP id 3so3286748ewy.37 for <6lowapp@ietf.org>; Wed, 04 Nov 2009 08:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=d4gineI8ip/rltLI4LE6lcAlxt14B1kOvDksq3RgG6I=; b=DSzZPPUHXHL3htynTd3R1xSAqwb4z4dx4hfzsQah1jKtLtXvO5NSTXKagH7GjASaWS Y9+FhDkzvzH7k9zUYOBy4sfwPFqbHb9dc/puUPy/jNzprCT8FqV2gJYUv1gEzBSOhBy4 An4OCOgMxwjw3C2TZnczqW4cryfuYQc9VviNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fDy4uWh3z/kG1U/KMogYUwDFfuqcYot2WP2FYpOH861PP6U2bjh9HL1k1jY9Yiq4YW gi31twk3SoA6t6BkbRbqEKul1gmQxt5t5dHaZ4a0R9uvx9akJDg2n7L4afvBb+eWLWNq HC09fhBOabrXGg0jv+Oar3as3k0JjSO4MvjAc= MIME-Version: 1.0 Received: by 10.216.88.79 with SMTP id z57mr659301wee.22.1257353052056; Wed, 04 Nov 2009 08:44:12 -0800 (PST) In-Reply-To: <4AF1A5ED.8070303@cisco.com> References: <85BCBB91-0C20-4354-9EA1-4F055E4D186A@sensinode.com> <20091104143600.GA8772@elstar.local> <4AF1A5ED.8070303@cisco.com> Date: Wed, 4 Nov 2009 11:44:11 -0500 Message-ID: <429b380e0911040844v1daeeb42na058489abefd473c@mail.gmail.com> From: Shidan To: paduffy@cisco.com Content-Type: multipart/alternative; boundary=0016e6d77d0306823804778e52fc Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:43:58 -0000 --0016e6d77d0306823804778e52fc Content-Type: text/plain; charset=ISO-8859-1 +1 on scoping for Building Management and utilityAMI's requirements and use cases. On Wed, Nov 4, 2009 at 11:03 AM, Paul Duffy wrote: > +1 on scoping for SE 2.x and Building Management > > > >> >> Exactly! I have been advocating this and I'm glad others are bumping into >> the same problem. If we want to make quick forward progress, we need to >> explicitly call out target applications (and probably use cases) in the >> charter. >> >> SE 2 and Building Management applications seems like a good starting list >> and I would be satisfied if we only focused on those two for the time being. >> >> -- >> Jonathan Hui >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --0016e6d77d0306823804778e52fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 on scoping for Building Management and utilityAMI's requirements and= use cases.

On Wed, Nov 4, 2009 at 11:03 = AM, Paul Duffy <paduffy@cisco.com> wrote:
+1 on scoping for SE 2.x and Building Manage= ment




Exactly! =A0I have been advocating this and I'm glad others are bumping= into the same problem. =A0If we want to make quick forward progress, we ne= ed to explicitly call out target applications (and probably use cases) in t= he charter.

SE 2 and Building Management applications seems like a good starting list a= nd I would be satisfied if we only focused on those two for the time being.=

--
Jonathan Hui

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

--0016e6d77d0306823804778e52fc-- From apezzuto@cisco.com Wed Nov 4 08:59:17 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEFC3A69C2 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.027 X-Spam-Level: X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 gZIGTbMe9qWw for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 08:59:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BE9C23A65A6 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 08:59:04 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcAAIBB8UqQ/uCWe2dsb2JhbACCJC6ZCwEBFiQGqguYGYQ9BIFlgyM X-IronPort-AV: E=Sophos;i="4.44,681,1249257600"; d="scan'208,217";a="53631929" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 04 Nov 2009 16:59:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA4GxPeG000446; Wed, 4 Nov 2009 16:59:25 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Nov 2009 17:59:24 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5D70.2956B06C" Date: Wed, 4 Nov 2009 17:59:28 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC9D1688@XMB-AMS-106.cisco.com> In-reply-to: <4AF1AD4C.5080908@gridmerge.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Proposed charter for 6LoWAPP BOF Thread-Index: AcpdbPNYISPwps79TJGyLLMUTXdMVQAAnlFg References: <4AF17892.8040108@cisco.com> <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> <4AF1AD4C.5080908@gridmerge.com> From: "Adriano Pezzuto (apezzuto)" To: X-OriginalArrivalTime: 04 Nov 2009 16:59:24.0783 (UTC) FILETIME=[2985B7F0:01CA5D70] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 16:59:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5D70.2956B06C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Robert, It sounds interesting. What you means exactly by saying "split the = application layer into the three layers defined in OSI" ? =20 Regards, Adriano =20 From: Robert Cragie [mailto:robert.cragie@gridmerge.com]=20 Sent: mercoled=EC 4 novembre 2009 17.35 To: Adriano Pezzuto (apezzuto) Cc: Paul Duffy (paduffy); zach@sensinode.com; 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF =20 Not considering specific use cases, I see two general requirements = coming out here: 1. The requirement for a universal application protocol which can work = across the wider internet all the way from head-end to edge devices 2. The requirement for an application protocol specific to low-power, = resource constrained nodes (CoAP) (1) pushes from the wider Internet to the edge devices. (2) pushes from the edge devices to the wider Internet. The utopian aim would be to find the intersection of these requirements, = if it exists. Then the Internet of Things truly becomes feasible. =20 Considering (1) further: The most feasible solution to run over the = wider Internet and into the home is likely to be RESTful HTTP over TCP = as it is so universally used now and is likely to persist well into the = future. One important reason for this argument is that so much existing = infrastructure supports this. For example, many small office and home = systems use IPv4 and NAT gateways/routers. This is itself puts some = imposition on the ability for true end-to-end IP routing as it stands = due to the use of TCP/UDP ports. Indeed, the protocol stack 'waist' can = almost be considered to be HTTP (80/tcp) these days, not IP at layer 3. Considering (2) further: If we ignored the wider Internet as a whole, = there is no doubt that a simple, efficient, low bandwidth application = protocol would be developed which is oriented towards CNets. Indeed, one = could argue that ZigBee satisfies that requirement very well. This sort = of network is also already capable of being connected to the wider = Internet through an application level gateway providing translation and = also proxying and buffering for low bandwidth and sleepy devices. The = fundamental problem with this approach is that the bridging is not = occurring at the 'waist' but at the 'chest'. The maintenance of all the = translations for the numerous networks could become a burden. This is = also counter to routing IP at layer 3. Therefore I see three ways of proceeding: 1. Define an application protocol which uses RESTful HTTP over TCP = extending to the edge devices and try to find a solution to the problems = of TCP over lossy links 2. Define an application protocol based on a universal transaction and = transport which is flexible enough for all media and takes into = consideration the underlying properties of the medium through = cross-layer controls. However the scope of this work is probably beyond = CoAP and assumes that IPv6 would become pervasive enough not to cause = problems with existing infrastructure 3. Define new application, transaction and transport protocols oriented = towards CNets and define a proxy model for extension into the wider = Internet Note these are not mutually exclusive. If (1) were done, (3) could still = be a solution for devices which do not meet the criteria to satisfy the = use of TCP. If (2) were done there would probably be no point in doing = (1) or (3). (3) could be done now but does not solve the requirement for = "end-to-end", although there are a number of possibilities there if you = split the application layer into the three layers defined in OSI, but = that's another debate. Regards, Robert Adriano Pezzuto (apezzuto) wrote:=20 Hello, I don't get one point here. Help me to understand. Are we searching for a well known protocol to use as CoAP for 6lowPAN = and WSN networks or are we searching for a "model" to use for? =20 I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the = plate. Each of these protocols have been developed for a specific = purpose keeping in mind specific constraints and requirements and each = of them is a valid choice for the respective domain. On the other side, = each of them have some drawbacks for 6lowPAN and WSN networks and I see = a lot of diverged opinions here. =20 Why we fear for define a new application protocol especially designed = for 6lowPAN and WSN networks? =20 I'm a newbie for 6lowPAN but my feeling is that a simple lightweight = protocol (I also prefer LoAP instead of CoAP) with a minimal set of = primitives (e.g. SET/SET-Reply, GET/GET-Reply and Event/Ack) is = sufficient to cover the most part of the use cases and interaction = models for 6lowPAN and WSN networks. Other items can be further added on = the plate like security, service discovery, nodes and network = management, and so on .. but all they can be solved with the same = minimal approach keeping in mind the real nature and the scope of = 6lowPAN networks. At the end of day, we are talking about CSMA/CA radio = networks with high lossy and few kilobytes of useful throughput. Also = the nodes spend most part of their time sleeping down to save power or = can be inactive for days (or months). I've some doubts that complex = protocols/frameworks (developed for other scopes than 6lowPAN) can run = efficiently on our small poor devices. But that's only the feeling of a = newbie .... =20 Adriano =20 -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On = Behalf Of Paul Duffy (paduffy) Sent: mercoled=EC 4 novembre 2009 13.50 To: nicolas.riou@fr.schneider-electric.com Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF =20 I agree there is a need for more than request/response messaging, but=20 WS_* gives me pause for constrained devices and links. It is probably=20 the most compute intensive, bandwidth hungry way to interface HAN-like=20 endpoints. =20 =20 =20 Hi Cullen, =20 >----- Message de Cullen Jennings = sur Sat, 31=20 Oct 2009 11:29:41 -0600 ----- >Pour: arjun.lists@hsc.com >cc: Don Sturek = , 6lowapp@ietf.org >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > > ... >OK - The way I want to try and derive us towards a decision here=20 is =20 >get a list of candidate protocols then for each one ask the=20 yes/no is =20 >the their agreement that we should do a mapping to that protocol.=20 The =20 >protocols I have heard so far are HTTP, SNMP, SMTP. So two=20 questions > >1) what other protocols mapping should we do? =20 The charter has significantly changed these days and I would like to=20 re-state the need for seamless interfacing between 6lowapp and the DPWS world. DPWS is a low=20 cost SOA solution at device level and will play a major role in future Building and=20 Industrial Automation systems (embedded in zone controllers, Automation servers, industrial=20 PLCs...). Besides, in some cases, native support of DPWS in VISTA and Windows 7 network explorer=20 might help in simplifying discovery and commissioning of devices. The HTTP REST model proposed in the new charter is sufficient for=20 simple get/set operations but I join Vlad Trifa when saying that there are requirements for more=20 than just request/response messaging patterns like e.g. publish/subscribe (multicast). IMO=20 seamless interfacing with WS_* (at least straightforward proxying) must be provided to ensure=20 efficient integration of 6lowpan networks in upcoming architectures. =20 Regards. Nicolas = ------------------------------------------------------------------------ =20 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp =20 =20 =20 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp =20 =20 ------_=_NextPart_001_01CA5D70.2956B06C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Robert,

It sounds interesting. What you means exactly by saying = “split the application layer into the three layers defined in OSI” = ?

 

Regards,

Adriano

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: mercoled=EC 4 novembre 2009 17.35
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); zach@sensinode.com; = 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP = BOF

 

Not considering specific use cases, I see two general requirements coming = out here:

  1. The requirement for a universal application protocol  which can = work across the wider internet all the way from head-end to edge = devices
  2. The requirement for an application protocol specific to low-power, = resource constrained nodes (CoAP)

(1) pushes from the wider Internet to the edge devices.
(2) pushes from the edge devices to the wider Internet.

The utopian aim would be to find the intersection of these requirements, = if it exists. Then the Internet of Things truly becomes feasible. 

Considering (1) further: The most feasible solution to run over the = wider Internet and into the home is likely to be RESTful HTTP over TCP as it = is so universally used now and is likely to persist well into the future. One important reason for this argument is that so much existing = infrastructure supports this. For example, many small office and home systems use IPv4 = and NAT gateways/routers. This is itself puts some imposition on the ability for = true end-to-end IP routing as it stands due to the use of TCP/UDP ports. = Indeed, the protocol stack ‘waist’ can almost be considered to be HTTP = (80/tcp) these days, not IP at layer 3.

Considering (2) further: If we ignored the wider Internet as a whole, = there is no doubt that a simple, efficient, low bandwidth application protocol = would be developed which is oriented towards CNets. Indeed, one could argue that = ZigBee satisfies that requirement very well. This sort of network is also = already capable of being connected to the wider Internet through an application = level gateway providing translation and also proxying and buffering for low = bandwidth and sleepy devices. The fundamental problem with this approach is that = the bridging is not occurring at the ‘waist’ but at the ‘chest’. The maintenance of all the translations for the = numerous networks could become a burden. This is also counter to routing IP at = layer 3.

Therefore I see three ways of proceeding:

  1. Define an application protocol which uses RESTful HTTP over TCP extending = to the edge devices and try to find a solution to the problems of TCP over = lossy links
  2. Define an application protocol based on a universal transaction and = transport which is flexible enough for all media and takes into consideration = the underlying properties of the medium through cross-layer controls. = However the scope of this work is probably beyond CoAP and assumes that = IPv6 would become pervasive enough not to cause problems with existing = infrastructure
  3. Define new application, transaction and transport protocols oriented = towards CNets and define a proxy model for extension into the wider = Internet

Note these are not mutually exclusive. If (1) were done, (3) could still be a = solution for devices which do not meet the criteria to satisfy the use of TCP. If (2) = were done there would probably be no point in doing (1) or (3). (3) could be = done now but does not solve the requirement for "end-to-end", = although there are a number of possibilities there if you split the application = layer into the three layers defined in OSI, but that's another debate.

Regards,

Robert

Adriano Pezzuto (apezzuto) wrote: 

Hello,
I don't get one point here. Help me to =
understand.
Are we searching for a well known =
protocol to use as CoAP for 6lowPAN and WSN networks or are we searching =
for a "model" to use =
for?
 
I'm seeing here a =
lot of proposal like HTTP, SNMP, SIP, XMPP on the plate. Each of these =
protocols have been developed for a specific purpose keeping in mind =
specific constraints and requirements and each of them is a valid choice =
for the respective domain. On the other side, each of them have some =
drawbacks for 6lowPAN and WSN networks and I see a lot of diverged =
opinions here.
 
Why we =
fear for define a new application protocol especially designed for =
6lowPAN and WSN =
networks?
 
I'm a newbie =
for 6lowPAN but my feeling is that a simple lightweight protocol (I also =
prefer LoAP instead of CoAP) with a minimal set of primitives (e.g. =
SET/SET-Reply, GET/GET-Reply and Event/Ack) is sufficient to cover the =
most part of the use cases and interaction models for 6lowPAN and WSN =
networks. Other items can be further added on the plate like security, =
service discovery, nodes and network management, and so on .. but all =
they can be solved with the same minimal approach keeping in mind the =
real nature and the scope of 6lowPAN networks. At the end of day, we are =
talking about CSMA/CA radio networks with high lossy and few kilobytes =
of useful throughput. Also the nodes spend most part of their time =
sleeping down to save power or can be inactive for days (or months). =
I've some doubts that complex protocols/frameworks (developed for other =
scopes than 6lowPAN) can run efficiently on our small poor devices. But =
that's only the feeling of a newbie =
....
 
Adriano<=
/pre>
 
-----Original =
Message-----
From: 6lowapp-bounces@ietf.org =
[mailto:6lowapp-bounces@ietf.org<=
/a>] On Behalf Of Paul Duffy (paduffy)
Sent: =
mercoled=EC 4 novembre 2009 13.50
To: nicolas.riou@fr.sc=
hneider-electric.com
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP =
BOF
 
I agree there is a =
need for more than request/response messaging, but =

WS_*=A0 gives me pause for constrained devices and =
links. It is probably 
the most compute intensive, =
bandwidth hungry way to interface HAN-like =

endpoints.
 
 
=A0 



Hi =
Cullen,
 
=A0=A0=A0 =
>----- Message de Cullen Jennings <fluffy@cisco.com> sur Sat, =
31 
Oct 2009 11:29:41 -0600 =
-----
=A0=A0=A0 >Pour:=A0=A0=A0=A0=A0=A0=A0 arjun.lists@hsc.com
=A0=A0=A0 >cc:=A0=A0=A0=A0=A0=A0=A0 Don Sturek <donsturek@grid2home.com>, 6lowapp@ietf.org
=A0=A0=A0 >Objet:=A0=A0=A0=A0=A0=A0=A0 Re: [6lowapp] Proposed =
charter for 6LoWAPP BOF
=A0=A0=A0 =
>
=A0=A0=A0 >On Oct 29, 2009, at 12:11 , =
Arjun Roychowdhury wrote:
=A0=A0=A0 =
>
=A0=A0=A0 > =
...
=A0=A0=A0 >OK - The way I want to try and =
derive us towards a decision here 
is=A0 =

=A0=A0=A0=A0>get a list of candidate protocols =
then for each one ask the 
yes/no is=A0 =

=A0=A0=A0=A0>the their agreement that we should =
do a mapping to that protocol. 
=A0The=A0 =

=A0=A0=A0=A0>protocols I have heard so far are =
HTTP, SNMP,=A0 SMTP. So two =

questions
=A0=A0=A0 =
>
=A0=A0=A0 >1) what other protocols mapping =
should we do?
 
The =
charter has significantly changed these days and I would like to =

re-state the need =
for
seamless interfacing between 6lowapp and the =
DPWS world. DPWS is a low 
cost SOA solution =
at
device level and will play a major role in =
future Building and 
Industrial Automation =
systems
(embedded in zone controllers, Automation =
servers, industrial 
PLCs...). Besides, in =
some
cases, native support of DPWS in VISTA and =
Windows 7 network explorer 
might help in =
simplifying
discovery and commissioning of =
devices.
The HTTP REST model proposed in the new =
charter is sufficient for 
simple get/set =
operations but
I join Vlad Trifa when saying that =
there are requirements for more 
than just =
request/response
messaging patterns like e.g. =
publish/subscribe (multicast). IMO 
seamless =
interfacing with WS_*
(at least straightforward =
proxying) must be provided to ensure 
efficient =
integration of 6lowpan networks
in upcoming =
architectures.
 
Regards.<=
o:p>
Nicolas
-----------------------=
-------------------------------------------------
 
_______________________________________________=

6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowapp
=A0 =

=A0=A0=A0=A0
 
________________________________________=
_______
6lowapp mailing =
list
6lowapp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowapp
____________________=
___________________________
6lowapp mailing =
list
6lowapp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowapp
 
=A0
------_=_NextPart_001_01CA5D70.2956B06C-- From shidan@gmail.com Wed Nov 4 09:20:54 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0407C28C112 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 09:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.213, 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 X27TBbn291p2 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 09:20:53 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 546CF28C0FF for <6lowapp@ietf.org>; Wed, 4 Nov 2009 09:20:52 -0800 (PST) Received: by ewy3 with SMTP id 3so3325794ewy.37 for <6lowapp@ietf.org>; Wed, 04 Nov 2009 09:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vUriwYbfs9il+djGkTit+QLSRdzX1VK3XtUX5q2fEf8=; b=LsOQlwm/X1wkDR0IFO0A8Iez+DC0Yv30QRcZ1uO9whrjgmmAvnPBG5tPzlE51+YCOS UnCV1WZjhSxZX8cY9MfHZ0Y8ZF2WxhC8qMnXltgpYdbaez5fPGVN0Iur2rgZQj4I9LWR 9Ul2Zg66qD0nb5mvYh4/5dKt8+sjn/FhxIJJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TqmiJQ8KpRu1KVKRWRaXG8br8zJ131GLCMxqmfsXFPYPWoAzn2NtrrnadN6+iFdYqL YuG4RYCqikWWhFdMG8MeDVANteGGYsDxoOhwOxk9U6io9ZcvStOmmVHwhCE6NKppUOmq Y0lHaiDqrRebevFPasENRdDmrYS4Y8yzR5/3c= MIME-Version: 1.0 Received: by 10.216.90.77 with SMTP id d55mr600746wef.146.1257355270019; Wed, 04 Nov 2009 09:21:10 -0800 (PST) In-Reply-To: <4AF1AD4C.5080908@gridmerge.com> References: <4AF17892.8040108@cisco.com> <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> <4AF1AD4C.5080908@gridmerge.com> Date: Wed, 4 Nov 2009 12:21:09 -0500 Message-ID: <429b380e0911040921r4d139947r687a3c77a568169e@mail.gmail.com> From: Shidan To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=0016e6d7ea6839e49f04778ed6cc Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 17:20:54 -0000 --0016e6d7ea6839e49f04778ed6cc Content-Type: text/plain; charset=ISO-8859-1 I couldn't agree more with your points which I highlighted below. We can't look at this in a vacuum of just HANs but rather, it has to be a holistic view. In this case since time is of the essence, looking specifically at energy management use cases is fine. I think Don went down this path in the thread for message filtering and collectors and I think it would be good if we saw more of how CoAp would relate to the rest of the networks and the ideal qualities we want in it considering this holistic view, and then see how much of that is possible. --- Shidan On Wed, Nov 4, 2009 at 11:35 AM, Robert Cragie wrote: > Not considering specific use cases, I see two general requirements coming > out here: > > 1. The requirement for a universal application protocol which can work > across the wider internet all the way from head-end to edge devices > 2. The requirement for an application protocol specific to low-power, > resource constrained nodes (CoAP) > > (1) pushes from the wider Internet to the edge devices. > (2) pushes from the edge devices to the wider Internet. > > The utopian aim would be to find the intersection of these requirements, if > it exists. Then the Internet of Things truly becomes feasible. > > --0016e6d7ea6839e49f04778ed6cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I couldn't agree more with your points which I highlighted below. We ca= n't look at this in a=A0vacuum of just HANs=A0but rather, it has to be = a holistic view.=A0

In this case since time is of the es= sence, looking specifically at energy management use cases is fine.=A0I thi= nk Don went down this path in the thread for message filtering and collecto= rs and I think it would be good if we saw more of how CoAp would relate to = the rest of the networks and the ideal=A0qualities=A0we want in it consider= ing this holistic view, and then see how much of that is possible.

---
Shidan

On Wed, Nov 4, 2009 at 11:35 AM, Robert Cragie <robert.cragie@gridmerg= e.com> wrote:
=20
Not considering specific use cases, I see two general requirements coming out here:
  1. The requirement for a universal application protocol=A0 which can work across the wider internet all the way from head-end to edge devices
  2. The requirement for an application protocol specific to low-power, resource constrained nodes (CoAP)
(1) pushes from the wider Internet to the edge devices.
(2) pushes from the edge devices to the wider Internet.

The utopian aim would be to find the intersection of these requirements, if it exists. Then the Internet of Things truly becomes feasible.=A0

--0016e6d7ea6839e49f04778ed6cc-- From robert.cragie@gridmerge.com Wed Nov 4 10:07:56 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8498F3A6922 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 10:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 Y4wQCFDLWPhZ for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 10:07:47 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 6EE7B3A691D for <6lowapp@ietf.org>; Wed, 4 Nov 2009 10:07:46 -0800 (PST) Received: from client-82-3-91-195.manc.adsl.virginmedia.com ([82.3.91.195] helo=[192.168.1.65]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) id 1N5kH7-0000HQ-87; Wed, 04 Nov 2009 18:08:06 +0000 Message-ID: <4AF1C2FF.8070502@gridmerge.com> Date: Wed, 04 Nov 2009 18:07:59 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Adriano Pezzuto (apezzuto)" References: <4AF17892.8040108@cisco.com> <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> <4AF1AD4C.5080908@gridmerge.com> <0D212BD466921646B58854FB79092CEC9D1688@XMB-AMS-106.cisco.com> In-Reply-To: <0D212BD466921646B58854FB79092CEC9D1688@XMB-AMS-106.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040108050808060007080309" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 18:07:56 -0000 This is a cryptographically signed message in MIME format. --------------ms040108050808060007080309 Content-Type: multipart/alternative; boundary="------------030109030001080009070700" This is a multi-part message in MIME format. --------------030109030001080009070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable In a nutshell: It is possible to consider presentation layer and session = layer translation as opposed to just 'application layer' translation.=20 Presentation layer translation could mean a common application protocol=20 (e.g. IEC 61968 CIM) with various presentation layers (e.g. MIME types - = text/xml, binary/exi etc.) and translations (or transformations) between = them. Similarly, session layer translation could have common application = and presentation layers but different session connections between=20 endpoints and transformation between session transactions. This could=20 facilitate proxying/buffering for low bandwidth/availability devices. Robert Adriano Pezzuto (apezzuto) wrote: > > Thanks Robert, > > It sounds interesting. What you means exactly by saying "split the=20 > application layer into the three layers defined in OSI" ? > > =20 > > Regards, > > Adriano > > =20 > > *From:* Robert Cragie [mailto:robert.cragie@gridmerge.com] > *Sent:* mercoled=EC 4 novembre 2009 17.35 > *To:* Adriano Pezzuto (apezzuto) > *Cc:* Paul Duffy (paduffy); zach@sensinode.com; 6lowapp@ietf.org > *Subject:* Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > =20 > > Not considering specific use cases, I see two general requirements=20 > coming out here: > > 1. The requirement for a universal application protocol which can > work across the wider internet all the way from head-end to edge > devices > 2. The requirement for an application protocol specific to > low-power, resource constrained nodes (CoAP) > > (1) pushes from the wider Internet to the edge devices. > (2) pushes from the edge devices to the wider Internet. > > The utopian aim would be to find the intersection of these=20 > requirements, if it exists. Then the Internet of Things truly becomes=20 > feasible.=20 > > Considering (1) further: The most feasible solution to run over the=20 > wider Internet and into the home is likely to be RESTful HTTP over TCP = > as it is so universally used now and is likely to persist well into=20 > the future. One important reason for this argument is that so much=20 > existing infrastructure supports this. For example, many small office=20 > and home systems use IPv4 and NAT gateways/routers. This is itself=20 > puts some imposition on the ability for true end-to-end IP routing as=20 > it stands due to the use of TCP/UDP ports. Indeed, the protocol stack=20 > 'waist' can almost be considered to be HTTP (80/tcp) these days, not=20 > IP at layer 3. > > Considering (2) further: If we ignored the wider Internet as a whole,=20 > there is no doubt that a simple, efficient, low bandwidth application=20 > protocol would be developed which is oriented towards CNets. Indeed,=20 > one could argue that ZigBee satisfies that requirement very well. This = > sort of network is also already capable of being connected to the=20 > wider Internet through an application level gateway providing=20 > translation and also proxying and buffering for low bandwidth and=20 > sleepy devices. The fundamental problem with this approach is that the = > bridging is not occurring at the 'waist' but at the 'chest'. The=20 > maintenance of all the translations for the numerous networks could=20 > become a burden. This is also counter to routing IP at layer 3. > > Therefore I see three ways of proceeding: > > 1. Define an application protocol which uses RESTful HTTP over TCP > extending to the edge devices and try to find a solution to the > problems of TCP over lossy links > 2. Define an application protocol based on a universal transaction > and transport which is flexible enough for all media and takes > into consideration the underlying properties of the medium > through cross-layer controls. However the scope of this work is > probably beyond CoAP and assumes that IPv6 would become > pervasive enough not to cause problems with existing infrastructu= re > 3. Define new application, transaction and transport protocols > oriented towards CNets and define a proxy model for extension > into the wider Internet > > Note these are not mutually exclusive. If (1) were done, (3) could=20 > still be a solution for devices which do not meet the criteria to=20 > satisfy the use of TCP. If (2) were done there would probably be no=20 > point in doing (1) or (3). (3) could be done now but does not solve=20 > the requirement for "end-to-end", although there are a number of=20 > possibilities there if you split the application layer into the three=20 > layers defined in OSI, but that's another debate. > > Regards, > > Robert > > Adriano Pezzuto (apezzuto) wrote: > > Hello, > I don't get one point here. Help me to understand. > Are we searching for a well known protocol to use as CoAP for 6lowPAN a= nd WSN networks or are we searching for a "model" to use for? > =20 > I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the pla= te. Each of these protocols have been developed for a specific purpose ke= eping in mind specific constraints and requirements and each of them is a= valid choice for the respective domain. On the other side, each of them = have some drawbacks for 6lowPAN and WSN networks and I see a lot of diver= ged opinions here. > =20 > Why we fear for define a new application protocol especially designed f= or 6lowPAN and WSN networks? > =20 > I'm a newbie for 6lowPAN but my feeling is that a simple lightweight pr= otocol (I also prefer LoAP instead of CoAP) with a minimal set of primiti= ves (e.g. SET/SET-Reply, GET/GET-Reply and Event/Ack) is sufficient to co= ver the most part of the use cases and interaction models for 6lowPAN and= WSN networks. Other items can be further added on the plate like securit= y, service discovery, nodes and network management, and so on .. but all = they can be solved with the same minimal approach keeping in mind the rea= l nature and the scope of 6lowPAN networks. At the end of day, we are tal= king about CSMA/CA radio networks with high lossy and few kilobytes of us= eful throughput. Also the nodes spend most part of their time sleeping do= wn to save power or can be inactive for days (or months). I've some doubt= s that complex protocols/frameworks (developed for other scopes than 6low= PAN) can run efficiently on our small poor devices. But that's only the f= eeling of a newbie .... > =20 > Adriano > =20 > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailt= o:6lowapp-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy) > Sent: mercoled=EC 4 novembre 2009 13.50 > To: nicolas.riou@fr.schneider-electric.com > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > =20 > I agree there is a need for more than request/response messaging, but=20 > WS_* gives me pause for constrained devices and links. It is probably = > the most compute intensive, bandwidth hungry way to interface HAN-like = > endpoints. > =20 > =20 > =20 > > Hi Cullen, > > =20 > > >----- Message de Cullen Jennings sur Sat, 31=20 > > Oct 2009 11:29:41 -0600 ----- > > >Pour: arjun.lists@hsc.com > > >cc: Don Sturek , 6lowapp@ietf.org > > >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF > > > > > >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: > > > > > > ... > > >OK - The way I want to try and derive us towards a decision he= re=20 > > is =20 > > >get a list of candidate protocols then for each one ask the=20 > > yes/no is =20 > > >the their agreement that we should do a mapping to that protoc= ol.=20 > > The =20 > > >protocols I have heard so far are HTTP, SNMP, SMTP. So two=20 > > questions > > > > > >1) what other protocols mapping should we do? > > =20 > > The charter has significantly changed these days and I would like t= o=20 > > re-state the need for > > seamless interfacing between 6lowapp and the DPWS world. DPWS is a = low=20 > > cost SOA solution at > > device level and will play a major role in future Building and=20 > > Industrial Automation systems > > (embedded in zone controllers, Automation servers, industrial=20 > > PLCs...). Besides, in some > > cases, native support of DPWS in VISTA and Windows 7 network explor= er=20 > > might help in simplifying > > discovery and commissioning of devices. > > The HTTP REST model proposed in the new charter is sufficient for=20 > > simple get/set operations but > > I join Vlad Trifa when saying that there are requirements for more = > > than just request/response > > messaging patterns like e.g. publish/subscribe (multicast). IMO=20 > > seamless interfacing with WS_* > > (at least straightforward proxying) must be provided to ensure=20 > > efficient integration of 6lowpan networks > > in upcoming architectures. > > =20 > > Regards. > > Nicolas > > -------------------------------------------------------------------= ----- > > =20 > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > =20 > > =20 > > =20 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > =20 > =20 --------------030109030001080009070700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In a nutshell: It is possible to consider presentation layer and session layer translation as opposed to just 'application layer' translation. Presentation layer translation could mean a common application protocol (e.g. IEC 61968 CIM) with various presentation layers (e.g. MIME types - text/xml, binary/exi etc.) and translations (or transformations) between them. Similarly, session layer translation could have common application and presentation layers but different session connections between endpoints and transformation between session transactions. This could facilitate proxying/buffering for low bandwidth/availability devices.

Robert

Adriano Pezzuto (apezzuto) wrote:

Thanks Robert,

It sounds interesting. What you means exactly by saying “split the application layer into the three layers defined in OSI” ?

 

Regards,

Adriano

 

From: Robert Cragie [mailto:robert.cragie@gridmerge.com]
Sent: mercoledì 4 novembre 2009 17.35
To: Adriano Pezzuto (apezzuto)
Cc: Paul Duffy (paduffy); zach@sensinode.com; 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

 

Not considering specific use cases, I see two general requirements coming out here:

  1. The requirement for a universal application protocol  which can work across the wider internet all the way from head-end to edge devices
  2. The requirement for an application protocol specific to low-power, resource constrained nodes (CoAP)

(1) pushes from the wider Internet to the edge devices.
(2) pushes from the edge devices to the wider Internet.

The utopian aim would be to find the intersection of these requirements, if it exists. Then the Internet of Things truly becomes feasible. 

Considering (1) further: The most feasible solution to run over the wider Internet and into the home is likely to be RESTful HTTP over TCP as it is so universally used now and is likely to persist well into the future. One important reason for this argument is that so much existing infrastructure supports this. For example, many small office and home systems use IPv4 and NAT gateways/routers. This is itself puts some imposition on the ability for true end-to-end IP routing as it stands due to the use of TCP/UDP ports. Indeed, the protocol stack ‘waist’ can almost be considered to be HTTP (80/tcp) these days, not IP at layer 3.

Considering (2) further: If we ignored the wider Internet as a whole, there is no doubt that a simple, efficient, low bandwidth application protocol would be developed which is oriented towards CNets. Indeed, one could argue that ZigBee satisfies that requirement very well. This sort of network is also already capable of being connected to the wider Internet through an application level gateway providing translation and also proxying and buffering for low bandwidth and sleepy devices. The fundamental problem with this approach is that the bridging is not occurring at the ‘waist’ but at the ‘chest’. The maintenance of all the translations for the numerous networks could become a burden. This is also counter to routing IP at layer 3.

Therefore I see three ways of proceeding:

  1. Define an application protocol which uses RESTful HTTP over TCP extending to the edge devices and try to find a solution to the problems of TCP over lossy links
  2. Define an application protocol based on a universal transaction and transport which is flexible enough for all media and takes into consideration the underlying properties of the medium through cross-layer controls. However the scope of this work is probably beyond CoAP and assumes that IPv6 would become pervasive enough not to cause problems with existing infrastructure
  3. Define new application, transaction and transport protocols oriented towards CNets and define a proxy model for extension into the wider Internet

Note these are not mutually exclusive. If (1) were done, (3) could still be a solution for devices which do not meet the criteria to satisfy the use of TCP. If (2) were done there would probably be no point in doing (1) or (3). (3) could be done now but does not solve the requirement for "end-to-end", although there are a number of possibilities there if you split the application layer into the three layers defined in OSI, but that's another debate.

Regards,

Robert

Adriano Pezzuto (apezzuto) wrote: 

Hello,
I don't get one point here. Help me to understand.
Are we searching for a well known protocol to use as CoAP for 6lowPAN and WSN networks or are we searching for a "model" to use for?
 
I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the plate. Each of these protocols have been developed for a specific purpose keeping in mind specific constraints and requirements and each of them is a valid choice for the respective domain. On the other side, each of them have some drawbacks for 6lowPAN and WSN networks and I see a lot of diverged opinions here.
 
Why we fear for define a new application protocol especially designed for 6lowPAN and WSN networks?
 
I'm a newbie for 6lowPAN but my feeling is that a simple lightweight protocol (I also prefer LoAP instead of CoAP) with a minimal set of primitives (e.g. SET/SET-Reply, GET/GET-Reply and Event/Ack) is sufficient to cover the most part of the use cases and interaction models for 6lowPAN and WSN networks. Other items can be further added on the plate like security, service discovery, nodes and network management, and so on .. but all they can be solved with the same minimal approach keeping in mind the real nature and the scope of 6lowPAN networks. At the end of day, we are talking about CSMA/CA radio networks with high lossy and few kilobytes of useful throughput. Also the nodes spend most part of their time sleeping down to save power or can be inactive for days (or months). I've some doubts that complex protocols/frameworks (developed for other scopes than 6lowPAN) can run efficiently on our small poor devices. But that's only the feeling of a newbie ....<
/pre>
  
 

  
Adriano

  
 

  
-----Original Message-----

  
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy)

  
Sent: mercoledì 4 novembre 2009 13.50

  
To: nicolas.riou@fr.schneider-electric.com

  
Cc: 6lowapp@ietf.org

  
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

  
 

  
I agree there is a need for more than request/response messaging, but 

  
WS_*  gives me pause for constrained devices and links. It is probably 

  
the most compute intensive, bandwidth hungry way to interface HAN-like 

  
endpoints.

  
 

  
 

  
  

  

    
Hi Cullen,

    
 

    
    >----- Message de Cullen Jennings <fluffy@cisco.com> sur Sat, 31 

    
Oct 2009 11:29:41 -0600 -----

    
    >Pour:        arjun.lists@hsc.com

    
    >cc:        Don Sturek <donsturek@grid2home.com>, 6lowapp@ietf.org

    
    >Objet:        Re: [6lowapp] Proposed charter for 6LoWAPP BOF

    
    >

    
    >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:

    
    >

    
    > ...

    
    >OK - The way I want to try and derive us towards a decision here 

    
is  

    
    >get a list of candidate protocols then for each one ask the 

    
yes/no is  

    
    >the their agreement that we should do a mapping to that protocol. 

    
 The  

    
    >protocols I have heard so far are HTTP, SNMP,  SMTP. So two 

    
questions

    
    >

    
    >1) what other protocols mapping should we do?

    
 

    
The charter has significantly changed these days and I would like to 

    
re-state the need for

    
seamless interfacing between 6lowapp and the DPWS world. DPWS is a low 

    
cost SOA solution at

    
device level and will play a major role in future Building and 

    
Industrial Automation systems

    
(embedded in zone controllers, Automation servers, industrial 

    
PLCs...). Besides, in some

    
cases, native support of DPWS in VISTA and Windows 7 network explorer 

    
might help in simplifying

    
discovery and commissioning of devices.

    
The HTTP REST model proposed in the new charter is sufficient for 

    
simple get/set operations but

    
I join Vlad Trifa when saying that there are requirements for more 

    
than just request/response

    
messaging patterns like e.g. publish/subscribe (multicast). IMO 

    
seamless interfacing with WS_*

    
(at least straightforward proxying) must be provided to ensure 

    
efficient integration of 6lowpan networks

    
in upcoming architectures.

    
 

    
Regards.

    
Nicolas

    
------------------------------------------------------------------------

    
 

    
_______________________________________________

    
6lowapp mailing list

    
6lowapp@ietf.org

    
https://www.ietf.org/mailman/listinfo/6lowapp

    
  

    
    

  

  
 

  
_______________________________________________

  
6lowapp mailing list

  
6lowapp@ietf.org

  
https://www.ietf.org/mailman/listinfo/6lowapp

  
_______________________________________________

  
6lowapp mailing list

  
6lowapp@ietf.org

  
https://www.ietf.org/mailman/listinfo/6lowapp

  
 

  
 
--------------030109030001080009070700-- --------------ms040108050808060007080309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEx MDQxODA3NTlaMCMGCSqGSIb3DQEJBDEWBBTJaRHpvTmM+KJWv+5B9T1crhxIuzBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAIh0AZ7ljsuVWZOwOeIQfadQcfRrP9a5NWFMdhz/skZmvzW5B4NIA5g0OsF3sftMWMEb tB91REd9GGK5EDXU4qagVlHDF8VMrRhpi9/IXcQivf67iPj5MsmoEiltxiAjPMU+Vw2wwOMj VgcnGxR6ld5knM922J/niWlqrQq2JmwQPdNpSgwXtpctyA/J4IQBVRpHqia2HM1fbeawfkYJ lVJKGADIrDbBDQgR86wFqvGqzYWuVogDKq1n6l3oj6LIlTQYbYIuIujY81qu3PF7QmY1o73/ nzCzo9pHYosLqQ1e6ydtx5dWOS7KKiNU0KPpv4900TtYejPRjTGwiSEWcL8AAAAAAAA= --------------ms040108050808060007080309-- From zach@sensinode.com Wed Nov 4 13:52:10 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616803A6836 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 13:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Xi66OSqcIhsV for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 13:52:09 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2D9263A681B for <6lowapp@ietf.org>; Wed, 4 Nov 2009 13:52:07 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA4LqJNn019479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Nov 2009 23:52:19 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <4AF1AD4C.5080908@gridmerge.com> Date: Wed, 4 Nov 2009 23:52:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4AF17892.8040108@cisco.com> <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> <4AF1AD4C.5080908@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 21:52:10 -0000 Robert, Very good points below, thanks for the mail! On Nov 4, 2009, at 18:35 , Robert Cragie wrote: > (1) pushes from the wider Internet to the edge devices. > (2) pushes from the edge devices to the wider Internet. Yep, this is the tussle at play here. We are not considering all edge =20= devices here, only the most constrained devices and networks. > Therefore I see three ways of proceeding: > =95 Define an application protocol which uses RESTful HTTP over = TCP =20 > extending to the edge devices and try to find a solution to the =20 > problems of TCP over lossy links So HTTP already is that protocol, and it is the current SOTA for =20 embedded devices and networks where it gets the job done. We already =20 determined that new transport work is a longer-term issue for the TSV =20= area. The whole point of this interest group (and WG effort) is that =20 there is a large set of devices, networks and applications where this =20= is not sufficient. So I would say that 1 is definitely done. > =95 Define an application protocol based on a universal = transaction =20 > and transport which is flexible enough for all media and takes into =20= > consideration the underlying properties of the medium through cross-=20= > layer controls. However the scope of this work is probably beyond =20 > CoAP and assumes that IPv6 would become pervasive enough not to =20 > cause problems with existing infrastructure This is out of scope of the APP area, and probably breaks lots of IETF =20= architectural concepts as well. So 2 is out. > =95 Define new application, transaction and transport protocols =20= > oriented towards CNets and define a proxy model for extension into =20 > the wider Internet This WG is not going to define new transport protocols (nor can it). =20 There is good consensus to use UDP by default and allow for the use of =20= TCP (or other suitable transports). > Note these are not mutually exclusive. If (1) were done, (3) could =20 > still be a solution for devices which do not meet the criteria to =20 > satisfy the use of TCP. TCP is only one issue, it is useful in some cases. HTTP and current =20 security models assumed by the web infrastructure are not suitable for =20= all constrained IP devices and networks. > If (2) were done there would probably be no point in doing (1) or =20 > (3). (3) could be done now but does not solve the requirement for =20 > "end-to-end", although there are a number of possibilities there if =20= > you split the application layer into the three layers defined in =20 > OSI, but that's another debate. I think you hit on the whole point here. 1 is done, 2 is not possible, =20= and what this WG needs to do is 3, making that as integrated into the =20= web architecture as we can. If we do our job well, I don't see =20 proxying between two protocols that share the same semantics (URLs, =20 REST etc.) and leave the payload alone to be a problem. Now. Considering that, do you have comments on the charter text? We =20 are working on a new version right now. Zach > > Regards, > > Robert > > Adriano Pezzuto (apezzuto) wrote: >> Hello, >> I don't get one point here. Help me to understand. >> Are we searching for a well known protocol to use as CoAP for =20 >> 6lowPAN and WSN networks or are we searching for a "model" to use =20 >> for? >> >> I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the =20= >> plate. Each of these protocols have been developed for a specific =20 >> purpose keeping in mind specific constraints and requirements and =20 >> each of them is a valid choice for the respective domain. On the =20 >> other side, each of them have some drawbacks for 6lowPAN and WSN =20 >> networks and I see a lot of diverged opinions here. >> >> Why we fear for define a new application protocol especially =20 >> designed for 6lowPAN and WSN networks? >> >> I'm a newbie for 6lowPAN but my feeling is that a simple =20 >> lightweight protocol (I also prefer LoAP instead of CoAP) with a =20 >> minimal set of primitives (e.g. SET/SET-Reply, GET/GET-Reply and =20 >> Event/Ack) is sufficient to cover the most part of the use cases =20 >> and interaction models for 6lowPAN and WSN networks. Other items =20 >> can be further added on the plate like security, service discovery, =20= >> nodes and network management, and so on .. but all they can be =20 >> solved with the same minimal approach keeping in mind the real =20 >> nature and the scope of 6lowPAN networks. At the end of day, we are =20= >> talking about CSMA/CA radio networks with high lossy and few =20 >> kilobytes of useful throughput. Also the nodes spend most part of =20 >> their time sleeping down to save power or can be inactive for days =20= >> (or months). I've some doubts that complex protocols/frameworks =20 >> (developed for other scopes than 6lowPAN) can run efficiently on =20 >> our small poor devices. But that's only the feeling of a newbie .... >> >> Adriano >> >> -----Original Message----- >> From: >> 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org >> ] On Behalf Of Paul Duffy (paduffy) >> Sent: mercoled=EC 4 novembre 2009 13.50 >> To: >> nicolas.riou@fr.schneider-electric.com >> >> Cc: >> 6lowapp@ietf.org >> >> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF >> >> I agree there is a need for more than request/response messaging, but >> WS_* gives me pause for constrained devices and links. It is =20 >> probably >> the most compute intensive, bandwidth hungry way to interface HAN-=20 >> like >> endpoints. >> >> >> >> >>> Hi Cullen, >>> >>> >----- Message de Cullen Jennings >>> >>> sur Sat, 31 >>> Oct 2009 11:29:41 -0600 ----- >>> >Pour: >>> arjun.lists@hsc.com >>> >>> >cc: Don Sturek >>> , 6lowapp@ietf.org >>> >>> >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF >>> > >>> >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: >>> > >>> > ... >>> >OK - The way I want to try and derive us towards a decision =20 >>> here >>> is >>> >get a list of candidate protocols then for each one ask the >>> yes/no is >>> >the their agreement that we should do a mapping to that =20 >>> protocol. >>> The >>> >protocols I have heard so far are HTTP, SNMP, SMTP. So two >>> questions >>> > >>> >1) what other protocols mapping should we do? >>> >>> The charter has significantly changed these days and I would like to >>> re-state the need for >>> seamless interfacing between 6lowapp and the DPWS world. DPWS is a =20= >>> low >>> cost SOA solution at >>> device level and will play a major role in future Building and >>> Industrial Automation systems >>> (embedded in zone controllers, Automation servers, industrial >>> PLCs...). Besides, in some >>> cases, native support of DPWS in VISTA and Windows 7 network =20 >>> explorer >>> might help in simplifying >>> discovery and commissioning of devices. >>> The HTTP REST model proposed in the new charter is sufficient for >>> simple get/set operations but >>> I join Vlad Trifa when saying that there are requirements for more >>> than just request/response >>> messaging patterns like e.g. publish/subscribe (multicast). IMO >>> seamless interfacing with WS_* >>> (at least straightforward proxying) must be provided to ensure >>> efficient integration of 6lowpan networks >>> in upcoming architectures. >>> >>> Regards. >>> Nicolas >>> = ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >>> >>> >>> >> >> _______________________________________________ >> 6lowapp mailing list >> >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> _______________________________________________ >> 6lowapp mailing list >> >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> >> >> --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From hgs@cs.columbia.edu Wed Nov 4 14:00:05 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F693A686C for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 14:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 O+jg1vC5x0WI for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 14:00:03 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 44EF23A67D3 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 14:00:03 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA4M0FYG014926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Nov 2009 17:00:15 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-14--108059138 From: Henning Schulzrinne In-Reply-To: <4AF1AD4C.5080908@gridmerge.com> Date: Wed, 4 Nov 2009 17:00:14 -0500 Message-Id: <6BB19374-5B51-447C-9CFF-DEACCE595312@cs.columbia.edu> References: <4AF17892.8040108@cisco.com> <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> <4AF1AD4C.5080908@gridmerge.com> To: robert.cragie@gridmerge.com X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 22:00:05 -0000 --Apple-Mail-14--108059138 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes I'm joining this discussion late, so I may be rehashing earlier =20 discussions, but I admit to some confusion. We seem to be conflating a =20= number of different constraints: - low bandwidth - low computational capabilities (CPU, memory) - lossy links Some systems suffer from all three, but others don't. For example, =20 while an IP-enabled lightswitch may have a puny CPU, it has plenty of =20= power and ZigBee is not exactly a low-bandwidth network and can easily =20= handle an occasional HTTP or SIP message exchanged among appliances. On the other hand, there's now a lot of interest in sensors that do =20 more than gather a few 8-bit measurements every day, e.g., video and =20 audio analysis. For those applications, HTTP isn't exactly the best fit. Many home networks will incorporate devices from lightswitches and =20 temperature sensors to appliances, home entertainment systems and =20 electric vehicles. For a light-switch, carrying one bit in a 100-byte =20= message isn't really necessary (X10 is far more efficient), but a GET/=20= SET protocol with one value isn't sufficient to control more =20 complicated appliances. Also, with distributed control, an event bus model seems most natural, =20= as there will be many listeners for sensors and possibly distributed =20 actuators for the same logical function. Again, not exactly a great =20 fit for HTTP if operating in a peer-to-peer mode. Henning On Nov 4, 2009, at 11:35 AM, Robert Cragie wrote: > Not considering specific use cases, I see two general requirements =20 > coming out here: > The requirement for a universal application protocol which can work =20= > across the wider internet all the way from head-end to edge devices > The requirement for an application protocol specific to low-power, =20 > resource constrained nodes (CoAP) > (1) pushes from the wider Internet to the edge devices. > (2) pushes from the edge devices to the wider Internet. > > The utopian aim would be to find the intersection of these =20 > requirements, if it exists. Then the Internet of Things truly =20 > becomes feasible. > > Considering (1) further: The most feasible solution to run over the =20= > wider Internet and into the home is likely to be RESTful HTTP over =20 > TCP as it is so universally used now and is likely to persist well =20 > into the future. One important reason for this argument is that so =20 > much existing infrastructure supports this. For example, many small =20= > office and home systems use IPv4 and NAT gateways/routers. This is =20 > itself puts some imposition on the ability for true end-to-end IP =20 > routing as it stands due to the use of TCP/UDP ports. Indeed, the =20 > protocol stack =91waist=92 can almost be considered to be HTTP = (80/tcp) =20 > these days, not IP at layer 3. > > Considering (2) further: If we ignored the wider Internet as a =20 > whole, there is no doubt that a simple, efficient, low bandwidth =20 > application protocol would be developed which is oriented towards =20 > CNets. Indeed, one could argue that ZigBee satisfies that =20 > requirement very well. This sort of network is also already capable =20= > of being connected to the wider Internet through an application =20 > level gateway providing translation and also proxying and buffering =20= > for low bandwidth and sleepy devices. The fundamental problem with =20 > this approach is that the bridging is not occurring at the =91waist=92 = =20 > but at the =91chest=92. The maintenance of all the translations for = the =20 > numerous networks could become a burden. This is also counter to =20 > routing IP at layer 3. > > Therefore I see three ways of proceeding: > Define an application protocol which uses RESTful HTTP over TCP =20 > extending to the edge devices and try to find a solution to the =20 > problems of TCP over lossy links > Define an application protocol based on a universal transaction and =20= > transport which is flexible enough for all media and takes into =20 > consideration the underlying properties of the medium through cross-=20= > layer controls. However the scope of this work is probably beyond =20 > CoAP and assumes that IPv6 would become pervasive enough not to =20 > cause problems with existing infrastructure > Define new application, transaction and transport protocols oriented =20= > towards CNets and define a proxy model for extension into the wider =20= > Internet > Note these are not mutually exclusive. If (1) were done, (3) could =20 > still be a solution for devices which do not meet the criteria to =20 > satisfy the use of TCP. If (2) were done there would probably be no =20= > point in doing (1) or (3). (3) could be done now but does not solve =20= > the requirement for "end-to-end", although there are a number of =20 > possibilities there if you split the application layer into the =20 > three layers defined in OSI, but that's another debate. > > Regards, > > Robert > > Adriano Pezzuto (apezzuto) wrote: >> >> Hello, >> I don't get one point here. Help me to understand. >> Are we searching for a well known protocol to use as CoAP for =20 >> 6lowPAN and WSN networks or are we searching for a "model" to use =20 >> for? >> >> I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the =20= >> plate. Each of these protocols have been developed for a specific =20 >> purpose keeping in mind specific constraints and requirements and =20 >> each of them is a valid choice for the respective domain. On the =20 >> other side, each of them have some drawbacks for 6lowPAN and WSN =20 >> networks and I see a lot of diverged opinions here. >> >> Why we fear for define a new application protocol especially =20 >> designed for 6lowPAN and WSN networks? >> >> I'm a newbie for 6lowPAN but my feeling is that a simple =20 >> lightweight protocol (I also prefer LoAP instead of CoAP) with a =20 >> minimal set of primitives (e.g. SET/SET-Reply, GET/GET-Reply and =20 >> Event/Ack) is sufficient to cover the most part of the use cases =20 >> and interaction models for 6lowPAN and WSN networks. Other items =20 >> can be further added on the plate like security, service discovery, =20= >> nodes and network management, and so on .. but all they can be =20 >> solved with the same minimal approach keeping in mind the real =20 >> nature and the scope of 6lowPAN networks. At the end of day, we are =20= >> talking about CSMA/CA radio networks with high lossy and few =20 >> kilobytes of useful throughput. Also the nodes spend most part of =20 >> their time sleeping down to save power or can be inactive for days =20= >> (or months). I've some doubts that complex protocols/frameworks =20 >> (developed for other scopes than 6lowPAN) can run efficiently on =20 >> our small poor devices. But that's only the feeling of a newbie .... >> >> Adriano >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On =20= >> Behalf Of Paul Duffy (paduffy) >> Sent: mercoled=EC 4 novembre 2009 13.50 >> To: nicolas.riou@fr.schneider-electric.com >> Cc: 6lowapp@ietf.org >> Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF >> >> I agree there is a need for more than request/response messaging, but >> WS_* gives me pause for constrained devices and links. It is =20 >> probably >> the most compute intensive, bandwidth hungry way to interface HAN-=20 >> like >> endpoints. >> >> >> >>> Hi Cullen, >>> >>> >----- Message de Cullen Jennings sur Sat, 31 >>> Oct 2009 11:29:41 -0600 ----- >>> >Pour: arjun.lists@hsc.com >>> >cc: Don Sturek , = 6lowapp@ietf.org >>> >Objet: Re: [6lowapp] Proposed charter for 6LoWAPP BOF >>> > >>> >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote: >>> > >>> > ... >>> >OK - The way I want to try and derive us towards a decision =20 >>> here >>> is >>> >get a list of candidate protocols then for each one ask the >>> yes/no is >>> >the their agreement that we should do a mapping to that =20 >>> protocol. >>> The >>> >protocols I have heard so far are HTTP, SNMP, SMTP. So two >>> questions >>> > >>> >1) what other protocols mapping should we do? >>> >>> The charter has significantly changed these days and I would like to >>> re-state the need for >>> seamless interfacing between 6lowapp and the DPWS world. DPWS is a =20= >>> low >>> cost SOA solution at >>> device level and will play a major role in future Building and >>> Industrial Automation systems >>> (embedded in zone controllers, Automation servers, industrial >>> PLCs...). Besides, in some >>> cases, native support of DPWS in VISTA and Windows 7 network =20 >>> explorer >>> might help in simplifying >>> discovery and commissioning of devices. >>> The HTTP REST model proposed in the new charter is sufficient for >>> simple get/set operations but >>> I join Vlad Trifa when saying that there are requirements for more >>> than just request/response >>> messaging patterns like e.g. publish/subscribe (multicast). IMO >>> seamless interfacing with WS_* >>> (at least straightforward proxying) must be provided to ensure >>> efficient integration of 6lowpan networks >>> in upcoming architectures. >>> >>> Regards. >>> Nicolas >>> = ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >>> >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --Apple-Mail-14--108059138 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Not considering specific use cases, I see two general requirements coming out here:
  1. The requirement for a universal application protocol  which can work across the wider internet all the way from head-end to edge devices
  2. The requirement for an application protocol specific to low-power, resource constrained nodes (CoAP)
(1) pushes from the wider Internet to the edge devices.
(2) pushes from the edge devices to the wider Internet.

The utopian aim would be to find the intersection of these requirements, if it exists. Then the Internet of Things truly becomes feasible. 

Considering (1) further: The most feasible solution to run over the wider Internet and into the home is likely to be RESTful HTTP over TCP as it is so universally used now and is likely to persist well into the future. One important reason for this argument is that so much existing infrastructure supports this. For example, many small office and home systems use IPv4 and NAT gateways/routers. This is itself puts some imposition on the ability for true end-to-end IP routing as it stands due to the use of TCP/UDP ports. Indeed, the protocol stack =91waist=92 can almost be considered = to be HTTP (80/tcp) these days, not IP at layer 3.

Considering (2) further: If we ignored the wider Internet as a whole, there is no doubt that a simple, efficient, low bandwidth application protocol would be developed which is oriented towards CNets. Indeed, one could argue that ZigBee satisfies that requirement very well. This sort of network is also already capable of being connected to the wider Internet through an application level gateway providing translation and also proxying and buffering for low bandwidth and sleepy devices. The fundamental problem with this approach is that the bridging is not occurring at the =91waist=92 but at the =91chest=92. The maintenance of = all the translations for the numerous networks could become a burden. This is also counter to routing IP at layer 3.

Therefore I see three ways of proceeding:
  1. Define an application protocol which uses RESTful HTTP over TCP extending to the edge devices and try to find a solution to the problems of TCP over lossy links
  2. Define an application protocol based on a universal transaction and transport which is flexible enough for all media and takes into consideration the underlying properties of the medium through cross-layer controls. However the scope of this work is probably beyond CoAP and assumes that IPv6 would become pervasive enough not to cause problems with existing infrastructure
  3. Define new application, transaction and transport protocols oriented towards CNets and define a proxy model for extension into the wider Internet
Note these are not mutually exclusive. If (1) were done, (3) could still be a solution for devices which do not meet the criteria to satisfy the use of TCP. = If (2) were done there would probably be no = point in doing (1) or (3). (3) could be done now but does not solve the requirement for "end-to-end", although there are a number of possibilities there if you split the application layer into the three layers defined in OSI, but that's another debate.

Regards,

Robert

Adriano Pezzuto (apezzuto) wrote: 
Hello,
I don't get one point here. Help me to understand.
Are we searching for a well known protocol to use as CoAP for 6lowPAN =
and WSN networks or are we searching for a "model" to use for?

I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the =
plate. Each of these protocols have been developed for a specific =
purpose keeping in mind specific constraints and requirements and each =
of them is a valid choice for the respective domain. On the other side, =
each of them have some drawbacks for 6lowPAN and WSN networks and I see =
a lot of diverged opinions here.

Why we fear for define a new application protocol especially designed =
for 6lowPAN and WSN networks?

I'm a newbie for 6lowPAN but my feeling is that a simple lightweight =
protocol (I also prefer LoAP instead of CoAP) with a minimal set of =
primitives (e.g. SET/SET-Reply, GET/GET-Reply and Event/Ack) is =
sufficient to cover the most part of the use cases and interaction =
models for 6lowPAN and WSN networks. Other items can be further added on =
the plate like security, service discovery, nodes and network =
management, and so on .. but all they can be solved with the same =
minimal approach keeping in mind the real nature and the scope of =
6lowPAN networks. At the end of day, we are talking about CSMA/CA radio =
networks with high lossy and few kilobytes of useful throughput. Also =
the nodes spend most part of their time sleeping down to save power or =
can be inactive for days (or months). I've some doubts that complex =
protocols/frameworks (developed for other scopes than 6lowPAN) can run =
efficiently on our small poor devices. But that's only the feeling of a =
newbie ....

Adriano

-----Original Message-----
From: 6lowapp-bounces@ietf.org =
[mailto:6lowapp-bounces@ietf.org] On Behalf Of Paul Duffy (paduffy)
Sent: mercoled=EC 4 novembre 2009 13.50
To: nicolas.riou@fr.sch=
neider-electric.com
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF

I agree there is a need for more than request/response messaging, but=20
WS_*  gives me pause for constrained devices and links. It is probably=20=

the most compute intensive, bandwidth hungry way to interface HAN-like=20=

endpoints.


  
Hi Cullen,

    >----- Message de Cullen Jennings <fluffy@cisco.com> sur Sat, =
31=20
Oct 2009 11:29:41 -0600 -----
    >Pour:        arjun.lists@hsc.com
    >cc:        Don Sturek <donsturek@grid2home.com>, 6lowapp@ietf.org
    >Objet:        Re: [6lowapp] Proposed charter for 6LoWAPP BOF
    >
    >On Oct 29, 2009, at 12:11 , Arjun Roychowdhury wrote:
    >
    > ...
    >OK - The way I want to try and derive us towards a decision here=20=

is =20
    >get a list of candidate protocols then for each one ask the=20
yes/no is =20
    >the their agreement that we should do a mapping to that =
protocol.=20
 The =20
    >protocols I have heard so far are HTTP, SNMP,  SMTP. So two=20
questions
    >
    >1) what other protocols mapping should we do?

The charter has significantly changed these days and I would like to=20
re-state the need for
seamless interfacing between 6lowapp and the DPWS world. DPWS is a low=20=

cost SOA solution at
device level and will play a major role in future Building and=20
Industrial Automation systems
(embedded in zone controllers, Automation servers, industrial=20
PLCs...). Besides, in some
cases, native support of DPWS in VISTA and Windows 7 network explorer=20
might help in simplifying
discovery and commissioning of devices.
The HTTP REST model proposed in the new charter is sufficient for=20
simple get/set operations but
I join Vlad Trifa when saying that there are requirements for more=20
than just request/response
messaging patterns like e.g. publish/subscribe (multicast). IMO=20
seamless interfacing with WS_*
(at least straightforward proxying) must be provided to ensure=20
efficient integration of 6lowpan networks
in upcoming architectures.

Regards.
Nicolas
------------------------------------------------------------------------

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.or=
g/mailman/listinfo/6lowapp
 =20
    

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.or=
g/mailman/listinfo/6lowapp
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.or=
g/mailman/listinfo/6lowapp
_______________________________________________
6lowapp mailing = list
6lowapp@ietf.org
https://www.ietf.= org/mailman/listinfo/6lowapp

= --Apple-Mail-14--108059138-- From hamid.mukhtar@gmail.com Wed Nov 4 14:41:06 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253663A6A2A for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 14:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.364 X-Spam-Level: X-Spam-Status: No, score=-101.364 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 OaB0JP-vfgGz for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 14:41:05 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 644DD3A6A29 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 14:41:05 -0800 (PST) Received: by pxi1 with SMTP id 1so5654652pxi.32 for <6lowapp@ietf.org>; Wed, 04 Nov 2009 14:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=Q9TMBLJtlOBeRbV9qi/QZWuVpLdL50vlhpZIhimiEjc=; b=mBABz8uu+isd1sICfjxy+i4NQhrcHBYt/T6+dHIg127FyCkA8mHkDLn10wxIwHkCZE kML+lGNim8CKBiOYnkL9wnXLnFao1BGXBffhVmSp6GIIhzmNlaBxyjXOvj/OrC5QVGQV fjvWEf7TTdg/DWa1CralNk30Meo8TpAZFBVws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=lDIzTfZR8kIQ9lHLxIlAFC0TMXIz5RSMUCt+ldSYJdZtGiR4DpZMPei4O4XuzEHZLc GLhwgBhhI8rgKfipaEbj1oUz+/qndt47+tLGGhAze1YVpcAg5GEH749+EHa+7oZWXgH3 LdmhC3ZIfK9pPAjyoBufwVPL9VAQjj0/VVlck= MIME-Version: 1.0 Sender: hamid.mukhtar@gmail.com Received: by 10.142.2.14 with SMTP id 14mr215744wfb.15.1257374484104; Wed, 04 Nov 2009 14:41:24 -0800 (PST) In-Reply-To: <4EDB0058-5EBB-417E-88B5-43A750B97796@cisco.com> References: <4EDB0058-5EBB-417E-88B5-43A750B97796@cisco.com> From: Hamid Mukhtar Date: Thu, 5 Nov 2009 07:41:09 +0900 X-Google-Sender-Auth: 073c8efdc6c7b006 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Updated Draft Agenda X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 22:41:06 -0000 The SNMP optimizations ID [draft-hamid-6lowpan-snmp-optimizations] may also be added to the list of related items. On Thu, Nov 5, 2009 at 12:47 AM, Cullen Jennings wrote: > > Current Agenda: (Updated Nov 4) > > 5 min =A0 Agenda bashing =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0Chairs > > 10 min =A0Goal and purpose of the BOF =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Chairs > > 10 min =A0Description of the problem/problem space =A0 =A0 =A0Carsten Bor= mann > =A0 =A0 =A0 =A0draft-bormann-6lowpan-6lowapp-problem-01 > > 20 min =A06lowapp WG charter proposal: part 1 =A0 =A0 =A0 =A0 =A0 Zach Sh= elby > =A0 =A0 =A0 =A0Draft charter at > =A0 =A0 =A0 =A0http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > > 10 min =A0Building Objectives =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 Peter Van Der Stok > =A0 =A0 =A0 =A0draft-gold-6lowapp-sensei-00 > =A0 =A0 =A0 =A0draft-martocci-6lowapp-building-applications-00 > > 10 min =A0Smart energy Objectives =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 Don Sturek > =A0 =A0 =A0 =A0draft-sturek-6lowapp-smartenergy-00 > > 10 min =A06lowapp WG charter proposal: part 2 =A0 =A0 =A0 =A0 =A0 Zach Sh= elby > > 30 min =A0Open Discussion =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 All > > 10 min =A0Calling the questions =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 ADs > > > Other drafts on interest: > =A0 =A0 =A0 =A0draft-frank-6lowapp-chopan-00 > =A0 =A0 =A0 =A0draft-manner-6lowapp-sdnd-00 > =A0 =A0 =A0 =A0draft-roychowdhury-6lowappsip-00 > =A0 =A0 =A0 =A0draft-ryanpitt-6lowapp-xpl-00 > =A0 =A0 =A0 =A0draft-schmitt-6lowapp-ipfix-ws-00 > =A0 =A0 =A0 =A0draft-shelby-6lowapp-encoding-00 > =A0 =A0 =A0 =A0draft-struik-6lowapp-security-considerations-00 > =A0 =A0 =A0 =A0draft-sturek-6lowapp-servicediscovery-00 > =A0 =A0 =A0 =A0draft-ietf-roll-home-routing-reqs-08 > =A0 =A0 =A0 =A0draft-ietf-roll-building-routing-reqs > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From cabo@tzi.org Wed Nov 4 21:34:16 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F843A6862 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 21:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 RFobnN-2YkjG for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 21:34:15 -0800 (PST) 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 3E90B3A67A3 for <6lowapp@ietf.org>; Wed, 4 Nov 2009 21:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nA55YGTJ007110; Thu, 5 Nov 2009 06:34:16 +0100 (CET) Received: from [192.168.217.101] (p5489FD43.dip.t-dialin.net [84.137.253.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 5175AB710; Thu, 5 Nov 2009 06:34:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Carsten Bormann In-Reply-To: Date: Thu, 5 Nov 2009 06:34:14 +0100 Content-Transfer-Encoding: 7bit Message-Id: <6A9F12D3-E164-466B-B029-54F738FA65DB@tzi.org> References: <4EDB0058-5EBB-417E-88B5-43A750B97796@cisco.com> To: Hamid Mukhtar X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Updated Draft Agenda X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 05:34:16 -0000 On Nov 4, 2009, at 23:41, Hamid Mukhtar wrote: > draft-hamid-6lowpan-snmp-optimizations Thanks Hamid. Fixed. (And I actually uploaded the agenda which for some reason didn't stick at:) http://www.ietf.org/proceedings/09nov/agenda/6lowapp.txt Gruesse, Carsten From cabo@tzi.org Wed Nov 4 21:59:32 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 326943A6781 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 21:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 K7byY9COcNm1 for <6lowapp@core3.amsl.com>; Wed, 4 Nov 2009 21:59:31 -0800 (PST) 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 2489B3A63EC for <6lowapp@ietf.org>; Wed, 4 Nov 2009 21:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nA55xcUl010993; Thu, 5 Nov 2009 06:59:39 +0100 (CET) Received: from [192.168.217.101] (p5489FD43.dip.t-dialin.net [84.137.253.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 2A985B712; Thu, 5 Nov 2009 06:59:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Carsten Bormann In-Reply-To: <6BB19374-5B51-447C-9CFF-DEACCE595312@cs.columbia.edu> Date: Thu, 5 Nov 2009 06:59:36 +0100 Content-Transfer-Encoding: 7bit Message-Id: <772085F9-B72B-47D9-876F-13F90B86464F@tzi.org> References: <4AF17892.8040108@cisco.com> <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> <4AF1AD4C.5080908@gridmerge.com> <6BB19374-5B51-447C-9CFF-DEACCE595312@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 05:59:32 -0000 On Nov 4, 2009, at 23:00, Henning Schulzrinne wrote: > We seem to be conflating a number of different constraints: > - low bandwidth > - low computational capabilities (CPU, memory) > - lossy links Let's add (again, for some, not all nodes in the mix): -- constraints on power (sleeping nodes) -- preference for node-initiated communication -- constraints on networking -- payloads beyond 50-70 bytes cause expensive/lossy fragmentation -- no IP multicast (except for a narrow radio range) CoAP is not aimed at high-power, high-bitrate nodes such as WiFi cameras. (CoAP might indeed help those WiFi cameras with talking to, say, additional PIR motion sensors or door/window sensors.) HANs/BANs will certainly use a mixture of protocols, and e.g. RTP plus some control protocol (SIP, XMPP) may be fine for a camera. Gruesse, Carsten From apezzuto@cisco.com Thu Nov 5 01:33:18 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE133A699E for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 01:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.099 X-Spam-Level: X-Spam-Status: No, score=-8.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 WGj-QRHoi1EZ for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 01:33:17 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 096863A6986 for <6lowapp@ietf.org>; Thu, 5 Nov 2009 01:33:17 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJsq8kqrR7Hu/2dsb2JhbADGfJdohD0EgWY X-IronPort-AV: E=Sophos;i="4.44,685,1249257600"; d="scan'208";a="266592435" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 05 Nov 2009 09:33:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nA59XSqx029448; Thu, 5 Nov 2009 09:33:39 GMT Received: from xmb-ams-106.cisco.com ([144.254.74.81]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Nov 2009 10:33:35 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Nov 2009 10:33:33 +0100 Message-ID: <0D212BD466921646B58854FB79092CEC9D1923@XMB-AMS-106.cisco.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Proposed charter for 6LoWAPP BOF Thread-Index: AcpdmRraMHOUJbxaTwSTCSvk+BUZvwAYSv6Q References: <4AF17892.8040108@cisco.com> <0D212BD466921646B58854FB79092CEC9D15C2@XMB-AMS-106.cisco.com> <4AF1AD4C.5080908@gridmerge.com> From: "Adriano Pezzuto (apezzuto)" To: "Zach Shelby" , X-OriginalArrivalTime: 05 Nov 2009 09:33:35.0301 (UTC) FILETIME=[0C006F50:01CA5DFB] Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 09:33:18 -0000 Hi Zach and Robert, I get the point. It sounds good. Thanks, Adriano >> If (2) were done there would probably be no point in doing (1) or =20 >> (3). (3) could be done now but does not solve the requirement for =20 >> "end-to-end", although there are a number of possibilities there if =20 >> you split the application layer into the three layers defined in =20 >> OSI, but that's another debate. > I think you hit on the whole point here. 1 is done, 2 is not possible, = =20 > and what this WG needs to do is 3, making that as integrated into the = > web architecture as we can. If we do our job well, I don't see =20 > proxying between two protocols that share the same semantics (URLs, =20 > REST etc.) and leave the payload alone to be a problem. -----Original Message----- From: Zach Shelby [mailto:zach@sensinode.com]=20 Sent: mercoled=EC 4 novembre 2009 22.52 To: robert.cragie@gridmerge.com Cc: Adriano Pezzuto (apezzuto); Paul Duffy (paduffy); 6lowapp@ietf.org Subject: Re: [6lowapp] Proposed charter for 6LoWAPP BOF Robert, Very good points below, thanks for the mail! On Nov 4, 2009, at 18:35 , Robert Cragie wrote: > (1) pushes from the wider Internet to the edge devices. > (2) pushes from the edge devices to the wider Internet. Yep, this is the tussle at play here. We are not considering all edge =20 devices here, only the most constrained devices and networks. > Therefore I see three ways of proceeding: > * Define an application protocol which uses RESTful HTTP over TCP =20 > extending to the edge devices and try to find a solution to the =20 > problems of TCP over lossy links So HTTP already is that protocol, and it is the current SOTA for =20 embedded devices and networks where it gets the job done. We already =20 determined that new transport work is a longer-term issue for the TSV =20 area. The whole point of this interest group (and WG effort) is that =20 there is a large set of devices, networks and applications where this =20 is not sufficient. So I would say that 1 is definitely done. > * Define an application protocol based on a universal transaction =20 > and transport which is flexible enough for all media and takes into =20 > consideration the underlying properties of the medium through cross-=20 > layer controls. However the scope of this work is probably beyond =20 > CoAP and assumes that IPv6 would become pervasive enough not to =20 > cause problems with existing infrastructure This is out of scope of the APP area, and probably breaks lots of IETF =20 architectural concepts as well. So 2 is out. > * Define new application, transaction and transport protocols =20 > oriented towards CNets and define a proxy model for extension into =20 > the wider Internet This WG is not going to define new transport protocols (nor can it). =20 There is good consensus to use UDP by default and allow for the use of =20 TCP (or other suitable transports). > Note these are not mutually exclusive. If (1) were done, (3) could =20 > still be a solution for devices which do not meet the criteria to =20 > satisfy the use of TCP. TCP is only one issue, it is useful in some cases. HTTP and current =20 security models assumed by the web infrastructure are not suitable for =20 all constrained IP devices and networks. > If (2) were done there would probably be no point in doing (1) or =20 > (3). (3) could be done now but does not solve the requirement for =20 > "end-to-end", although there are a number of possibilities there if =20 > you split the application layer into the three layers defined in =20 > OSI, but that's another debate. I think you hit on the whole point here. 1 is done, 2 is not possible, =20 and what this WG needs to do is 3, making that as integrated into the =20 web architecture as we can. If we do our job well, I don't see =20 proxying between two protocols that share the same semantics (URLs, =20 REST etc.) and leave the payload alone to be a problem. Now. Considering that, do you have comments on the charter text? We =20 are working on a new version right now. Zach > > Regards, > > Robert > > Adriano Pezzuto (apezzuto) wrote: >> Hello, >> I don't get one point here. Help me to understand. >> Are we searching for a well known protocol to use as CoAP for =20 >> 6lowPAN and WSN networks or are we searching for a "model" to use =20 >> for? >> >> I'm seeing here a lot of proposal like HTTP, SNMP, SIP, XMPP on the =20 >> plate. Each of these protocols have been developed for a specific =20 >> purpose keeping in mind specific constraints and requirements and =20 >> each of them is a valid choice for the respective domain. On the =20 >> other side, each of them have some drawbacks for 6lowPAN and WSN =20 >> networks and I see a lot of diverged opinions here. >> >> Why we fear for define a new application protocol especially =20 >> designed for 6lowPAN and WSN networks? >> >> I'm a newbie for 6lowPAN but my feeling is that a simple =20 >> lightweight protocol (I also prefer LoAP instead of CoAP) with a =20 >> minimal set of primitives (e.g. SET/SET-Reply, GET/GET-Reply and =20 >> Event/Ack) is sufficient to cover the most part of the use cases =20 >> and interaction models for 6lowPAN and WSN networks. Other items =20 >> can be further added on the plate like security, service discovery, =20 >> nodes and network management, and so on .. but all they can be =20 >> solved with the same minimal approach keeping in mind the real =20 >> nature and the scope of 6lowPAN networks. At the end of day, we are =20 >> talking about CSMA/CA radio networks with high lossy and few =20 >> kilobytes of useful throughput. Also the nodes spend most part of =20 >> their time sleeping down to save power or can be inactive for days =20 >> (or months). I've some doubts that complex protocols/frameworks =20 >> (developed for other scopes than 6lowPAN) can run efficiently on =20 >> our small poor devices. But that's only the feeling of a newbie .... >> >> Adriano >> From cabo@tzi.org Thu Nov 5 02:06:44 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D33FD3A68A6 for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 02:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 mm9nd8h6ptkc for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 02:06:44 -0800 (PST) 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 9AF023A67B2 for <6lowapp@ietf.org>; Thu, 5 Nov 2009 02:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nA5A6tDI015222 for <6lowapp@ietf.org>; Thu, 5 Nov 2009 11:06:55 +0100 (CET) Received: from ip-77-24-138-13.web.vodafone.de (ip-77-24-138-13.web.vodafone.de [77.24.138.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 6BA1EB84B; Thu, 5 Nov 2009 11:06:54 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 5 Nov 2009 11:06:51 +0100 To: 6lowapp@ietf.org Message-Id: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 10:06:44 -0000 I have put a new version of the WG charter proposal on the wiki page at http://6lowapp.net = http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp (charter text is at the end of the page). Obviously, I could not pick up every comment that was on the list (they were partially going in conflicting directions), but please do comment on the new version. Gruesse, Carsten From kerlyn2001@gmail.com Thu Nov 5 08:03:24 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DCC3A6AD5 for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 08:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 TWuntxZj1pyd for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 08:03:19 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 2D9D03A66B4 for <6lowapp@ietf.org>; Thu, 5 Nov 2009 08:03:19 -0800 (PST) Received: by bwz23 with SMTP id 23so134896bwz.29 for <6lowapp@ietf.org>; Thu, 05 Nov 2009 08:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=a5Jaafn9UQaetcStIQezjcdBInNe8t/dSRZBpOEiXCY=; b=qGOBNGMRhBN5qghfMJyGezpP2EveQlNpSoPWGYNHDvyet223/pyfS7nAO5Oh6yfpEk 2C1bnRqnGpXaGFpvr9XV8SMG3F32k4YF1szoPGZBHUrtttt0LvueJ8V8X8JUW/oNg9PI MuyiH0N9Istyzk4dCKUU2eVWt6Hf7OZSWCM+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=abTZBcdn9E7P7CPjbYjVnGF6pPTUEHtN8eBO2OkSkgElAfCV1PJ3v2KODLboy2cIDu dn33KXv3WVmf5g+R8mO9FYd/qKgb3SJhjtm0yzp6HhFKVFawpVPU0N5J9AjdvXwC83OM zBvFHrXZFMl5a0C08uivwPtWuTlvvlobeN8hU= MIME-Version: 1.0 Received: by 10.204.154.150 with SMTP id o22mr3202304bkw.154.1257437014536; Thu, 05 Nov 2009 08:03:34 -0800 (PST) In-Reply-To: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> Date: Thu, 5 Nov 2009 11:03:34 -0500 Message-ID: <3fe58b590911050803l352fc5e1idbd554ba10823868@mail.gmail.com> From: Kerry Lynn To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:03:24 -0000 I plan to finish reading through all the email archives before the 6lowapp meeting, so this is the last time I'll apologize for not having complete context. There seems to be a wide divergence of opinion on the meaning of "constrained", from full-on WS* to unable to contain any strings. I would offer a working definition, borrowed from Einstein, that CoNodes should be "as simple as possible, but no simpler." I believe that by moving as much functionality as possible from the CoNodes into the CoGII nodes, we end up with a lower total system cost and, ultimately, greater ubiquity. The definition of CoNode should admit wired (e.g. power line connected) as well as wireless Devices. As a general approach to foster consensus, I'd suggest the WG might add to its "objectives and architecture" document a specification of which services must be present in a CoNode and which must be present in the CoGII node (and how the CoGII node differs from a ROLL node; e.g. where does header de/compression reside?) I support the viewpoint that a collection of CoNodes should be able to implement some non-trivial applications without requiring a CoGII node (e.g. the "one light, one switch" scenario). Others may disagree with this (perhaps even strongly) but I believe statements of this sort will help focus the debate and lead to the the ultimate meaning of "constrained". I personally find it easier in the early stages to think in terms of abstract services rather than specific protocols. For example, "BACnet relies on the ability to enumerate all the devices on the network and to query the value of objects within a device." The first is accomplished using the "Who-is" or "Who-has" services (indeed, one might argue that having two such mechanisms runs counter to interoperability) while the second is accomplished using the "ReadProperty" service. If we can reach consensus on which services we need then mapping to specific implementations might be easier. Lastly, might I suggest using in the charter "CoNet" in place of "CNN"? Respectfully submitted, Kerry Lynn On Thu, Nov 5, 2009 at 5:06 AM, Carsten Bormann wrote: > I have put a new version of the WG charter proposal on the wiki page at > http://6lowapp.net > = > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > (charter text is at the end of the page). > > Obviously, I could not pick up every comment that was on the list (they were > partially going in conflicting directions), but please do comment on the new > version. > > Gruesse, Carsten > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From arjunrc@gmail.com Thu Nov 5 08:30:37 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9506C28C1F7 for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 08:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Qkmir9rdMfot for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 08:30:36 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 6A28F3A6823 for <6lowapp@ietf.org>; Thu, 5 Nov 2009 08:30:36 -0800 (PST) Received: by qyk41 with SMTP id 41so85655qyk.29 for <6lowapp@ietf.org>; Thu, 05 Nov 2009 08:30:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=YPRGVpYT60cO+Ll/sQL7ADLdxGuLkAmUuLVpsNYJhb8=; b=jaVtTlUdwSjviEfmgtlriJmcPxqK81DKBw8itlU99lKDSka4mJhjIFwnKHwQynut0x Pe/u15GNjI07OuORfUxO9mo/Yb1Wl4xT9RjEguKOkdtPoNHsz5z5XxrZ1GyTx5oTUpwe fdeWuJ8JLMU5R08CskVJu4jeX7sbTOpmQzjVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=cejkg/Oi1sjE5o12Fe9CLfczDVMxdtDbG62XRcalwg38k0sMNhsnbaQSeh9YYwoZ/z b0T9wfSfXSDdv1juWUxSwos9EgHX5EunNiiszazRhirH7OHR2ldihpOcrABWcnNFNVRP WK5gvq4JVthk+sMJeQBQvuNl+qOjMdMTW7a9o= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.33.195 with SMTP id i3mr1589623qad.386.1257438656067; Thu, 05 Nov 2009 08:30:56 -0800 (PST) In-Reply-To: <3fe58b590911050803l352fc5e1idbd554ba10823868@mail.gmail.com> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> <3fe58b590911050803l352fc5e1idbd554ba10823868@mail.gmail.com> From: Arjun Roychowdhury Date: Thu, 5 Nov 2009 11:30:36 -0500 X-Google-Sender-Auth: bc0276b13b4b369c Message-ID: To: Kerry Lynn Content-Type: multipart/alternative; boundary=000feaf20b726bfdc70477a24013 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:30:37 -0000 --000feaf20b726bfdc70477a24013 Content-Type: text/plain; charset=ISO-8859-1 > > There seems to be a wide divergence of opinion on the meaning of > "constrained", from full-on WS* to unable to contain any strings. I would > offer a working definition, borrowed from Einstein, that CoNodes should > be "as simple as possible, but no simpler." > ARC> agree. > > I believe that by moving as much functionality as possible from the > CoNodes into the CoGII nodes, we end up with a lower total system cost > and, ultimately, greater ubiquity. The definition of CoNode should admit > wired (e.g. power line connected) as well as wireless Devices. > ARC> This is usually the same argument for a network full of 'interoperability gateways' though (and the core principle of dumb nodes, intelligent networks). The problem with heavy reliance on CoGII is that while it results in short term low system cost, over a longer term, these CoGII elements become single point of failures, complicate network management and make the end-end architecture brittle. Pushing functionality by default to CoGII also results in quicker architecture and deployment - but in the longer run, we have a system that is full of technology islands patched together with frail bridges. So the CoGII approach, to me, really should be "as few as possible and no more" > > As a general approach to foster consensus, I'd suggest the WG might > add to its "objectives and architecture" document a specification of > which services must be present in a CoNode and which must be > present in the CoGII node (and how the CoGII node differs from a > ROLL node; e.g. where does header de/compression reside?) > > I support the viewpoint that a collection of CoNodes should be able to > implement some non-trivial applications without requiring a CoGII > node (e.g. the "one light, one switch" scenario). Others may disagree > with this (perhaps even strongly) but I believe statements of this sort > will help focus the debate and lead to the the ultimate meaning of > "constrained". > ARC> +1 > > I personally find it easier in the early stages to think in terms of > abstract > services rather than specific protocols. For example, "BACnet relies on > the ability to enumerate all the devices on the network and to query the > value of objects within a device." The first is accomplished using the > "Who-is" or "Who-has" services (indeed, one might argue that having > two such mechanisms runs counter to interoperability) while the second > is accomplished using the "ReadProperty" service. If we can reach > consensus on which services we need then mapping to specific > implementations might be easier. > ARC> +1 > > Lastly, might I suggest using in the charter "CoNet" in place of "CNN"? > > Respectfully submitted, Kerry Lynn > > -- > Arjun Roychowdhury --000feaf20b726bfdc70477a24013 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There seems to b= e a wide divergence of opinion on the meaning of
"constrained", from full-on WS* to unable to contain any strings.= =A0I would
offer a working definition, borrowed from Einstein, that CoNodes should
be "as simple as possible, but no simpler."
=
ARC> agree.
=A0

I believe that by moving as much functionality as possible from the
CoNodes into the CoGII nodes, we end up with a lower total system cost
and, ultimately, greater ubiquity. The definition of CoNode should admit wired (e.g. power line connected) as well as wireless Devices.

ARC> This is usually the same argument for a net= work full of 'interoperability gateways' though (and the core princ= iple of dumb nodes, intelligent networks). The problem with heavy reliance = on CoGII is that while it results in short term low system cost, over a lon= ger term, these CoGII elements become single point of failures, complicate = network management and make the end-end architecture brittle. Pushing funct= ionality by default to CoGII also results in quicker architecture and deplo= yment - but in the longer run, we have a system that is full of technology = islands patched together with frail bridges.

So the CoGII approach, to me, really should be "as= few as possible and no more"
=A0

As a general approach to foster consensus, I'd suggest the WG might
add to its "objectives and architecture" document a specification= of
which services must be present in a CoNode and which must be
present in the CoGII node (and how the CoGII node differs from a
ROLL node; e.g. where does header de/compression reside?)
<= div>


I support the viewpoint that a collection of CoNodes should be able to
implement some non-trivial applications without requiring a CoGII
node (e.g. the "one light, one switch" scenario). =A0Others may d= isagree
with this (perhaps even strongly) but I believe statements of this sort
will help focus the debate and lead to the the ultimate meaning of
"constrained".

ARC> +1
=A0

I personally find it easier in the early stages to think in terms of abstra= ct
services rather than specific protocols. =A0For example, "BACnet relie= s on
the ability to enumerate all the devices on the network and to query the value of objects within a device." =A0The first is accomplished using = the
"Who-is" or "Who-has" services (indeed, one might argue= that having
two such mechanisms runs counter to interoperability) while the second
is accomplished using the "ReadProperty" service. =A0If we can re= ach
consensus on which services we need then mapping to specific
implementations might be easier.

ARC>= ; +1
=A0

Lastly, might I suggest using in the charter "CoNet" in place of = "CNN"?

Respectfully submitted, Kerry Lynn

--=A0
A= rjun Roychowdhury

--000feaf20b726bfdc70477a24013-- From j.schoenwaelder@jacobs-university.de Thu Nov 5 08:35:34 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4653D3A697C for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 08:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 grqogtekWcUA for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 08:35:33 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 028963A694F for <6lowapp@ietf.org>; Thu, 5 Nov 2009 08:35:33 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20BC6C003C; Thu, 5 Nov 2009 17:35:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UBaG6LgeaN+a; Thu, 5 Nov 2009 17:35:53 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81F2DC003A; Thu, 5 Nov 2009 17:35:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DA303DA3476; Thu, 5 Nov 2009 17:35:52 +0100 (CET) Date: Thu, 5 Nov 2009 17:35:52 +0100 From: Juergen Schoenwaelder To: Carsten Bormann Message-ID: <20091105163552.GA10440@elstar.local> Mail-Followup-To: Carsten Bormann , "6lowapp@ietf.org" <6lowapp@ietf.org> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 16:35:34 -0000 On Thu, Nov 05, 2009 at 11:06:51AM +0100, Carsten Bormann wrote: > I have put a new version of the WG charter proposal on the wiki page at > http://6lowapp.net > = > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > (charter text is at the end of the page). Some feedback from a quick read of the charter text. -- I have not clue what this means: [...] For these benchmark cases, the payload will be based on interface profile specific XML documents compressed with EXI. Which benchmark cases is this text referring to? And why suddenly fix a certain encoding? -- I also do not understand the relationship of 4a) to 4). Since 4) talks specifically about HTTP REST, how can 4a talk about non HTTP REST protocols? I think 4) should say: 4) Specification how other protocols interface via a CoGII to CoAP. Separate specifications are envisioned zero or more of: SNMP, SMTP, SIP, and XMPP. [[Note: In the BOF it would be nice to figure out which of these are in the charter.]] -- I find the text on various commissioning methods rather strange for the charter of a working group. A working group charter item can be the production of a BCP on commissioning methods. The current text more looks like the initial draft of such a BCP, which does not belong into a charter. -- CoAP will use CMS for object security. [...lost of more detail...] This again looks like prescribing the solution - are we sure we do understand that CMS is the right choice? Are we sure we understand how CMS object security maps to other protocols mentioned under 4) and that CoAP is supposed to interface to? Do we understand the overhead of CMS security for say a simple meter reading? It might be better to have a charter item to work on the security aspects and it might be good to have security area advisors involved in this from the very beginning. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From zach@sensinode.com Thu Nov 5 13:05:05 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375793A67EC for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 13:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fhjpBftKi1+w for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 13:05:04 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 103E83A67B0 for <6lowapp@ietf.org>; Thu, 5 Nov 2009 13:05:03 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA5L5JR7032741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Nov 2009 23:05:21 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <20091105163552.GA10440@elstar.local> Date: Thu, 5 Nov 2009 23:05:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BD6C5F2-4101-4E54-B3BE-E3E55596D191@sensinode.com> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> <20091105163552.GA10440@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1076) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:05:05 -0000 On Nov 5, 2009, at 18:35 , Juergen Schoenwaelder wrote: > -- > > I have not clue what this means: > > [...] For these benchmark cases, the > payload will be based on interface profile specific XML documents > compressed with EXI. > > Which benchmark cases is this text referring to? And why suddenly fix > a certain encoding? I agree, it should be removed. The EXI was mentioned there as a =20 benchmark for payload sizes (not to fix anything), but that doesn't =20 make sense either. I think the overhead goal should be more explicit =20 there instead of talking about benchmarks. Now it says "enabling a =20 50-70 byte payload".... considering what? I assume a 50-70 payload =20 after IEEE 802.15.4 + 6LoWPAN + UDP + CoAP without LoWPAN =20 fragmentation.... without security. Or should we just say CoAP should =20= aim at a header overhead of less than 10 bytes for simple cases =20 without security? Zach --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From zach@sensinode.com Thu Nov 5 13:23:29 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D8A3A68AB for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 13:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 F6BNvg6YIipG for <6lowapp@core3.amsl.com>; Thu, 5 Nov 2009 13:23:28 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 7405A3A682A for <6lowapp@ietf.org>; Thu, 5 Nov 2009 13:23:28 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nA5LNjPk000586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Nov 2009 23:23:46 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <3fe58b590911050803l352fc5e1idbd554ba10823868@mail.gmail.com> Date: Thu, 5 Nov 2009 23:23:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <550E719B-94BD-4CCE-8328-8AF02DE3EA96@sensinode.com> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> <3fe58b590911050803l352fc5e1idbd554ba10823868@mail.gmail.com> To: Kerry Lynn X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 21:23:30 -0000 On Nov 5, 2009, at 18:03 , Kerry Lynn wrote: > > There seems to be a wide divergence of opinion on the meaning of > "constrained", from full-on WS* to unable to contain any strings. I =20= > would > offer a working definition, borrowed from Einstein, that CoNodes =20 > should > be "as simple as possible, but no simpler." +1. We are trying to enable the minimal features required by the targeted =20= application domains, while integrating that with the web architecture =20= the best we can. So I like your saying. Let me add another - "keep it =20= simple, stupid". > > I believe that by moving as much functionality as possible from the > CoNodes into the CoGII nodes, we end up with a lower total system cost > and, ultimately, greater ubiquity. The definition of CoNode should =20 > admit > wired (e.g. power line connected) as well as wireless Devices. Coogies (CoGII) are not required at all in the charter (nor should =20 they be), in fact they are only necessary for interconnecting the CoAP =20= framework with HTTP or other possible paradigms. CoAP is meant to work =20= totally stand-alone between embedded devices, between devices and =20 servers etc. So the goal is to keep it really simple, as we can't =20 assume there is anywhere to move functionality to. Now that said, there are useful things CoNodes (I kindof like that) =20 may use a Coogie for, but those are performance improvements. For =20 example you may cache profiles there. > > As a general approach to foster consensus, I'd suggest the WG might > add to its "objectives and architecture" document a specification of > which services must be present in a CoNode and which must be > present in the CoGII node (and how the CoGII node differs from a > ROLL node; e.g. where does header de/compression reside?) Node speaking CoAP need to be totally autonomous, this is a must for =20 these application areas. Coogies provide proxying to HTTP, possible =20 caching for requests from the rest of the Internet etc. Coogies operate at L5, and can be located just about anywhere. Sure, =20 it may sometimes be running on the same device which operated as a =20 LoWPAN Edge Router and/or LLN Border Router. More likely it is placed =20= at the edge of the constrained domain, e.g. on the gateway router of =20 the building automation IP network, or the AMI infrastructure etc. Does that make sense from the charter? Ideas and making it more =20 specific? > > I support the viewpoint that a collection of CoNodes should be able to > implement some non-trivial applications without requiring a CoGII > node (e.g. the "one light, one switch" scenario). Others may disagree > with this (perhaps even strongly) but I believe statements of this =20 > sort > will help focus the debate and lead to the the ultimate meaning of > "constrained". > > I personally find it easier in the early stages to think in terms of =20= > abstract > services rather than specific protocols. For example, "BACnet =20 > relies on > the ability to enumerate all the devices on the network and to query =20= > the > value of objects within a device." The first is accomplished using =20= > the > "Who-is" or "Who-has" services (indeed, one might argue that having > two such mechanisms runs counter to interoperability) while the second > is accomplished using the "ReadProperty" service. If we can reach > consensus on which services we need then mapping to specific > implementations might be easier. Abstract services are what the charter is going after, we are not =20 specifying how the protocol itself is to be realized yet. > > Lastly, might I suggest using in the charter "CoNet" in place of =20 > "CNN"? I get a TV feeling from CNN myself.... So you are thinking CoNode and =20= CoNet? Zach > > Respectfully submitted, Kerry Lynn > > > On Thu, Nov 5, 2009 at 5:06 AM, Carsten Bormann wrote: >> I have put a new version of the WG charter proposal on the wiki =20 >> page at >> http://6lowapp.net >> =3D >> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp >> (charter text is at the end of the page). >> >> Obviously, I could not pick up every comment that was on the list =20 >> (they were >> partially going in conflicting directions), but please do comment =20 >> on the new >> version. >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From robert.cragie@gridmerge.com Fri Nov 6 06:25:25 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDFD13A683E for <6lowapp@core3.amsl.com>; Fri, 6 Nov 2009 06:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 j2h+JwIpFT-W for <6lowapp@core3.amsl.com>; Fri, 6 Nov 2009 06:25:24 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 8561D3A68F6 for <6lowapp@ietf.org>; Fri, 6 Nov 2009 06:25:23 -0800 (PST) Received: from client-82-13-28-168.brhm.adsl.virginmedia.com ([82.13.28.168] helo=[192.168.1.65]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) id 1N6Pl2-00052F-RQ; Fri, 06 Nov 2009 14:25:45 +0000 Message-ID: <4AF431E3.4010304@gridmerge.com> Date: Fri, 06 Nov 2009 14:25:39 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carsten Bormann References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> In-Reply-To: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010307090608010500090002" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 14:25:25 -0000 This is a cryptographically signed message in MIME format. --------------ms010307090608010500090002 Content-Type: multipart/alternative; boundary="------------010803070703050001060909" This is a multi-part message in MIME format. --------------010803070703050001060909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Some comments on the charter. * Generally, I like bullet points for clarity * Para 1 could do with a more bullet points. Suggested change: "Applications are being developed for networks where a substantial number of nodes: * Use very limited packet sizes * Have limited range * Exhibit a high degree of packet loss * Have restrictions on available power budget * May be powered off at any point in time but periodically "wake up" for brief periods of time * Have restrictions on the complexity that can be supported due to limited code size and limited RAM More generally, we speak of constrained-node/network (CNN) applications whenever at least some of the nodes and networks involved exhibit these characteristics. This WG is concentrating on requirements from energy (e.g. Smart Energy 2.0) and building management applications." * +1 for CoNet * +1 for CoNode. The idea of a "CoNode" makes more sense than a CoNet. It is possible to imagine a CoNet with nodes which don't have all the properties of a CoNode and thus could communicate using a different application protocol, i.e. one more familiar to the wider Internet (e.g. WS-*, HTTP REST). Do we only want to consider a CoNet containining CoNodes? If so, these non-CoNodes are probably out of scope of the discussion. * Para 2: "are becoming increasing important" -> "are becoming increasingly important" * Para 2: "a framework a limited class of applications" -> "a framework for a limited class of applications" * Para 3 could do with more bullet points. Suggested change: "The general architecture consists of nodes on the CNN, called Devices, that have one or more Resources that may represent sensors and actuators or other parameters. * Devices send messages to change Resources on other Devices * Devices send messages to query Resources on other Devices * Devices can send notifications about changed Resource values to subscribed Devices. In other words, the architecture requires push, pull and a notify approach to manipulating Resources. As part of the framework for building these applications, the WG will define a Constrained-node/network Application Protocol (CoAP) for manipulation of Resources on Devices. The framework will also specify a way to define new interface profiles that can be defined by vendors and other standards bodies to define the particular Resources on a Device and what manipulation is possible." * Should Device be CoDevice (i.e. CoNode + application functionality)? * "CoAP will be designed to be used between Devices (intra- or inter-CNN) as well as between Devices and general nodes on the Internet.". This suggests that we are defining an application protocol which would be suited to the wider Internet. However, then there is the introduction of the CoGII. This brings me back to my earlier post regarding intersection - are we trying to achieve this? Or is the CoAP really aimed at CoNodes only? In this case, the description as is of the CoGII is about right, i.e. an application layer gateway. * If we are considering a CoNet with CoNodes and non-CoNodes, there could also be a more general router between the non-CoNodes and the wider Internet using a different application protocol (e.g. WS-*, HTTP REST) * I agree with other comments re. specifiying EXI - not necessary for the purposes of the charter. State the requirement and in development state that EXI would meet the requirement * I think if you have the notion of the CoGII you can really come up with any binding you want so whilst I think HTTP REST may be the most important, others should become second-class citizens at this stage. * Commissioning methodologies. Whilst important, the suggestions seem to me too specific * Duckling mode general procedure is quite specific but the details are vague. Imprinting a shared secret seems like some sort of magic the way it is described * Out-of-band key mode. Too specific with regard to barcodes/URLs. There are many ways to set up a shared secret out-of-band * Certificate mode. Again, too specific with regard to barcodes and certificate replacement. Other issues need to be considered with certificates too (authentication, revocation etc.) * "In all modes, once Device A and Device B have formed a secure connection with Device C, Device C can be used to transitively introduce A and B so now A and B have a secure connection with C." I don't quite get this statement - should it say "so now A and B have a secure connection with each other"? * The use of a heavyweight syntax such as CMS (rfc5652) seems at odds with the aims of CoAP. In conjunction with a CoGII, there may be no need for such protection - symmetric key frame protection such as AES-CCM may well suffice. In summary, my main question is: Do we want to limit the CoNet to just CoNodes and a (optional) CoGII? Is it enough to acknowledge that there will be another non-CoNode application protocol, which is suitable for some nodes in, say, 6LoWPAN, i.e. those with enough horsepower, power budget, link reliability to be able to natively handle RESTful HTTP/TCP? Robert Carsten Bormann wrote: > I have put a new version of the WG charter proposal on the wiki page at > http://6lowapp.net > = > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > (charter text is at the end of the page). > > Obviously, I could not pick up every comment that was on the list > (they were partially going in conflicting directions), but please do > comment on the new version. > > Gruesse, Carsten > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --------------010803070703050001060909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Some comments on the charter.
  • Generally, I like bullet points for clarity
  • Para 1 could do with a more bullet points. Suggested change:
"Applications are being developed for networks where a substantial number of nodes:

* Use very limited packet sizes
* Have limited range
* Exhibit a high degree of packet loss
* Have restrictions on available power budget
* May be powered off at any point in time but periodically "wake up" for brief periods of time
* Have restrictions on the complexity that can be supported due to limited code size and limited RAM

More generally, we speak of constrained-node/network (CNN) applications whenever at least some of the nodes and networks involved exhibit these characteristics.  This WG is concentrating on requirements from energy (e.g. Smart Energy 2.0) and building management applications."
  • +1 for CoNet
  • +1 for CoNode. The idea of a "CoNode" makes more sense than a CoNet. It is possible to imagine a CoNet with nodes which don't have all the properties of a CoNode and thus could communicate using a different application protocol, i.e. one more familiar to the wider Internet (e.g. WS-*, HTTP REST). Do we only want to consider a CoNet containining CoNodes? If so, these non-CoNodes are probably out of scope of the discussion.
  • Para 2: "are becoming increasing important" -> "are becoming increasingly important"
  • Para 2: "a framework a limited class of applications" -> "a framework for a limited class of applications"
  • Para 3 could do with more bullet points. Suggested change:
"The general architecture consists of nodes on the CNN, called Devices, that have one or more Resources that may represent sensors and actuators or other parameters.

* Devices send messages to change Resources on other Devices
* Devices send messages to query Resources on other Devices
* Devices can send notifications about changed Resource values to subscribed Devices.

In other words, the architecture requires push, pull and a notify approach to manipulating Resources.

As part of the framework for building these applications, the WG will define a Constrained-node/network Application Protocol (CoAP) for manipulation of Resources on Devices. The framework will also specify a way to define new interface profiles that can be defined by vendors and other standards bodies to define the particular Resources on a Device and what manipulation is possible."
  • Should Device be CoDevice (i.e. CoNode + application functionality)?
  • "CoAP will be designed to be used between Devices (intra- or inter-CNN) as well as between Devices and general nodes on the Internet.". This suggests that we are defining an application protocol which would be suited to the wider Internet. However, then there is the introduction of the CoGII. This brings me back to my earlier post regarding intersection - are we trying to achieve this? Or is the CoAP really aimed at CoNodes only? In this case, the description as is of the CoGII is about right, i.e. an application layer gateway.
  • If we are considering a CoNet with CoNodes and non-CoNodes, there could also be a more general router between the non-CoNodes and the wider Internet using a different application protocol (e.g. WS-*, HTTP REST)
  • I agree with other comments re. specifiying EXI - not necessary for the purposes of the charter. State the requirement and in development state that EXI would meet the requirement
  • I think if you have the notion of the CoGII you can really come up with any binding you want so whilst I think HTTP REST may be the most important, others should become second-class citizens at this stage.
  • Commissioning methodologies. Whilst important, the suggestions seem to me too specific
  • Duckling mode general procedure is quite specific but the details are vague. Imprinting a shared secret seems like some sort of magic the way it is described
  • Out-of-band key mode. Too specific with regard to barcodes/URLs. There are many ways to set up a shared secret out-of-band
  • Certificate mode. Again, too specific with regard to barcodes and certificate replacement. Other issues need to be considered with certificates too (authentication, revocation etc.)
  • "In all modes, once Device A and Device B have formed a secure connection with Device C, Device C can be used to transitively introduce A and B so now A and B have a secure connection with C." I don't quite get this statement - should it say "so now A and B have a secure connection with each other"?
  • The use of a heavyweight syntax such as CMS (rfc5652) seems at odds with the aims of CoAP. In conjunction with a CoGII, there may be no need for such protection - symmetric key frame protection such as AES-CCM may well suffice.
In summary, my main question is: Do we want to limit the CoNet to just CoNodes and a (optional) CoGII? Is it enough to acknowledge that there will be another non-CoNode application protocol, which is suitable for some nodes in, say, 6LoWPAN, i.e. those with enough horsepower, power budget, link reliability to be able to natively handle RESTful HTTP/TCP?

Robert

Carsten Bormann wrote:
I have put a new version of the WG charter proposal on the wiki page at
http://6lowapp.net
=
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
(charter text is at the end of the page).

Obviously, I could not pick up every comment that was on the list (they were partially going in conflicting directions), but please do comment on the new version.

Gruesse, Carsten

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

--------------010803070703050001060909-- --------------ms010307090608010500090002 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEx MDYxNDI1MzlaMCMGCSqGSIb3DQEJBDEWBBSa6d0vx9GJwHIU/jtZCHP0KijCajBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBALLphGZ/yZrlJMk+a9MamQCstQguL8xRfyvThZgjFDkmcmf8JeZ4OGAvG0/We2EO75+H NDZdM7o9HJP4ik5SvUdQ5tyFNqScG+Ni4M0WrHZ2dVfHvUyqV8z+U7ckG0k/6oNJtoaHr7q6 GS2Ks+5fJ6Cd9Nm0YWnXfdMSNmoS+fjpnm3WgYv3GKxnIFZUSs9FtK+wpRDE0OyPiiKvP1/l 91E6Z+yGFnur2JYh7QJLT+y4KjLABrTNUU0csby702roxh4HHgiui/rxWJIPAIB0I3Rkbh9O caAmygOxNTWqTxT/H6vkWxrmuJpwPJovRrcsf+Um0+vLngviPrHYIPEf2WEAAAAAAAA= --------------ms010307090608010500090002-- From kkim86@gmail.com Fri Nov 6 17:19:57 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6409E3A6902 for <6lowapp@core3.amsl.com>; Fri, 6 Nov 2009 17:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 RXdbaoKn5Tgj for <6lowapp@core3.amsl.com>; Fri, 6 Nov 2009 17:19:56 -0800 (PST) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 6FE863A6767 for <6lowapp@ietf.org>; Fri, 6 Nov 2009 17:19:56 -0800 (PST) Received: by pxi1 with SMTP id 1so1180604pxi.32 for <6lowapp@ietf.org>; Fri, 06 Nov 2009 17:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type; bh=oB4xtXByTv4sPeu7ovLivbuKoLGKZvUHLNZ+pOe74rc=; b=pMxVdjfmWlwyo3i7he8eAmSfUSYpPskVwqVNNuH7GydovWj+QmVzRiNAcWgS9xOEUo uP6GnaK4U3SEjIHwpkzCytY8knsbu2nF/IjHvakXWXqD4rHB9tYmdV8sclgFP/ooBMDT jLwvKvt5oa6z5tLB+gmE36XporfQabhG+a+LY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=qpUvJYBeCiw8mq5gJMfJ3BEU/gK+Rlg80/KX7xu3LYdJQ1kzlTDFU1r67g6C6tcd6u +dtUIsNAznbUw27DNtshmwzqdSii1g4bxjehancC0oIuk0eqAkl+mbpdSMHiQccO4q/s RquLiLXcYSMGbpoxtxxCpb4OfosA3TBB8UzRU= MIME-Version: 1.0 Received: by 10.114.237.19 with SMTP id k19mr7531064wah.69.1257556820332; Fri, 06 Nov 2009 17:20:20 -0800 (PST) In-Reply-To: References: <20091026171847.2956D28C0FA@core3.amsl.com> From: =?UTF-8?B?S2ktSHl1bmcgS2ltICjquYDquLDtmJUp?= Date: Sat, 7 Nov 2009 10:20:00 +0900 Message-ID: To: 6lowapp <6lowapp@ietf.org> Content-Type: multipart/alternative; boundary=0016e64c2cea8f91db0477bdc31a Subject: [6lowapp] Fwd: New Version Notification for draft-daniel-6lowpan-sslp-02 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2009 01:19:57 -0000 --0016e64c2cea8f91db0477bdc31a Content-Type: text/plain; charset=ISO-8859-1 Forwarding again because of the bounce of the mailing list. ---------- Forwarded message ---------- From: Ki-Hyung Kim Date: 2009/11/7 Subject: Fwd: New Version Notification for draft-daniel-6lowpan-sslp-02 To: 6lowpan@ietf.org, 6lowapp@ietf.org Cc: Zach Shelby , Carsten Hi all, We have updated the I-D "Simple Service Location Protocol (SSLP) for 6LoWPAN" (http://tools.ietf.org/html/draft-daniel-6lowpan-sslp-02 ). The new version covers how to include binary XML in the simplified SLP (SSLP) for 6lowpan. Any reviews or comments are appreciated. Thanks, __ Ki-Hyung Kim Professor, Ajou University, Korea, http://ilab.ajou.ac.kr Tel: +82-31-219-2433, Cel: +82-10-4760-2551 ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Oct 27, 2009 at 02:18 Subject: New Version Notification for draft-daniel-6lowpan-sslp-02 To: waleedbaig@ajou.ac.kr Cc: soohong.park@samsung.com, swyoo@ajou.ac.kr, kkim86@ajou.ac.kr, hamid@etri.re.kr A new version of I-D, draft-daniel-6lowpan-sslp-02.txt has been successfuly submitted by Waleed Baig and posted to the IETF repository. Filename: draft-daniel-6lowpan-sslp Revision: 02 Title: Simple Service Location Protocol (SSLP) for 6LoWPAN Creation_date: 2009-10-26 WG ID: Independent Submission Number_of_pages: 15 Abstract: The Simple Service Location Protocol (SSLP) provides a framework for the discovery and selection of the services working on 6LoWPAN. The protocol has a simple structure that is easy to be implemented on 6LoWPAN devices that are characterized by short range, low bit rate and low power. The protocol also offers a mechanism for interoperability with the IP networks under SLP. It enables communication between 6LoWPAN and other IP networks. The IETF Secretariat. --0016e64c2cea8f91db0477bdc31a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Forwarding again because of the bounce of the ma= iling list.

---------- Forwarded message ----------
From: Ki-Hyung Kim <kkim86@gmail.com>
Date: 2009/11/7
Subject: Fwd: New Version Notification for draft-daniel-= 6lowpan-sslp-02
To: 6lowpan@ietf.org= , 6lowapp@ietf.org
Cc: Zach = Shelby <zach@sensinode.com>= , Carsten <cabo@tzi.org>


Hi all,
=A0
We have updated the= I-D=A0"Simple Service Location Protocol (SSLP) for 6LoWPAN&quo= t; (http://tools.ietf.org/html/draft-daniel-6lowpan-sslp-02= =A0).=A0The new version covers how to include binary XML in the simplified = SLP (SSLP) for 6lowpan.

Any reviews or comments are appreciated.
=A0
Thanks,<= /div>

__
Ki-Hyung Kim
Professor, Ajo= u University, Korea, =A0http://ilab.ajou.ac.kr =A0
Tel: +82-31-219-2433, Cel: +82-10-4760-2551



---------- Forwarded message ----------<= br>From: IETF I-D Submission Tool <i= dsubmission@ietf.org>
Date: Tue, Oct 27, 2009 at 02:18
Subject: New Version Notification for d= raft-daniel-6lowpan-sslp-02
To: waleedbaig@ajou.ac.kr
Cc: soohong.park@samsung.com, swyoo@ajou.ac.kr, kkim86@ajou.ac.kr, hamid@etri.re.kr


A new version of I-D, draft-daniel-6lowpan-sslp-02.txt has been successfuly= submitted by Waleed Baig and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-daniel-6lowpan-sslp
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Simple Service Location Protocol (SSLP) for 6LoW= PAN
Creation_date: =A0 2009-10-26
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 15

Abstract:
The Simple Service Location Protocol (SSLP) provides a framework for
the discovery and selection of the services working on 6LoWPAN. =A0The
protocol has a simple structure that is easy to be implemented on
6LoWPAN devices that are characterized by short range, low bit rate
and low power. =A0The protocol also offers a mechanism for
interoperability with the IP networks under SLP. =A0It enables
communication between 6LoWPAN and other IP networks.



The IETF Secretariat.






--0016e64c2cea8f91db0477bdc31a-- From cabo@tzi.org Sun Nov 8 17:51:08 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6173A68DB for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 17:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 w3ED0AfVXfR4 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 17:51:07 -0800 (PST) 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 C9E013A67F3 for <6lowapp@ietf.org>; Sun, 8 Nov 2009 17:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nA91pN3V014646 for <6lowapp@ietf.org>; Mon, 9 Nov 2009 02:51:23 +0100 (CET) Received: from host-24-126.meeting.ietf.org (host-24-126.meeting.ietf.org [133.93.24.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 34E97B29F; Mon, 9 Nov 2009 02:51:21 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 9 Nov 2009 10:51:16 +0900 To: 6lowapp@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [6lowapp] BOF 1300-1500 today, slides uploaded X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 01:51:08 -0000 I have uploaded the slideset for the BOF today, see: http://www.ietf.org/proceedings/09nov/slides/6lowapp-0.pdf See you at 1300 in Acacia West. Gruesse, Carsten From bclaise@cisco.com Sun Nov 8 18:23:46 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84CF528C0E1 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 18:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139, 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 8kbcYgTdOHVV for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 18:23:45 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 0CC6228C0E0 for <6lowapp@ietf.org>; Sun, 8 Nov 2009 18:23:44 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA92KOQ3018674; Mon, 9 Nov 2009 03:20:24 +0100 (CET) Received: from [10.70.230.161] (tky-vpn-client-230-161.cisco.com [10.70.230.161]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA92KMNS013686; Mon, 9 Nov 2009 03:20:23 +0100 (CET) Message-ID: <4AF77C65.3050309@cisco.com> Date: Mon, 09 Nov 2009 03:20:21 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Carsten Bormann References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> In-Reply-To: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> Content-Type: multipart/alternative; boundary="------------090201080101060006020809" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:23:46 -0000 This is a multi-part message in MIME format. --------------090201080101060006020809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Carsten, Thanks for the new charter proposal. - "This WG is concentrating on requirements from energy (e.g. Smart Energy 2.0) and building management applications." Is the goal to describe these requirements in the "objectives and architecture" document? If not, where can we understand those requirements from? The following were mentioned on the list: There are a lot of use cases to start with. Here is a starter set: 1) OpenHAN: http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-%20v1.04%20-%200808 19-1.pdf 2) SmartGridipedia: http://www.smartgridipedia.org/index.php/Category:Use_Cases, both the Intelligrid and Southern California Edison use cases are good 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are using for our Smart Energy V2 work): http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf Any other ones? "The framework will also specify specify a way to support interface profiles, ..." Can you expand on "interface profile". "A document with operation and management advice about running a network using these applications." Is advice the right word? It seems like one or two advices are sufficient to manage the network ;-) Regards, Benoit. > I have put a new version of the WG charter proposal on the wiki page at > http://6lowapp.net > = > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > (charter text is at the end of the page). > > Obviously, I could not pick up every comment that was on the list > (they were partially going in conflicting directions), but please do > comment on the new version. > > Gruesse, Carsten > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --------------090201080101060006020809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Carsten,

Thanks for the new charter proposal. 

- "This WG is concentrating on requirements from energy (e.g. Smart Energy 2.0) and building management applications."
Is the goal to describe these requirements in the "objectives and architecture" document?
If not, where can we understand those requirements from? 
The following were mentioned on the list:

There are a lot of use cases to start with.  Here is a starter set:
1)  OpenHAN:
http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-%20v1.04%20-%200808
19-1.pdf
2)  SmartGridipedia:
http://www.smartgridipedia.org/index.php/Category:Use_Cases, both the
Intelligrid and Southern California Edison use cases are good
3)  ZigBee/HomePlug Market Requirements and Use Cases (which we are using
for our Smart Energy V2 work):
http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf 
Any other ones?

"The framework will also specify specify a way to support interface profiles, ..."
Can you expand on "interface profile".


"A document with operation and management advice about running a network using these applications."
Is advice the right word? It seems like one or two advices are sufficient to manage the network ;-)
Regards, Benoit.
I have put a new version of the WG charter proposal on the wiki page at
http://6lowapp.net
=
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
(charter text is at the end of the page).

Obviously, I could not pick up every comment that was on the list (they were partially going in conflicting directions), but please do comment on the new version.

Gruesse, Carsten

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

--------------090201080101060006020809-- From hgs@cs.columbia.edu Sun Nov 8 18:32:30 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC003A68EE for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 18:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LsXzdpccE969 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 18:32:29 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 9FABF3A68DB for <6lowapp@ietf.org>; Sun, 8 Nov 2009 18:32:29 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA92WpUN012173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Nov 2009 21:32:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne In-Reply-To: <4AF77C65.3050309@cisco.com> Date: Sun, 8 Nov 2009 21:32:51 -0500 Content-Transfer-Encoding: 7bit Message-Id: <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> <4AF77C65.3050309@cisco.com> To: Benoit Claise X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:32:30 -0000 I find this conflation of Smart Energy/HAN and LowApp confusing. Most of the in-home networks are not exactly "challenged". Even ZigBee has 250 kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to early DSL or 1990's modems. Henning On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: > Carsten, > > Thanks for the new charter proposal. > > - "This WG is concentrating on requirements from energy (e.g. Smart > Energy 2.0) and building management applications." > Is the goal to describe these requirements in the "objectives and > architecture" document? > If not, where can we understand those requirements from? > The following were mentioned on the list: > > There are a lot of use cases to start with. Here is a starter set: > 1) OpenHAN: > > http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-%20v1.04%20-%200808 > > 19-1.pdf > 2) SmartGridipedia: > > http://www.smartgridipedia.org/index.php/Category:Use_Cases > , both the > Intelligrid and Southern California Edison use cases are good > 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are > using > for our Smart Energy V2 work): > > http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf > Any other ones? > > "The framework will also specify specify a way to support interface > profiles, ..." > Can you expand on "interface profile". > > > "A document with operation and management advice about running a > network using these applications." > Is advice the right word? It seems like one or two advices are > sufficient to manage the network ;-) > > > Regards, Benoit. >> I have put a new version of the WG charter proposal on the wiki >> page at >> http://6lowapp.net >> = >> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp >> (charter text is at the end of the page). >> >> Obviously, I could not pick up every comment that was on the list >> (they were partially going in conflicting directions), but please >> do comment on the new version. >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From Michael.Stuber@itron.com Sun Nov 8 19:18:01 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37013A6767 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 19:18:01 -0800 (PST) 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 A9igcVB7LmXB for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 19:18:00 -0800 (PST) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id AC2A53A6A61 for <6lowapp@ietf.org>; Sun, 8 Nov 2009 19:18:00 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2009 19:18:26 -0800 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com> In-Reply-To: <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Next version of charter proposal up on 6lowapp.net Thread-Index: Acpg5QFKry80nBCHSkqE7hITtDKSlQABbIWA References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org><4AF77C65.3050309@cisco.com> <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> From: "Stuber, Michael" To: "Henning Schulzrinne" , "Benoit Claise" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:18:01 -0000 Keep in mind though, that much of that bandwidth is shared on these networks In an 802.15.4 environment, devices will share a single channel. If this work is successful there will be many constrained nodes within the network, rather than a single pair of nodes. -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, November 08, 2009 6:33 PM To: Benoit Claise Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net I find this conflation of Smart Energy/HAN and LowApp confusing. Most of the in-home networks are not exactly "challenged". Even ZigBee has 250 kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to early DSL or 1990's modems. Henning On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: > Carsten, > > Thanks for the new charter proposal. > > - "This WG is concentrating on requirements from energy (e.g. Smart=20 > Energy 2.0) and building management applications." > Is the goal to describe these requirements in the "objectives and=20 > architecture" document? > If not, where can we understand those requirements from? > The following were mentioned on the list: > > There are a lot of use cases to start with. Here is a starter set: > 1) OpenHAN: > > http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-%20v1.04%20-% > 200808 > > 19-1.pdf > 2) SmartGridipedia: > > http://www.smartgridipedia.org/index.php/Category:Use_Cases > , both the > Intelligrid and Southern California Edison use cases are good > 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are=20 > using for our Smart Energy V2 work): > > http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf > Any other ones? > > "The framework will also specify specify a way to support interface=20 > profiles, ..." > Can you expand on "interface profile". > > > "A document with operation and management advice about running a=20 > network using these applications." > Is advice the right word? It seems like one or two advices are=20 > sufficient to manage the network ;-) > > > Regards, Benoit. >> I have put a new version of the WG charter proposal on the wiki =20 >> page at >> http://6lowapp.net >> =3D >> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp >> (charter text is at the end of the page). >> >> Obviously, I could not pick up every comment that was on the list =20 >> (they were partially going in conflicting directions), but please =20 >> do comment on the new version. >> >> Gruesse, Carsten >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From hgs@cs.columbia.edu Sun Nov 8 19:24:45 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C89D28C0E4 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 19:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 OVDQMYK-Vmsg for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 19:24:44 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 11A0828C0E1 for <6lowapp@ietf.org>; Sun, 8 Nov 2009 19:24:43 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nA93P7a3019633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Nov 2009 22:25:08 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com> Date: Sun, 8 Nov 2009 22:25:07 -0500 Content-Transfer-Encoding: 7bit Message-Id: <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org><4AF77C65.3050309@cisco.com> <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com> To: "Stuber, Michael" X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:24:45 -0000 Right, but the bandwidth per device is really, really low. How many bits do you send each day to a thermostat or light switch? Are there any measurements of the realistic signaling load in such networks? I'm worried about artificially constraining the solution space to solve a practical non-problem. Henning On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: > Keep in mind though, that much of that bandwidth is shared on these > networks In an 802.15.4 environment, devices will share a single > channel. If this work is successful there will be many constrained > nodes within the network, rather than a single pair of nodes. > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf Of Henning Schulzrinne > Sent: Sunday, November 08, 2009 6:33 PM > To: Benoit Claise > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Next version of charter proposal up on > 6lowapp.net > > I find this conflation of Smart Energy/HAN and LowApp confusing. > Most of > the in-home networks are not exactly "challenged". Even ZigBee has 250 > kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to > early DSL or 1990's modems. > > Henning > > On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: > >> Carsten, >> >> Thanks for the new charter proposal. >> >> - "This WG is concentrating on requirements from energy (e.g. Smart >> Energy 2.0) and building management applications." >> Is the goal to describe these requirements in the "objectives and >> architecture" document? >> If not, where can we understand those requirements from? >> The following were mentioned on the list: >> >> There are a lot of use cases to start with. Here is a starter set: >> 1) OpenHAN: >> >> http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- >> %20v1.04%20-% >> 200808 >> >> 19-1.pdf >> 2) SmartGridipedia: >> >> http://www.smartgridipedia.org/index.php/Category:Use_Cases >> , both the >> Intelligrid and Southern California Edison use cases are good >> 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are >> using for our Smart Energy V2 work): >> >> http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf >> Any other ones? >> >> "The framework will also specify specify a way to support interface >> profiles, ..." >> Can you expand on "interface profile". >> >> >> "A document with operation and management advice about running a >> network using these applications." >> Is advice the right word? It seems like one or two advices are >> sufficient to manage the network ;-) >> >> >> Regards, Benoit. >>> I have put a new version of the WG charter proposal on the wiki >>> page at >>> http://6lowapp.net >>> = >>> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp >>> (charter text is at the end of the page). >>> >>> Obviously, I could not pick up every comment that was on the list >>> (they were partially going in conflicting directions), but please >>> do comment on the new version. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From Michael.Stuber@itron.com Sun Nov 8 19:48:20 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E9D3A6924 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 19:48:20 -0800 (PST) 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 uVJ1s7avr-FF for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 19:48:19 -0800 (PST) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 140733A691E for <6lowapp@ietf.org>; Sun, 8 Nov 2009 19:48:19 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Nov 2009 19:48:44 -0800 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> In-Reply-To: <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] Next version of charter proposal up on 6lowapp.net Thread-Index: Acpg7EHSqCwYTL9MRde0iQ+w34l5bQAAjpmQ References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org><4AF77C65.3050309@cisco.com> <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com> <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> From: "Stuber, Michael" To: "Henning Schulzrinne" Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:48:20 -0000 The amount of bandwidth required per applications varies a great deal. Some devices, like light switches, or battery powered sensors may only send a message or two per day. Other devices such as energy usage monitors or electric vehicles may send a large number of updates. Electric meters may send current usage information to in-home displays every 10 seconds. Electric cars may start with an extended exchange to negotiate a charging regime, followed by periodic updates to in-home displays regarding the device's state of charge. Most of the networks that I worry about are indeed likely to be small (>30 nodes); however, there are places where folks have been running larger smart energy networks for meter data collection that are upwards of thousands of nodes. The 802.15.4 T4G SUN work is likely to expand this trend. Starting with efficient protocols provides headroom for growth in the application later. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Sunday, November 08, 2009 7:25 PM To: Stuber, Michael Cc: Benoit Claise; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net Right, but the bandwidth per device is really, really low. How many bits do you send each day to a thermostat or light switch? Are there any measurements of the realistic signaling load in such networks? I'm worried about artificially constraining the solution space to solve a practical non-problem. Henning On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: > Keep in mind though, that much of that bandwidth is shared on these=20 > networks In an 802.15.4 environment, devices will share a single=20 > channel. If this work is successful there will be many constrained=20 > nodes within the network, rather than a single pair of nodes. > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On=20 > Behalf Of Henning Schulzrinne > Sent: Sunday, November 08, 2009 6:33 PM > To: Benoit Claise > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Next version of charter proposal up on=20 > 6lowapp.net > > I find this conflation of Smart Energy/HAN and LowApp confusing. =20 > Most of > the in-home networks are not exactly "challenged". Even ZigBee has 250 > kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to=20 > early DSL or 1990's modems. > > Henning > > On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: > >> Carsten, >> >> Thanks for the new charter proposal. >> >> - "This WG is concentrating on requirements from energy (e.g. Smart=20 >> Energy 2.0) and building management applications." >> Is the goal to describe these requirements in the "objectives and=20 >> architecture" document? >> If not, where can we understand those requirements from? >> The following were mentioned on the list: >> >> There are a lot of use cases to start with. Here is a starter set: >> 1) OpenHAN: >> >> http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- >> %20v1.04%20-% >> 200808 >> >> 19-1.pdf >> 2) SmartGridipedia: >> >> http://www.smartgridipedia.org/index.php/Category:Use_Cases >> , both the >> Intelligrid and Southern California Edison use cases are good >> 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are=20 >> using for our Smart Energy V2 work): >> >> http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf >> Any other ones? >> >> "The framework will also specify specify a way to support interface=20 >> profiles, ..." >> Can you expand on "interface profile". >> >> >> "A document with operation and management advice about running a=20 >> network using these applications." >> Is advice the right word? It seems like one or two advices are=20 >> sufficient to manage the network ;-) >> >> >> Regards, Benoit. >>> I have put a new version of the WG charter proposal on the wiki page >>> at http://6lowapp.net =3D=20 >>> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp >>> (charter text is at the end of the page). >>> >>> Obviously, I could not pick up every comment that was on the list=20 >>> (they were partially going in conflicting directions), but please do >>> comment on the new version. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From peter.van.der.stok@philips.com Sun Nov 8 22:21:28 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AEAE3A6906 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 22:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 rRmbrTFtHSeT for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 22:21:26 -0800 (PST) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.20]) by core3.amsl.com (Postfix) with ESMTP id F12503A6867 for <6lowapp@ietf.org>; Sun, 8 Nov 2009 22:21:24 -0800 (PST) Received: from NLAMSEXH05.connect1.local (172.16.153.68) by connect1.philips.com (172.16.156.49) with Microsoft SMTP Server (TLS) id 8.1.393.1; Mon, 9 Nov 2009 07:21:55 +0100 Received: from NLCLUEXM03.connect1.local ([172.16.157.42]) by NLAMSEXH05.connect1.local ([172.16.153.68]) with mapi; Mon, 9 Nov 2009 07:21:46 +0100 From: "Van Der Stok, Peter" To: "Stuber, Michael" , Henning Schulzrinne Date: Mon, 9 Nov 2009 07:21:42 +0100 Thread-Topic: [6lowapp] Next version of charter proposal up on 6lowapp.net Thread-Index: Acpg7EHSqCwYTL9MRde0iQ+w34l5bQAAjpmQAAV5s1A= Message-ID: References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org><4AF77C65.3050309@ cisco.com><517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu><05C6A38D73 2F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com><7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 06:21:28 -0000 Although I agree with the not challenged statement, a few updates: I expect a presence detector to send out a message once per second or per 1= 0 seconds There may be 1 till 100 in one wireless mesh, dependent on office lay-out. The crux comes when an alarm hits. Then we will have an avalanche of messag= es and some can be just thrown away and a few need to be sent on through th= e routers to some central post(s)regardless. There is the challenge of over= load handling. Peter -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf = Of Stuber, Michael Sent: Monday 9 November 2009 4:49 To: Henning Schulzrinne Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net The amount of bandwidth required per applications varies a great deal. Some devices, like light switches, or battery powered sensors may only send a message or two per day. Other devices such as energy usage monitors or electric vehicles may send a large number of updates. Electric meters may send current usage information to in-home displays every 10 seconds. Electric cars may start with an extended exchange to negotiate a charging regime, followed by periodic updates to in-home displays regarding the device's state of charge. Most of the networks that I worry about are indeed likely to be small (>30 nodes); however, there are places where folks have been running larger smart energy networks for meter data collection that are upwards of thousands of nodes. The 802.15.4 T4G SUN work is likely to expand this trend. Starting with efficient protocols provides headroom for growth in the application later. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, November 08, 2009 7:25 PM To: Stuber, Michael Cc: Benoit Claise; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net Right, but the bandwidth per device is really, really low. How many bits do you send each day to a thermostat or light switch? Are there any measurements of the realistic signaling load in such networks? I'm worried about artificially constraining the solution space to solve a practical non-problem. Henning On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: > Keep in mind though, that much of that bandwidth is shared on these > networks In an 802.15.4 environment, devices will share a single > channel. If this work is successful there will be many constrained > nodes within the network, rather than a single pair of nodes. > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On > Behalf Of Henning Schulzrinne > Sent: Sunday, November 08, 2009 6:33 PM > To: Benoit Claise > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Next version of charter proposal up on > 6lowapp.net > > I find this conflation of Smart Energy/HAN and LowApp confusing. > Most of > the in-home networks are not exactly "challenged". Even ZigBee has 250 > kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to > early DSL or 1990's modems. > > Henning > > On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: > >> Carsten, >> >> Thanks for the new charter proposal. >> >> - "This WG is concentrating on requirements from energy (e.g. Smart >> Energy 2.0) and building management applications." >> Is the goal to describe these requirements in the "objectives and >> architecture" document? >> If not, where can we understand those requirements from? >> The following were mentioned on the list: >> >> There are a lot of use cases to start with. Here is a starter set: >> 1) OpenHAN: >> >> http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- >> %20v1.04%20-% >> 200808 >> >> 19-1.pdf >> 2) SmartGridipedia: >> >> http://www.smartgridipedia.org/index.php/Category:Use_Cases >> , both the >> Intelligrid and Southern California Edison use cases are good >> 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are >> using for our Smart Energy V2 work): >> >> http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf >> Any other ones? >> >> "The framework will also specify specify a way to support interface >> profiles, ..." >> Can you expand on "interface profile". >> >> >> "A document with operation and management advice about running a >> network using these applications." >> Is advice the right word? It seems like one or two advices are >> sufficient to manage the network ;-) >> >> >> Regards, Benoit. >>> I have put a new version of the WG charter proposal on the wiki page >>> at http://6lowapp.net =3D >>> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp >>> (charter text is at the end of the page). >>> >>> Obviously, I could not pick up every comment that was on the list >>> (they were partially going in conflicting directions), but please do >>> comment on the new version. >>> >>> Gruesse, Carsten >>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From bclaise@cisco.com Sun Nov 8 23:15:19 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBCF3A692F for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 23:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, 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 ptgmlB7bFvJ5 for <6lowapp@core3.amsl.com>; Sun, 8 Nov 2009 23:15:17 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 7D2C83A6920 for <6lowapp@ietf.org>; Sun, 8 Nov 2009 23:15:17 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA97FY9x003266; Mon, 9 Nov 2009 08:15:34 +0100 (CET) Received: from [10.70.231.89] (tky-vpn-client-231-89.cisco.com [10.70.231.89]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id nA97FSJ3010804; Mon, 9 Nov 2009 08:15:29 +0100 (CET) Message-ID: <4AF7C18F.5030107@cisco.com> Date: Mon, 09 Nov 2009 08:15:27 +0100 From: Benoit Claise User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Van Der Stok, Peter" References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org><4AF77C65.3050309@ cisco.com><517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu><05C6A38D73 2F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com><7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070608050607000707020509" Cc: "Stuber, Michael" , "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 07:15:19 -0000 This is a multi-part message in MIME format. --------------070608050607000707020509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From the requirement/use case remark in my initial email, I wanted to understand: how many constrained nodes in a single constrained network must share the 250kbit/s? For example, in case of discovery, concurrent events, concurrent queries, etc. IMHO, this is an important input for the protocol design, which I didn't get from the BOF. Regards, Benoit. > Although I agree with the not challenged statement, a few updates: > I expect a presence detector to send out a message once per second or per 10 seconds > There may be 1 till 100 in one wireless mesh, dependent on office lay-out. > The crux comes when an alarm hits. Then we will have an avalanche of messages and some can be just thrown away and a few need to be sent on through the routers to some central post(s)regardless. There is the challenge of overload handling. > > Peter > > > -----Original Message----- > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Stuber, Michael > Sent: Monday 9 November 2009 4:49 > To: Henning Schulzrinne > Cc: 6lowapp@ietf.org > Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net > > The amount of bandwidth required per applications varies a great deal. > Some devices, like light switches, or battery powered sensors may only > send a message or two per day. Other devices such as energy usage > monitors or electric vehicles may send a large number of updates. > Electric meters may send current usage information to in-home displays > every 10 seconds. Electric cars may start with an extended exchange to > negotiate a charging regime, followed by periodic updates to in-home > displays regarding the device's state of charge. > > Most of the networks that I worry about are indeed likely to be small > (>30 nodes); however, there are places where folks have been running > larger smart energy networks for meter data collection that are upwards > of thousands of nodes. The 802.15.4 T4G SUN work is likely to expand > this trend. Starting with efficient protocols provides headroom for > growth in the application later. > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, November 08, 2009 7:25 PM > To: Stuber, Michael > Cc: Benoit Claise; 6lowapp@ietf.org > Subject: Re: [6lowapp] Next version of charter proposal up on > 6lowapp.net > > Right, but the bandwidth per device is really, really low. How many bits > do you send each day to a thermostat or light switch? Are there any > measurements of the realistic signaling load in such networks? > > I'm worried about artificially constraining the solution space to solve > a practical non-problem. > > Henning > > On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: > > >> Keep in mind though, that much of that bandwidth is shared on these >> networks In an 802.15.4 environment, devices will share a single >> channel. If this work is successful there will be many constrained >> nodes within the network, rather than a single pair of nodes. >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> Behalf Of Henning Schulzrinne >> Sent: Sunday, November 08, 2009 6:33 PM >> To: Benoit Claise >> Cc: 6lowapp@ietf.org >> Subject: Re: [6lowapp] Next version of charter proposal up on >> 6lowapp.net >> >> I find this conflation of Smart Energy/HAN and LowApp confusing. >> Most of >> the in-home networks are not exactly "challenged". Even ZigBee has 250 >> > > >> kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to >> early DSL or 1990's modems. >> >> Henning >> >> On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: >> >> >>> Carsten, >>> >>> Thanks for the new charter proposal. >>> >>> - "This WG is concentrating on requirements from energy (e.g. Smart >>> Energy 2.0) and building management applications." >>> Is the goal to describe these requirements in the "objectives and >>> architecture" document? >>> If not, where can we understand those requirements from? >>> The following were mentioned on the list: >>> >>> There are a lot of use cases to start with. Here is a starter set: >>> 1) OpenHAN: >>> >>> http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- >>> %20v1.04%20-% >>> 200808 >>> >>> 19-1.pdf >>> 2) SmartGridipedia: >>> >>> http://www.smartgridipedia.org/index.php/Category:Use_Cases >>> , both the >>> Intelligrid and Southern California Edison use cases are good >>> 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are >>> using for our Smart Energy V2 work): >>> >>> http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf >>> Any other ones? >>> >>> "The framework will also specify specify a way to support interface >>> profiles, ..." >>> Can you expand on "interface profile". >>> >>> >>> "A document with operation and management advice about running a >>> network using these applications." >>> Is advice the right word? It seems like one or two advices are >>> sufficient to manage the network ;-) >>> >>> >>> Regards, Benoit. >>> >>>> I have put a new version of the WG charter proposal on the wiki page >>>> > > >>>> at http://6lowapp.net = >>>> http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp >>>> (charter text is at the end of the page). >>>> >>>> Obviously, I could not pick up every comment that was on the list >>>> (they were partially going in conflicting directions), but please do >>>> > > >>>> comment on the new version. >>>> >>>> Gruesse, Carsten >>>> >>>> _______________________________________________ >>>> 6lowapp mailing list >>>> 6lowapp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowapp >>>> >>> _______________________________________________ >>> 6lowapp mailing list >>> 6lowapp@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowapp >>> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> >> > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --------------070608050607000707020509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >From the requirement/use case remark in my initial email, I wanted to understand: how many constrained nodes in a single constrained network must share the 250kbit/s? For example, in case of discovery, concurrent events, concurrent queries, etc.
IMHO, this is an important input for the protocol design, which I didn't get from the BOF.

Regards, Benoit.
Although I agree with the not challenged statement, a few updates:
I expect a presence detector to send out a message once per second or per 10 seconds
There may be 1 till 100 in one wireless mesh, dependent on office lay-out.
The crux comes when an alarm hits. Then we will have an avalanche of messages and some can be just thrown away and a few need to be sent on through the routers to some central post(s)regardless. There is the challenge of overload handling.

Peter


-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Stuber, Michael
Sent: Monday 9 November 2009 4:49
To: Henning Schulzrinne
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

The amount of bandwidth required per applications varies a great deal.
Some devices, like light switches, or battery powered sensors may only
send a message or two per day.  Other devices such as energy usage
monitors or electric vehicles may send a large number of updates.
Electric meters may send current usage information to in-home displays
every 10 seconds.  Electric cars may start with an extended exchange to
negotiate a charging regime, followed by periodic updates to in-home
displays regarding the device's state of charge.

Most of the networks that I worry about are indeed likely to be small
(>30 nodes); however, there are places where folks have been running
larger smart energy networks for meter data collection that are upwards
of thousands of nodes.  The 802.15.4 T4G SUN work is likely to expand
this trend.  Starting with efficient protocols provides headroom for
growth in the application later.

-----Original Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael
Cc: Benoit Claise; 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

Right, but the bandwidth per device is really, really low. How many bits
do you send each day to a thermostat or light switch? Are there any
measurements of the realistic signaling load in such networks?

I'm worried about artificially constraining the solution space to solve
a practical non-problem.

Henning

On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote:

  
Keep in mind though, that much of that bandwidth is shared on these
networks  In an 802.15.4 environment, devices will share a single
channel.  If this work is successful there will be many constrained
nodes within the network, rather than a single pair of nodes.

-----Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On
Behalf Of Henning Schulzrinne
Sent: Sunday, November 08, 2009 6:33 PM
To: Benoit Claise
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on
6lowapp.net

I find this conflation of Smart Energy/HAN and LowApp confusing.
Most of
the in-home networks are not exactly "challenged". Even ZigBee has 250
    

  
kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to
early DSL or 1990's modems.

Henning

On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote:

    
Carsten,

Thanks for the new charter proposal.

- "This WG is concentrating on requirements from energy (e.g. Smart
Energy 2.0) and building management applications."
Is the goal to describe these requirements in the "objectives and
architecture" document?
If not, where can we understand those requirements from?
The following were mentioned on the list:

There are a lot of use cases to start with.  Here is a starter set:
1)  OpenHAN:

http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-
%20v1.04%20-%
200808

19-1.pdf
2)  SmartGridipedia:

http://www.smartgridipedia.org/index.php/Category:Use_Cases
, both the
Intelligrid and Southern California Edison use cases are good
3)  ZigBee/HomePlug Market Requirements and Use Cases (which we are
using for our Smart Energy V2 work):

http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf
Any other ones?

"The framework will also specify specify a way to support interface
profiles, ..."
Can you expand on "interface profile".


"A document with operation and management advice about running a
network using these applications."
Is advice the right word? It seems like one or two advices are
sufficient to manage the network ;-)


Regards, Benoit.
      
I have put a new version of the WG charter proposal on the wiki page
        

  
at http://6lowapp.net =
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
(charter text is at the end of the page).

Obviously, I could not pick up every comment that was on the list
(they were partially going in conflicting directions), but please do
        

  
comment on the new version.

Gruesse, Carsten

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
        
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp
      
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

    

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

--------------070608050607000707020509-- From d.sturek@att.net Mon Nov 9 03:30:34 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283073A68B7 for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 03:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.19 X-Spam-Level: X-Spam-Status: No, score=-0.19 tagged_above=-999 required=5 tests=[AWL=0.624, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 lZrltmnLj8IG for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 03:30:32 -0800 (PST) Received: from smtp107.sbc.mail.gq1.yahoo.com (smtp107.sbc.mail.gq1.yahoo.com [67.195.14.110]) by core3.amsl.com (Postfix) with SMTP id 333D83A6857 for <6lowapp@ietf.org>; Mon, 9 Nov 2009 03:30:32 -0800 (PST) Received: (qmail 63550 invoked from network); 9 Nov 2009 11:30:56 -0000 Received: from host-160-85.meeting.ietf.org (d.sturek@133.93.160.85 with login) by smtp107.sbc.mail.gq1.yahoo.com with SMTP; 09 Nov 2009 03:30:55 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: RldefaQVM1lJhnL1zc7YmRpFyX2xUbPCHaYZgVSJ5GNjJjnKgXwS1IRC6XT7TIHXVuIhvOI3Vlzp3K6LgIkpi97_nZPGj9Epz5BzlQAXtwEZhXgftsJrfBFiPfzXPhZdzSBWSBqRqyul4t8qRfV9oiI_nPcGtQIGWDrem4JNdtWIiQmlItscJ4gniThNYS3b7bZeIKXcLk8Q_FB2ghLH38o9j.928Vxkk2ETtZlmanJlA2qH_jW_dvDLoXFtNVXI.CeES5s5eV1NHDozSnH8HdcQD1_IaF0iX4UnN.lBF29eDPeWTzWTLlcZC6sqDHhURwa3ikuLBwZc1oBOaBLvscIEAMlMfhNMinDyFZ_n.knMGG6fb2ExsTGLLWYx.QU7Ki8w1TO1t.ZcpXFAOUmBZ_Uc8BlUWiBPnKmJbtAWn7hedo_tzyS8yVdYI2v_JiQBlDNTpObGMAkcgPbUvG2MzqPLwz2InnFXZrigqCAiz454sjz9WXmiIgs0kRNq7SeoReOz6hdktgSjAvDLZxQA_bsjZ1hXQkw4ywX3BSi6qRkRK2ljzmuxjZaa85YwxLE_d7wuNeOOTtxEygvxKuq48EgIwQheIP1.9697ciCsHjJUnxFEzXXxslnlqLRqKbRiEzIeGjP.NP9mZthHAW4ClQ-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Benoit Claise'" , "'Van Der Stok, Peter'" References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org><4AF77C65.3050309@ cisco.com><517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu><05C6A38D73 2F1144A8C4016BA4416BFE0242D03C@SPO-EXVS-02.itron.com><7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> <4AF7C18F.5030107@cisco.com> In-Reply-To: <4AF7C18F.5030107@cisco.com> Date: Mon, 9 Nov 2009 03:30:49 -0800 Message-ID: <00e201ca6130$17a84a70$46f8df50$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E3_01CA60ED.09850A70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphDHX15TZVHVgqTSi2hOYhLF6NjAAIvfDw Content-Language: en-us Cc: "'Stuber, Michael'" , 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 11:30:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E3_01CA60ED.09850A70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 250 Kbps is the theoretical maximum on the data link. Considering back offs and other required channel operations (CSMA) the maximum you will see in practice is about 140 Kbps. Next, the 140 Kbps is from point to point (a device to its neighbor). Depending on the network topology and the data transfer characteristics (for example, if you had an application where predominant traffic is MP2P where all devices in a multihop network were to send data to a single access point) you might see less than 10K bps at the concentrator (again, depends on the data traffic model, the frequency of data transfer, the number of hops from leaf nodes in the network to the concentrator, etc.). Don From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Sunday, November 08, 2009 11:15 PM To: Van Der Stok, Peter Cc: Stuber, Michael; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net >From the requirement/use case remark in my initial email, I wanted to understand: how many constrained nodes in a single constrained network must share the 250kbit/s? For example, in case of discovery, concurrent events, concurrent queries, etc. IMHO, this is an important input for the protocol design, which I didn't get from the BOF. Regards, Benoit. Although I agree with the not challenged statement, a few updates: I expect a presence detector to send out a message once per second or per 10 seconds There may be 1 till 100 in one wireless mesh, dependent on office lay-out. The crux comes when an alarm hits. Then we will have an avalanche of messages and some can be just thrown away and a few need to be sent on through the routers to some central post(s)regardless. There is the challenge of overload handling. Peter -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Stuber, Michael Sent: Monday 9 November 2009 4:49 To: Henning Schulzrinne Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net The amount of bandwidth required per applications varies a great deal. Some devices, like light switches, or battery powered sensors may only send a message or two per day. Other devices such as energy usage monitors or electric vehicles may send a large number of updates. Electric meters may send current usage information to in-home displays every 10 seconds. Electric cars may start with an extended exchange to negotiate a charging regime, followed by periodic updates to in-home displays regarding the device's state of charge. Most of the networks that I worry about are indeed likely to be small (>30 nodes); however, there are places where folks have been running larger smart energy networks for meter data collection that are upwards of thousands of nodes. The 802.15.4 T4G SUN work is likely to expand this trend. Starting with efficient protocols provides headroom for growth in the application later. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, November 08, 2009 7:25 PM To: Stuber, Michael Cc: Benoit Claise; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net Right, but the bandwidth per device is really, really low. How many bits do you send each day to a thermostat or light switch? Are there any measurements of the realistic signaling load in such networks? I'm worried about artificially constraining the solution space to solve a practical non-problem. Henning On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: Keep in mind though, that much of that bandwidth is shared on these networks In an 802.15.4 environment, devices will share a single channel. If this work is successful there will be many constrained nodes within the network, rather than a single pair of nodes. -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, November 08, 2009 6:33 PM To: Benoit Claise Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net I find this conflation of Smart Energy/HAN and LowApp confusing. Most of the in-home networks are not exactly "challenged". Even ZigBee has 250 kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to early DSL or 1990's modems. Henning On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: Carsten, Thanks for the new charter proposal. - "This WG is concentrating on requirements from energy (e.g. Smart Energy 2.0) and building management applications." Is the goal to describe these requirements in the "objectives and architecture" document? If not, where can we understand those requirements from? The following were mentioned on the list: There are a lot of use cases to start with. Here is a starter set: 1) OpenHAN: http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- %20v1.04%20-% 200808 19-1.pdf 2) SmartGridipedia: http://www.smartgridipedia.org/index.php/Category:Use_Cases , both the Intelligrid and Southern California Edison use cases are good 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are using for our Smart Energy V2 work): http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf Any other ones? "The framework will also specify specify a way to support interface profiles, ..." Can you expand on "interface profile". "A document with operation and management advice about running a network using these applications." Is advice the right word? It seems like one or two advices are sufficient to manage the network ;-) Regards, Benoit. I have put a new version of the WG charter proposal on the wiki page at http://6lowapp.net = http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp (charter text is at the end of the page). Obviously, I could not pick up every comment that was on the list (they were partially going in conflicting directions), but please do comment on the new version. Gruesse, Carsten _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp ------=_NextPart_000_00E3_01CA60ED.09850A70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

250 Kbps is the theoretical maximum on the data = link.   Considering back offs and other required channel operations (CSMA) the = maximum you will see in practice is about 140 Kbps.

 

Next, the 140 Kbps is from point to point (a device to = its neighbor).  Depending on the network topology and the data transfer = characteristics (for example, if you had an application where predominant traffic is = MP2P where all devices in a multihop network were to send data to a single access = point) you might see less than 10K bps at the concentrator (again, depends on = the data traffic model, the frequency of data transfer, the number of hops from = leaf nodes in the network to the concentrator, etc.).

 

Don

 

 

From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Sunday, November 08, 2009 11:15 PM
To: Van Der Stok, Peter
Cc: Stuber, Michael; 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

 

From the requirement/use case remark in my initial = email, I wanted to understand: how many constrained nodes in a single constrained network must share the 250kbit/s? For example, in case of discovery, = concurrent events, concurrent queries, etc.
IMHO, this is an important input for the protocol design, which I didn't = get from the BOF.

Regards, Benoit.

Although I agree with the not challenged statement, a few =
updates:
I expect a presence detector to send out a =
message once per second or per 10 seconds
There may =
be 1 till 100 in one wireless mesh, dependent on office =
lay-out.
The crux comes when an alarm hits. Then we =
will have an avalanche of messages and some can be just thrown away and =
a few need to be sent on through the routers to some central =
post(s)regardless. There is the challenge of overload =
handling.
 
Peter
 
 
----=
-Original Message-----
From: 6lowapp-bounces@ietf.org =
[mailto:6lowapp-bounces@ietf.org<=
/a>] On Behalf Of Stuber, Michael
Sent: Monday 9 =
November 2009 4:49
To: Henning =
Schulzrinne
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on = 6lowapp.net
 
The amount =
of bandwidth required per applications varies a great =
deal.
Some devices, like light switches, or battery =
powered sensors may only
send a message or two per =
day.  Other devices such as energy =
usage
monitors or electric vehicles may send a =
large number of updates.
Electric meters may send =
current usage information to in-home displays
every =
10 seconds.  Electric cars may start with an extended exchange =
to
negotiate a charging regime, followed by =
periodic updates to in-home
displays regarding the =
device's state of =
charge.
 
Most of the =
networks that I worry about are indeed likely to be =
small
(>30 nodes); however, there are places =
where folks have been running
larger smart energy =
networks for meter data collection that are =
upwards
of thousands of nodes.  The 802.15.4 =
T4G SUN work is likely to expand
this trend.  =
Starting with efficient protocols provides headroom =
for
growth in the application =
later.
 
-----Original =
Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]<=
/o:p>
Sent: Sunday, November 08, 2009 7:25 =
PM
To: Stuber, Michael
Cc: =
Benoit Claise; 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up = on
6lowapp.net
 
Right, but the bandwidth per device is really, really low. =
How many bits
do you send each day to a thermostat =
or light switch? Are there any
measurements of the =
realistic signaling load in such =
networks?
 
I'm worried =
about artificially constraining the solution space to =
solve
a practical =
non-problem.
 
Henning
 
On Nov 8, 2009, at 10:18 =
PM, Stuber, Michael =
wrote:
 
  =

Keep in =
mind though, that much of that bandwidth is shared on =
these
networks  In an 802.15.4 environment, =
devices will share a single
channel.  If this =
work is successful there will be many =
constrained
nodes within the network, rather than a =
single pair of =
nodes.
 
-----Original =
Message-----
From: 6lowapp-bounces@ietf.org =
[mailto:6lowapp-bounces@ietf.org<=
/a>] On
Behalf Of Henning =
Schulzrinne
Sent: Sunday, November 08, 2009 6:33 =
PM
To: Benoit Claise
Cc: 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up = on
6lowapp.net
 
I find this conflation of Smart Energy/HAN and LowApp =
confusing.
Most of
the in-home =
networks are not exactly "challenged". Even ZigBee has =
250
    =

 
  
kb/s (or =
20 kb/s in the lowest-bandwidth mode), i.e., equivalent =
to
early DSL or 1990's =
modems.
 
Henning
 
On Nov 8, 2009, at 9:20 PM, =
Benoit Claise =
wrote:
 
   =
; 
Carsten,
 
Thanks for the new charter =
proposal.
 
- "This =
WG is concentrating on requirements from energy (e.g. =
Smart
Energy 2.0) and building management =
applications."
Is the goal to describe these =
requirements in the "objectives =
and
architecture" =
document?
If not, where can we understand those =
requirements from?
The following were mentioned on =
the list:
 
There are a =
lot of use cases to start with.  Here is a starter =
set:
1)  =
OpenHAN:
 
http://=
www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-
%20v1.04%20-%
200808
&n=
bsp;
19-1.pdf
2)  =
SmartGridipedia:
 
http=
://www.smartgridipedia.org/index.php/Category:Use_Cases
, both the
Intelligrid and Southern =
California Edison use cases are good
3)  =
ZigBee/HomePlug Market Requirements and Use Cases (which we =
are
using for our Smart Energy V2 =
work):
 
http://w=
ww.homeplug.org/products/ZBHP_SE_MRD_090624.pdf
=
Any other =
ones?
 
"The =
framework will also specify specify a way to support =
interface
profiles, =
..."
Can you expand on "interface =
profile".
 
&nbs=
p;
"A document with operation and management advice =
about running a
network using these =
applications."
Is advice the right word? It =
seems like one or two advices are
sufficient to =
manage the network =
;-)
 
 
Regards, =
Benoit.
      =




I have =
put a new version of the WG charter proposal on the wiki =
page
        =




 
  
at http://6lowapp.net =
=3D
http://tra=
c.tools.ietf.org/area/app/trac/wiki/6LowApp
(cha=
rter text is at the end of the =
page).
 
Obviously, I =
could not pick up every comment that was on the =
list
(they were partially going in conflicting =
directions), but please =
do
        =

 
  
comment =
on the new =
version.
 
Gruesse, =
Carsten
 
________________=
_______________________________
6lowapp mailing =
list
6lowapp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowapp
   &n=
bsp;    
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowapp
   &n=
bsp;  
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowapp
 
    
 
________________________________________=
_______
6lowapp mailing =
list
6lowapp@ietf.org
https://www.ietf.o= rg/mailman/listinfo/6lowapp
 
The information contained in this message may be confidential =
and legally protected under applicable law. The message is intended =
solely for the addressee(s). If you are not the intended recipient, you =
are hereby notified that any use, forwarding, dissemination, or =
reproduction of this message is strictly prohibited and may be unlawful. =
If you are not the intended recipient, please contact the sender by =
return e-mail and destroy all copies of the original =
message.
___________________________________________=
____
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.o=
rg/mailman/listinfo/6lowapp
  =

 

------=_NextPart_000_00E3_01CA60ED.09850A70-- From arjunrc@gmail.com Mon Nov 9 06:35:27 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015CD3A63C9 for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 06:35:27 -0800 (PST) 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 fPoPNiMy7CJP for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 06:35:25 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id A79E03A680C for <6lowapp@ietf.org>; Mon, 9 Nov 2009 06:35:24 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so665327qwb.31 for <6lowapp@ietf.org>; Mon, 09 Nov 2009 06:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=jkokrMVENcB1GZ5MkfvGxyxctfVs+rTpE3tDaI4Y42U=; b=kRF+X1AWbKS/jBMkV785W77Pdi0tylVHxAOHbuxll/0LBAByYnxpbrWGPFJlNmWrZr PcVMexVYZD2DPg8MkzJflFkf0DNdv2OxTJrt+KM0IsavU+tXNBoj/4yDTOCfTg5CL1jd Lsgi48xIQIIRbl4s3l0+74dzq8CRk7oHRYHQg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=W56HW9h9aCuZu/vgFgUXp0R5GRqGaJ3C62LhLEePX3RWdbpHHfmBOZ6vzmTf6CYty1 6EnOM9cEqwaBNp8G7arrXTKxT/BfAi5DHSNcqNGb/MFqJjr95dU3pic/aEzzMLK5k0KL gynFXiKTJHDxzpTTrwEdHyff0fjbg2sNxLLLM= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.121.129 with SMTP id h1mr4146493qar.55.1257777348156; Mon, 09 Nov 2009 06:35:48 -0800 (PST) In-Reply-To: <9083133113177307269@unknownmsgid> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> <4AF7C18F.5030107@cisco.com> <9083133113177307269@unknownmsgid> From: Arjun Roychowdhury Date: Mon, 9 Nov 2009 09:35:28 -0500 X-Google-Sender-Auth: 50850a83ded65527 Message-ID: To: d.sturek@att.net Content-Type: multipart/alternative; boundary=000feaf081200b1ea10477f11c47 Cc: "Stuber, Michael" , 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 14:35:27 -0000 --000feaf081200b1ea10477f11c47 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay, I am sorry, I am very confused now. Can someone please point me to a resource where I can read up what are the constraints for HAN devices this group is talking about, specifically: a) CPU constraints (and what sort of devices this applies/does not apply to= ) b) Network constraints c) What is the network topology for which modelling needs to be done to figure out whether a protocol is appropriate or not? I see numbers being talked about in this list and while discussing the charter, but I am unable to see a clear modeling that arrives at those numbers. regds arjun On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek wrote: > 250 Kbps is the theoretical maximum on the data link. Considering back > offs and other required channel operations (CSMA) the maximum you will se= e > in practice is about 140 Kbps. > > > > Next, the 140 Kbps is from point to point (a device to its neighbor). > Depending on the network topology and the data transfer characteristics (= for > example, if you had an application where predominant traffic is MP2P wher= e > all devices in a multihop network were to send data to a single access > point) you might see less than 10K bps at the concentrator (again, depend= s > on the data traffic model, the frequency of data transfer, the number of > hops from leaf nodes in the network to the concentrator, etc.). > > > > Don > > > > > > *From:* 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] *On > Behalf Of *Benoit Claise > *Sent:* Sunday, November 08, 2009 11:15 PM > *To:* Van Der Stok, Peter > *Cc:* Stuber, Michael; 6lowapp@ietf.org > > *Subject:* Re: [6lowapp] Next version of charter proposal up on > 6lowapp.net > > > > From the requirement/use case remark in my initial email, I wanted to > understand: how many constrained nodes in a single constrained network mu= st > share the 250kbit/s? For example, in case of discovery, concurrent events= , > concurrent queries, etc. > IMHO, this is an important input for the protocol design, which I didn't > get from the BOF. > > Regards, Benoit. > > Although I agree with the not challenged statement, a few updates: > > I expect a presence detector to send out a message once per second or per= 10 seconds > > There may be 1 till 100 in one wireless mesh, dependent on office lay-out= . > > The crux comes when an alarm hits. Then we will have an avalanche of mess= ages and some can be just thrown away and a few need to be sent on through = the routers to some central post(s)regardless. There is the challenge of ov= erload handling. > > > > Peter > > > > > > -----Original Message----- > > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org <6lowapp-= bounces@ietf.org>] On Behalf Of Stuber, Michael > > Sent: Monday 9 November 2009 4:49 > > To: Henning Schulzrinne > > Cc: 6lowapp@ietf.org > > Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net > > > > The amount of bandwidth required per applications varies a great deal. > > Some devices, like light switches, or battery powered sensors may only > > send a message or two per day. Other devices such as energy usage > > monitors or electric vehicles may send a large number of updates. > > Electric meters may send current usage information to in-home displays > > every 10 seconds. Electric cars may start with an extended exchange to > > negotiate a charging regime, followed by periodic updates to in-home > > displays regarding the device's state of charge. > > > > Most of the networks that I worry about are indeed likely to be small > > (>30 nodes); however, there are places where folks have been running > > larger smart energy networks for meter data collection that are upwards > > of thousands of nodes. The 802.15.4 T4G SUN work is likely to expand > > this trend. Starting with efficient protocols provides headroom for > > growth in the application later. > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu ] > > Sent: Sunday, November 08, 2009 7:25 PM > > To: Stuber, Michael > > Cc: Benoit Claise; 6lowapp@ietf.org > > Subject: Re: [6lowapp] Next version of charter proposal up on > > 6lowapp.net > > > > Right, but the bandwidth per device is really, really low. How many bits > > do you send each day to a thermostat or light switch? Are there any > > measurements of the realistic signaling load in such networks? > > > > I'm worried about artificially constraining the solution space to solve > > a practical non-problem. > > > > > Henning > > > > On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: > > > > > > Keep in mind though, that much of that bandwidth is shared on these > > networks In an 802.15.4 environment, devices will share a single > > channel. If this work is successful there will be many constrained > > nodes within the network, rather than a single pair of nodes. > > > > -----Original Message----- > > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org <6lowapp-= bounces@ietf.org>] On > > Behalf Of Henning Schulzrinne > > Sent: Sunday, November 08, 2009 6:33 PM > > To: Benoit Claise > > Cc: 6lowapp@ietf.org > > Subject: Re: [6lowapp] Next version of charter proposal up on > > 6lowapp.net > > > > I find this conflation of Smart Energy/HAN and LowApp confusing. > > Most of > > the in-home networks are not exactly "challenged". Even ZigBee has 250 > > > > > > > > kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to > > early DSL or 1990's modems. > > > > Henning > > > > > On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: > > > > > > Carsten, > > > > Thanks for the new charter proposal. > > > > - "This WG is concentrating on requirements from energy (e.g. Smart > > Energy 2.0) and building management applications." > > Is the goal to describe these requirements in the "objectives and > > architecture" document? > > If not, where can we understand those requirements from? > > The following were mentioned on the list: > > > > There are a lot of use cases to start with. Here is a starter set: > > 1) OpenHAN: > > > > http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- > > %20v1.04%20-% > > 200808 > > > > 19-1.pdf > > 2) SmartGridipedia: > > > > http://www.smartgridipedia.org/index.php/Category:Use_Cases > > , both the > > Intelligrid and Southern California Edison use cases are good > > 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are > > using for our Smart Energy V2 work): > > > > > http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf > > Any other ones? > > > > "The framework will also specify specify a way to support interface > > profiles, ..." > > Can you expand on "interface profile". > > > > > > "A document with operation and management advice about running a > > network using these applications." > > Is advice the right word? It seems like one or two advices are > > sufficient to manage the network ;-) > > > > > > Regards, Benoit. > > > > I have put a new version of the WG charter proposal on the wiki page > > > > > > > > at http://6lowapp.net =3D > > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > > (charter text is at the end of the page). > > > > Obviously, I could not pick up every comment that was on the list > > (they were partially going in conflicting directions), but please do > > > > > > > > > comment on the new version. > > > > Gruesse, Carsten > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > > > > > > > *********************************************DISCLAIMER******************= *************************** > The email is subject to Disclaimer as per - > http://www.hsc.com/tabid/91/Default.aspx#emaildisclaimer > > > --=20 Arjun Roychowdhury --000feaf081200b1ea10477f11c47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay, I am sorry, I am very confused now. Can someone please point me to a = resource where I can read up what are the constraints for HAN devices this = group is talking about, specifically:

a) CPU constraints= (and what sort of devices this applies/does not apply to)
b) Network constraints
c) What is the network topology for w= hich modelling needs to be done to figure out whether a protocol is appropr= iate or not?

I see numbers being talked about in t= his list and while discussing the charter, but I am unable to see a clear m= odeling that arrives at those numbers.

regds
arjun

On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek <d.sturek@att.net> wrote:

250 K= bps is the theoretical maximum on the data link.=A0=A0 Considering back offs and other required channel operations (CSMA) the maxi= mum you will see in practice is about 140 Kbps.

=A0

Next,= the 140 Kbps is from point to point (a device to its neighbor).=A0 Depending on the network topology and the data transfer chara= cteristics (for example, if you had an application where predominant traffic is MP2P w= here all devices in a multihop network were to send data to a single access poin= t) you might see less than 10K bps at the concentrator (again, depends on the = data traffic model, the frequency of data transfer, the number of hops from leaf nodes in the network to the concentrator, etc.).

=A0

Don

=A0

=A0

From: 6lowapp-bounces@ietf= .org [mailto:6lowa= pp-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Sunday, November 08, 2009 11:15 PM
To: Van Der Stok, Peter
Cc: Stuber, Michael; 6lowapp@ietf.org

Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

=A0

From the requirement/use case remark in my initial e= mail, I wanted to understand: how many constrained nodes in a single constrained network must share the 250kbit/s? For example, in case of discovery, concur= rent events, concurrent queries, etc.
IMHO, this is an important input for the protocol design, which I didn'= t get from the BOF.

Regards, Benoit.

Although I agree with the not challenged statement, a few updates:
I expect a presence detector to send out a message once per second o=
r per 10 seconds
There may be 1 till 100 in one wireless mesh, de=
pendent on office lay-out.



The crux comes when an alarm hits. Then we will have an avalanche of m=
essages and some can be just thrown away and a few need to be sent on throu=
gh the routers to some central post(s)regardless. There is the challenge of=
 overload handling.



=A0
Peter
=A0
=A0
-----Origina=
l Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On =
Behalf Of Stuber, Michael



Sent: Monday 9 November 2009 4:49
To: Henning Schulzrinne
Cc: 6lowapp@i=
etf.org
Subject: Re: [6lowapp] Next version of charter propos=
al up on 6lowapp.net


=A0
The amount of bandwidth required per applications varies=
 a great deal.
Some devices, like light switches, or battery powe=
red sensors may only
send a message or two per day.=A0 Other devi=
ces such as energy usage



monitors or electric vehicles may send a large number of updates.
Electric meters may send current usage information to in-home display=
s
every 10 seconds.=A0 Electric cars may start with an extended e=
xchange to



negotiate a charging regime, followed by periodic updates to in-home
displays regarding the device's state of charge.
=A0=

Most of the networks that I worry about are indeed likely to be =
small



(>30 nodes); however, there are places where folks have been runnin=
g
larger smart energy networks for meter data collection that are=
 upwards
of thousands of nodes.=A0 The 802.15.4 T4G SUN work is l=
ikely to expand



this trend.=A0 Starting with efficient protocols provides headroom for=

growth in the application later.
=A0
-----Or=
iginal Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]


Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael<=
/pre>
Cc: Benoit Claise; 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version =
of charter proposal up on



6lowapp.net
=

=A0
Right, but the bandwidth per device is really, really lo=
w. How many bits
do you send each day to a thermostat or light sw=
itch? Are there any



measurements of the realistic signaling load in such networks?
=A0
I'm worried about artificially constraining the soluti=
on space to solve
a practical non-problem.
=A0


Henning
=A0
On Nov 8, 2009, at 10:18 PM, Stuber, Michae=
l wrote:
=A0
=A0 



Keep in min=
d though, that much of that bandwidth is shared on these
networks=
=A0 In an 802.15.4 environment, devices will share a single
chann=
el.=A0 If this work is successful there will be many constrained



nodes within the network, rather than a single pair of nodes.
=A0
-----Original Message-----
From: 6lowapp-bounces@ietf.org =
[mailto:6lowa=
pp-bounces@ietf.org] On



Behalf Of Henning Schulzrinne
Sent: Sunday, November 08, 200=
9 6:33 PM
To: Benoit Claise
Cc: 6lowapp@ietf.org
Subject: Re: =
[6lowapp] Next version of charter proposal up on



6lowapp.net
=

=A0
I find this conflation of Smart Energy/HAN and LowApp co=
nfusing.
Most of
the in-home networks are not exactly &=
quot;challenged". Even ZigBee has 250



=A0=A0=A0 
=A0
=A0 
kb/s (or 20=
 kb/s in the lowest-bandwidth mode), i.e., equivalent to
early DS=
L or 1990's modems.
=A0
Henning
=A0
= 

On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote:
=A0
=
=A0=A0=A0 
Carsten,
=A0
Thanks for the new charter proposal.
=A0
- "This WG is concentrating on requirements from energy (e.g. =
Smart



Energy 2.0) and building management applications."
Is t=
he goal to describe these requirements in the "objectives and
architecture" document?
If not, where can we understand th=
ose requirements from?



The following were mentioned on the list:
=A0
Ther=
e are a lot of use cases to start with.=A0 Here is a starter set:
1)=A0 OpenHAN:
=A0
http://www.utilityami.o=
rg/docs/UtilityAMI%20HAN%20SRS%20-
%20v1.04%20-%
200808
=A0
19-1.pdf
<= pre>2)=A0 SmartGridipedia:
=A0
http://ww=
w.smartgridipedia.org/index.php/Category:Use_Cases
, both the
Intelligrid and Southern California Edison use ca=
ses are good
3)=A0 ZigBee/HomePlug Market Requirements and Use Ca=
ses (which we are
using for our Smart Energy V2 work):

=A0
http://www.homeplug.org/products/ZBHP_SE_MRD_09062=
4.pdf
Any other ones?
=A0
"The frame=
work will also specify specify a way to support interface
profiles, ..."
Can you expand on "interface profil=
e".
=A0
=A0
"A document with operat=
ion and management advice about running a
network using these app=
lications."
Is advice the right word? It seems like one or two advices are
sufficient to manage the network ;-)
=A0
=A0
Regards, Benoit.
=A0=A0=A0=A0=A0 
I have put =
a new version of the WG charter proposal on the wiki page
=A0=A0=
=A0=A0=A0=A0=A0 
=A0
=A0 
at http://6lowapp.net =3D
<= pre>http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp 
(charter text is at the end of the page).
=A0
Obvi=
ously, I could not pick up every comment that was on the list
(th=
ey were partially going in conflicting directions), but please do
=A0=A0=A0=A0=A0=A0=A0 
=A0
=A0 
comment on =
the new version.
=A0
Gruesse, Carsten
=A0
_______________________________________________
6lowapp ma=
iling list



6lowapp@ietf.org=

https://www.ietf.org/mailman/listinfo/6lowapp
=A0=A0=A0=A0=A0=A0=A0 
_______________________________________________
6lowapp mail=
ing list
6l=
owapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp=

=A0=A0=A0=A0=A0 
_______________________________________________
6lowapp mail=
ing list
6l=
owapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp=

=A0
=A0=A0=A0 
=A0
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/li=
stinfo/6lowapp
=A0
The information contained in this message may be confide=
ntial and legally protected under applicable law. The message is intended s=
olely for the addressee(s). If you are not the intended recipient, you are =
hereby notified that any use, forwarding, dissemination, or reproduction of=
 this message is strictly prohibited and may be unlawful. If you are not th=
e intended recipient, please contact the sender by return e-mail and destro=
y all copies of the original message.
_______________________________________________
6lowapp mail=
ing list
6l=
owapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp=

=A0

=A0


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp






*********************************************DISCLAIMER********************= *************************
The email is subject to Disclaimer as per - http://www.hsc.com/= tabid/91/Default.aspx#emaildisclaimer





--
Arjun Roychowdhury<= br>
--000feaf081200b1ea10477f11c47-- From shidan@gmail.com Mon Nov 9 08:03:33 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803B83A6942 for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 08:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 w3W2szzWKUkw for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 08:03:31 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.184]) by core3.amsl.com (Postfix) with ESMTP id 9A9883A686E for <6lowapp@ietf.org>; Mon, 9 Nov 2009 08:03:30 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so263871gvc.15 for <6lowapp@ietf.org>; Mon, 09 Nov 2009 08:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aEIDsisjdb6KSjzDt6IwLi834Zg4m6WPhKEsYsB9xn4=; b=EoAYgWW4tx3ZD+L+8OFpTmJg19iF8JHpojaU1AZLE/EDuDJIEAzGzBbLRAGx7p1U2L wqjUZB/uTjxAVEYEjJd8s49hR4oJf/OIoWJrkorOPOeXcbzwW/hFwbHnDzta9L0iBkEJ 3y9wEK+KHaW0B3qAYSfPCILVCeXPYPzSShtu0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jN2f6+HEOa67Fix9gctIDNaAtH1aWHmAtkX0AdW1rY3yFG18h7cegoL+SLhcz4D0LJ /bD75WqLv2ieJZKBVVPX8+IfGZ9uV6Svc46cq2Iz0+PQnsRW8updUCFfZiv0AIIiD5Rq LZtNM04KgZKQjrh+t5zyyBTGb89e5Lu4kkFrM= MIME-Version: 1.0 Received: by 10.216.93.18 with SMTP id k18mr2590925wef.218.1257782633533; Mon, 09 Nov 2009 08:03:53 -0800 (PST) In-Reply-To: <9083133113177307269@unknownmsgid> References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> <4AF7C18F.5030107@cisco.com> <9083133113177307269@unknownmsgid> Date: Mon, 9 Nov 2009 11:03:53 -0500 Message-ID: <429b380e0911090803v6592582bp5c97e7071da3fda0@mail.gmail.com> From: Shidan To: d.sturek@att.net Content-Type: multipart/alternative; boundary=0016e6d9762013922c0477f257d4 Cc: "Stuber, Michael" , 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 16:03:33 -0000 --0016e6d9762013922c0477f257d4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just curious, if this is the an edge case and far from typical? If it is, would it be reasonable to assume more than one concentrator? On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek wrote: > 250 Kbps is the theoretical maximum on the data link. Considering back > offs and other required channel operations (CSMA) the maximum you will se= e > in practice is about 140 Kbps. > > > > Next, the 140 Kbps is from point to point (a device to its neighbor). > Depending on the network topology and the data transfer characteristics (= for > example, if you had an application where predominant traffic is MP2P wher= e > all devices in a multihop network were to send data to a single access > point) you might see less than 10K bps at the concentrator (again, depend= s > on the data traffic model, the frequency of data transfer, the number of > hops from leaf nodes in the network to the concentrator, etc.). > > > > Don > > > > > > *From:* 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] *On > Behalf Of *Benoit Claise > *Sent:* Sunday, November 08, 2009 11:15 PM > *To:* Van Der Stok, Peter > *Cc:* Stuber, Michael; 6lowapp@ietf.org > > *Subject:* Re: [6lowapp] Next version of charter proposal up on > 6lowapp.net > > > > From the requirement/use case remark in my initial email, I wanted to > understand: how many constrained nodes in a single constrained network mu= st > share the 250kbit/s? For example, in case of discovery, concurrent events= , > concurrent queries, etc. > IMHO, this is an important input for the protocol design, which I didn't > get from the BOF. > > Regards, Benoit. > > Although I agree with the not challenged statement, a few updates: > > I expect a presence detector to send out a message once per second or per= 10 seconds > > There may be 1 till 100 in one wireless mesh, dependent on office lay-out= . > > The crux comes when an alarm hits. Then we will have an avalanche of mess= ages and some can be just thrown away and a few need to be sent on through = the routers to some central post(s)regardless. There is the challenge of ov= erload handling. > > > > Peter > > > > > > -----Original Message----- > > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org <6lowapp-= bounces@ietf.org>] On Behalf Of Stuber, Michael > > Sent: Monday 9 November 2009 4:49 > > To: Henning Schulzrinne > > Cc: 6lowapp@ietf.org > > Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net > > > > The amount of bandwidth required per applications varies a great deal. > > Some devices, like light switches, or battery powered sensors may only > > send a message or two per day. Other devices such as energy usage > > monitors or electric vehicles may send a large number of updates. > > Electric meters may send current usage information to in-home displays > > every 10 seconds. Electric cars may start with an extended exchange to > > negotiate a charging regime, followed by periodic updates to in-home > > displays regarding the device's state of charge. > > > > Most of the networks that I worry about are indeed likely to be small > > (>30 nodes); however, there are places where folks have been running > > larger smart energy networks for meter data collection that are upwards > > of thousands of nodes. The 802.15.4 T4G SUN work is likely to expand > > this trend. Starting with efficient protocols provides headroom for > > growth in the application later. > > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu ] > > Sent: Sunday, November 08, 2009 7:25 PM > > To: Stuber, Michael > > Cc: Benoit Claise; 6lowapp@ietf.org > > Subject: Re: [6lowapp] Next version of charter proposal up on > > 6lowapp.net > > > > Right, but the bandwidth per device is really, really low. How many bits > > do you send each day to a thermostat or light switch? Are there any > > measurements of the realistic signaling load in such networks? > > > > I'm worried about artificially constraining the solution space to solve > > a practical non-problem. > > > > Henning > > > > On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: > > > > > > Keep in mind though, that much of that bandwidth is shared on these > > networks In an 802.15.4 environment, devices will share a single > > channel. If this work is successful there will be many constrained > > nodes within the network, rather than a single pair of nodes. > > > > -----Original Message----- > > From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org <6lowapp-= bounces@ietf.org>] On > > Behalf Of Henning Schulzrinne > > Sent: Sunday, November 08, 2009 6:33 PM > > To: Benoit Claise > > Cc: 6lowapp@ietf.org > > Subject: Re: [6lowapp] Next version of charter proposal up on > > 6lowapp.net > > > > I find this conflation of Smart Energy/HAN and LowApp confusing. > > Most of > > the in-home networks are not exactly "challenged". Even ZigBee has 250 > > > > > > > > kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to > > early DSL or 1990's modems. > > > > Henning > > > > On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: > > > > > > Carsten, > > > > Thanks for the new charter proposal. > > > > - "This WG is concentrating on requirements from energy (e.g. Smart > > Energy 2.0) and building management applications." > > Is the goal to describe these requirements in the "objectives and > > architecture" document? > > If not, where can we understand those requirements from? > > The following were mentioned on the list: > > > > There are a lot of use cases to start with. Here is a starter set: > > 1) OpenHAN: > > > > http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- > > %20v1.04%20-% > > 200808 > > > > 19-1.pdf > > 2) SmartGridipedia: > > > > http://www.smartgridipedia.org/index.php/Category:Use_Cases > > , both the > > Intelligrid and Southern California Edison use cases are good > > 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are > > using for our Smart Energy V2 work): > > > > http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf > > Any other ones? > > > > "The framework will also specify specify a way to support interface > > profiles, ..." > > Can you expand on "interface profile". > > > > > > "A document with operation and management advice about running a > > network using these applications." > > Is advice the right word? It seems like one or two advices are > > sufficient to manage the network ;-) > > > > > > Regards, Benoit. > > > > I have put a new version of the WG charter proposal on the wiki page > > > > > > > > at http://6lowapp.net =3D > > http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp > > (charter text is at the end of the page). > > > > Obviously, I could not pick up every comment that was on the list > > (they were partially going in conflicting directions), but please do > > > > > > > > comment on the new version. > > > > Gruesse, Carsten > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > > > > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. > > _______________________________________________ > > 6lowapp mailing list > > 6lowapp@ietf.org > > https://www.ietf.org/mailman/listinfo/6lowapp > > > > > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > --0016e6d9762013922c0477f257d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just curious, if this is the an edge case and far from typical? If it is, w= ould it be reasonable to assume more than one concentrator?

<= div>

On Mon, Nov 9, 2009 at 6:30 AM, Don = Sturek <d.sturek@a= tt.net> wrote:

250 K= bps is the theoretical maximum on the data link.=A0=A0 Considering back offs and other required channel operations (CSMA) the maxi= mum you will see in practice is about 140 Kbps.

=A0

Next,= the 140 Kbps is from point to point (a device to its neighbor).=A0 Depending on the network topology and the data transfer chara= cteristics (for example, if you had an application where predominant traffic is MP2P w= here all devices in a multihop network were to send data to a single access poin= t) you might see less than 10K bps at the concentrator (again, depends on the = data traffic model, the frequency of data transfer, the number of hops from leaf nodes in the network to the concentrator, etc.).

=A0

Don

=A0

=A0

From: 6lowapp-bounces@ietf= .org [mailto:6lowa= pp-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Sunday, November 08, 2009 11:15 PM
To: Van Der Stok, Peter
Cc: Stuber, Michael; 6lowapp@ietf.org

Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

=A0

From the requirement/use case remark in my initial e= mail, I wanted to understand: how many constrained nodes in a single constrained network must share the 250kbit/s? For example, in case of discovery, concur= rent events, concurrent queries, etc.
IMHO, this is an important input for the protocol design, which I didn'= t get from the BOF.

Regards, Benoit.

Although I agree with the not challenged statement, a few updates:
I expect a presence detector to send out a message once per second o=
r per 10 seconds
There may be 1 till 100 in one wireless mesh, de=
pendent on office lay-out.


The crux comes when an alarm hits. Then we will have an avalanche of m=
essages and some can be just thrown away and a few need to be sent on throu=
gh the routers to some central post(s)regardless. There is the challenge of=
 overload handling.


=A0
Peter
=A0
=A0
-----Origina=
l Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On =
Behalf Of Stuber, Michael


Sent: Monday 9 November 2009 4:49
To: Henning Schulzrinne
Cc: 6lowapp@i=
etf.org
Subject: Re: [6lowapp] Next version of charter propos=
al up on 6lowapp.net

=A0
The amount of bandwidth required per applications varies=
 a great deal.
Some devices, like light switches, or battery powe=
red sensors may only
send a message or two per day.=A0 Other devi=
ces such as energy usage


monitors or electric vehicles may send a large number of updates.
Electric meters may send current usage information to in-home display=
s
every 10 seconds.=A0 Electric cars may start with an extended e=
xchange to


negotiate a charging regime, followed by periodic updates to in-home
displays regarding the device's state of charge.
=A0=

Most of the networks that I worry about are indeed likely to be =
small


(>30 nodes); however, there are places where folks have been runnin=
g
larger smart energy networks for meter data collection that are=
 upwards
of thousands of nodes.=A0 The 802.15.4 T4G SUN work is l=
ikely to expand


this trend.=A0 Starting with efficient protocols provides headroom for=

growth in the application later.
=A0
-----Or=
iginal Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]

Sent: Sunday, November 08, 2009 7:25 PM
To: Stuber, Michael<=
/pre>
Cc: Benoit Claise; 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version =
of charter proposal up on


6lowapp.net
=

=A0
Right, but the bandwidth per device is really, really lo=
w. How many bits
do you send each day to a thermostat or light sw=
itch? Are there any


measurements of the realistic signaling load in such networks?
=A0
I'm worried about artificially constraining the soluti=
on space to solve
a practical non-problem.
=A0

Henning
=A0
On Nov 8, 2009, at 10:18 PM, Stuber, Michae=
l wrote:
=A0
=A0 



Keep in min=
d though, that much of that bandwidth is shared on these
networks=
=A0 In an 802.15.4 environment, devices will share a single
chann=
el.=A0 If this work is successful there will be many constrained


nodes within the network, rather than a single pair of nodes.
=A0
-----Original Message-----
From: 6lowapp-bounces@ietf.org =
[mailto:6lowa=
pp-bounces@ietf.org] On


Behalf Of Henning Schulzrinne
Sent: Sunday, November 08, 200=
9 6:33 PM
To: Benoit Claise
Cc: 6lowapp@ietf.org
Subject: Re: =
[6lowapp] Next version of charter proposal up on


6lowapp.net
=

=A0
I find this conflation of Smart Energy/HAN and LowApp co=
nfusing.
Most of
the in-home networks are not exactly &=
quot;challenged". Even ZigBee has 250


=A0=A0=A0 
=A0
=A0 
kb/s (or 20=
 kb/s in the lowest-bandwidth mode), i.e., equivalent to
early DS=
L or 1990's modems.
=A0
Henning
=A0
= 
On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote:
=A0
=
=A0=A0=A0 
Carsten,
=A0
Thanks for the new charter proposal.
=A0
- "This WG is concentrating on requirements from energy (e.g. =
Smart


Energy 2.0) and building management applications."
Is t=
he goal to describe these requirements in the "objectives and
architecture" document?
If not, where can we understand th=
ose requirements from?


The following were mentioned on the list:
=A0
Ther=
e are a lot of use cases to start with.=A0 Here is a starter set:
1)=A0 OpenHAN:
=A0
http://www.utilityami.o=
rg/docs/UtilityAMI%20HAN%20SRS%20-
%20v1.04%20-%
200808
=A0
19-1.pdf
<= pre>2)=A0 SmartGridipedia:
=A0
http://ww=
w.smartgridipedia.org/index.php/Category:Use_Cases
, both the
Intelligrid and Southern California Edison use ca=
ses are good
3)=A0 ZigBee/HomePlug Market Requirements and Use Ca=
ses (which we are
using for our Smart Energy V2 work):
=A0
http://www.homeplug.org/products/ZBHP_SE_MRD_09062=
4.pdf
Any other ones?
=A0
"The frame=
work will also specify specify a way to support interface
profiles, ..."
Can you expand on "interface profil=
e".
=A0
=A0
"A document with operat=
ion and management advice about running a
network using these app=
lications."
Is advice the right word? It seems like one or two advices are
sufficient to manage the network ;-)
=A0
=A0
Regards, Benoit.
=A0=A0=A0=A0=A0 
I have put =
a new version of the WG charter proposal on the wiki page
=A0=A0=
=A0=A0=A0=A0=A0 
=A0
=A0 
at http://6lowapp.net =3D
<= pre>http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp 
(charter text is at the end of the page).
=A0
Obvi=
ously, I could not pick up every comment that was on the list
(th=
ey were partially going in conflicting directions), but please do
=A0=A0=A0=A0=A0=A0=A0 
=A0
=A0 
comment on =
the new version.
=A0
Gruesse, Carsten
=A0
_______________________________________________
6lowapp ma=
iling list


6lowapp@ietf.org=

https://www.ietf.org/mailman/listinfo/6lowapp
=A0=A0=A0=A0=A0=A0=A0 
_______________________________________________
6lowapp mail=
ing list
6l=
owapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp=

=A0=A0=A0=A0=A0 
_______________________________________________
6lowapp mail=
ing list
6l=
owapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp=

=A0
=A0=A0=A0 
=A0
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/li=
stinfo/6lowapp
=A0
The information contained in this message may be confide=
ntial and legally protected under applicable law. The message is intended s=
olely for the addressee(s). If you are not the intended recipient, you are =
hereby notified that any use, forwarding, dissemination, or reproduction of=
 this message is strictly prohibited and may be unlawful. If you are not th=
e intended recipient, please contact the sender by return e-mail and destro=
y all copies of the original message.
_______________________________________________
6lowapp mail=
ing list
6l=
owapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp=

=A0

=A0


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp


--0016e6d9762013922c0477f257d4-- From trifa@inf.ethz.ch Mon Nov 9 10:25:40 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190FB3A6801 for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 10:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 7FhQ5d1-nzuV for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 10:25:39 -0800 (PST) Received: from gwse.ethz.ch (gwse.ethz.ch [129.132.178.238]) by core3.amsl.com (Postfix) with ESMTP id 801AD3A6774 for <6lowapp@ietf.org>; Mon, 9 Nov 2009 10:25:37 -0800 (PST) Received: from CAS01.d.ethz.ch (129.132.178.235) by gws01.d.ethz.ch (129.132.178.238) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 Nov 2009 19:26:02 +0100 Received: from [192.168.126.71] (77.58.206.5) by mail.ethz.ch (129.132.178.227) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 Nov 2009 19:25:40 +0100 Message-ID: From: Vlad Trifa To: <6lowapp@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail-21-311065775" MIME-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 19:25:39 +0100 X-Mailer: Apple Mail (2.936) Subject: [6lowapp] CFP - First International Workshop on the Web of Things (WoT 2010) @ PerCom 2010 X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 18:25:40 -0000 --Apple-Mail-21-311065775 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello, sorry for spamming, but I think this is very relevant to this WG. Sorry for the short delay, I just thought now to send this here. You receive this mail because we would like you to join the Web of Things initiative by submitting your contribution to the First International Workshop on the Web of Things at IEEE Percom 2010: http://www.webofthings.com/wot/ You probably already received information about this event, but we believe your personal work is highly relevant to the workshop's topic - which is exactly what this WG is all about. We invite you to submit a contribution by this Sunday (15th of November 2009). Exceptionally, if you ask we could add an extra week, to offer you all a chance to participate. We also welcome shorter contributions as well as contributions describing your current prototypes in this field. The aim of this venue is also to bootstrap a community and thus we would really value your presence there. Vlad Trifa, on behalf of the WoT Team: Dominique Guinard, ETH Zurich / SAP Research Erik Wilde, UC Berkeley Vlad Trifa, ETH Zurich / SAP Research ps. I hope the BOF was a great success, I wish I could have attended. I'm looking forward for see what's happened. --Apple-Mail-21-311065775 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello, sorry for spamming, = but I think this is very relevant to this WG. Sorry for the short = delay, I just thought now to send this here.






= --Apple-Mail-21-311065775-- From d.sturek@att.net Mon Nov 9 12:29:26 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292F03A68A6 for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 12:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.422 X-Spam-Level: X-Spam-Status: No, score=0.422 tagged_above=-999 required=5 tests=[AWL=1.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 Mp154dEV2MvE for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 12:29:15 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 760D03A68B4 for <6lowapp@ietf.org>; Mon, 9 Nov 2009 12:29:15 -0800 (PST) Received: (qmail 80847 invoked from network); 9 Nov 2009 20:29:39 -0000 Received: from host-160-85.meeting.ietf.org (d.sturek@133.93.160.85 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 09 Nov 2009 12:29:38 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 2FttzKYVM1kamkZbGdsTY7pJD92irt5V2BgdVIo3Bpk34Ap9lq4tscyHfW3gifMfmw1D8xV7nuFy3q892VvrAroJhpsF_xqYMQ2HKIaqKIuuc1uP9NSEjYZOtQcm.TvroaDOK8qbsuRCdKtraj9vONIAczlvqB9x9XRbQTsZGzKo5QhANypflsWJUZTKLDRm77Di1vqYa_0Y1q4pfzeji1uCPl4bi.g5TlNGrqlAiZJSEtL64eTrpduHt5sXcyN7UPtmQkk2gtUdUppa1t9XLfscgADb2YT14hN8rKYnmyJH3y7SiQajLUS3HhObNmlFFeAmIzkLHoYNtq85OwLCXsercEZfWRsPOriP.wB_Ltix3OdJd.bBjO57_6C7_mZWNrkM4wUc.5w_yl0el5PTKv50cnzBwRmbSthAKZPky8EAdXhOhmc0CyzGUVttOiVf0KnrNWJ7fgW8Q2cHBLgjaatmnyVuiZEsScIGDqXWAGO1nmvn.GzWPMixAMfckFuNQcRsSb6Jyzy68VybBUfkpBOhVGwENJ.jwUlMcIrXDuVo3wWv69GQVF0VQQYF7Y_fsqaKitvB81siMfg2kyWb4nEbmUIQAaPHWhe7QQJ.xNIKg744g.Ajx2dqpJOuXR9QPbSDpg7ymUbqLByD X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Shidan'" References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> <4AF7C18F.5030107@cisco.com> <9083133113177307269@unknownmsgid> <429b380e0911090803v6592582bp5c97e7071da3fda0@mail.gmail.com> In-Reply-To: <429b380e0911090803v6592582bp5c97e7071da3fda0@mail.gmail.com> Date: Mon, 9 Nov 2009 12:29:33 -0800 Message-ID: <017f01ca617b$5a2b76b0$0e826410$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0180_01CA6138.4C0836B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphVkGmmNN7V3/KQw2T4qdy+vKcAgAJMkCg Content-Language: en-us Cc: "'Stuber, Michael'" , 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:29:26 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0180_01CA6138.4C0836B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In terms of an edge case, this was a use where someone wanted to have a single concentrator supporting as many sensor devices as possible each reporting 1 second data. It turns out the number you could support was in the hundreds not thousands. Whether this is an edge case or not is debatable. It wasn't in this case since the concentrators were expensive and they wanted to support 1000+ sensors to make their business case. Don From: Shidan [mailto:shidan@gmail.com] Sent: Monday, November 09, 2009 8:04 AM To: d.sturek@att.net Cc: Benoit Claise; Van Der Stok, Peter; Stuber, Michael; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net Just curious, if this is the an edge case and far from typical? If it is, would it be reasonable to assume more than one concentrator? On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek wrote: 250 Kbps is the theoretical maximum on the data link. Considering back offs and other required channel operations (CSMA) the maximum you will see in practice is about 140 Kbps. Next, the 140 Kbps is from point to point (a device to its neighbor). Depending on the network topology and the data transfer characteristics (for example, if you had an application where predominant traffic is MP2P where all devices in a multihop network were to send data to a single access point) you might see less than 10K bps at the concentrator (again, depends on the data traffic model, the frequency of data transfer, the number of hops from leaf nodes in the network to the concentrator, etc.). Don From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Sunday, November 08, 2009 11:15 PM To: Van Der Stok, Peter Cc: Stuber, Michael; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net >From the requirement/use case remark in my initial email, I wanted to understand: how many constrained nodes in a single constrained network must share the 250kbit/s? For example, in case of discovery, concurrent events, concurrent queries, etc. IMHO, this is an important input for the protocol design, which I didn't get from the BOF. Regards, Benoit. Although I agree with the not challenged statement, a few updates: I expect a presence detector to send out a message once per second or per 10 seconds There may be 1 till 100 in one wireless mesh, dependent on office lay-out. The crux comes when an alarm hits. Then we will have an avalanche of messages and some can be just thrown away and a few need to be sent on through the routers to some central post(s)regardless. There is the challenge of overload handling. Peter -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Stuber, Michael Sent: Monday 9 November 2009 4:49 To: Henning Schulzrinne Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net The amount of bandwidth required per applications varies a great deal. Some devices, like light switches, or battery powered sensors may only send a message or two per day. Other devices such as energy usage monitors or electric vehicles may send a large number of updates. Electric meters may send current usage information to in-home displays every 10 seconds. Electric cars may start with an extended exchange to negotiate a charging regime, followed by periodic updates to in-home displays regarding the device's state of charge. Most of the networks that I worry about are indeed likely to be small (>30 nodes); however, there are places where folks have been running larger smart energy networks for meter data collection that are upwards of thousands of nodes. The 802.15.4 T4G SUN work is likely to expand this trend. Starting with efficient protocols provides headroom for growth in the application later. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, November 08, 2009 7:25 PM To: Stuber, Michael Cc: Benoit Claise; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net Right, but the bandwidth per device is really, really low. How many bits do you send each day to a thermostat or light switch? Are there any measurements of the realistic signaling load in such networks? I'm worried about artificially constraining the solution space to solve a practical non-problem. Henning On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: Keep in mind though, that much of that bandwidth is shared on these networks In an 802.15.4 environment, devices will share a single channel. If this work is successful there will be many constrained nodes within the network, rather than a single pair of nodes. -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, November 08, 2009 6:33 PM To: Benoit Claise Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net I find this conflation of Smart Energy/HAN and LowApp confusing. Most of the in-home networks are not exactly "challenged". Even ZigBee has 250 kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to early DSL or 1990's modems. Henning On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: Carsten, Thanks for the new charter proposal. - "This WG is concentrating on requirements from energy (e.g. Smart Energy 2.0) and building management applications." Is the goal to describe these requirements in the "objectives and architecture" document? If not, where can we understand those requirements from? The following were mentioned on the list: There are a lot of use cases to start with. Here is a starter set: 1) OpenHAN: http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- %20v1.04%20-% 200808 19-1.pdf 2) SmartGridipedia: http://www.smartgridipedia.org/index.php/Category:Use_Cases , both the Intelligrid and Southern California Edison use cases are good 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are using for our Smart Energy V2 work): http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf Any other ones? "The framework will also specify specify a way to support interface profiles, ..." Can you expand on "interface profile". "A document with operation and management advice about running a network using these applications." Is advice the right word? It seems like one or two advices are sufficient to manage the network ;-) Regards, Benoit. I have put a new version of the WG charter proposal on the wiki page at http://6lowapp.net = http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp (charter text is at the end of the page). Obviously, I could not pick up every comment that was on the list (they were partially going in conflicting directions), but please do comment on the new version. Gruesse, Carsten _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp ------=_NextPart_000_0180_01CA6138.4C0836B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In terms of an edge case, this was a use where someone = wanted to have a single concentrator supporting as many sensor devices as possible = each reporting 1 second data.  It turns out the number you could support = was in the hundreds not thousands.

 

Whether this is an edge case or not is debatable.  = It wasn’t in this case since the concentrators were expensive and they wanted to = support 1000+ sensors to make their business case.

 

Don

 

 

From:= Shidan [mailto:shidan@gmail.com]
Sent: Monday, November 09, 2009 8:04 AM
To: d.sturek@att.net
Cc: Benoit Claise; Van Der Stok, Peter; Stuber, Michael; 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

 

Just curious, if this is the an edge case and far = from typical? If it is, would it be reasonable to assume more than one = concentrator?

 

 

On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek <d.sturek@att.net> = wrote:

250 Kbps is the theoretical = maximum on the data link.   Considering back offs and other required = channel operations (CSMA) the maximum you will see in practice is about 140 = Kbps.

 

Next, the 140 Kbps is from = point to point (a device to its neighbor).  Depending on the network = topology and the data transfer characteristics (for example, if you had an = application where predominant traffic is MP2P where all devices in a multihop network were = to send data to a single access point) you might see less than 10K bps at = the concentrator (again, depends on the data traffic model, the frequency of = data transfer, the number of hops from leaf nodes in the network to the concentrator, etc.).

 

Don

 

 

From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Sunday, November 08, 2009 11:15 PM
To: Van Der Stok, Peter
Cc: Stuber, Michael; 6lowapp@ietf.org


Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

 <= /o:p>

From the requirement/use case remark in my initial email, I wanted to = understand: how many constrained nodes in a single constrained network must share = the 250kbit/s? For example, in case of discovery, concurrent events, = concurrent queries, etc.
IMHO, this is an important input for the protocol design, which I didn't = get from the BOF.

Regards, Benoit.

Although I agree with the not challenged statement, a few =
updates:
I expect a presence detector to send out a =
message once per second or per 10 seconds
There may =
be 1 till 100 in one wireless mesh, dependent on office =
lay-out.
The crux comes when an alarm hits. Then we =
will have an avalanche of messages and some can be just thrown away and =
a few need to be sent on through the routers to some central =
post(s)regardless. There is the challenge of overload =
handling.
 
Peter
 
 
----=
-Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of =
Stuber, Michael
Sent: Monday 9 November 2009 =
4:49
To: Henning =
Schulzrinne
Cc: 6lowapp@ietf.org
Subject: Re: =
[6lowapp] Next version of charter proposal up on 6lowapp.net
 <=
/pre>
The amount of bandwidth required per applications varies a =
great deal.
Some devices, like light switches, or =
battery powered sensors may only
send a message or =
two per day.  Other devices such as energy =
usage
monitors or electric vehicles may send a =
large number of updates.
Electric meters may send =
current usage information to in-home displays
every =
10 seconds.  Electric cars may start with an extended exchange =
to
negotiate a charging regime, followed by =
periodic updates to in-home
displays regarding the =
device's state of =
charge.
 
Most of the =
networks that I worry about are indeed likely to be =
small
(>30 nodes); however, there are places =
where folks have been running
larger smart energy =
networks for meter data collection that are =
upwards
of thousands of nodes.  The 802.15.4 =
T4G SUN work is likely to expand
this trend.  =
Starting with efficient protocols provides headroom =
for
growth in the application =
later.
 
-----Original =
Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Se=
nt: Sunday, November 08, 2009 7:25 PM
To: Stuber, =
Michael
Cc: Benoit Claise; 6lowapp@ietf.org
Subject: Re: =
[6lowapp] Next version of charter proposal up on
6lowapp.net
 <=
/pre>
Right, but the bandwidth per device is really, really low. How =
many bits
do you send each day to a thermostat or =
light switch? Are there any
measurements of the =
realistic signaling load in such =
networks?
 
I'm worried =
about artificially constraining the solution space to =
solve
a practical =
non-problem.
 
 =

Henning
 
On Nov 8, 2009, at 10:18 PM, Stuber, Michael =
wrote:
 
  =




Keep in =
mind though, that much of that bandwidth is shared on =
these
networks  In an 802.15.4 environment, =
devices will share a single
channel.  If this =
work is successful there will be many =
constrained
nodes within the network, rather than a =
single pair of =
nodes.
 
-----Original =
Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] =
On
Behalf Of Henning =
Schulzrinne
Sent: Sunday, November 08, 2009 6:33 =
PM
To: Benoit Claise
Cc: 6lowapp@ietf.org
Subject: Re: =
[6lowapp] Next version of charter proposal up on
6lowapp.net
 <=
/pre>
I find this conflation of Smart Energy/HAN and LowApp =
confusing.
Most of
the in-home =
networks are not exactly "challenged". Even ZigBee has =
250
    =




 
  



kb/s (or =
20 kb/s in the lowest-bandwidth mode), i.e., equivalent =
to
early DSL or 1990's =
modems.
 
Henning
 
 
On =
Nov 8, 2009, at 9:20 PM, Benoit Claise =
wrote:
 
   =
; 



Carsten,
 
Thanks for the new charter =
proposal.
 
- "This =
WG is concentrating on requirements from energy (e.g. =
Smart
Energy 2.0) and building management =
applications."
Is the goal to describe these =
requirements in the "objectives =
and
architecture" =
document?
If not, where can we understand those =
requirements from?
The following were mentioned on =
the list:
 
There are a =
lot of use cases to start with.  Here is a starter =
set:
1)  =
OpenHAN:
 
http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%2=
0-
%20v1.04%20-%
200808
 
19-1.pdf
2)  =
SmartGridipedia:
 
http://www.smartgridipedia.org/index.php/Category:Use_C=
ases
, both =
the
Intelligrid and Southern California Edison use =
cases are good
3)  ZigBee/HomePlug Market =
Requirements and Use Cases (which we are
using for =
our Smart Energy V2 =
work):
 
 =

http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf=

Any other =
ones?
 
"The =
framework will also specify specify a way to support =
interface
profiles, =
..."
Can you expand on "interface =
profile".
 
 
"A document with operation and management advice =
about running a
network using these =
applications."
Is advice the right word? It =
seems like one or two advices are
sufficient to =
manage the network =
;-)
 
 
Regards, =
Benoit.
      =




I have =
put a new version of the WG charter proposal on the wiki =
page
        =










 
  









at http://6lowapp.net =
=3D
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
(charter text is at the end of the =
page).
 
Obviously, I =
could not pick up every comment that was on the =
list
(they were partially going in conflicting =
directions), but please =
do
 
   &nb=
sp;    









 
  









comment =
on the new =
version.
 
Gruesse, =
Carsten
 
________________=
_______________________________
6lowapp mailing =
list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
        =




_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
      =

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
 
    =

 
________________________________________=
_______
6lowapp mailing =
list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
 
The information contained in =
this message may be confidential and legally protected under applicable =
law. The message is intended solely for the addressee(s). If you are not =
the intended recipient, you are hereby notified that any use, =
forwarding, dissemination, or reproduction of this message is strictly =
prohibited and may be unlawful. If you are not the intended recipient, =
please contact the sender by return e-mail and destroy all copies of the =
original =
message.
___________________________________________=
____
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
 

 <= /o:p>


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<= /o:p>

 

------=_NextPart_000_0180_01CA6138.4C0836B0-- From d.sturek@att.net Mon Nov 9 12:42:44 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9E428C245 for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 12:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.242 X-Spam-Level: X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 4nphh8V5Z1U3 for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 12:42:42 -0800 (PST) Received: from smtp105.sbc.mail.gq1.yahoo.com (smtp105.sbc.mail.gq1.yahoo.com [67.195.14.108]) by core3.amsl.com (Postfix) with SMTP id 46AD628C233 for <6lowapp@ietf.org>; Mon, 9 Nov 2009 12:42:42 -0800 (PST) Received: (qmail 64776 invoked from network); 9 Nov 2009 20:43:06 -0000 Received: from host-160-85.meeting.ietf.org (d.sturek@133.93.160.85 with login) by smtp105.sbc.mail.gq1.yahoo.com with SMTP; 09 Nov 2009 12:43:05 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: TI1QPgQVM1nZdbqWk7oLFDw7T6IKm0O6Oheyex82yCgHnzPtdBba4n6wxzc8MGtWCq.Bj6fYgOpcdyIVer8WAYMUAvK0Jx3JHoFUYH2.wTqgzxobqYl42YfteunGeBGotcZD3E9X7ke2CU7PTVqaRvcZsABd1HrmFXGZGj28yvaB1HaaT8AJe33bSsdbphHRG82kS1WeIxQZ7ATVTEAmcHimS7P.BG18Ayn_E.7iF.8JFS604AsHCLX9z0XIcsssYUyC0spCgjt1mXlJdJORqvpJFZAO0GvxdT1qQU9ZMl51lhgp3A-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: References: <547D55FF-B03C-458E-A51C-3223D5F005F4@tzi.org> <517197C5-5B51-4A0F-9E18-6DC876EB971C@cs.columbia.edu> <7F90BA96-1AC8-4DBF-9F76-5B200CA118D4@cs.columbia.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D03E@SPO-EXVS-02.itron.com> <4AF7C18F.5030107@cisco.com> <9083133113177307269@unknownmsgid> In-Reply-To: Date: Mon, 9 Nov 2009 12:42:56 -0800 Message-ID: <018901ca617d$3ae409f0$b0ac1dd0$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018A_01CA613A.2CC0C9F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphSe4uDuWxklNTRH2YAjtqO/jHdQAMuEZg Content-Language: en-us Cc: "'Stuber, Michael'" , 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 20:42:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_018A_01CA613A.2CC0C9F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Have a look at the 6LowAPP presentation at the BOF. There is a slide outlining a typical CPU used on such a system. There is not a single set of network constraints or topologies. There are many networks deployed today using IEEE 802.15.4. Many of these networks run proprietary or vendor consortium standards (non-IP). The 6LowAPP problem statement (and 6LowPAN) capture what is needed to displace these solutions with IP. Don From: arjunrc@gmail.com [mailto:arjunrc@gmail.com] On Behalf Of Arjun Roychowdhury Sent: Monday, November 09, 2009 6:35 AM To: d.sturek@att.net Cc: Benoit Claise; Van Der Stok, Peter; Stuber, Michael; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net Okay, I am sorry, I am very confused now. Can someone please point me to a resource where I can read up what are the constraints for HAN devices this group is talking about, specifically: a) CPU constraints (and what sort of devices this applies/does not apply to) b) Network constraints c) What is the network topology for which modelling needs to be done to figure out whether a protocol is appropriate or not? I see numbers being talked about in this list and while discussing the charter, but I am unable to see a clear modeling that arrives at those numbers. regds arjun On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek wrote: 250 Kbps is the theoretical maximum on the data link. Considering back offs and other required channel operations (CSMA) the maximum you will see in practice is about 140 Kbps. Next, the 140 Kbps is from point to point (a device to its neighbor). Depending on the network topology and the data transfer characteristics (for example, if you had an application where predominant traffic is MP2P where all devices in a multihop network were to send data to a single access point) you might see less than 10K bps at the concentrator (again, depends on the data traffic model, the frequency of data transfer, the number of hops from leaf nodes in the network to the concentrator, etc.). Don From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Sunday, November 08, 2009 11:15 PM To: Van Der Stok, Peter Cc: Stuber, Michael; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net >From the requirement/use case remark in my initial email, I wanted to understand: how many constrained nodes in a single constrained network must share the 250kbit/s? For example, in case of discovery, concurrent events, concurrent queries, etc. IMHO, this is an important input for the protocol design, which I didn't get from the BOF. Regards, Benoit. Although I agree with the not challenged statement, a few updates: I expect a presence detector to send out a message once per second or per 10 seconds There may be 1 till 100 in one wireless mesh, dependent on office lay-out. The crux comes when an alarm hits. Then we will have an avalanche of messages and some can be just thrown away and a few need to be sent on through the routers to some central post(s)regardless. There is the challenge of overload handling. Peter -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Stuber, Michael Sent: Monday 9 November 2009 4:49 To: Henning Schulzrinne Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net The amount of bandwidth required per applications varies a great deal. Some devices, like light switches, or battery powered sensors may only send a message or two per day. Other devices such as energy usage monitors or electric vehicles may send a large number of updates. Electric meters may send current usage information to in-home displays every 10 seconds. Electric cars may start with an extended exchange to negotiate a charging regime, followed by periodic updates to in-home displays regarding the device's state of charge. Most of the networks that I worry about are indeed likely to be small (>30 nodes); however, there are places where folks have been running larger smart energy networks for meter data collection that are upwards of thousands of nodes. The 802.15.4 T4G SUN work is likely to expand this trend. Starting with efficient protocols provides headroom for growth in the application later. -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Sunday, November 08, 2009 7:25 PM To: Stuber, Michael Cc: Benoit Claise; 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net Right, but the bandwidth per device is really, really low. How many bits do you send each day to a thermostat or light switch? Are there any measurements of the realistic signaling load in such networks? I'm worried about artificially constraining the solution space to solve a practical non-problem. Henning On Nov 8, 2009, at 10:18 PM, Stuber, Michael wrote: Keep in mind though, that much of that bandwidth is shared on these networks In an 802.15.4 environment, devices will share a single channel. If this work is successful there will be many constrained nodes within the network, rather than a single pair of nodes. -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, November 08, 2009 6:33 PM To: Benoit Claise Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net I find this conflation of Smart Energy/HAN and LowApp confusing. Most of the in-home networks are not exactly "challenged". Even ZigBee has 250 kb/s (or 20 kb/s in the lowest-bandwidth mode), i.e., equivalent to early DSL or 1990's modems. Henning On Nov 8, 2009, at 9:20 PM, Benoit Claise wrote: Carsten, Thanks for the new charter proposal. - "This WG is concentrating on requirements from energy (e.g. Smart Energy 2.0) and building management applications." Is the goal to describe these requirements in the "objectives and architecture" document? If not, where can we understand those requirements from? The following were mentioned on the list: There are a lot of use cases to start with. Here is a starter set: 1) OpenHAN: http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20- %20v1.04%20-% 200808 19-1.pdf 2) SmartGridipedia: http://www.smartgridipedia.org/index.php/Category:Use_Cases , both the Intelligrid and Southern California Edison use cases are good 3) ZigBee/HomePlug Market Requirements and Use Cases (which we are using for our Smart Energy V2 work): http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf Any other ones? "The framework will also specify specify a way to support interface profiles, ..." Can you expand on "interface profile". "A document with operation and management advice about running a network using these applications." Is advice the right word? It seems like one or two advices are sufficient to manage the network ;-) Regards, Benoit. I have put a new version of the WG charter proposal on the wiki page at http://6lowapp.net = http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp (charter text is at the end of the page). Obviously, I could not pick up every comment that was on the list (they were partially going in conflicting directions), but please do comment on the new version. Gruesse, Carsten _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp *********************************************DISCLAIMER********************* ************************ The email is subject to Disclaimer as per - http://www.hsc.com/tabid/91/Default.aspx#emaildisclaimer -- Arjun Roychowdhury ------=_NextPart_000_018A_01CA613A.2CC0C9F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Have a look at the 6LowAPP presentation at the = BOF.   There is a slide outlining a typical CPU used on such a = system.

 

There is not a single set of network constraints or topologies.   There are many networks deployed today using = IEEE 802.15.4.  Many of these networks run proprietary or vendor consortium standards = (non-IP).  The 6LowAPP problem statement (and 6LowPAN) capture what is needed to = displace these solutions with IP.

 

Don

 

 

From:= = arjunrc@gmail.com [mailto:arjunrc@gmail.com] On Behalf Of Arjun Roychowdhury
Sent: Monday, November 09, 2009 6:35 AM
To: d.sturek@att.net
Cc: Benoit Claise; Van Der Stok, Peter; Stuber, Michael; 6lowapp@ietf.org
Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

 

Okay, I am sorry, I am very confused now. Can = someone please point me to a resource where I can read up what are the constraints for = HAN devices this group is talking about, specifically:

 

a) CPU constraints (and what sort of devices this applies/does not apply to)

b) Network constraints

c) What is the network topology for which modelling = needs to be done to figure out whether a protocol is appropriate or = not?

 

I see numbers being talked about in this list and = while discussing the charter, but I am unable to see a clear modeling that = arrives at those numbers.

 

regds

arjun

 

On Mon, Nov 9, 2009 at 6:30 AM, Don Sturek <d.sturek@att.net> = wrote:

250 Kbps is the theoretical = maximum on the data link.   Considering back offs and other required = channel operations (CSMA) the maximum you will see in practice is about 140 = Kbps.

 

Next, the 140 Kbps is from = point to point (a device to its neighbor).  Depending on the network = topology and the data transfer characteristics (for example, if you had an = application where predominant traffic is MP2P where all devices in a multihop network were = to send data to a single access point) you might see less than 10K bps at = the concentrator (again, depends on the data traffic model, the frequency of = data transfer, the number of hops from leaf nodes in the network to the concentrator, etc.).

 

Don

 

 

From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Sunday, November 08, 2009 11:15 PM
To: Van Der Stok, Peter
Cc: Stuber, Michael; 6lowapp@ietf.org


Subject: Re: [6lowapp] Next version of charter proposal up on 6lowapp.net

 <= /o:p>

From the requirement/use case remark in my initial email, I wanted to = understand: how many constrained nodes in a single constrained network must share = the 250kbit/s? For example, in case of discovery, concurrent events, = concurrent queries, etc.
IMHO, this is an important input for the protocol design, which I didn't = get from the BOF.

Regards, Benoit.

Although I agree with the not challenged statement, a few =
updates:
I expect a presence detector to send out a =
message once per second or per 10 seconds
There may =
be 1 till 100 in one wireless mesh, dependent on office =
lay-out.
The crux comes when an alarm hits. Then we =
will have an avalanche of messages and some can be just thrown away and =
a few need to be sent on through the routers to some central =
post(s)regardless. There is the challenge of overload =
handling.
 
Peter
 
 
----=
-Original Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of =
Stuber, Michael
Sent: Monday 9 November 2009 =
4:49
To: Henning =
Schulzrinne
Cc: 6lowapp@ietf.org
Subject: Re: =
[6lowapp] Next version of charter proposal up on 6lowapp.net
 <=
/pre>
The amount of bandwidth required per applications varies a =
great deal.
Some devices, like light switches, or =
battery powered sensors may only
send a message or =
two per day.  Other devices such as energy =
usage
monitors or electric vehicles may send a =
large number of updates.
Electric meters may send =
current usage information to in-home displays
every =
10 seconds.  Electric cars may start with an extended exchange =
to
negotiate a charging regime, followed by =
periodic updates to in-home
displays regarding the =
device's state of =
charge.
 
Most of the =
networks that I worry about are indeed likely to be =
small
(>30 nodes); however, there are places =
where folks have been running
larger smart energy =
networks for meter data collection that are =
upwards
of thousands of nodes.  The 802.15.4 =
T4G SUN work is likely to expand
this trend.  =
Starting with efficient protocols provides headroom =
for
growth in the application =
later.
 
-----Original =
Message-----
From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Se=
nt: Sunday, November 08, 2009 7:25 PM
To: Stuber, =
Michael
Cc: Benoit Claise; 6lowapp@ietf.org
Subject: Re: =
[6lowapp] Next version of charter proposal up on
6lowapp.net
 <=
/pre>
Right, but the bandwidth per device is really, really low. How =
many bits
do you send each day to a thermostat or =
light switch? Are there any
measurements of the =
realistic signaling load in such =
networks?
 
I'm worried =
about artificially constraining the solution space to =
solve
a practical =
non-problem.
 
 =

 
Henning
 
On Nov 8, 2009, at 10:18 PM, Stuber, =
Michael wrote:
 
  =




Keep in =
mind though, that much of that bandwidth is shared on =
these
networks  In an 802.15.4 environment, =
devices will share a single
channel.  If this =
work is successful there will be many =
constrained
nodes within the network, rather than a =
single pair of =
nodes.
 
-----Original =
Message-----
From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] =
On
Behalf Of Henning =
Schulzrinne
Sent: Sunday, November 08, 2009 6:33 =
PM
To: Benoit Claise
Cc: 6lowapp@ietf.org
Subject: Re: =
[6lowapp] Next version of charter proposal up on
6lowapp.net
 <=
/pre>
I find this conflation of Smart Energy/HAN and LowApp =
confusing.
Most of
the in-home =
networks are not exactly "challenged". Even ZigBee has =
250
    =




 
  



kb/s (or =
20 kb/s in the lowest-bandwidth mode), i.e., equivalent =
to
early DSL or 1990's =
modems.
 
Henning
 
 
 
On Nov 8, 2009, at 9:20 PM, Benoit Claise =
wrote:
 
   =
; 



Carsten,
 
Thanks for the new charter =
proposal.
 
- "This =
WG is concentrating on requirements from energy (e.g. =
Smart
Energy 2.0) and building management =
applications."
Is the goal to describe these =
requirements in the "objectives =
and
architecture" =
document?
If not, where can we understand those =
requirements from?
The following were mentioned on =
the list:
 
There are a =
lot of use cases to start with.  Here is a starter =
set:
1)  =
OpenHAN:
 
http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%2=
0-
%20v1.04%20-%
200808
 
19-1.pdf
2)  =
SmartGridipedia:
 
http://www.smartgridipedia.org/index.php/Category:Use_C=
ases
, both =
the
Intelligrid and Southern California Edison use =
cases are good
3)  ZigBee/HomePlug Market =
Requirements and Use Cases (which we are
using for =
our Smart Energy V2 =
work):
 
 =

 
http://www.homeplug.org/products/ZBHP_SE_MRD_090624.pdf=

Any other =
ones?
 
"The =
framework will also specify specify a way to support =
interface
profiles, =
..."
Can you expand on "interface =
profile".
 
 
"A document with operation and management advice =
about running a
network using these =
applications."
Is advice the right word? It =
seems like one or two advices are
sufficient to =
manage the network =
;-)
 
 
Regards, =
Benoit.
      =




I have =
put a new version of the WG charter proposal on the wiki =
page
        =










 
  









at http://6lowapp.net =
=3D
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
(charter text is at the end of the =
page).
 
Obviously, I =
could not pick up every comment that was on the =
list
(they were partially going in conflicting =
directions), but please =
do
 
 
        =










 
  









comment =
on the new =
version.
 
Gruesse, =
Carsten
 
________________=
_______________________________
6lowapp mailing =
list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
        =




_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
      =

_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
 
    =

 
________________________________________=
_______
6lowapp mailing =
list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
 
The information contained in =
this message may be confidential and legally protected under applicable =
law. The message is intended solely for the addressee(s). If you are not =
the intended recipient, you are hereby notified that any use, =
forwarding, dissemination, or reproduction of this message is strictly =
prohibited and may be unlawful. If you are not the intended recipient, =
please contact the sender by return e-mail and destroy all copies of the =
original =
message.
___________________________________________=
____
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp<=
/o:p>
 

 <= /o:p>


_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp






*********************************************DISCLAIMER******************= ***************************
The email is subject to Disclaimer as per - http://www.hsc.com/tabid/91/Default.aspx#emaildisclaime= r




--
Arjun Roychowdhury

------=_NextPart_000_018A_01CA613A.2CC0C9F0-- From pister@eecs.berkeley.edu Mon Nov 9 18:53:03 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C863A68C2; Mon, 9 Nov 2009 18:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 yo0rF3LfP7Fk; Mon, 9 Nov 2009 18:53:02 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 3E7123A6841; Mon, 9 Nov 2009 18:53:02 -0800 (PST) Received: from [192.168.1.100] (c-24-4-148-227.hsd1.ca.comcast.net [24.4.148.227]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nAA2rOdn019503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 18:53:26 -0800 (PST) Message-ID: <4AF8D5A0.1020600@eecs.berkeley.edu> Date: Mon, 09 Nov 2009 18:53:20 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jonathan Hui References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> In-Reply-To: <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: [6lowapp] hardware trends, new vs. existing protocols [Re: [6lowpan] 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:53:03 -0000 +1 in favor of using optimized DHCP if possible (no opinion on 'if possible'), rather than inventing something new. As I've shared with several people in private emails recently, it's pretty clear that lowpan nodes are going to get more capable moving forward, not less. Why? Radios don't scale down in area when you scale CMOS processes. Today's 15.4 single-chip nodes are made in technologies that are several (maybe five?) generations behind the cutting edge. This makes economic sense because the sales volumes don't support the need for expensive mask sets yet. When there's a volume application, and someone puts a 5mm2 radio into modern CMOS, it just doesn't make sense to put 48kB of rom/flash and 10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and many tens of kB of RAM, and the radio will still be by far the biggest thing on the chip. Even the 48k/10k node from the (very nice) 6lowapp bof presentation is not up to commercial standards - it's a five year old, expensive, academic platform - great for it's time, but old. Single-chip nodes from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit processor, and they aren't made in cutting-edge processes yet either. Life is just going to get better. Let's try to find the smallest optimized set of *existing* protocols that serve our needs, that run on the existing new low-cost hardware (not the old workhorses). Let's invent the absolute minimum of new "optimized" protocols, because it's not at all clear to me that we are optimizing the right things at this point. The less we invent, the broader the set of applications and applications programmers we address. ksjp Jonathan Hui wrote: > > On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: > >> Again, entirely getting rid of a function is always the best >> optimization. >> Can we do that for DAD? > > The *need* for DAD is the core question for me. As specified within > 6lowpan-nd now, IPv6 addresses are maintained using a centralized > protocol. That protocol looks and smells like DHCP - there's > request/response, lease times, relays. The whiteboard may also > administratively assign addresses. So in the end, it's not clear to > me why we would need to *detect* duplicates when we essentially > *avoid* them from the beginning. > > I've voiced my comment several times over the past 1+ years and > presented a draft that argues for the use of optimized DHCP in Dublin, > so this is not new from my end. The fact that the current 6lowpan-nd > document has evolved towards using DHCP-like mechanisms is not an > accident. But if what we do is DHCP-like, it would seem to make sense > to utilize existing DHCP infrastructure rather than defining something > new. > > -- > Jonathan Hui > From pthubert@cisco.com Mon Nov 9 18:57:38 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752AC3A68F3; Mon, 9 Nov 2009 18:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.78 X-Spam-Level: X-Spam-Status: No, score=-9.78 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ntnHKjC9p+HZ; Mon, 9 Nov 2009 18:57:37 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D62793A67BD; Mon, 9 Nov 2009 18:57:36 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYAAMNl+EqQ/uCWe2dsb2JhbACbfQEBFiQGqHWXXIQ+BIFoiiM X-IronPort-AV: E=Sophos;i="4.44,712,1249257600"; d="scan'208";a="54011660" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 02:58:02 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA2w27G008879; Tue, 10 Nov 2009 02:58:02 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 03:58:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 03:57:58 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D96021B@XMB-AMS-107.cisco.com> In-Reply-To: <4AF8D5A0.1020600@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcphsP7gZXYrOvV7S0eDgCxIjmrefwAACwZw References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "Kris Pister" , "Jonathan Hui" , "Ralph Droms (rdroms)" X-OriginalArrivalTime: 10 Nov 2009 02:58:02.0803 (UTC) FILETIME=[9E656030:01CA61B1] Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 02:57:38 -0000 Hi Kris: Nothing says that DHCP cannot be used in that world, for what DHCP is for.=20 The question is whether we can use DHCP as ND.=20 My short answer is no, these are 2 different models, like a push and a pull. I agree with Jonathan that there are good reasons why the flows in 6LoWPAN ND look so much like DHCP. Where I disagree is pushing the analogy as far as getting confused between the 2. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Kris Pister >Sent: mardi 10 novembre 2009 03:53 >To: Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] > >+1 in favor of using optimized DHCP if possible (no opinion on 'if >possible'), rather than inventing something new. > >As I've shared with several people in private emails recently, it's >pretty clear that lowpan nodes are going to get more capable moving >forward, not less. Why? Radios don't scale down in area when you scale >CMOS processes. Today's 15.4 single-chip nodes are made in technologies >that are several (maybe five?) generations behind the cutting edge. >This makes economic sense because the sales volumes don't support the >need for expensive mask sets yet. >When there's a volume application, and someone puts a 5mm2 radio into >modern CMOS, it just doesn't make sense to put 48kB of rom/flash and >10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and >many tens of kB of RAM, and the radio will still be by far the biggest >thing on the chip. > >Even the 48k/10k node from the (very nice) 6lowapp bof presentation is >not up to commercial standards - it's a five year old, expensive, >academic platform - great for it's time, but old. Single-chip nodes >from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit >processor, and they aren't made in cutting-edge processes yet either. >Life is just going to get better. Let's try to find the smallest >optimized set of *existing* protocols that serve our needs, that run on >the existing new low-cost hardware (not the old workhorses). Let's >invent the absolute minimum of new "optimized" protocols, because it's >not at all clear to me that we are optimizing the right things at this >point. The less we invent, the broader the set of applications and >applications programmers we address. > >ksjp > >Jonathan Hui wrote: >> >> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >> >>> Again, entirely getting rid of a function is always the best >>> optimization. >>> Can we do that for DAD? >> >> The *need* for DAD is the core question for me. As specified within >> 6lowpan-nd now, IPv6 addresses are maintained using a centralized >> protocol. That protocol looks and smells like DHCP - there's >> request/response, lease times, relays. The whiteboard may also >> administratively assign addresses. So in the end, it's not clear to >> me why we would need to *detect* duplicates when we essentially >> *avoid* them from the beginning. >> >> I've voiced my comment several times over the past 1+ years and >> presented a draft that argues for the use of optimized DHCP in Dublin, >> so this is not new from my end. The fact that the current 6lowpan-nd >> document has evolved towards using DHCP-like mechanisms is not an >> accident. But if what we do is DHCP-like, it would seem to make sense >> to utilize existing DHCP infrastructure rather than defining something >> new. >> >> -- >> Jonathan Hui >> >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Mon Nov 9 19:46:35 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658F23A6822; Mon, 9 Nov 2009 19:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 buaaZ66kOD9u; Mon, 9 Nov 2009 19:46:34 -0800 (PST) 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 492823A6767; Mon, 9 Nov 2009 19:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nAA3kkcu003525; Tue, 10 Nov 2009 04:46:47 +0100 (CET) Received: from host-24-126.meeting.ietf.org (host-24-126.meeting.ietf.org [133.93.24.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 70A60B818; Tue, 10 Nov 2009 04:46:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Carsten Bormann In-Reply-To: <4AF8D5A0.1020600@eecs.berkeley.edu> Date: Tue, 10 Nov 2009 12:46:39 +0900 Content-Transfer-Encoding: 7bit Message-Id: <7DADDFD8-D1E1-4DF2-BD57-1A8ED1CFA5B0@tzi.org> References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> To: Kris Pister X-Mailer: Apple Mail (2.1076) Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:46:35 -0000 On Nov 10, 2009, at 11:53, Kris Pister wrote: > +1 in favor of using optimized DHCP if possible (no opinion on 'if > possible'), rather than inventing something new. I'm a big fan of not reinventing the wheel. When what we need is a cup, however, we should not try to use wheels. I have lots of experience with misappropriating protocols Gruesse, Carsten From Michael.Stuber@itron.com Mon Nov 9 19:56:22 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E91E3A6910; Mon, 9 Nov 2009 19:56:22 -0800 (PST) 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 b2rYpz+WZdWU; Mon, 9 Nov 2009 19:56:21 -0800 (PST) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 467503A685B; Mon, 9 Nov 2009 19:56:21 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 19:56:49 -0800 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> In-Reply-To: <4AF8D5A0.1020600@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcphsP24BwjkVxaNSQWl7M9/snvrqgABq6gA References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> From: "Stuber, Michael" To: "Kris Pister" , "Jonathan Hui" Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:56:22 -0000 Life may be getting better, but that doesn't mean we have the wrong target. Abandoning the installed base just goes to reinforce the idea that IP isn't an appropriate technology for things. Qualifications for parts in appliances, meters, and cars may take much longer than in other consumer electronics. There are lots of products shipping today with 802.15.4 chips that do not match the (nicer) specs you outline below. If we want to enable IP everywhere, we must acknowledge that small footprint parts are an important part of "everywhere." That said, I too am in favor of exploring optimized DHCP. It would provide the flexibility of living in an edge router, or being centralized. It is a well defined, characterized protocol. =20 -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Kris Pister Sent: Monday, November 09, 2009 6:53 PM To: Jonathan Hui Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] +1 in favor of using optimized DHCP if possible (no opinion on 'if=20 possible'), rather than inventing something new. As I've shared with several people in private emails recently, it's=20 pretty clear that lowpan nodes are going to get more capable moving=20 forward, not less. Why? Radios don't scale down in area when you scale CMOS processes. Today's 15.4 single-chip nodes are made in technologies that are several (maybe five?) generations behind the cutting edge. =20 This makes economic sense because the sales volumes don't support the=20 need for expensive mask sets yet. When there's a volume application, and someone puts a 5mm2 radio into=20 modern CMOS, it just doesn't make sense to put 48kB of rom/flash and=20 10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and=20 many tens of kB of RAM, and the radio will still be by far the biggest=20 thing on the chip. Even the 48k/10k node from the (very nice) 6lowapp bof presentation is=20 not up to commercial standards - it's a five year old, expensive,=20 academic platform - great for it's time, but old. Single-chip nodes=20 from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit=20 processor, and they aren't made in cutting-edge processes yet either.=20 Life is just going to get better. Let's try to find the smallest=20 optimized set of *existing* protocols that serve our needs, that run on=20 the existing new low-cost hardware (not the old workhorses). Let's=20 invent the absolute minimum of new "optimized" protocols, because it's=20 not at all clear to me that we are optimizing the right things at this=20 point. The less we invent, the broader the set of applications and=20 applications programmers we address. ksjp Jonathan Hui wrote: > > On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: > >> Again, entirely getting rid of a function is always the best=20 >> optimization. >> Can we do that for DAD? > > The *need* for DAD is the core question for me. As specified within=20 > 6lowpan-nd now, IPv6 addresses are maintained using a centralized=20 > protocol. That protocol looks and smells like DHCP - there's=20 > request/response, lease times, relays. The whiteboard may also=20 > administratively assign addresses. So in the end, it's not clear to=20 > me why we would need to *detect* duplicates when we essentially=20 > *avoid* them from the beginning. > > I've voiced my comment several times over the past 1+ years and=20 > presented a draft that argues for the use of optimized DHCP in Dublin, > so this is not new from my end. The fact that the current 6lowpan-nd=20 > document has evolved towards using DHCP-like mechanisms is not an=20 > accident. But if what we do is DHCP-like, it would seem to make sense > to utilize existing DHCP infrastructure rather than defining something > new. > > --=20 > Jonathan Hui > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From Michael.Stuber@itron.com Mon Nov 9 19:57:47 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8333A6930; Mon, 9 Nov 2009 19:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_63=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 kyOlH8Aa+1Lm; Mon, 9 Nov 2009 19:57:46 -0800 (PST) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 6AB403A6921; Mon, 9 Nov 2009 19:57:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 19:58:15 -0800 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE0242D3B2@SPO-EXVS-02.itron.com> In-Reply-To: <7DADDFD8-D1E1-4DF2-BD57-1A8ED1CFA5B0@tzi.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcphuHr+x5xRkMqERK2++6ZB2roPTQAAWbVA References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com><4AF8D5A0.1020600@eecs.berkeley.edu> <7DADDFD8-D1E1-4DF2-BD57-1A8ED1CFA5B0@tzi.org> From: "Stuber, Michael" To: "Carsten Bormann" , "Kris Pister" Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 03:57:47 -0000 So Carsten, are you volunteering to guide us on the best way to misappropriate the protocol? =20 :) -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Carsten Bormann Sent: Monday, November 09, 2009 7:47 PM To: Kris Pister Cc: 6lowpan; 6lowapp@ietf.org Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] On Nov 10, 2009, at 11:53, Kris Pister wrote: > +1 in favor of using optimized DHCP if possible (no opinion on 'if =20 > possible'), rather than inventing something new. I'm a big fan of not reinventing the wheel. When what we need is a cup, however, we should not try to use wheels. I have lots of experience with misappropriating protocols Gruesse, Carsten _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From pthubert@cisco.com Mon Nov 9 20:22:03 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 637F43A6824; Mon, 9 Nov 2009 20:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.493 X-Spam-Level: X-Spam-Status: No, score=-9.493 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 eKosRSDLR1QW; Mon, 9 Nov 2009 20:22:02 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9E7903A67BD; Mon, 9 Nov 2009 20:22:01 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYAAK55+EqQ/uCWe2dsb2JhbACbfAEBFiQGqD6XZYQ+BIFoGYoK X-IronPort-AV: E=Sophos;i="4.44,713,1249257600"; d="scan'208";a="54014003" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 04:22:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA4MQvM019112; Tue, 10 Nov 2009 04:22:26 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 05:22:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 05:21:09 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D960226@XMB-AMS-107.cisco.com> In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcphsP24BwjkVxaNSQWl7M9/snvrqgABq6gAAAEv34A= References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com><4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> From: "Pascal Thubert (pthubert)" To: "Stuber, Michael" , "Kris Pister" , "Jonathan Hui" X-OriginalArrivalTime: 10 Nov 2009 04:22:26.0369 (UTC) FILETIME=[68843B10:01CA61BD] Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:22:03 -0000 Hi Michael; To be very clear, I have nothing against using / optimizing DHCP in LoWPAN. All the contrary. A great item for rechartering I suspect. Just don't call it ND.=20 Note that even if an address is obtained via DHCP, it has to be DADed through ND.=20 And if a backbone is used, the address has to be proxied. Etc... IOW, DHCP is an alternate to SLAAC to get an address (and other stuff), but the ND draft is still needed.=20 DHCP does not remove the need for ND, never did still does not. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stuber, Michael >Sent: mardi 10 novembre 2009 04:57 >To: Kris Pister; Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] > >Life may be getting better, but that doesn't mean we have the wrong >target. Abandoning the installed base just goes to reinforce the idea >that IP isn't an appropriate technology for things. Qualifications for >parts in appliances, meters, and cars may take much longer than in other >consumer electronics. There are lots of products shipping today with >802.15.4 chips that do not match the (nicer) specs you outline below. >If we want to enable IP everywhere, we must acknowledge that small >footprint parts are an important part of "everywhere." > >That said, I too am in favor of exploring optimized DHCP. It would >provide the flexibility of living in an edge router, or being >centralized. It is a well defined, characterized protocol. > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >Behalf Of Kris Pister >Sent: Monday, November 09, 2009 6:53 PM >To: Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 >usage in LLNs] > >+1 in favor of using optimized DHCP if possible (no opinion on 'if >possible'), rather than inventing something new. > >As I've shared with several people in private emails recently, it's >pretty clear that lowpan nodes are going to get more capable moving >forward, not less. Why? Radios don't scale down in area when you scale > >CMOS processes. Today's 15.4 single-chip nodes are made in technologies > >that are several (maybe five?) generations behind the cutting edge. >This makes economic sense because the sales volumes don't support the >need for expensive mask sets yet. >When there's a volume application, and someone puts a 5mm2 radio into >modern CMOS, it just doesn't make sense to put 48kB of rom/flash and >10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and >many tens of kB of RAM, and the radio will still be by far the biggest >thing on the chip. > >Even the 48k/10k node from the (very nice) 6lowapp bof presentation is >not up to commercial standards - it's a five year old, expensive, >academic platform - great for it's time, but old. Single-chip nodes >from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit >processor, and they aren't made in cutting-edge processes yet either. >Life is just going to get better. Let's try to find the smallest >optimized set of *existing* protocols that serve our needs, that run on >the existing new low-cost hardware (not the old workhorses). Let's >invent the absolute minimum of new "optimized" protocols, because it's >not at all clear to me that we are optimizing the right things at this >point. The less we invent, the broader the set of applications and >applications programmers we address. > >ksjp > >Jonathan Hui wrote: >> >> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >> >>> Again, entirely getting rid of a function is always the best >>> optimization. >>> Can we do that for DAD? >> >> The *need* for DAD is the core question for me. As specified within >> 6lowpan-nd now, IPv6 addresses are maintained using a centralized >> protocol. That protocol looks and smells like DHCP - there's >> request/response, lease times, relays. The whiteboard may also >> administratively assign addresses. So in the end, it's not clear to >> me why we would need to *detect* duplicates when we essentially >> *avoid* them from the beginning. >> >> I've voiced my comment several times over the past 1+ years and >> presented a draft that argues for the use of optimized DHCP in Dublin, > >> so this is not new from my end. The fact that the current 6lowpan-nd >> document has evolved towards using DHCP-like mechanisms is not an >> accident. But if what we do is DHCP-like, it would seem to make sense > >> to utilize existing DHCP infrastructure rather than defining something > >> new. >> >> -- >> Jonathan Hui >> >_______________________________________________ >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 From Michael.Stuber@itron.com Mon Nov 9 20:40:08 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526FC3A6820; Mon, 9 Nov 2009 20:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_63=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 RAxtelMpeSN0; Mon, 9 Nov 2009 20:40:07 -0800 (PST) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 382E53A680F; Mon, 9 Nov 2009 20:40:07 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Nov 2009 20:40:35 -0800 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE0242D3BF@SPO-EXVS-02.itron.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D960226@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcphsP24BwjkVxaNSQWl7M9/snvrqgABq6gAAAEv34AAAFs9YA== References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com><4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <6A2A459175DABE4BB11DE2026AA50A5D960226@XMB-AMS-107.cisco.com> From: "Stuber, Michael" To: "Pascal Thubert (pthubert)" , "Kris Pister" , "Jonathan Hui" Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:40:08 -0000 I realize that I'm new here, and I may be asking questions that have already been hashed to death, but I confess I don't feel think that DAD is appropriate on 802.15.4 mesh networks, unless the scope is limited to the immediate neighbors. Imagine a PAN with hundreds of nodes trying to form. =20 I understand that this may run afoul of the v6 RFCs, but I believe the idea with 6LowPAN was to have an adaption for 802.15.4 networks, and I believe this would be a reasonable adaption. I for one am willing to give up mesh-wide DAD in this context. =20 -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Monday, November 09, 2009 8:21 PM To: Stuber, Michael; Kris Pister; Jonathan Hui Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] Hi Michael; To be very clear, I have nothing against using / optimizing DHCP in LoWPAN. All the contrary. A great item for rechartering I suspect. Just don't call it ND.=20 Note that even if an address is obtained via DHCP, it has to be DADed through ND.=20 And if a backbone is used, the address has to be proxied. Etc... IOW, DHCP is an alternate to SLAAC to get an address (and other stuff), but the ND draft is still needed.=20 DHCP does not remove the need for ND, never did still does not. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stuber, Michael >Sent: mardi 10 novembre 2009 04:57 >To: Kris Pister; Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] > >Life may be getting better, but that doesn't mean we have the wrong=20 >target. Abandoning the installed base just goes to reinforce the idea=20 >that IP isn't an appropriate technology for things. Qualifications for >parts in appliances, meters, and cars may take much longer than in other >consumer electronics. There are lots of products shipping today with >802.15.4 chips that do not match the (nicer) specs you outline below. >If we want to enable IP everywhere, we must acknowledge that small=20 >footprint parts are an important part of "everywhere." > >That said, I too am in favor of exploring optimized DHCP. It would=20 >provide the flexibility of living in an edge router, or being=20 >centralized. It is a well defined, characterized protocol. > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On=20 >Behalf Of Kris Pister >Sent: Monday, November 09, 2009 6:53 PM >To: Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 >usage in LLNs] > >+1 in favor of using optimized DHCP if possible (no opinion on 'if >possible'), rather than inventing something new. > >As I've shared with several people in private emails recently, it's=20 >pretty clear that lowpan nodes are going to get more capable moving=20 >forward, not less. Why? Radios don't scale down in area when you scale > >CMOS processes. Today's 15.4 single-chip nodes are made in technologies > >that are several (maybe five?) generations behind the cutting edge. >This makes economic sense because the sales volumes don't support the=20 >need for expensive mask sets yet. >When there's a volume application, and someone puts a 5mm2 radio into=20 >modern CMOS, it just doesn't make sense to put 48kB of rom/flash and=20 >10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and=20 >many tens of kB of RAM, and the radio will still be by far the biggest=20 >thing on the chip. > >Even the 48k/10k node from the (very nice) 6lowapp bof presentation is=20 >not up to commercial standards - it's a five year old, expensive,=20 >academic platform - great for it's time, but old. Single-chip nodes=20 >from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit >processor, and they aren't made in cutting-edge processes yet either. >Life is just going to get better. Let's try to find the smallest=20 >optimized set of *existing* protocols that serve our needs, that run on >the existing new low-cost hardware (not the old workhorses). Let's=20 >invent the absolute minimum of new "optimized" protocols, because it's=20 >not at all clear to me that we are optimizing the right things at this=20 >point. The less we invent, the broader the set of applications and=20 >applications programmers we address. > >ksjp > >Jonathan Hui wrote: >> >> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >> >>> Again, entirely getting rid of a function is always the best=20 >>> optimization. >>> Can we do that for DAD? >> >> The *need* for DAD is the core question for me. As specified within=20 >> 6lowpan-nd now, IPv6 addresses are maintained using a centralized=20 >> protocol. That protocol looks and smells like DHCP - there's=20 >> request/response, lease times, relays. The whiteboard may also=20 >> administratively assign addresses. So in the end, it's not clear to=20 >> me why we would need to *detect* duplicates when we essentially >> *avoid* them from the beginning. >> >> I've voiced my comment several times over the past 1+ years and=20 >> presented a draft that argues for the use of optimized DHCP in Dublin, > >> so this is not new from my end. The fact that the current 6lowpan-nd >> document has evolved towards using DHCP-like mechanisms is not an=20 >> accident. But if what we do is DHCP-like, it would seem to make sense > >> to utilize existing DHCP infrastructure rather than defining something > >> new. >> >> -- >> Jonathan Hui >> >_______________________________________________ >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 From pthubert@cisco.com Mon Nov 9 20:47:56 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672053A6820; Mon, 9 Nov 2009 20:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] 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 qu4eVL5Qkj9z; Mon, 9 Nov 2009 20:47:55 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7D5523A680F; Mon, 9 Nov 2009 20:47:54 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYAAIp/+EqQ/uCWe2dsb2JhbACbfAEBFiQGqCCXaYQ+BIFoGYoK X-IronPort-AV: E=Sophos;i="4.44,713,1249257600"; d="scan'208";a="54014602" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 04:48:20 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA4mIBm022181; Tue, 10 Nov 2009 04:48:18 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 05:48:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 05:48:14 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D96022B@XMB-AMS-107.cisco.com> In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE0242D3BF@SPO-EXVS-02.itron.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcphsP24BwjkVxaNSQWl7M9/snvrqgABq6gAAAEv34AAAFs9YAAAr+2A References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com><4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <6A2A459175DABE4BB11DE2026AA50A5D960226@XMB-AMS-107.cisco.com> <05C6A38D732F1144A8C4016BA4416BFE0242D3BF@SPO-EXVS-02.itron.com> From: "Pascal Thubert (pthubert)" To: "Stuber, Michael" , "Kris Pister" , "Jonathan Hui" X-OriginalArrivalTime: 10 Nov 2009 04:48:18.0341 (UTC) FILETIME=[05905D50:01CA61C1] Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:47:56 -0000 Hi Michael: My take is that address ownership and uniqueness is a fundamental assumption of the IPv6 architecture and it must be ensured. The current ND does that at low cost. Basically similar to the cost of DHCP, with similar flows. Pascal >-----Original Message----- >From: Stuber, Michael [mailto:Michael.Stuber@itron.com] >Sent: mardi 10 novembre 2009 05:41 >To: Pascal Thubert (pthubert); Kris Pister; Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] > >I realize that I'm new here, and I may be asking questions that have >already been hashed to death, but I confess I don't feel think that DAD >is appropriate on 802.15.4 mesh networks, unless the scope is limited to >the immediate neighbors. Imagine a PAN with hundreds of nodes trying to >form. > >I understand that this may run afoul of the v6 RFCs, but I believe the >idea with 6LowPAN was to have an adaption for 802.15.4 networks, and I >believe this would be a reasonable adaption. I for one am willing to >give up mesh-wide DAD in this context. > >-----Original Message----- >From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] >Sent: Monday, November 09, 2009 8:21 PM >To: Stuber, Michael; Kris Pister; Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re: >4861 usage in LLNs] > >Hi Michael; > >To be very clear, I have nothing against using / optimizing DHCP in >LoWPAN. All the contrary. >A great item for rechartering I suspect. Just don't call it ND. > >Note that even if an address is obtained via DHCP, it has to be DADed >through ND. >And if a backbone is used, the address has to be proxied. Etc... > >IOW, DHCP is an alternate to SLAAC to get an address (and other stuff), >but the ND draft is still needed. >DHCP does not remove the need for ND, never did still does not. > >Pascal > >>-----Original Message----- >>From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >Behalf Of Stuber, Michael >>Sent: mardi 10 novembre 2009 04:57 >>To: Kris Pister; Jonathan Hui >>Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >>Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re: >4861 usage in LLNs] >> >>Life may be getting better, but that doesn't mean we have the wrong >>target. Abandoning the installed base just goes to reinforce the idea >>that IP isn't an appropriate technology for things. Qualifications for > >>parts in appliances, meters, and cars may take much longer than in >other >>consumer electronics. There are lots of products shipping today with >>802.15.4 chips that do not match the (nicer) specs you outline below. >>If we want to enable IP everywhere, we must acknowledge that small >>footprint parts are an important part of "everywhere." >> >>That said, I too am in favor of exploring optimized DHCP. It would >>provide the flexibility of living in an edge router, or being >>centralized. It is a well defined, characterized protocol. >> >>-----Original Message----- >>From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>Behalf Of Kris Pister >>Sent: Monday, November 09, 2009 6:53 PM >>To: Jonathan Hui >>Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >>Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: >4861 >>usage in LLNs] >> >>+1 in favor of using optimized DHCP if possible (no opinion on 'if >>possible'), rather than inventing something new. >> >>As I've shared with several people in private emails recently, it's >>pretty clear that lowpan nodes are going to get more capable moving >>forward, not less. Why? Radios don't scale down in area when you >scale >> >>CMOS processes. Today's 15.4 single-chip nodes are made in >technologies >> >>that are several (maybe five?) generations behind the cutting edge. >>This makes economic sense because the sales volumes don't support the >>need for expensive mask sets yet. >>When there's a volume application, and someone puts a 5mm2 radio into >>modern CMOS, it just doesn't make sense to put 48kB of rom/flash and >>10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and >>many tens of kB of RAM, and the radio will still be by far the biggest >>thing on the chip. >> >>Even the 48k/10k node from the (very nice) 6lowapp bof presentation is >>not up to commercial standards - it's a five year old, expensive, >>academic platform - great for it's time, but old. Single-chip nodes >>from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit > >>processor, and they aren't made in cutting-edge processes yet either. >>Life is just going to get better. Let's try to find the smallest >>optimized set of *existing* protocols that serve our needs, that run on > >>the existing new low-cost hardware (not the old workhorses). Let's >>invent the absolute minimum of new "optimized" protocols, because it's >>not at all clear to me that we are optimizing the right things at this >>point. The less we invent, the broader the set of applications and >>applications programmers we address. >> >>ksjp >> >>Jonathan Hui wrote: >>> >>> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >>> >>>> Again, entirely getting rid of a function is always the best >>>> optimization. >>>> Can we do that for DAD? >>> >>> The *need* for DAD is the core question for me. As specified within >>> 6lowpan-nd now, IPv6 addresses are maintained using a centralized >>> protocol. That protocol looks and smells like DHCP - there's >>> request/response, lease times, relays. The whiteboard may also >>> administratively assign addresses. So in the end, it's not clear to >>> me why we would need to *detect* duplicates when we essentially >>> *avoid* them from the beginning. >>> >>> I've voiced my comment several times over the past 1+ years and >>> presented a draft that argues for the use of optimized DHCP in >Dublin, >> >>> so this is not new from my end. The fact that the current 6lowpan-nd > >>> document has evolved towards using DHCP-like mechanisms is not an >>> accident. But if what we do is DHCP-like, it would seem to make >sense >> >>> to utilize existing DHCP infrastructure rather than defining >something >> >>> new. >>> >>> -- >>> Jonathan Hui >>> >>_______________________________________________ >>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 From d.sturek@att.net Mon Nov 9 20:53:42 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276CE3A6820 for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 20:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.413 X-Spam-Level: X-Spam-Status: No, score=0.413 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 lcLeRG25pCbd for <6lowapp@core3.amsl.com>; Mon, 9 Nov 2009 20:53:42 -0800 (PST) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id 0BF343A680F for <6lowapp@ietf.org>; Mon, 9 Nov 2009 20:53:42 -0800 (PST) Received: (qmail 51824 invoked from network); 10 Nov 2009 04:47:29 -0000 Received: from host-19-96.meeting.ietf.org (d.sturek@133.93.19.96 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 09 Nov 2009 20:47:28 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: Zw5HnM0VM1lsEqgBbX7RiWBO7TFNqZclyUyoYIvi..tIrYEJLTUyNzmrWd2rmqrs0ENxjxbEo8NEDL3iTRaffIlWM7S9pI.GJ_bO94ZUkvjcODxIbiupWCKUosoxpbBc_n7qWWATau2GugPbTM9.G.YlGzYiPkrJO0urosTWQzPCDMKdjZstWjeq3nLc0D3jWWEAVZC8aAdyAK8urSDAsfbr_3E5XUolexPVpJxCn03B3V8gQ4ekbKJjCBoVQ6WJ7VyWpLR98Unm6mhMoJHNXGAYMwc_l.l1nmQGtDq40629Xr_JT_M- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Stuber, Michael'" , "'Pascal Thubert \(pthubert\)'" , "'Kris Pister'" , "'Jonathan Hui'" References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com><4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <6A2A459175DABE4BB11DE2026AA50A5D960226@XMB-AMS-107.cisco.com> <05C6A38D732F1144A8C4016BA4416BFE0242D3BF@SPO-EXVS-02.itron.com> In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE0242D3BF@SPO-EXVS-02.itron.com> Date: Mon, 9 Nov 2009 20:47:22 -0800 Message-ID: <00ca01ca61c0$e639e750$b2adb5f0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcphsP24BwjkVxaNSQWl7M9/snvrqgABq6gAAAEv34AAAFs9YAAAtVPg Content-Language: en-us Cc: '6lowpan' <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 04:53:42 -0000 My read on 4861 and 6LowPAN-ND (and prior knowledge of DHCP) would indicate that 6LowPAN-ND is still needed as Pascal points out. Does everyone agree with this? Don -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stuber, Michael Sent: Monday, November 09, 2009 8:41 PM To: Pascal Thubert (pthubert); Kris Pister; Jonathan Hui Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org Subject: Re: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] I realize that I'm new here, and I may be asking questions that have already been hashed to death, but I confess I don't feel think that DAD is appropriate on 802.15.4 mesh networks, unless the scope is limited to the immediate neighbors. Imagine a PAN with hundreds of nodes trying to form. I understand that this may run afoul of the v6 RFCs, but I believe the idea with 6LowPAN was to have an adaption for 802.15.4 networks, and I believe this would be a reasonable adaption. I for one am willing to give up mesh-wide DAD in this context. -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Monday, November 09, 2009 8:21 PM To: Stuber, Michael; Kris Pister; Jonathan Hui Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org Subject: RE: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] Hi Michael; To be very clear, I have nothing against using / optimizing DHCP in LoWPAN. All the contrary. A great item for rechartering I suspect. Just don't call it ND. Note that even if an address is obtained via DHCP, it has to be DADed through ND. And if a backbone is used, the address has to be proxied. Etc... IOW, DHCP is an alternate to SLAAC to get an address (and other stuff), but the ND draft is still needed. DHCP does not remove the need for ND, never did still does not. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Stuber, Michael >Sent: mardi 10 novembre 2009 04:57 >To: Kris Pister; Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] > >Life may be getting better, but that doesn't mean we have the wrong >target. Abandoning the installed base just goes to reinforce the idea >that IP isn't an appropriate technology for things. Qualifications for >parts in appliances, meters, and cars may take much longer than in other >consumer electronics. There are lots of products shipping today with >802.15.4 chips that do not match the (nicer) specs you outline below. >If we want to enable IP everywhere, we must acknowledge that small >footprint parts are an important part of "everywhere." > >That said, I too am in favor of exploring optimized DHCP. It would >provide the flexibility of living in an edge router, or being >centralized. It is a well defined, characterized protocol. > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >Behalf Of Kris Pister >Sent: Monday, November 09, 2009 6:53 PM >To: Jonathan Hui >Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 >usage in LLNs] > >+1 in favor of using optimized DHCP if possible (no opinion on 'if >possible'), rather than inventing something new. > >As I've shared with several people in private emails recently, it's >pretty clear that lowpan nodes are going to get more capable moving >forward, not less. Why? Radios don't scale down in area when you scale > >CMOS processes. Today's 15.4 single-chip nodes are made in technologies > >that are several (maybe five?) generations behind the cutting edge. >This makes economic sense because the sales volumes don't support the >need for expensive mask sets yet. >When there's a volume application, and someone puts a 5mm2 radio into >modern CMOS, it just doesn't make sense to put 48kB of rom/flash and >10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and >many tens of kB of RAM, and the radio will still be by far the biggest >thing on the chip. > >Even the 48k/10k node from the (very nice) 6lowapp bof presentation is >not up to commercial standards - it's a five year old, expensive, >academic platform - great for it's time, but old. Single-chip nodes >from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit >processor, and they aren't made in cutting-edge processes yet either. >Life is just going to get better. Let's try to find the smallest >optimized set of *existing* protocols that serve our needs, that run on >the existing new low-cost hardware (not the old workhorses). Let's >invent the absolute minimum of new "optimized" protocols, because it's >not at all clear to me that we are optimizing the right things at this >point. The less we invent, the broader the set of applications and >applications programmers we address. > >ksjp > >Jonathan Hui wrote: >> >> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >> >>> Again, entirely getting rid of a function is always the best >>> optimization. >>> Can we do that for DAD? >> >> The *need* for DAD is the core question for me. As specified within >> 6lowpan-nd now, IPv6 addresses are maintained using a centralized >> protocol. That protocol looks and smells like DHCP - there's >> request/response, lease times, relays. The whiteboard may also >> administratively assign addresses. So in the end, it's not clear to >> me why we would need to *detect* duplicates when we essentially >> *avoid* them from the beginning. >> >> I've voiced my comment several times over the past 1+ years and >> presented a draft that argues for the use of optimized DHCP in Dublin, > >> so this is not new from my end. The fact that the current 6lowpan-nd >> document has evolved towards using DHCP-like mechanisms is not an >> accident. But if what we do is DHCP-like, it would seem to make sense > >> to utilize existing DHCP infrastructure rather than defining something > >> new. >> >> -- >> Jonathan Hui >> >_______________________________________________ >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 From pister@eecs.berkeley.edu Mon Nov 9 22:11:49 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108D628C0F8; Mon, 9 Nov 2009 22:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 fCbyXiffcFcs; Mon, 9 Nov 2009 22:11:45 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 787F528B56A; Mon, 9 Nov 2009 22:11:44 -0800 (PST) Received: from [192.168.1.100] (c-24-4-148-227.hsd1.ca.comcast.net [24.4.148.227]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nAA6C8LD020840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 9 Nov 2009 22:12:10 -0800 (PST) Message-ID: <4AF90433.30204@eecs.berkeley.edu> Date: Mon, 09 Nov 2009 22:12:03 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Stuber, Michael" References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> In-Reply-To: <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:11:50 -0000 > Abandoning the installed base just goes to reinforce the idea > that IP isn't an appropriate technology for things. Michael - I think that we have the same goal, but I disagree with that statement. I think that re-writing every protocol from discovery through transport to applications, from scratch, is what reinforces the idea that IP isn't an appropriate technology for things. I realize that there are pressures from an installed base, but at this point it's a tiny fraction of the overall potential. If we let the 1% installed base dictate the path for the next 99%, we should do our best to ensure that it's the right path. ksjp Stuber, Michael wrote: > Life may be getting better, but that doesn't mean we have the wrong > target. Abandoning the installed base just goes to reinforce the idea > that IP isn't an appropriate technology for things. Qualifications for > parts in appliances, meters, and cars may take much longer than in other > consumer electronics. There are lots of products shipping today with > 802.15.4 chips that do not match the (nicer) specs you outline below. > If we want to enable IP everywhere, we must acknowledge that small > footprint parts are an important part of "everywhere." > > That said, I too am in favor of exploring optimized DHCP. It would > provide the flexibility of living in an edge router, or being > centralized. It is a well defined, characterized protocol. > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Kris Pister > Sent: Monday, November 09, 2009 6:53 PM > To: Jonathan Hui > Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org > Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 > usage in LLNs] > > +1 in favor of using optimized DHCP if possible (no opinion on 'if > possible'), rather than inventing something new. > > As I've shared with several people in private emails recently, it's > pretty clear that lowpan nodes are going to get more capable moving > forward, not less. Why? Radios don't scale down in area when you scale > > CMOS processes. Today's 15.4 single-chip nodes are made in technologies > > that are several (maybe five?) generations behind the cutting edge. > This makes economic sense because the sales volumes don't support the > need for expensive mask sets yet. > When there's a volume application, and someone puts a 5mm2 radio into > modern CMOS, it just doesn't make sense to put 48kB of rom/flash and > 10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and > many tens of kB of RAM, and the radio will still be by far the biggest > thing on the chip. > > Even the 48k/10k node from the (very nice) 6lowapp bof presentation is > not up to commercial standards - it's a five year old, expensive, > academic platform - great for it's time, but old. Single-chip nodes > from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit > processor, and they aren't made in cutting-edge processes yet either. > Life is just going to get better. Let's try to find the smallest > optimized set of *existing* protocols that serve our needs, that run on > the existing new low-cost hardware (not the old workhorses). Let's > invent the absolute minimum of new "optimized" protocols, because it's > not at all clear to me that we are optimizing the right things at this > point. The less we invent, the broader the set of applications and > applications programmers we address. > > ksjp > > Jonathan Hui wrote: > >> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >> >> >>> Again, entirely getting rid of a function is always the best >>> optimization. >>> Can we do that for DAD? >>> >> The *need* for DAD is the core question for me. As specified within >> 6lowpan-nd now, IPv6 addresses are maintained using a centralized >> protocol. That protocol looks and smells like DHCP - there's >> request/response, lease times, relays. The whiteboard may also >> administratively assign addresses. So in the end, it's not clear to >> me why we would need to *detect* duplicates when we essentially >> *avoid* them from the beginning. >> >> I've voiced my comment several times over the past 1+ years and >> presented a draft that argues for the use of optimized DHCP in Dublin, >> > > >> so this is not new from my end. The fact that the current 6lowpan-nd >> document has evolved towards using DHCP-like mechanisms is not an >> accident. But if what we do is DHCP-like, it would seem to make sense >> > > >> to utilize existing DHCP infrastructure rather than defining something >> > > >> new. >> >> -- >> Jonathan Hui >> >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From shidan@gmail.com Mon Nov 9 22:20:18 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E143C28C0CF; Mon, 9 Nov 2009 22:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.174, 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 VOOGFP7qJGF0; Mon, 9 Nov 2009 22:20:17 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id B19733A6899; Mon, 9 Nov 2009 22:20:16 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 4so332081eyf.51 for ; Mon, 09 Nov 2009 22:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GK3JbpM0cfL8v4WXZPXi4xpgiuTLdUKlr8C0zYYGN98=; b=tm+N8kUi0avhiwtKzV7iy0C+brf1Jn67FsFyN34gGKsGrPtvD/Fbo873fqX1QV4eTR OQxOOXii2123ui0U1KngvmQOlpkrUci+G8e20WpZycL0wZY9NAUm/YRgpD26CQciDgr2 kU490toxC9zh1qeAvxVewktIMD7hOrEn6kI40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OcvhcgOPSrHm35hCNK8y3E+6FefBWVK37GV3GvGYrDXHgzaPeZbXsc6foI20iOhdua LugZKr9ILqq3U1vOarrsUz9KqlO8KEwuEaKjOdASNyrESST9xOX9hDWC9iFAryA0YN/Q p5EYs3e+G3+DgK0JLFADf9Vl9hiaRixYS1iyA= MIME-Version: 1.0 Received: by 10.216.86.135 with SMTP id w7mr2862243wee.176.1257834039906; Mon, 09 Nov 2009 22:20:39 -0800 (PST) In-Reply-To: <4AF90433.30204@eecs.berkeley.edu> References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> Date: Tue, 10 Nov 2009 01:20:39 -0500 Message-ID: <429b380e0911092220m4a3b0c09n319bb162e92bbbe9@mail.gmail.com> From: Shidan To: Kris Pister Content-Type: multipart/alternative; boundary=0016e6d6495622937c0477fe4fd7 Cc: "Stuber, Michael" , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 06:20:19 -0000 --0016e6d6495622937c0477fe4fd7 Content-Type: text/plain; charset=ISO-8859-1 +100 On Tue, Nov 10, 2009 at 1:12 AM, Kris Pister wrote: > > Abandoning the installed base just goes to reinforce the idea > > that IP isn't an appropriate technology for things. > > Michael - I think that we have the same goal, but I disagree with that > statement. I think that re-writing every protocol from discovery through > transport to applications, from scratch, is what reinforces the idea that IP > isn't an appropriate technology for things. > > I realize that there are pressures from an installed base, but at this > point it's a tiny fraction of the overall potential. If we let the 1% > installed base dictate the path for the next 99%, we should do our best to > ensure that it's the right path. > > ksjp > > > Stuber, Michael wrote: > >> Life may be getting better, but that doesn't mean we have the wrong >> target. Abandoning the installed base just goes to reinforce the idea >> that IP isn't an appropriate technology for things. Qualifications for >> parts in appliances, meters, and cars may take much longer than in other >> consumer electronics. There are lots of products shipping today with >> 802.15.4 chips that do not match the (nicer) specs you outline below. >> If we want to enable IP everywhere, we must acknowledge that small >> footprint parts are an important part of "everywhere." >> >> That said, I too am in favor of exploring optimized DHCP. It would >> provide the flexibility of living in an edge router, or being >> centralized. It is a well defined, characterized protocol. >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Kris Pister >> Sent: Monday, November 09, 2009 6:53 PM >> To: Jonathan Hui >> Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >> Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 >> usage in LLNs] >> >> +1 in favor of using optimized DHCP if possible (no opinion on 'if >> possible'), rather than inventing something new. >> >> As I've shared with several people in private emails recently, it's pretty >> clear that lowpan nodes are going to get more capable moving forward, not >> less. Why? Radios don't scale down in area when you scale >> >> CMOS processes. Today's 15.4 single-chip nodes are made in technologies >> >> that are several (maybe five?) generations behind the cutting edge. This >> makes economic sense because the sales volumes don't support the need for >> expensive mask sets yet. >> When there's a volume application, and someone puts a 5mm2 radio into >> modern CMOS, it just doesn't make sense to put 48kB of rom/flash and 10kB of >> RAM next to it. You'll put hundreds of kB of rom/flash, and many tens of kB >> of RAM, and the radio will still be by far the biggest thing on the chip. >> >> Even the 48k/10k node from the (very nice) 6lowapp bof presentation is not >> up to commercial standards - it's a five year old, expensive, academic >> platform - great for it's time, but old. Single-chip nodes from Jennic, >> Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit processor, and >> they aren't made in cutting-edge processes yet either. Life is just going to >> get better. Let's try to find the smallest optimized set of *existing* >> protocols that serve our needs, that run on the existing new low-cost >> hardware (not the old workhorses). Let's invent the absolute minimum of new >> "optimized" protocols, because it's not at all clear to me that we are >> optimizing the right things at this point. The less we invent, the broader >> the set of applications and applications programmers we address. >> >> ksjp >> >> Jonathan Hui wrote: >> >> >>> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >>> >>> >>> >>>> Again, entirely getting rid of a function is always the best >>>> optimization. >>>> Can we do that for DAD? >>>> >>>> >>> The *need* for DAD is the core question for me. As specified within >>> 6lowpan-nd now, IPv6 addresses are maintained using a centralized protocol. >>> That protocol looks and smells like DHCP - there's request/response, lease >>> times, relays. The whiteboard may also administratively assign addresses. >>> So in the end, it's not clear to me why we would need to *detect* >>> duplicates when we essentially *avoid* them from the beginning. >>> >>> I've voiced my comment several times over the past 1+ years and presented >>> a draft that argues for the use of optimized DHCP in Dublin, >>> >>> >> >> >> >>> so this is not new from my end. The fact that the current 6lowpan-nd >>> document has evolved towards using DHCP-like mechanisms is not an accident. >>> But if what we do is DHCP-like, it would seem to make sense >>> >>> >> >> >> >>> to utilize existing DHCP infrastructure rather than defining something >>> >>> >> >> >> >>> new. >>> >>> -- >>> Jonathan Hui >>> >>> >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --0016e6d6495622937c0477fe4fd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +100

On Tue, Nov 10, 2009 at 1:12 AM, Kri= s Pister <= pister@eecs.berkeley.edu> wrote:
> Abandoning the installed base just goes to reinforce= the idea
> that IP isn't an appropriate technology for things.

Michael - I think that we have the same goal, but I disagree with that stat= ement. =A0I think that re-writing every protocol from discovery through tra= nsport to applications, from scratch, is what reinforces the idea that IP i= sn't an appropriate technology for things.

I realize that there are pressures from an installed base, but at this poin= t it's a tiny fraction of the overall potential. =A0If we let the 1% in= stalled base dictate the path for the next 99%, we should do our best to en= sure that it's the right path.

ksjp


Stuber, Michael wrote:
Life may be getting better, but that doesn't mean we have the wrong
target. =A0Abandoning the installed base just goes to reinforce the idea that IP isn't an appropriate technology for things. =A0Qualifications f= or
parts in appliances, meters, and cars may take much longer than in other consumer electronics. =A0There are lots of products shipping today with
802.15.4 chips that do not match the (nicer) specs you outline below.
If we want to enable IP everywhere, we must acknowledge that small
footprint parts are an important part of "everywhere."

That said, I too am in favor of exploring optimized DHCP. =A0It would
provide the flexibility of living in an edge router, or being
centralized. =A0It is a well defined, characterized protocol. =A0
-----Original Message-----
From: 6lowpan= -bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On
Behalf Of Kris Pister
Sent: Monday, November 09, 2009 6:53 PM
To: Jonathan Hui
Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org
Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs]

+1 in favor of using optimized DHCP if possible (no opinion on 'if poss= ible'), rather than inventing something new.

As I've shared with several people in private emails recently, it's= pretty clear that lowpan nodes are going to get more capable moving forwar= d, not less. =A0Why? =A0Radios don't scale down in area when you scale<= br>
CMOS processes. =A0Today's 15.4 single-chip nodes are made in technolog= ies

that are several (maybe five?) generations behind the cutting edge. =A0This= makes economic sense because the sales volumes don't support the need = for expensive mask sets yet.
When there's a volume application, and someone puts a 5mm2 radio into m= odern CMOS, it just doesn't make sense to put 48kB of rom/flash and 10k= B of RAM next to it. =A0You'll put hundreds of kB of rom/flash, and man= y tens of kB of RAM, and the radio will still be by far the biggest thing o= n the chip.

Even the 48k/10k node from the (very nice) 6lowapp bof presentation is not = up to commercial standards - it's a five year old, expensive, academic = platform - great for it's time, but old. =A0Single-chip nodes from Jenn= ic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit processor, a= nd they aren't made in cutting-edge processes yet either. Life is just = going to get better. =A0Let's try to find the smallest optimized set of= *existing* protocols that serve our needs, that run on the existing new lo= w-cost hardware (not the old workhorses). Let's invent the absolute min= imum of new "optimized" protocols, because it's not at all cl= ear to me that we are optimizing the right things at this point. =A0The les= s we invent, the broader the set of applications and applications programme= rs we address.

ksjp

Jonathan Hui wrote:
=A0
On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote:

=A0 =A0
Again, entirely getting rid of a function is always the best optimization.<= br> Can we do that for DAD?
=A0 =A0 =A0
The *need* for DAD is the core question for me. =A0As specified within 6low= pan-nd now, IPv6 addresses are maintained using a centralized protocol. =A0= That protocol looks and smells like DHCP - there's request/response, le= ase times, relays. =A0The whiteboard may also administratively assign addre= sses. =A0So in the end, it's not clear to me why we would need to *dete= ct* duplicates when we essentially *avoid* them from the beginning.

I've voiced my comment several times over the past 1+ years and present= ed a draft that argues for the use of optimized DHCP in Dublin,
=A0 =A0

=A0
so this is not new from my end. =A0The fact that the current 6lowpan-nd doc= ument has evolved towards using DHCP-like mechanisms is not an accident. = =A0But if what we do is DHCP-like, it would seem to make sense
=A0 =A0

=A0
to utilize existing DHCP infrastructure rather than defining something
=A0 =A0

=A0
new.

--
Jonathan Hui

=A0 =A0
_______________________________________________
6lowpan mailing list
6lowpan@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowpan
=A0
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/6lowapp

--0016e6d6495622937c0477fe4fd7-- From pthubert@cisco.com Tue Nov 10 00:14:09 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513853A6A6E; Tue, 10 Nov 2009 00:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.809 X-Spam-Level: X-Spam-Status: No, score=-9.809 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 APPpKoXFo3an; Tue, 10 Nov 2009 00:14:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 3D9633A67A3; Tue, 10 Nov 2009 00:14:05 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYAAJev+EqQ/uCWe2dsb2JhbACbfAEBFiQGqC6YA4Q+BIFoGYoK X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208";a="54024283" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 08:14:31 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAA8EU5q026309; Tue, 10 Nov 2009 08:14:31 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 09:14:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 09:14:26 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D9602A6@XMB-AMS-107.cisco.com> In-Reply-To: <4AF90433.30204@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcphzMdEejWlc0u0TNCRN7YGQ4S8IgAAvjKQ References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com><4AF8D5A0.1020600@eecs.berkeley.edu><05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> From: "Pascal Thubert (pthubert)" To: "Kris Pister" , "Stuber, Michael" X-OriginalArrivalTime: 10 Nov 2009 08:14:31.0118 (UTC) FILETIME=[D4504EE0:01CA61DD] Cc: 6lowpan <6lowpan@ietf.org>, 6man Mailing List , Dave Thaler , 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 08:14:09 -0000 Hi Kris: I would adhere to your idea but not that it applies to 6LoWPAN ND. We are not rewriting IP from scratch. We are not even reinventing ND.=20 We are adding another mechanism to the NDP suite, which already counts a number of them (3122, 4861, 4862...). It is a surprise for nobody that we have more than one classical IGP or MANET protocol. In fact, MANET is working on one reactive and one proactive protocol. Why would there only be one ND flavor? Should that be at all cost? Hopefully, ND is not so cast in stone that we can't improve it for new purposes. That would be the real bad news. This additional mechanism goes along the sense of history: 1) it is proactive.=20 In general, global flooding and centralized registries are extremes and apply to very different scales and goals.=20 You'll find protocols that occupy different places on a scale between with those 2 extremes, with different optimization goals. 2) it is compatible with the other mechanisms You can run it together with 4861 on ethernet or together with 3122 on FR/ATM. In a same way that you can do NS/NA and RS/RA on a same link. It is just an additional mechanism that provides additional benefits but not a replacement though there's intersection for DAD and for address resolution between host and router.=20 3) It provides new benefits Specifically, it is a way to grant the right to use an address over a link, this grant including the validation that the address is unique. There's a WG (SAVI) at the IETF dealing with one of the limitations of the reactive ND.=20 They end up snooping ND flows to reconstruct what may be the owners of IPv6 addresses; A proactive registration resolves this. 4) It is lightweight The model for that new operation is that the node only needs connect to its router(s). IOW the protocol addition operates with an implicit not on link model. This yields a low footprint both on the node and in the air.=20 5) It scales Using a backbone that interconnects the white boards, the new mechanism enables a subnet to grow pretty large. The spec uses proxy (4861) ND there but other mechanisms like TRILL could be put in place. 6) It DADs, it ROLLs, and it moves The new registration messages are designed to be extendable to enable an end-node to join a RPL network. DAD using a distributed registry enables a solid Address Duplication avoidance without the hassle of multicast. Transparent mobility within the subnet is ensured by the protocol operation between the registries. The mechanism also detects duplicate MACs, an 'attack' that might be uncommon today but might appear more and more as forgery speads in this domain. The alternate on the table is not to do DAD and call it compliant to 4861. I see people raising larger-than-life red flags to preserve their precious pre-standard implementation, inflating the effort to make it look either huge, incompatible, or a dead end that will not benefit from further work on ND. I think none of this is true. If we do our job well, with the help and support from 6MAN, then we can make this mechanism a lot more generic than meets the eyes, with application on all sorts of network, and thus an integral piece of ND from then on. It seems clear to me that the resolution for the 6LoWPAN ND problem cannot come from 6LoWPAN alone.=20 Most of the objections that we see can be alleviated if 6MAN: * adheres to the new model and completes it into a generic support * confirms whether DAD is still required these days or whether has become an obsolete commodity that we can live without with no hassle The other way around, if 6MAN thinks that we are really on a dead end, it would save a lot of time and friendly fire to let us know ASAP. Either way, I think that 6LoWPAN needs external help. Pascal >-----Original Message----- >From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Kris Pister >Sent: mardi 10 novembre 2009 07:12 >To: Stuber, Michael >Cc: 6lowpan; 6lowapp@ietf.org >Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] > > > > Abandoning the installed base just goes to reinforce the idea > > that IP isn't an appropriate technology for things. > >Michael - I think that we have the same goal, but I disagree with that >statement. I think that re-writing every protocol from discovery >through transport to applications, from scratch, is what reinforces the >idea that IP isn't an appropriate technology for things. > >I realize that there are pressures from an installed base, but at this >point it's a tiny fraction of the overall potential. If we let the 1% >installed base dictate the path for the next 99%, we should do our best >to ensure that it's the right path. > >ksjp > >Stuber, Michael wrote: >> Life may be getting better, but that doesn't mean we have the wrong >> target. Abandoning the installed base just goes to reinforce the idea >> that IP isn't an appropriate technology for things. Qualifications for >> parts in appliances, meters, and cars may take much longer than in other >> consumer electronics. There are lots of products shipping today with >> 802.15.4 chips that do not match the (nicer) specs you outline below. >> If we want to enable IP everywhere, we must acknowledge that small >> footprint parts are an important part of "everywhere." >> >> That said, I too am in favor of exploring optimized DHCP. It would >> provide the flexibility of living in an edge router, or being >> centralized. It is a well defined, characterized protocol. >> >> -----Original Message----- >> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >> Behalf Of Kris Pister >> Sent: Monday, November 09, 2009 6:53 PM >> To: Jonathan Hui >> Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >> Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 >> usage in LLNs] >> >> +1 in favor of using optimized DHCP if possible (no opinion on 'if >> possible'), rather than inventing something new. >> >> As I've shared with several people in private emails recently, it's >> pretty clear that lowpan nodes are going to get more capable moving >> forward, not less. Why? Radios don't scale down in area when you scale >> >> CMOS processes. Today's 15.4 single-chip nodes are made in technologies >> >> that are several (maybe five?) generations behind the cutting edge. >> This makes economic sense because the sales volumes don't support the >> need for expensive mask sets yet. >> When there's a volume application, and someone puts a 5mm2 radio into >> modern CMOS, it just doesn't make sense to put 48kB of rom/flash and >> 10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and >> many tens of kB of RAM, and the radio will still be by far the biggest >> thing on the chip. >> >> Even the 48k/10k node from the (very nice) 6lowapp bof presentation is >> not up to commercial standards - it's a five year old, expensive, >> academic platform - great for it's time, but old. Single-chip nodes >> from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a 32bit >> processor, and they aren't made in cutting-edge processes yet either. >> Life is just going to get better. Let's try to find the smallest >> optimized set of *existing* protocols that serve our needs, that run on >> the existing new low-cost hardware (not the old workhorses). Let's >> invent the absolute minimum of new "optimized" protocols, because it's >> not at all clear to me that we are optimizing the right things at this >> point. The less we invent, the broader the set of applications and >> applications programmers we address. >> >> ksjp >> >> Jonathan Hui wrote: >> >>> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >>> >>> >>>> Again, entirely getting rid of a function is always the best >>>> optimization. >>>> Can we do that for DAD? >>>> >>> The *need* for DAD is the core question for me. As specified within >>> 6lowpan-nd now, IPv6 addresses are maintained using a centralized >>> protocol. That protocol looks and smells like DHCP - there's >>> request/response, lease times, relays. The whiteboard may also >>> administratively assign addresses. So in the end, it's not clear to >>> me why we would need to *detect* duplicates when we essentially >>> *avoid* them from the beginning. >>> >>> I've voiced my comment several times over the past 1+ years and >>> presented a draft that argues for the use of optimized DHCP in Dublin, >>> >> >> >>> so this is not new from my end. The fact that the current 6lowpan-nd >>> document has evolved towards using DHCP-like mechanisms is not an >>> accident. But if what we do is DHCP-like, it would seem to make sense >>> >> >> >>> to utilize existing DHCP infrastructure rather than defining something >>> >> >> >>> new. >>> >>> -- >>> Jonathan Hui >>> >>> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan >> >_______________________________________________ >6lowapp mailing list >6lowapp@ietf.org >https://www.ietf.org/mailman/listinfo/6lowapp From Michael.Stuber@itron.com Tue Nov 10 02:22:44 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 949303A6985; Tue, 10 Nov 2009 02:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 PGmz3YISnmcf; Tue, 10 Nov 2009 02:22:43 -0800 (PST) Received: from mailer-1.itron.com (mailer-1.itron.com [198.182.8.121]) by core3.amsl.com (Postfix) with ESMTP id 744F83A695A; Tue, 10 Nov 2009 02:22:43 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Nov 2009 02:23:11 -0800 Message-ID: <05C6A38D732F1144A8C4016BA4416BFE0242D3CA@SPO-EXVS-02.itron.com> In-Reply-To: <4AF90433.30204@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcphzMX0cVDlkwnlTRO7AjR+HZWE5gAIRiwA References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com><1257809361.11184.123.camel@dellx1><4AF8C20C.3070905@eecs.berkeley.edu><9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org><6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com><4AF8D5A0.1020600@eecs.berkeley.edu><05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> From: "Stuber, Michael" To: "Kris Pister" Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 10:22:44 -0000 To be clear, I am not arguing that we should re-write every protocol, and certainly not from scratch. I think we need to be thoughtful about how we apply these technologies to the problem space. We need to be efficient with all our resources. The chips may get more powerful, but the network (802.15.4) that we are targeting here will remain constrained. No doubt there will come a day when different network technologies are applied in this space, but at that point I don't think we're talking 6LoWPAN anymore. -----Original Message----- From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On Behalf Of Kris Pister Sent: Monday, November 09, 2009 10:12 PM To: Stuber, Michael Cc: 6lowpan; 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] > Abandoning the installed base just goes to reinforce the idea > that IP isn't an appropriate technology for things. Michael - I think that we have the same goal, but I disagree with that statement. I think that re-writing every protocol from discovery through transport to applications, from scratch, is what reinforces the idea that IP isn't an appropriate technology for things. I realize that there are pressures from an installed base, but at this point it's a tiny fraction of the overall potential. If we let the 1% installed base dictate the path for the next 99%, we should do our best to ensure that it's the right path. ksjp Stuber, Michael wrote: > Life may be getting better, but that doesn't mean we have the wrong=20 > target. Abandoning the installed base just goes to reinforce the idea > that IP isn't an appropriate technology for things. Qualifications=20 > for parts in appliances, meters, and cars may take much longer than in > other consumer electronics. There are lots of products shipping today > with > 802.15.4 chips that do not match the (nicer) specs you outline below. > If we want to enable IP everywhere, we must acknowledge that small=20 > footprint parts are an important part of "everywhere." > > That said, I too am in favor of exploring optimized DHCP. It would=20 > provide the flexibility of living in an edge router, or being=20 > centralized. It is a well defined, characterized protocol. > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On=20 > Behalf Of Kris Pister > Sent: Monday, November 09, 2009 6:53 PM > To: Jonathan Hui > Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org > Subject: [6lowpan] hardware trends, new vs. existing protocols [Re:=20 > 4861 usage in LLNs] > > +1 in favor of using optimized DHCP if possible (no opinion on 'if > possible'), rather than inventing something new. > > As I've shared with several people in private emails recently, it's=20 > pretty clear that lowpan nodes are going to get more capable moving=20 > forward, not less. Why? Radios don't scale down in area when you=20 > scale > > CMOS processes. Today's 15.4 single-chip nodes are made in=20 > technologies > > that are several (maybe five?) generations behind the cutting edge. =20 > This makes economic sense because the sales volumes don't support the=20 > need for expensive mask sets yet. > When there's a volume application, and someone puts a 5mm2 radio into=20 > modern CMOS, it just doesn't make sense to put 48kB of rom/flash and=20 > 10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and=20 > many tens of kB of RAM, and the radio will still be by far the biggest > thing on the chip. > > Even the 48k/10k node from the (very nice) 6lowapp bof presentation is > not up to commercial standards - it's a five year old, expensive,=20 > academic platform - great for it's time, but old. Single-chip nodes=20 > from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a=20 > 32bit processor, and they aren't made in cutting-edge processes yet either. > Life is just going to get better. Let's try to find the smallest=20 > optimized set of *existing* protocols that serve our needs, that run=20 > on the existing new low-cost hardware (not the old workhorses). Let's=20 > invent the absolute minimum of new "optimized" protocols, because it's > not at all clear to me that we are optimizing the right things at this > point. The less we invent, the broader the set of applications and=20 > applications programmers we address. > > ksjp > > Jonathan Hui wrote: > =20 >> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >> >> =20 >>> Again, entirely getting rid of a function is always the best=20 >>> optimization. >>> Can we do that for DAD? >>> =20 >> The *need* for DAD is the core question for me. As specified within=20 >> 6lowpan-nd now, IPv6 addresses are maintained using a centralized=20 >> protocol. That protocol looks and smells like DHCP - there's=20 >> request/response, lease times, relays. The whiteboard may also=20 >> administratively assign addresses. So in the end, it's not clear to=20 >> me why we would need to *detect* duplicates when we essentially >> *avoid* them from the beginning. >> >> I've voiced my comment several times over the past 1+ years and=20 >> presented a draft that argues for the use of optimized DHCP in=20 >> Dublin, >> =20 > > =20 >> so this is not new from my end. The fact that the current 6lowpan-nd >> document has evolved towards using DHCP-like mechanisms is not an=20 >> accident. But if what we do is DHCP-like, it would seem to make=20 >> sense >> =20 > > =20 >> to utilize existing DHCP infrastructure rather than defining=20 >> something >> =20 > > =20 >> new. >> >> -- >> Jonathan Hui >> >> =20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > =20 _______________________________________________ 6lowapp mailing list 6lowapp@ietf.org https://www.ietf.org/mailman/listinfo/6lowapp From jvasseur@cisco.com Tue Nov 10 04:28:06 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F82628C181 for <6lowapp@core3.amsl.com>; Tue, 10 Nov 2009 04:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.736 X-Spam-Level: X-Spam-Status: No, score=-9.736 tagged_above=-999 required=5 tests=[AWL=0.862, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 lD5VOhZ8XPNr for <6lowapp@core3.amsl.com>; Tue, 10 Nov 2009 04:28:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id E65B528C187 for <6lowapp@ietf.org>; Tue, 10 Nov 2009 04:28:03 -0800 (PST) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4AAFvr+EqQ/uCWe2dsb2JhbACCJBUYmS8BARYkBqh9mAyEPgSBaBk X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208,217";a="54052354" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 10 Nov 2009 12:28:29 +0000 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAACSTpe013913 for <6lowapp@ietf.org>; Tue, 10 Nov 2009 12:28:29 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:28:30 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:28:28 +0100 Message-Id: From: JP Vasseur To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-183-376034398 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 13:28:28 +0100 References: <3795C7C9-56AF-47AA-9728-7F661EE25FE8@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Nov 2009 12:28:28.0989 (UTC) FILETIME=[4ECAE6D0:01CA6201] Subject: [6lowapp] Fwd: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:28:06 -0000 --Apple-Mail-183-376034398 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: JP Vasseur > Date: November 10, 2009 1:20:04 PM CEST > To: Kris Pister , Michael Stuber > > Cc: 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org > Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing > protocols [Re: 4861 usage in LLNs] > > > On Nov 10, 2009, at 7:12 AM, Kris Pister wrote: > >> >> > Abandoning the installed base just goes to reinforce the idea >> > that IP isn't an appropriate technology for things. >> >> Michael - I think that we have the same goal, but I disagree with >> that statement. I think that re-writing every protocol from >> discovery through transport to applications, from scratch, is what >> reinforces the idea that IP isn't an appropriate technology for >> things. > > I strongly second this statement. What worries me here is the > tendency to jump on new protocols without any evidence that existing > protocols can be used. Yes there are areas where we need new IP > protocols for constrained devices but there are also many more cases > where existing protocols could be re-used as such or with a small > adaptation. > >> >> I realize that there are pressures from an installed base, but at >> this point it's a tiny fraction of the overall potential. If we >> let the 1% installed base dictate the path for the next 99%, we >> should do our best to ensure that it's the right path. >> >> ksjp >> >> Stuber, Michael wrote: >>> Life may be getting better, but that doesn't mean we have the wrong >>> target. Abandoning the installed base just goes to reinforce the >>> idea >>> that IP isn't an appropriate technology for things. >>> Qualifications for >>> parts in appliances, meters, and cars may take much longer than in >>> other >>> consumer electronics. There are lots of products shipping today >>> with >>> 802.15.4 chips that do not match the (nicer) specs you outline >>> below. >>> If we want to enable IP everywhere, we must acknowledge that small >>> footprint parts are an important part of "everywhere." >>> >>> That said, I too am in favor of exploring optimized DHCP. It would >>> provide the flexibility of living in an edge router, or being >>> centralized. It is a well defined, characterized protocol. >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Kris Pister >>> Sent: Monday, November 09, 2009 6:53 PM >>> To: Jonathan Hui >>> Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >>> Subject: [6lowpan] hardware trends, new vs. existing protocols >>> [Re: 4861 >>> usage in LLNs] >>> >>> +1 in favor of using optimized DHCP if possible (no opinion on 'if >>> possible'), rather than inventing something new. >>> >>> As I've shared with several people in private emails recently, >>> it's pretty clear that lowpan nodes are going to get more capable >>> moving forward, not less. Why? Radios don't scale down in area >>> when you scale >>> >>> CMOS processes. Today's 15.4 single-chip nodes are made in >>> technologies >>> >>> that are several (maybe five?) generations behind the cutting >>> edge. This makes economic sense because the sales volumes don't >>> support the need for expensive mask sets yet. >>> When there's a volume application, and someone puts a 5mm2 radio >>> into modern CMOS, it just doesn't make sense to put 48kB of rom/ >>> flash and 10kB of RAM next to it. You'll put hundreds of kB of >>> rom/flash, and many tens of kB of RAM, and the radio will still be >>> by far the biggest thing on the chip. >>> >>> Even the 48k/10k node from the (very nice) 6lowapp bof >>> presentation is not up to commercial standards - it's a five year >>> old, expensive, academic platform - great for it's time, but old. >>> Single-chip nodes from Jennic, Freescale, etc. have ~200kB ROM/ >>> flash + 128kB RAM, a 32bit processor, and they aren't made in >>> cutting-edge processes yet either. Life is just going to get >>> better. Let's try to find the smallest optimized set of >>> *existing* protocols that serve our needs, that run on the >>> existing new low-cost hardware (not the old workhorses). Let's >>> invent the absolute minimum of new "optimized" protocols, because >>> it's not at all clear to me that we are optimizing the right >>> things at this point. The less we invent, the broader the set of >>> applications and applications programmers we address. >>> >>> ksjp >>> >>> Jonathan Hui wrote: >>> >>>> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >>>> >>>> >>>>> Again, entirely getting rid of a function is always the best >>>>> optimization. >>>>> Can we do that for DAD? >>>>> >>>> The *need* for DAD is the core question for me. As specified >>>> within 6lowpan-nd now, IPv6 addresses are maintained using a >>>> centralized protocol. That protocol looks and smells like DHCP - >>>> there's request/response, lease times, relays. The whiteboard >>>> may also administratively assign addresses. So in the end, it's >>>> not clear to me why we would need to *detect* duplicates when we >>>> essentially *avoid* them from the beginning. >>>> >>>> I've voiced my comment several times over the past 1+ years and >>>> presented a draft that argues for the use of optimized DHCP in >>>> Dublin, >>>> >>> >>> >>>> so this is not new from my end. The fact that the current >>>> 6lowpan-nd document has evolved towards using DHCP-like >>>> mechanisms is not an accident. But if what we do is DHCP-like, >>>> it would seem to make sense >>>> >>> >>> >>>> to utilize existing DHCP infrastructure rather than defining >>>> something >>>> >>> >>> >>>> new. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > --Apple-Mail-183-376034398 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = November 10, 2009 1:20:04 PM CEST
To: Kris = Pister <pister@eecs.berkeley.edu>,= Michael Stuber <Michael.Stuber@itron.com><= /font>
Subject: = Re: [6lowapp] [6lowpan] hardware trends, new vs. existing = protocols [Re:  4861 = usage in LLNs]


On Nov 10, 2009, at 7:12 AM, Kris = Pister wrote:


> Abandoning = the installed base just goes to reinforce the = idea
> that IP isn't an = appropriate technology for things.

Michael - I = think that we have the same goal, but I disagree with that statement. =  I think that re-writing every protocol from discovery through = transport to applications, from scratch, is what reinforces the idea = that IP isn't an appropriate technology for = things.

I strongly second this statement. What = worries me here is the tendency to jump on new protocols without any = evidence that existing protocols can be used. Yes there are areas where = we need new IP protocols for constrained devices but there are also many = more cases where existing protocols could be re-used as such or with a = small adaptation.


I realize that = there are pressures from an installed base, but at this point it's a = tiny fraction of the overall potential.  If we let the 1% installed = base dictate the path for the next 99%, we should do our best to ensure = that it's the right path.

ksjp

Stuber, Michael = wrote:
Life may be getting better, but that doesn't mean we have = the wrong
target.  Abandoning the = installed base just goes to reinforce the = idea
that IP isn't an appropriate technology for things. =  Qualifications for
parts in appliances, meters, and = cars may take much longer than in = other
consumer electronics.  There are lots of products = shipping today with
802.15.4 chips that do not match = the (nicer) specs you outline = below.
If we want to enable IP everywhere, we must acknowledge = that small
footprint parts are an important = part of "everywhere."

That said, I too am in favor of = exploring optimized DHCP.  It = would
provide the flexibility of living in an edge router, or = being
centralized.  It is a well defined, characterized = protocol.
-----Original = Message-----
From: 6lowpan-bounces@ietf.org = [mailto:6lowpan-bounces@ietf.org] On
Behalf Of Kris = Pister
Sent: Monday, November 09, 2009 6:53 = PM
To: Jonathan Hui
Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org
Subject: = [6lowpan] hardware trends, new vs. existing protocols [Re: = 4861
usage in LLNs]

+1 in favor of using optimized = DHCP if possible (no opinion on 'if possible'), rather than inventing = something new.

As I've shared with several = people in private emails recently, it's pretty clear that lowpan nodes = are going to get more capable moving forward, not less.  Why? =  Radios don't scale down in area when you = scale

CMOS processes.  Today's = 15.4 single-chip nodes are made in = technologies

that are several (maybe five?) = generations behind the cutting edge.  This makes economic sense = because the sales volumes don't support the need for expensive mask sets = yet.
When there's a volume application, and someone puts a 5mm2 = radio into modern CMOS, it just doesn't make sense to put 48kB of = rom/flash and 10kB of RAM next to it.  You'll put hundreds of kB of = rom/flash, and many tens of kB of RAM, and the radio will still be by = far the biggest thing on the = chip.

Even the 48k/10k node from the = (very nice) 6lowapp bof presentation is not up to commercial standards - = it's a five year old, expensive, academic platform - great for it's = time, but old.  Single-chip nodes from Jennic, Freescale, etc. have = ~200kB ROM/flash + 128kB RAM, a 32bit processor, and they aren't made in = cutting-edge processes yet either. Life is just going to get better. =  Let's try to find the smallest optimized set of *existing* = protocols that serve our needs, that run on the existing new low-cost = hardware (not the old workhorses). Let's invent the absolute minimum of = new "optimized" protocols, because it's not at all clear to me that we = are optimizing the right things at this point.  The less we invent, = the broader the set of applications and applications programmers we = address.

ksjp

Jonathan Hui = wrote:

On Nov = 9, 2009, at 5:50 PM, Carsten Bormann = wrote:


Again, entirely getting rid of a = function is always the best = optimization.
Can we do that for = DAD?

The *need* for DAD is the core question for me.  As = specified within 6lowpan-nd now, IPv6 addresses are maintained using a = centralized protocol.  That protocol looks and smells like DHCP - = there's request/response, lease times, relays.  The whiteboard may = also administratively assign addresses.  So in the end, it's not = clear to me why we would need to *detect* duplicates when we essentially = *avoid* them from the = beginning.

I've = voiced my comment several times over the past 1+ years and presented a = draft that argues for the use of optimized DHCP in = Dublin,



so = this is not new from my end.  The fact that the current 6lowpan-nd = document has evolved towards using DHCP-like mechanisms is not an = accident.  But if what we do is DHCP-like, it would seem to make = sense



to = utilize existing DHCP infrastructure rather than defining = something



new.

-- =
Jonathan= Hui


_______________________________________________
6lowpan mailing = list
6lowpan@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowpan

_______________________________________________
6lowapp mailing = list
6lowapp@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowapp


= --Apple-Mail-183-376034398-- From jvasseur@cisco.com Tue Nov 10 04:28:14 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADDCA3A6A1E for <6lowapp@core3.amsl.com>; Tue, 10 Nov 2009 04:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.748 X-Spam-Level: X-Spam-Status: No, score=-7.748 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Kon25Po8nlzE for <6lowapp@core3.amsl.com>; Tue, 10 Nov 2009 04:28:13 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6243D3A6A1A for <6lowapp@ietf.org>; Tue, 10 Nov 2009 04:28:12 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcFAFvr+EqtJV2Z/2dsb2JhbACCJBUYwm6YDIQ+BIFoGQ X-IronPort-AV: E=Sophos;i="4.44,715,1249257600"; d="scan'208,217";a="67216628" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2009 12:28:38 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id nAACSNkV013461 for <6lowapp@ietf.org>; Tue, 10 Nov 2009 12:28:38 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:28:34 +0100 Received: from ams-jvasseur-8713.cisco.com ([10.55.201.132]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 13:28:33 +0100 Message-Id: From: JP Vasseur To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-184-376039752 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Nov 2009 13:28:33 +0100 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Nov 2009 12:28:34.0068 (UTC) FILETIME=[51D1E540:01CA6201] Subject: [6lowapp] Fwd: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 12:28:14 -0000 --Apple-Mail-184-376039752 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Begin forwarded message: > From: JP Vasseur > Date: November 10, 2009 1:25:52 PM CEST > To: "Stuber, Michael" > Cc: "Kris Pister" , 6lowpan <6lowpan@ietf.org > >, 6lowapp@ietf.org > Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing > protocols [Re: 4861 usage in LLNs] > > > On Nov 10, 2009, at 11:23 AM, Stuber, Michael wrote: > >> To be clear, I am not arguing that we should re-write every protocol, >> and certainly not from scratch. I think we need to be thoughtful >> about >> how we apply these technologies to the problem space. We need to be >> efficient with all our resources. The chips may get more powerful, >> but >> the network (802.15.4) that we are targeting here will remain >> constrained. No doubt there will come a day when different network >> technologies are applied in this space, but at that point I don't >> think >> we're talking 6LoWPAN anymore. > > I would word it a bit differently ... Yes we do need to be careful > of where we > apply technologies in light of specific constraints. But each time > we are tempted > to re-invent a protocol let's first try to demonstrate that we > cannot use an existing > protocol. > > Note that we may at some point start using a more generic term than > 6lowpans > and rather talk about LLNs (Low power and Lossy Networks) or any > other term: > they are many constrained networks using other low power > technologies than 15.4 > > JP. > >> >> -----Original Message----- >> From: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On >> Behalf Of Kris Pister >> Sent: Monday, November 09, 2009 10:12 PM >> To: Stuber, Michael >> Cc: 6lowpan; 6lowapp@ietf.org >> Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing >> protocols [Re: 4861 usage in LLNs] >> >>> Abandoning the installed base just goes to reinforce the idea > >>> that >> IP isn't an appropriate technology for things. >> >> Michael - I think that we have the same goal, but I disagree with >> that >> statement. I think that re-writing every protocol from discovery >> through transport to applications, from scratch, is what reinforces >> the >> idea that IP isn't an appropriate technology for things. >> >> I realize that there are pressures from an installed base, but at >> this >> point it's a tiny fraction of the overall potential. If we let the >> 1% >> installed base dictate the path for the next 99%, we should do our >> best >> to ensure that it's the right path. >> >> ksjp >> >> Stuber, Michael wrote: >>> Life may be getting better, but that doesn't mean we have the wrong >>> target. Abandoning the installed base just goes to reinforce the >>> idea >> >>> that IP isn't an appropriate technology for things. Qualifications >>> for parts in appliances, meters, and cars may take much longer >>> than in >> >>> other consumer electronics. There are lots of products shipping >>> today >> >>> with >>> 802.15.4 chips that do not match the (nicer) specs you outline >>> below. >>> If we want to enable IP everywhere, we must acknowledge that small >>> footprint parts are an important part of "everywhere." >>> >>> That said, I too am in favor of exploring optimized DHCP. It would >>> provide the flexibility of living in an edge router, or being >>> centralized. It is a well defined, characterized protocol. >>> >>> -----Original Message----- >>> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On >>> Behalf Of Kris Pister >>> Sent: Monday, November 09, 2009 6:53 PM >>> To: Jonathan Hui >>> Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org >>> Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: >>> 4861 usage in LLNs] >>> >>> +1 in favor of using optimized DHCP if possible (no opinion on 'if >>> possible'), rather than inventing something new. >>> >>> As I've shared with several people in private emails recently, it's >>> pretty clear that lowpan nodes are going to get more capable moving >>> forward, not less. Why? Radios don't scale down in area when you >>> scale >>> >>> CMOS processes. Today's 15.4 single-chip nodes are made in >>> technologies >>> >>> that are several (maybe five?) generations behind the cutting edge. >>> This makes economic sense because the sales volumes don't support >>> the >>> need for expensive mask sets yet. >>> When there's a volume application, and someone puts a 5mm2 radio >>> into >>> modern CMOS, it just doesn't make sense to put 48kB of rom/flash and >>> 10kB of RAM next to it. You'll put hundreds of kB of rom/flash, and >>> many tens of kB of RAM, and the radio will still be by far the >>> biggest >> >>> thing on the chip. >>> >>> Even the 48k/10k node from the (very nice) 6lowapp bof >>> presentation is >> >>> not up to commercial standards - it's a five year old, expensive, >>> academic platform - great for it's time, but old. Single-chip nodes >>> from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a >>> 32bit processor, and they aren't made in cutting-edge processes yet >> either. >>> Life is just going to get better. Let's try to find the smallest >>> optimized set of *existing* protocols that serve our needs, that run >>> on the existing new low-cost hardware (not the old workhorses). >>> Let's >>> invent the absolute minimum of new "optimized" protocols, because >>> it's >> >>> not at all clear to me that we are optimizing the right things at >>> this >> >>> point. The less we invent, the broader the set of applications and >>> applications programmers we address. >>> >>> ksjp >>> >>> Jonathan Hui wrote: >>> >>>> On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: >>>> >>>> >>>>> Again, entirely getting rid of a function is always the best >>>>> optimization. >>>>> Can we do that for DAD? >>>>> >>>> The *need* for DAD is the core question for me. As specified >>>> within >>>> 6lowpan-nd now, IPv6 addresses are maintained using a centralized >>>> protocol. That protocol looks and smells like DHCP - there's >>>> request/response, lease times, relays. The whiteboard may also >>>> administratively assign addresses. So in the end, it's not clear >>>> to >>>> me why we would need to *detect* duplicates when we essentially >>>> *avoid* them from the beginning. >>>> >>>> I've voiced my comment several times over the past 1+ years and >>>> presented a draft that argues for the use of optimized DHCP in >>>> Dublin, >>>> >>> >>> >>>> so this is not new from my end. The fact that the current >>>> 6lowpan-nd >> >>>> document has evolved towards using DHCP-like mechanisms is not an >>>> accident. But if what we do is DHCP-like, it would seem to make >>>> sense >>>> >>> >>> >>>> to utilize existing DHCP infrastructure rather than defining >>>> something >>>> >>> >>> >>>> new. >>>> >>>> -- >>>> Jonathan Hui >>>> >>>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan >>> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp > --Apple-Mail-184-376039752 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = JP Vasseur <jvasseur@cisco.com>
=
Date: = November 10, 2009 1:25:52 PM CEST
To: "Stuber, = Michael" <Michael.Stuber@itron.com><= /font>
Subject: = Re: [6lowapp] [6lowpan] hardware trends, new vs. existing = protocols [Re:  4861 = usage in LLNs]


On Nov 10, 2009, at 11:23 AM, Stuber, = Michael wrote:

To be clear, I am not = arguing that we should re-write every = protocol,
and certainly not = from scratch.  I think we need to be thoughtful = about
how we apply these = technologies to the problem space.  We need to = be
efficient with all our = resources.  The chips may get more powerful, = but
the network (802.15.4) = that we are targeting here will remain
constrained.  No doubt there will come a day when = different network
technologies = are applied in this space, but at that point I don't = think
we're talking 6LoWPAN = anymore.

I would word it a bit differently ... Yes = we do need to be careful of where we
apply technologies in light of = specific constraints. But each time we are tempted
to re-invent a = protocol let's first try to demonstrate that we cannot use an = existing
protocol.

Note that we may at some point start using = a more generic term than 6lowpans
and rather talk about LLNs (Low = power and Lossy Networks) or any other term:
they are many = constrained networks using other low power technologies than = 15.4

JP.


-----Original = Message-----
From: = 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] On
Behalf Of Kris = Pister
Sent: Monday, November = 09, 2009 10:12 PM
To: Stuber, = Michael
Cc: 6lowpan; 6lowapp@ietf.org
Subject: Re: [6lowapp] [6lowpan] hardware trends, = new vs. existing
protocols = [Re: 4861 usage in LLNs]

Abandoning the installed base just goes to reinforce the = idea  > that
IP isn't an appropriate technology for = things.

Michael - I = think that we have the same goal, but I disagree with = that
statement.  I think = that re-writing every protocol from = discovery
through transport to = applications, from scratch, is what reinforces = the
idea that IP isn't an = appropriate technology for things.

I realize that = there are pressures from an installed base, but at = this
point it's a tiny = fraction of the overall potential.  If we let the = 1%
installed base dictate the = path for the next 99%, we should do our best
to ensure that it's the right = path.

ksjp

Stuber, Michael = wrote:
Life may be getting better, but that doesn't mean we have = the wrong
target.  Abandoning the = installed base just goes to reinforce the = idea

that IP isn't an appropriate technology for things. =  Qualifications
for parts in appliances, meters, = and cars may take much longer than = in

other consumer electronics.  There are lots of = products shipping today

with
802.15.4 chips that do not match = the (nicer) specs you outline = below.
If we want to enable IP everywhere, we must acknowledge = that small
footprint parts are an important = part of "everywhere."

That said, I too am in favor of = exploring optimized DHCP.  It = would
provide the flexibility of living in an edge router, or = being
centralized.  It is a well defined, characterized = protocol.

-----Original = Message-----
From: 6lowpan-bounces@ietf.org = [mailto:6lowpan-bounces@ietf.org] On
Behalf Of Kris = Pister
Sent: Monday, November 09, 2009 6:53 = PM
To: Jonathan Hui
Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org
Subject: = [6lowpan] hardware trends, new vs. existing protocols = [Re:
4861 usage in = LLNs]

+1 in favor of using optimized = DHCP if possible (no opinion on = 'if
possible'), rather than inventing something = new.

As I've shared with several = people in private emails recently, = it's
pretty clear that lowpan nodes are going to get more = capable moving
forward, not less.  Why? =  Radios don't scale down in area when = you
scale

CMOS processes.  Today's = 15.4 single-chip nodes are made = in
technologies

that are several (maybe five?) = generations behind the cutting = edge.
This makes economic sense because the sales volumes don't = support the
need for expensive mask sets = yet.
When there's a volume application, and someone puts a 5mm2 = radio into
modern CMOS, it just doesn't = make sense to put 48kB of rom/flash = and
10kB of RAM next to it.  You'll put hundreds of kB of = rom/flash, and
many tens of kB of RAM, and the = radio will still be by far the = biggest

thing on the = chip.

Even the 48k/10k node from the = (very nice) 6lowapp bof presentation = is

not up to commercial standards - it's a five year old, = expensive,
academic platform - great for = it's time, but old.  Single-chip = nodes
from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB = RAM, a
32bit processor, and they aren't made in cutting-edge = processes yet
either.
Life is just going to get = better.  Let's try to find the = smallest
optimized set of *existing* = protocols that serve our needs, that = run
on the existing new low-cost hardware (not the old = workhorses). Let's
invent the absolute minimum of = new "optimized" protocols, because = it's

not at all clear to me that we are optimizing the right = things at this

point.  The less we invent, the broader the set of = applications and
applications programmers we = address.

ksjp

Jonathan Hui = wrote:

On Nov = 9, 2009, at 5:50 PM, Carsten Bormann = wrote:


Again, entirely getting rid of a = function is always the = best
optimization.
Can we do that for = DAD?

The *need* for DAD is the core question for me.  As = specified within
6lowpan-nd now, IPv6 addresses are maintained using a = centralized
protocol.  That protocol looks and smells like DHCP - = there's
request/response, lease times, relays.  The = whiteboard may = also
administratively assign addresses.  So in the end, = it's not clear to
me why = we would need to *detect* duplicates when we = essentially
*avoid* = them from the = beginning.

I've = voiced my comment several times over the past 1+ years = and
presented a draft that argues for the use of optimized = DHCP in
Dublin,



so = this is not new from my end.  The fact that the current = 6lowpan-nd

document has evolved towards = using DHCP-like mechanisms is not = an
accident.  But if what we do is DHCP-like, it would = seem to make
sense



to = utilize existing DHCP infrastructure rather than = defining
something



new.

--
Jonathan= Hui


_______________________________________________
6lowpan mailing = list
6lowpan@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowpan

_______________________________________________
6lowapp mailing = list
6lowapp@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowapp
_______________________________________________
6lowapp mailing = list
6lowapp@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowapp


= --Apple-Mail-184-376039752-- From hgs@cs.columbia.edu Tue Nov 10 05:33:49 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C763A67FC; Tue, 10 Nov 2009 05:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 e08SfhkEzFso; Tue, 10 Nov 2009 05:33:47 -0800 (PST) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id A8FCC3A69F0; Tue, 10 Nov 2009 05:33:47 -0800 (PST) Received: from new-host.home (pool-71-187-38-54.nwrknj.fios.verizon.net [71.187.38.54]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nAADY9DP007463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Nov 2009 08:34:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Henning Schulzrinne In-Reply-To: <429b380e0911092220m4a3b0c09n319bb162e92bbbe9@mail.gmail.com> Date: Tue, 10 Nov 2009 08:34:08 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <429b380e0911092220m4a3b0c09n319bb162e92bbbe9@mail.gmail.com> To: Shidan X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6 Cc: "Stuber, Michael" , 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 13:33:49 -0000 From participation in other working groups, discussions about encoding, known as the famous binary vs. text discussion, have a long and unproductive history. If this is to be more than assertions and argument-by-authority, proponents of feature-restricted or special- purpose protocols have the burden of proof: They have to show, based on realistic assumptions and real-world measurements, that more general techniques don't work in an interesting set of cases. Just saying that you can construct a network where a meter wants to tell its life story every ten seconds to 1000 light bulbs equipped with 2- bit processors all on the same PAN isn't too helpful unless this is a realistic deployment scenario. (I'm not saying anybody has done this so far, but we've come close.) In particular, I'd like to see observation-based estimates of message and bit rates for likely deployment scenarios. Even a 20 kb/s network can shovel 160,000 bytes a minute - that's a lot of air time for meters to fill. From experience, binary and other special-purpose encodings often only save 20 or 50%, i.e., not enough to make a fundamental difference and the processing effort is also often exaggerated. This is particularly true once you add crypto to the mix, which tends to completely dominate simple processing like embedded web servers. We are unlikely to get away with protocols that ignore security or rely on non-crypto mechanisms going forward, so focusing on whether it takes 1 or 10 bytes to turn on a lightbulb isn't likely going to help much if the signature takes 500 bytes. I also agree with the deployed-base fallacy. In real life, much of that base is never upgraded - often because remote upgrades simply aren't supported. By the time you send a technician to the household to swap the EPROM, the hardware cost is in the noise compared to the cost of the truck roll. In such cases, it's much better to run the old, insecure and inflexible protocol in parallel with the new version for more capable hardware. Henning On Nov 10, 2009, at 1:20 AM, Shidan wrote: > +100 > > On Tue, Nov 10, 2009 at 1:12 AM, Kris Pister > wrote: > > Abandoning the installed base just goes to reinforce the idea > > that IP isn't an appropriate technology for things. > > Michael - I think that we have the same goal, but I disagree with > that statement. I think that re-writing every protocol from > discovery through transport to applications, from scratch, is what > reinforces the idea that IP isn't an appropriate technology for > things. > > I realize that there are pressures from an installed base, but at > this point it's a tiny fraction of the overall potential. If we let > the 1% installed base dictate the path for the next 99%, we should > do our best to ensure that it's the right path. > > ksjp > > > Stuber, Michael wrote: > Life may be getting better, but that doesn't mean we have the wrong > target. Abandoning the installed base just goes to reinforce the idea > that IP isn't an appropriate technology for things. Qualifications > for > parts in appliances, meters, and cars may take much longer than in > other > consumer electronics. There are lots of products shipping today with > 802.15.4 chips that do not match the (nicer) specs you outline below. > If we want to enable IP everywhere, we must acknowledge that small > footprint parts are an important part of "everywhere." > > That said, I too am in favor of exploring optimized DHCP. It would > provide the flexibility of living in an edge router, or being > centralized. It is a well defined, characterized protocol. > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On > Behalf Of Kris Pister > Sent: Monday, November 09, 2009 6:53 PM > To: Jonathan Hui > Cc: Carsten Bormann; 6lowpan; 6lowapp@ietf.org > Subject: [6lowpan] hardware trends, new vs. existing protocols [Re: > 4861 > usage in LLNs] > > +1 in favor of using optimized DHCP if possible (no opinion on 'if > possible'), rather than inventing something new. > > As I've shared with several people in private emails recently, it's > pretty clear that lowpan nodes are going to get more capable moving > forward, not less. Why? Radios don't scale down in area when you > scale > > CMOS processes. Today's 15.4 single-chip nodes are made in > technologies > > that are several (maybe five?) generations behind the cutting edge. > This makes economic sense because the sales volumes don't support > the need for expensive mask sets yet. > When there's a volume application, and someone puts a 5mm2 radio > into modern CMOS, it just doesn't make sense to put 48kB of rom/ > flash and 10kB of RAM next to it. You'll put hundreds of kB of rom/ > flash, and many tens of kB of RAM, and the radio will still be by > far the biggest thing on the chip. > > Even the 48k/10k node from the (very nice) 6lowapp bof presentation > is not up to commercial standards - it's a five year old, expensive, > academic platform - great for it's time, but old. Single-chip nodes > from Jennic, Freescale, etc. have ~200kB ROM/flash + 128kB RAM, a > 32bit processor, and they aren't made in cutting-edge processes yet > either. Life is just going to get better. Let's try to find the > smallest optimized set of *existing* protocols that serve our needs, > that run on the existing new low-cost hardware (not the old > workhorses). Let's invent the absolute minimum of new "optimized" > protocols, because it's not at all clear to me that we are > optimizing the right things at this point. The less we invent, the > broader the set of applications and applications programmers we > address. > > ksjp > > Jonathan Hui wrote: > > On Nov 9, 2009, at 5:50 PM, Carsten Bormann wrote: > > > Again, entirely getting rid of a function is always the best > optimization. > Can we do that for DAD? > > The *need* for DAD is the core question for me. As specified within > 6lowpan-nd now, IPv6 addresses are maintained using a centralized > protocol. That protocol looks and smells like DHCP - there's > request/response, lease times, relays. The whiteboard may also > administratively assign addresses. So in the end, it's not clear to > me why we would need to *detect* duplicates when we essentially > *avoid* them from the beginning. > > I've voiced my comment several times over the past 1+ years and > presented a draft that argues for the use of optimized DHCP in Dublin, > > > > so this is not new from my end. The fact that the current 6lowpan- > nd document has evolved towards using DHCP-like mechanisms is not an > accident. But if what we do is DHCP-like, it would seem to make sense > > > > to utilize existing DHCP infrastructure rather than defining something > > > > new. > > -- > Jonathan Hui > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From richard.kelsey@ember.com Tue Nov 10 09:25:46 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0027C3A68AD; Tue, 10 Nov 2009 09:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 HMpH1kqbcCx9; Tue, 10 Nov 2009 09:25:45 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 13BB03A6B44; Tue, 10 Nov 2009 09:25:44 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 12:27:37 -0500 Date: Tue, 10 Nov 2009 12:22:58 -0500 Message-Id: <87639il2fh.fsf@kelsey-ws.hq.ember.com> To: Kris Pister In-reply-to: <4AF90433.30204@eecs.berkeley.edu> (message from Kris Pister on Mon, 09 Nov 2009 22:12:03 -0800) From: Richard Kelsey References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> X-OriginalArrivalTime: 10 Nov 2009 17:27:37.0539 (UTC) FILETIME=[18F64930:01CA622B] Cc: Michael.Stuber@itron.com, 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 17:25:46 -0000 Date: Mon, 09 Nov 2009 22:12:03 -0800 From: Kris Pister > Abandoning the installed base just goes to reinforce the idea > that IP isn't an appropriate technology for things. Michael - I think that we have the same goal, but I disagree with that statement. I think that re-writing every protocol from discovery through transport to applications, from scratch, is what reinforces the idea that IP isn't an appropriate technology for things. I realize that there are pressures from an installed base, but at this point it's a tiny fraction of the overall potential. If we let the 1% installed base dictate the path for the next 99%, we should do our best to ensure that it's the right path. Taking these two paragraphs together, you seem to be saying that IP is an appropriate technology for tomorrow's things, but not necessarily for today's. While the hardware will obviously improve over time, we still need to pick some target platform. The current 6lowpan charter gives 32K of flash as an example and mentions 802.15.4 repeatedly. Are you suggesting that we recharter? The increasing capabilities of the hardware does give us the reassuring prospect that the longer we take the solve the problems the easier it will be to so. -Richard Kelsey From pister@eecs.berkeley.edu Tue Nov 10 11:13:01 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0F53A6B75; Tue, 10 Nov 2009 11:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 1J7cg1FF5eOY; Tue, 10 Nov 2009 11:13:00 -0800 (PST) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 7CDAE3A698D; Tue, 10 Nov 2009 11:13:00 -0800 (PST) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.3/8.13.5) with ESMTP id nAAJDOqB028381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Nov 2009 11:13:25 -0800 (PST) Message-ID: <4AF9BB54.7070006@eecs.berkeley.edu> Date: Tue, 10 Nov 2009 11:13:24 -0800 From: Kris Pister User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Richard Kelsey References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87639il2fh.fsf@kelsey-ws.hq.ember.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael.Stuber@itron.com, 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 19:13:01 -0000 Richard - I think that today's things are being designed with wonderful chips like your Ember EM351 and EM357 which have 128kB and 192kB of flash and lots of RAM; like the Jennic JN5148, the Freescale MC13224, the Dust DN2510. They can run IP, they will run IP, and in many cases they do run IP. We all agree on that, and we're all excited about that. The debate centers on how many new protocols we need to invent, vs. how many we can adopt or adapt, with the existing hardware, and with an eye toward where technology trends are taking us. My concern, like yours, is over the rate of adoption. If the fastest path to broad adoption is to create new protocols for routing, ND, transport, and applications, then by all means let's do that. I'm concerned, however, that this has not been a uniformly successful approach for wireless sensor networks in the past. :) Many of us believe that we will see the fastest adoption by minimizing the number of new protocols. We might be wrong, and that's the debate. ksjp Richard Kelsey wrote: > Date: Mon, 09 Nov 2009 22:12:03 -0800 > From: Kris Pister > > > Abandoning the installed base just goes to reinforce the idea > > that IP isn't an appropriate technology for things. > > Michael - I think that we have the same goal, but I disagree with that > statement. I think that re-writing every protocol from discovery > through transport to applications, from scratch, is what reinforces the > idea that IP isn't an appropriate technology for things. > > I realize that there are pressures from an installed base, but at this > point it's a tiny fraction of the overall potential. If we let the 1% > installed base dictate the path for the next 99%, we should do our best > to ensure that it's the right path. > > Taking these two paragraphs together, you seem to be saying > that IP is an appropriate technology for tomorrow's things, > but not necessarily for today's. While the hardware will > obviously improve over time, we still need to pick some > target platform. The current 6lowpan charter gives 32K of > flash as an example and mentions 802.15.4 repeatedly. Are > you suggesting that we recharter? > > The increasing capabilities of the hardware does give us the > reassuring prospect that the longer we take the solve the > problems the easier it will be to so. > > -Richard Kelsey > From shidan@gmail.com Tue Nov 10 14:59:48 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03F4C3A6931; Tue, 10 Nov 2009 14:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.192, 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 bxZkJg2JgKHV; Tue, 10 Nov 2009 14:59:46 -0800 (PST) Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 094303A6BBB; Tue, 10 Nov 2009 14:59:45 -0800 (PST) Received: by ewy3 with SMTP id 3so599667ewy.37 for ; Tue, 10 Nov 2009 15:00:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UDXf/A/wyw8YRVtZzP7ioqOtq+/n4lWAozfz3IcOPpw=; b=MTSoWaUie3HZ2BMM/7CVXGHfbUkmgZ2u46pS4lLlsDMCT+yLOHr11z6IzIXnHW2ecz VfbBwOanCr7i60QR/4Zqz7H+tqaBuvNqUhcBskYyvsoNZoW3p0Hc1IGaUslhVGbdEG7k o8ZVkMtp49hh7LsauCKlRwoc7AdzbRM7lSU9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o+I/7gRXgW36spwLpGAuLlUc1aDiIwvGWVzu9QYGo7cR9cDLMeZGCa3nuZ8Im6kjOA w7tAAeZay2RSW+iSy/T0sndoxvnpd3tQWrQBefXABGb6YOWs+39QMfrnMzhKUELHVrud hBqR27x7/O9X/cBcnPN6mrIh+3b8v1R+Qvdqw= MIME-Version: 1.0 Received: by 10.216.88.14 with SMTP id z14mr233359wee.25.1257894009397; Tue, 10 Nov 2009 15:00:09 -0800 (PST) In-Reply-To: <87639il2fh.fsf@kelsey-ws.hq.ember.com> References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> Date: Tue, 10 Nov 2009 18:00:09 -0500 Message-ID: <429b380e0911101500p3564d253g9dabe7aa1b002ac2@mail.gmail.com> From: Shidan To: Richard Kelsey Content-Type: multipart/alternative; boundary=0016e6d7e9259862e404780c45b9 Cc: Michael.Stuber@itron.com, 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 22:59:48 -0000 --0016e6d7e9259862e404780c45b9 Content-Type: text/plain; charset=ISO-8859-1 Specially with respect to energy management, I don't think anyone is suggesting IP doesn't fit the bill today. Rather, to the contrary, many including myself, find it less clear if it's really necessary to redefine everything proposed to meet today's use cases. I'm not saying it's not, but just that it needs more careful analysis. What Kris is saying on the state of current technology and where it is headed, unlike some of the opposing arguments I've witnessed in this group, is very clear and understandable to me. I think what would alleviate everyones concerns, are equally clear arguments based on numbers, facts and use cases as to why we need an overhaul of everything. --- Shidan Gouran On Tue, Nov 10, 2009 at 12:22 PM, Richard Kelsey wrote: > Date: Mon, 09 Nov 2009 22:12:03 -0800 > From: Kris Pister > > > Abandoning the installed base just goes to reinforce the idea > > that IP isn't an appropriate technology for things. > > Michael - I think that we have the same goal, but I disagree with that > statement. I think that re-writing every protocol from discovery > through transport to applications, from scratch, is what reinforces the > idea that IP isn't an appropriate technology for things. > > I realize that there are pressures from an installed base, but at this > point it's a tiny fraction of the overall potential. If we let the 1% > installed base dictate the path for the next 99%, we should do our best > to ensure that it's the right path. > > Taking these two paragraphs together, you seem to be saying > that IP is an appropriate technology for tomorrow's things, > but not necessarily for today's. While the hardware will > obviously improve over time, we still need to pick some > target platform. The current 6lowpan charter gives 32K of > flash as an example and mentions 802.15.4 repeatedly. Are > you suggesting that we recharter? > > The increasing capabilities of the hardware does give us the > reassuring prospect that the longer we take the solve the > problems the easier it will be to so. > > -Richard Kelsey > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --0016e6d7e9259862e404780c45b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Specially with respect to energy management, I don't think anyone is su= ggesting IP doesn't fit the bill today. Rather, to the contrary, many i= ncluding myself, find it less clear if it's really necessary to redefin= e everything proposed to meet today's use cases. I'm not saying it&= #39;s not, but just that it needs more careful analysis.=A0

What Kris is saying on the state of current technology and w= here it is headed, unlike some of the opposing arguments I've witnessed= in this group, is very clear and understandable to me.=A0I think what woul= d alleviate everyones concerns, are equally clear arguments based on number= s, facts and use cases as to why we need an overhaul of everything.

--- =A0
Shidan Gouran=A0

=
On Tue, Nov 10, 2009 at 12:22 PM, Richard Kelsey <richard.kelsey@emb= er.com> wrote:=A0
= =A0 Date: Mon, 09 Nov 2009 22:12:03 -0800
=A0 From: Kris Pister <pist= er@eecs.berkeley.edu>

=A0 =A0> Abandoning the installed base just goes to reinforce the idea<= br> =A0 =A0> that IP isn't an appropriate technology for things.

=A0 Michael - I think that we have the same goal, but I disagree with that=
=A0 statement. =A0I think that re-writing every protocol from discovery =A0 through transport to applications, from scratch, is what reinforces th= e
=A0 idea that IP isn't an appropriate technology for things.

=A0 I realize that there are pressures from an installed base, but at this=
=A0 point it's a tiny fraction of the overall potential. =A0If we let = the 1%
=A0 installed base dictate the path for the next 99%, we should do our bes= t
=A0 to ensure that it's the right path.

Taking these two paragraphs together, you seem to be saying
that IP is an appropriate technology for tomorrow's things,
but not necessarily for today's. =A0While the hardware will
obviously improve over time, we still need to pick some
target platform. =A0The current 6lowpan charter gives 32K of
flash as an example and mentions 802.15.4 repeatedly. =A0Are
you suggesting that we recharter?

The increasing capabilities of the hardware does give us the
reassuring prospect that the longer we take the solve the
problems the easier it will be to so.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-Richard Ke= lsey
__________________________________= _____________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

--0016e6d7e9259862e404780c45b9-- From d.sturek@att.net Tue Nov 10 15:05:09 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21E928C1F9 for <6lowapp@core3.amsl.com>; Tue, 10 Nov 2009 15:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 tEKP86V2fIS2 for <6lowapp@core3.amsl.com>; Tue, 10 Nov 2009 15:05:09 -0800 (PST) Received: from smtp109.sbc.mail.gq1.yahoo.com (smtp109.sbc.mail.gq1.yahoo.com [67.195.14.39]) by core3.amsl.com (Postfix) with SMTP id 8E8DC28C0DD for <6lowapp@ietf.org>; Tue, 10 Nov 2009 15:05:09 -0800 (PST) Received: (qmail 54426 invoked from network); 10 Nov 2009 22:58:57 -0000 Received: from host-160-85.meeting.ietf.org (d.sturek@133.93.160.85 with login) by smtp109.sbc.mail.gq1.yahoo.com with SMTP; 10 Nov 2009 14:58:57 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: 1INt7CEVM1nDM.DbBcRvuNiWRB6nPLSmu69sk0ZZinc4ogtoQT1yDmoEMWZKN6eedpw4HR9upF_pbBH4WJBC2ucI5xiWsK2xGEvxnh_rcHRonFtNoEQCjFIgmrr0L23jZtb_OAmtBWanHjxFlwUK6eM6qCUVyxTJAbtRhFLIkecZQMVKBPf9PJ4CAK9Qtxyh5evAKmvA9_XpzBdSjqU8OUfkQ0RgFybOVDk5RmifGn369Ra_qIHihCbcHQKtW.j7oYOIvbV0JxTeKEheDepvC0aJFuDhsvhpAczGERaMbYbRKUpvwNWdSJjee9T27Q9N88eR5LTSNZpmU_U2dRHfDq0- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'Kris Pister'" , "'Richard Kelsey'" References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> In-Reply-To: <4AF9BB54.7070006@eecs.berkeley.edu> Date: Tue, 10 Nov 2009 14:58:54 -0800 Message-ID: <019f01ca6259$625528c0$26ff7a40$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpiOeUcq/TvAEg9RCGWZ32RY3XEYwAHlhSg Content-Language: en-us Cc: 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:05:09 -0000 Hi Kris, Prior to all of the wireless work I have done in the past 10 years, I worked at a specialty edge router company. We worked in large data centers migrating serial protocols (bisync, X.25, etc.) to IP. This work did actually require new IETF protocols and extensions (MPLS, reliable multicast, etc). I think for 6LowPAN to proliferate, we need to partially do what you suggest (limit where possible creating new protocols) but augment existing IETF standards as well. I really see the CoRE work aligning with that vision since we are mapping it to a RESTfull HTTP deployment which has precedence in current web services. Having CoRE re-use existing transports and security is critical There was one thing missing from your note on new hardware: cost. Lowering the bar on cost with CoRE will allow the technology to be deployed in places where new ARM processors with 192K flash/etc are too expensive. Don -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Kris Pister Sent: Tuesday, November 10, 2009 11:13 AM To: Richard Kelsey Cc: 6lowpan@ietf.org; 6lowapp@ietf.org Subject: Re: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Richard - I think that today's things are being designed with wonderful chips like your Ember EM351 and EM357 which have 128kB and 192kB of flash and lots of RAM; like the Jennic JN5148, the Freescale MC13224, the Dust DN2510. They can run IP, they will run IP, and in many cases they do run IP. We all agree on that, and we're all excited about that. The debate centers on how many new protocols we need to invent, vs. how many we can adopt or adapt, with the existing hardware, and with an eye toward where technology trends are taking us. My concern, like yours, is over the rate of adoption. If the fastest path to broad adoption is to create new protocols for routing, ND, transport, and applications, then by all means let's do that. I'm concerned, however, that this has not been a uniformly successful approach for wireless sensor networks in the past. :) Many of us believe that we will see the fastest adoption by minimizing the number of new protocols. We might be wrong, and that's the debate. ksjp Richard Kelsey wrote: > Date: Mon, 09 Nov 2009 22:12:03 -0800 > From: Kris Pister > > > Abandoning the installed base just goes to reinforce the idea > > that IP isn't an appropriate technology for things. > > Michael - I think that we have the same goal, but I disagree with that > statement. I think that re-writing every protocol from discovery > through transport to applications, from scratch, is what reinforces the > idea that IP isn't an appropriate technology for things. > > I realize that there are pressures from an installed base, but at this > point it's a tiny fraction of the overall potential. If we let the 1% > installed base dictate the path for the next 99%, we should do our best > to ensure that it's the right path. > > Taking these two paragraphs together, you seem to be saying > that IP is an appropriate technology for tomorrow's things, > but not necessarily for today's. While the hardware will > obviously improve over time, we still need to pick some > target platform. The current 6lowpan charter gives 32K of > flash as an example and mentions 802.15.4 repeatedly. Are > you suggesting that we recharter? > > The increasing capabilities of the hardware does give us the > reassuring prospect that the longer we take the solve the > problems the easier it will be to so. > > -Richard Kelsey > _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From richard.kelsey@ember.com Tue Nov 10 15:15:51 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B18E28C233; Tue, 10 Nov 2009 15:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 LHxQ2AlfhG-w; Tue, 10 Nov 2009 15:15:50 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4C79A28C227; Tue, 10 Nov 2009 15:15:50 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 18:17:43 -0500 Date: Tue, 10 Nov 2009 18:13:04 -0500 Message-Id: <87eio62cu7.fsf@kelsey-ws.hq.ember.com> To: Kris Pister In-reply-to: <4AF9BB54.7070006@eecs.berkeley.edu> (message from Kris Pister on Tue, 10 Nov 2009 11:13:24 -0800) From: Richard Kelsey References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> X-OriginalArrivalTime: 10 Nov 2009 23:17:43.0646 (UTC) FILETIME=[0193D7E0:01CA625C] Cc: Michael.Stuber@itron.com, 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 23:15:51 -0000 Date: Tue, 10 Nov 2009 11:13:24 -0800 From: Kris Pister I think that today's things are being designed with wonderful chips like your Ember EM351 and EM357 which have 128kB and 192kB of flash and lots of RAM; like the Jennic JN5148, the Freescale MC13224, the Dust DN2510. They can run IP, they will run IP, and in many cases they do run IP. Kris, Their wonderfulness aside, those chips are not what the 6lowpan charter describes. Yes, I agree that rechartering for bigger platforms would make our job easier, and could reduce the number of new protocols needed. I am not arguing for or against it, just asking you if you are proposing that we amend the charter. If not, then we should use the specs that it has. -Richard Kelsey From robert.cragie@gridmerge.com Tue Nov 10 16:24:49 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596913A67B6; Tue, 10 Nov 2009 16:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 73GWTNF3r+nU; Tue, 10 Nov 2009 16:24:47 -0800 (PST) Received: from mail26.extendcp.co.uk (mail26.extendcp.co.uk [79.170.40.26]) by core3.amsl.com (Postfix) with ESMTP id 25FF328C25A; Tue, 10 Nov 2009 16:24:47 -0800 (PST) Received: from client-82-3-89-126.manc.adsl.virginmedia.com ([82.3.89.126] helo=[192.168.1.66]) by mail26.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) id 1N811I-0003w4-2A; Wed, 11 Nov 2009 00:25:08 +0000 Message-ID: <4AFA0462.2090807@gridmerge.com> Date: Wed, 11 Nov 2009 00:25:06 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Kris Pister References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> In-Reply-To: <4AF9BB54.7070006@eecs.berkeley.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040802090508050607040607" Cc: Michael.Stuber@itron.com, 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 00:24:49 -0000 This is a cryptographically signed message in MIME format. --------------ms040802090508050607040607 Content-Type: multipart/alternative; boundary="------------040803000407020901030903" This is a multi-part message in MIME format. --------------040803000407020901030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So it is again down to trying to find the intersection between well-established and well-known protocols which work in networks with limited resources whose nodes have limited resources. There is a chance that despite the extent of the IETF smorgasbord, existing protocols may need to be tweaked or updated to accommodate these requirements. However, this must be the underlying aim - not to reinvent, but to take verbatim where possible and adapt where necessary. Where there is a clear demand, solutions will appear based on existing protocols plus adaptations - for example, VoIP. Regarding resource: There will be classes of devices which currently will not support IP packets as the resource constraints are too high, e.g. self-powered switches where the power budget is so constrained you can barely get a squeak out of them. Do we want to accommodate these devices in CoRE etc.? Probably not, and so it makes sense to develop the network which suits those devices and proxy them on a gateway. On the other hand, I think we have established that we don't want to persistently continue to develop a plethora of coexisting but non-interoperating networks all connected to the internet through a hodge-podge of application gateways for the sake of it. This is the reality today and it could be argued that this has stifled the development of the highly-connected "Internet of Things" we have all been dreaming about; it is a solution but a clumsy one and one which doesn't scale well. Regarding bandwidth: I remember back in the early 90's being able to look at basic websites over a V32.bis (14400 bps max.) modem; whilst the experience could be frustratingly slow, it was usable. And that was an online, interactive experience. So whilst we need to consider the arguments about bandwidth, I think that realistic traffic scenarios need to be carefully looked at before ruling some solutions out. I am sure there is already a plethora of experience from many of the contributors to this group who already work in this area. So we come down to the limited ROM/RAM devices which sit uneasily between the clearly capable devices currently available and the very constrained and highly specific devices for certain types of network. Which way do we want to push them? On the basis that these are the devices which will become obsolete first, I would push them towards the constrained side and say they are all proxied. In which case, CoRE/ROLL/6LoWPAN becomes becomes focused on the more clearly capable devices and therefore, as said at the beginning of this e-mail, based on protocols taken verbatim where possible and adapted where necessary. Robert Kris Pister wrote: > Richard - > I think that today's things are being designed with wonderful chips > like your Ember EM351 and EM357 > which have 128kB and 192kB of flash and lots of RAM; like the Jennic > JN5148, the Freescale MC13224, the Dust DN2510. > They can run IP, they will run IP, and in many cases they do run IP. > We all agree on that, and we're all excited about that. The debate > centers on how many new protocols we need to invent, vs. how many we > can adopt or adapt, with the existing hardware, and with an eye toward > where technology trends are taking us. My concern, like yours, is > over the rate of adoption. If the fastest path to broad adoption is > to create new protocols for routing, ND, transport, and applications, > then by all means let's do that. I'm concerned, however, that this > has not been a uniformly successful approach for wireless sensor > networks in the past. :) > Many of us believe that we will see the fastest adoption by minimizing > the number of new protocols. We might be wrong, and that's the debate. > > ksjp > > Richard Kelsey wrote: >> Date: Mon, 09 Nov 2009 22:12:03 -0800 >> From: Kris Pister >> >> > Abandoning the installed base just goes to reinforce the idea >> > that IP isn't an appropriate technology for things. >> >> Michael - I think that we have the same goal, but I disagree with >> that statement. I think that re-writing every protocol from >> discovery through transport to applications, from scratch, is what >> reinforces the idea that IP isn't an appropriate technology for >> things. >> >> I realize that there are pressures from an installed base, but at >> this point it's a tiny fraction of the overall potential. If we >> let the 1% installed base dictate the path for the next 99%, we >> should do our best to ensure that it's the right path. >> >> Taking these two paragraphs together, you seem to be saying >> that IP is an appropriate technology for tomorrow's things, >> but not necessarily for today's. While the hardware will >> obviously improve over time, we still need to pick some >> target platform. The current 6lowpan charter gives 32K of >> flash as an example and mentions 802.15.4 repeatedly. Are >> you suggesting that we recharter? >> The increasing capabilities of the hardware does give us the >> reassuring prospect that the longer we take the solve the >> problems the easier it will be to so. >> >> -Richard Kelsey >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > --------------040803000407020901030903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit So it is again down to trying to find the intersection between well-established and well-known protocols which work in networks with limited resources whose nodes have limited resources. There is a chance that despite the extent of the IETF smorgasbord, existing protocols may need to be tweaked or updated to accommodate these requirements. However, this must be the underlying aim - not to reinvent, but to take verbatim where possible and adapt where necessary. Where there is a clear demand, solutions will appear based on existing protocols plus adaptations - for example, VoIP.

Regarding resource: There will be classes of devices which currently will not support IP packets as the resource constraints are too high, e.g. self-powered switches where the power budget is so constrained you can barely get a squeak out of them. Do we want to accommodate these devices in CoRE etc.? Probably not, and so it makes sense to develop the network which suits those devices and proxy them on a gateway. On the other hand, I think we have established that we don't want to persistently continue to develop a plethora of coexisting but non-interoperating networks all connected to the internet through a hodge-podge of application gateways for the sake of it. This is the reality today and it could be argued that this has stifled the development of the highly-connected "Internet of Things" we have all been dreaming about; it is a solution but a clumsy one and one which doesn't scale well.

Regarding bandwidth: I remember back in the early 90's being able to look at basic websites over a V32.bis (14400 bps max.) modem; whilst the experience could be frustratingly slow, it was usable. And that was an online, interactive experience. So whilst we need to consider the arguments about bandwidth, I think that realistic traffic scenarios need to be carefully looked at before ruling some solutions out. I am sure there is already a plethora of experience from many of the contributors to this group who already work in this area.

So we come down to the limited ROM/RAM devices which sit uneasily between the clearly capable devices currently available and the very constrained and highly specific devices for certain types of network. Which way do we want to push them? On the basis that these are the devices which will become obsolete first, I would push them towards the constrained side and say they are all proxied. In which case, CoRE/ROLL/6LoWPAN becomes becomes focused on the more clearly capable devices and therefore, as said at the beginning of this e-mail, based on protocols taken verbatim where possible and adapted where necessary.

Robert

Kris Pister wrote:
Richard -
I think that today's things are being designed with wonderful chips like your Ember EM351 and EM357
which have 128kB and 192kB of flash and lots of RAM; like the Jennic JN5148, the Freescale MC13224, the Dust DN2510.
They can run IP, they will run IP, and in many cases they do run IP.  We all agree on that, and we're all excited about that. The debate centers on how many new protocols we need to invent, vs. how many we can adopt or adapt, with the existing hardware, and with an eye toward where technology trends are taking us.  My concern, like yours, is over the rate of adoption.  If the fastest path to broad adoption is to create new protocols for routing, ND, transport, and applications, then by all means let's do that.  I'm concerned, however, that this has not been a uniformly successful approach for wireless sensor networks in the past. :)
Many of us believe that we will see the fastest adoption by minimizing the number of new protocols.  We might be wrong, and that's the debate.

ksjp

Richard Kelsey wrote:
   Date: Mon, 09 Nov 2009 22:12:03 -0800
   From: Kris Pister <pister@eecs.berkeley.edu>

    > Abandoning the installed base just goes to reinforce the idea
    > that IP isn't an appropriate technology for things.

   Michael - I think that we have the same goal, but I disagree with that    statement.  I think that re-writing every protocol from discovery    through transport to applications, from scratch, is what reinforces the    idea that IP isn't an appropriate technology for things.

   I realize that there are pressures from an installed base, but at this    point it's a tiny fraction of the overall potential.  If we let the 1%    installed base dictate the path for the next 99%, we should do our best    to ensure that it's the right path.

Taking these two paragraphs together, you seem to be saying
that IP is an appropriate technology for tomorrow's things,
but not necessarily for today's.  While the hardware will
obviously improve over time, we still need to pick some
target platform.  The current 6lowpan charter gives 32K of
flash as an example and mentions 802.15.4 repeatedly.  Are
you suggesting that we recharter? 
The increasing capabilities of the hardware does give us the
reassuring prospect that the longer we take the solve the
problems the easier it will be to so.

                                -Richard Kelsey
 
_______________________________________________
6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.org/mailman/listinfo/6lowapp

--------------040803000407020901030903-- --------------ms040802090508050607040607 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTEx MTEwMDI1MDZaMCMGCSqGSIb3DQEJBDEWBBRAMSjdCDTlyvXzcr1afCYa7IYUFjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAAl5xu4+6iUZJtgvpCcz9shd5uiLhLsRifLZ3TQ164MN/MXY6YE4Wh29TRhuvWgjBWrq ey7o08i0xe2cUelNVaHHuQaaUo0UzxekAzESl/g0a7R7655YXAlGeHY2atF0fl0wTa9n5FE4 17ivmRhxWHnCsq3vwr834c4vC+GPnBXUAB+UsWUmimZMpFXhGa5QsiAlTy9fbU061iPjw8AL F/ij+1mkcI18xyVV4vPwdQr+bdjDi8Sdsxpd1Sj5XxllhjscDPWwKOWCidaaGbyW5zgmEFa2 lU1jd1WbYs+8AtMFGp8PwRce1EHgh1Jc3DDR0lL4umyWooeQSlH0y4ruLBoAAAAAAAA= --------------ms040802090508050607040607-- From trifa@inf.ethz.ch Wed Nov 11 00:19:33 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 634743A6822; Wed, 11 Nov 2009 00:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 iOvEbW1Eok0E; Wed, 11 Nov 2009 00:19:31 -0800 (PST) Received: from gwse.ethz.ch (gwse.ethz.ch [129.132.178.238]) by core3.amsl.com (Postfix) with ESMTP id A676E3A6841; Wed, 11 Nov 2009 00:19:26 -0800 (PST) Received: from CAS00.d.ethz.ch (129.132.178.234) by gws01.d.ethz.ch (129.132.178.238) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 Nov 2009 09:19:53 +0100 Received: from [192.168.126.71] (77.58.206.5) by mail.ethz.ch (129.132.178.227) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 11 Nov 2009 09:19:42 +0100 Message-ID: From: Vlad Trifa To: In-Reply-To: <4AFA0462.2090807@gridmerge.com> Content-Type: multipart/alternative; boundary="Apple-Mail-50-447506445" MIME-Version: 1.0 (Apple Message framework v936) Date: Wed, 11 Nov 2009 09:19:40 +0100 References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> <4AFA0462.2090807@gridmerge.com> X-Mailer: Apple Mail (2.936) Cc: Michael.Stuber@itron.com, 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:19:33 -0000 --Apple-Mail-50-447506445 Content-Type: text/plain; charset="US-ASCII"; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I totally second you Robert! I think indeed, we shouldn't try to accomodate everything from enocean light switches to servers, but rather enabling interoperability between a wide class of devices with similar (limited) resources, basically the same class of devices where 6lowpan could be used, and basta. Indeed, our focus should be really making the web of things a reality, and make it scale as well, rather than take into account too much bandwidth constraints and have them as central "design problem to solve", as the actual problem we're trying to solve is different, and bandwidth is a not-so-critical constraint (if we need very high data rate and quasi real time constraints, nobody prevents us by using gateways to connect legacy networks with other pure CoRE ones), as long as CoRE can "semantically" accommodate different QoS with high data rates transmitted through protocols that we're designed for that (http). If the proxying or device-level core-enablement is transparent, then it doesn't matter because interactions will be CoREful (I like that term :) anyway. It's not because a protocol was not made for something that we should't use it, especially if it works fine for the scenarios we consider. What's really missing is a concrete evaluation of the scalability of HTTP-based scenarios for devices to show that it works (or doesn't). Unless we have that, I don't see why we start with the assumption that http-based solutions would be inherently bad and won't scale because of the verbosity, and we need to get a grasp of their actual limitations in that area. Vlad On Nov 11, 2009, at 1:25 AM, Robert Cragie wrote: > Regarding resource: There will be classes of devices which currently > will not support IP packets as the resource constraints are too > high, e.g. self-powered switches where the power budget is so > constrained you can barely get a squeak out of them. Do we want to > accommodate these devices in CoRE etc.? Probably not, and so it > makes sense to develop the network which suits those devices and > proxy them on a gateway. On the other hand, I think we have > established that we don't want to persistently continue to develop a > plethora of coexisting but non-interoperating networks all connected > to the internet through a hodge-podge of application gateways for > the sake of it. This is the reality today and it could be argued > that this has stifled the development of the highly-connected > "Internet of Things" we have all been dreaming about; it is a > solution but a clumsy one and one which doesn't scale well. > > Regarding bandwidth: I remember back in the early 90's being able to > look at basic websites over a V32.bis (14400 bps max.) modem; whilst > the experience could be frustratingly slow, it was usable. And that > was an online, interactive experience. So whilst we need to consider > the arguments about bandwidth, I think that realistic traffic > scenarios need to be carefully looked at before ruling some > solutions out. I am sure there is already a plethora of experience > from many of the contributors to this group who already work in this > area. > > So we come down to the limited ROM/RAM devices which sit uneasily > between the clearly capable devices currently available and the very > constrained and highly specific devices for certain types of > network. Which way do we want to push them? On the basis that these > are the devices which will become obsolete first, I would push them > towards the constrained side and say they are all proxied. In which > case, CoRE/ROLL/6LoWPAN becomes becomes focused on the more clearly > capable devices and therefore, as said at the beginning of this e- > mail, based on protocols taken verbatim where possible and adapted > where necessary. > > Robert > > Kris Pister wrote: >> >> Richard - >> I think that today's things are being designed with wonderful chips >> like your Ember EM351 and EM357 >> which have 128kB and 192kB of flash and lots of RAM; like the >> Jennic JN5148, the Freescale MC13224, the Dust DN2510. >> They can run IP, they will run IP, and in many cases they do run >> IP. We all agree on that, and we're all excited about that. The >> debate centers on how many new protocols we need to invent, vs. how >> many we can adopt or adapt, with the existing hardware, and with an >> eye toward where technology trends are taking us. My concern, like >> yours, is over the rate of adoption. If the fastest path to broad >> adoption is to create new protocols for routing, ND, transport, and >> applications, then by all means let's do that. I'm concerned, >> however, that this has not been a uniformly successful approach for >> wireless sensor networks in the past. :) >> Many of us believe that we will see the fastest adoption by >> minimizing the number of new protocols. We might be wrong, and >> that's the debate. >> >> ksjp >> >> Richard Kelsey wrote: >>> Date: Mon, 09 Nov 2009 22:12:03 -0800 >>> From: Kris Pister >>> >>> > Abandoning the installed base just goes to reinforce the idea >>> > that IP isn't an appropriate technology for things. >>> >>> Michael - I think that we have the same goal, but I disagree >>> with that statement. I think that re-writing every protocol >>> from discovery through transport to applications, from scratch, >>> is what reinforces the idea that IP isn't an appropriate >>> technology for things. >>> >>> I realize that there are pressures from an installed base, but >>> at this point it's a tiny fraction of the overall potential. >>> If we let the 1% installed base dictate the path for the next >>> 99%, we should do our best to ensure that it's the right path. >>> >>> Taking these two paragraphs together, you seem to be saying >>> that IP is an appropriate technology for tomorrow's things, >>> but not necessarily for today's. While the hardware will >>> obviously improve over time, we still need to pick some >>> target platform. The current 6lowpan charter gives 32K of >>> flash as an example and mentions 802.15.4 repeatedly. Are >>> you suggesting that we recharter? >>> The increasing capabilities of the hardware does give us the >>> reassuring prospect that the longer we take the solve the >>> problems the easier it will be to so. >>> >>> -Richard Kelsey >>> >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >> > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --Apple-Mail-50-447506445 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I totally second you = Robert! 

I think indeed, we shouldn't try to = accomodate everything from enocean light switches to servers, but rather = enabling interoperability between a wide class of devices with similar = (limited) resources, basically the same class of devices where 6lowpan = could be used, and basta. 

Indeed, our focus = should be really making the web of things a reality, and make it scale = as well, rather than take into account too much bandwidth constraints = and have them as central "design problem to solve", as the actual = problem we're trying to solve is different, and bandwidth is a = not-so-critical constraint (if we need very high data rate and quasi = real time constraints, nobody prevents us by using gateways to connect = legacy networks with other pure CoRE ones), as long as CoRE can = "semantically" accommodate different QoS with high data rates = transmitted through protocols that we're designed for that (http). If = the proxying or device-level core-enablement is transparent, then it = doesn't matter because interactions will be CoREful (I like that term = :)  anyway.

It's not because a = protocol was not made for something that we should't use it, especially = if it works fine for the scenarios we consider. What's really missing is = a concrete evaluation of the scalability of HTTP-based scenarios for = devices to show that it works (or doesn't). Unless we have that, I don't = see why we start with the assumption that http-based solutions would be = inherently bad and won't scale because of the verbosity, and we need to = get a grasp of their actual limitations in that = area.

Vlad


 

On Nov 11, 2009, at 1:25 AM, Robert = Cragie wrote:
Regarding resource: There will be = classes of devices which currently will not support IP packets as the = resource constraints are too high, e.g. self-powered switches where the = power budget is so constrained you can barely get a squeak out of them. = Do we want to accommodate these devices in CoRE etc.? Probably not, and = so it makes sense to develop the network which suits those devices and = proxy them on a gateway. On the other hand, I think we have established = that we don't want to persistently continue to develop a plethora of = coexisting but non-interoperating networks all connected to the internet = through a hodge-podge of application gateways for the sake of it. This = is the reality today and it could be argued that this has stifled the = development of the highly-connected "Internet of Things" we have all = been dreaming about; it is a solution but a clumsy one and one which = doesn't scale well.

Regarding bandwidth: I remember back in the = early 90's being able to look at basic websites over a V32.bis (14400 = bps max.) modem; whilst the experience could be frustratingly slow, it = was usable. And that was an online, interactive experience. So whilst we = need to consider the arguments about bandwidth, I think that realistic = traffic scenarios need to be carefully looked at before ruling some = solutions out. I am sure there is already a plethora of experience from = many of the contributors to this group who already work in this = area.

So we come down to the limited ROM/RAM devices which sit = uneasily between the clearly capable devices currently available and the = very constrained and highly specific devices for certain types of = network. Which way do we want to push them? On the basis that these are = the devices which will become obsolete first, I would push them towards = the constrained side and say they are all proxied. In which case, = CoRE/ROLL/6LoWPAN becomes becomes focused on the more clearly capable = devices and therefore, as said at the beginning of this e-mail, based on = protocols taken verbatim where possible and adapted where necessary.
=
Robert

Kris Pister wrote:
Richard - =
I think that today's things are being designed with wonderful chips = like your Ember EM351 and EM357
which have 128kB and 192kB of flash = and lots of RAM; like the Jennic JN5148, the Freescale MC13224, the Dust = DN2510.
They can run IP, they will run IP, and in many cases they = do run IP.  We all agree on that, and we're all excited about that. = The debate centers on how many new protocols we need to invent, vs. how = many we can adopt or adapt, with the existing hardware, and with an eye = toward where technology trends are taking us.  My concern, like = yours, is over the rate of adoption.  If the fastest path to broad = adoption is to create new protocols for routing, ND, transport, and = applications, then by all means let's do that.  I'm concerned, = however, that this has not been a uniformly successful approach for = wireless sensor networks in the past. :)
Many of us believe that we = will see the fastest adoption by minimizing the number of new = protocols.  We might be wrong, and that's the debate.

= ksjp

Richard Kelsey wrote:
   Date: Mon, 09 Nov 2009 22:12:03 -0800
=    From: Kris Pister <pister@eecs.berkeley.edu><= /a>

    > Abandoning the installed = base just goes to reinforce the idea
    > that = IP isn't an appropriate technology for things.

   = Michael - I think that we have the same goal, but I disagree with that =    statement.  I think that re-writing every protocol = from discovery    through transport to applications, from = scratch, is what reinforces the    idea that IP isn't an = appropriate technology for things.

   I realize = that there are pressures from an installed base, but at this =    point it's a tiny fraction of the overall potential.  = If we let the 1%    installed base dictate the path for the = next 99%, we should do our best    to ensure that it's the = right path.

Taking these two paragraphs together, you seem = to be saying
that IP is an appropriate technology for tomorrow's = things,
but not necessarily for today's.  While the hardware = will
obviously improve over time, we still need to pick some
= target platform.  The current 6lowpan charter gives 32K of
= flash as an example and mentions 802.15.4 repeatedly.  Are
you = suggesting that we recharter? 
The increasing capabilities of = the hardware does give us the
reassuring prospect that the longer = we take the solve the
problems the easier it will be to so.
=
=             &n= bsp;           &nbs= p;       -Richard Kelsey
  =
_______________________________________________
= 6lowapp mailing list
6lowapp@ietf.org
https://www.ietf.or= g/mailman/listinfo/6lowapp

= _______________________________________________
6lowapp mailing = list
6lowapp@ietf.org
https://www.ietf.= org/mailman/listinfo/6lowapp

<= /body>= --Apple-Mail-50-447506445-- From cabo@tzi.org Wed Nov 11 00:46:56 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C753D3A6A01 for <6lowapp@core3.amsl.com>; Wed, 11 Nov 2009 00:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 0P5mOWO-B2-G for <6lowapp@core3.amsl.com>; Wed, 11 Nov 2009 00:46:56 -0800 (PST) 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 A39EB3A6A85 for <6lowapp@ietf.org>; Wed, 11 Nov 2009 00:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nAB8lGrF007945; Wed, 11 Nov 2009 09:47:16 +0100 (CET) Received: from host-24-126.meeting.ietf.org (host-24-126.meeting.ietf.org [133.93.24.126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id EB61EBE25; Wed, 11 Nov 2009 09:47:14 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Carsten Bormann In-Reply-To: Date: Wed, 11 Nov 2009 17:47:10 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> <4AFA0462.2090807@gridmerge.com> To: Vlad Trifa X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 08:46:56 -0000 [limiting reply set to 6lowapp trying to untangle this thread] On Nov 11, 2009, at 17:19, Vlad Trifa wrote: > bandwidth is a not-so-critical constraint I don't think you can describe the difficulties of constrained nodes/ networks using a single metric. Indeed, the peak bitrate of a wireless technology may not be so bad, but challenges remain that may make existing protocols hard to use. Or maybe they don't -- that's why we are not at all trying to funnel all communication from the constrained network through CoAP (or CoGIIs). This *is* IP, after all. Gruesse, Carsten From hgs@cs.columbia.edu Wed Nov 11 02:12:15 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BD33A69FC; Wed, 11 Nov 2009 02:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 mhCl9axn0F2G; Wed, 11 Nov 2009 02:12:13 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id 7840E3A68CB; Wed, 11 Nov 2009 02:12:13 -0800 (PST) Received: from fokuswl198.fhi-fokus.de (fokuswl198.fhi-fokus.de [193.174.153.198]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nABACZqO000202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Nov 2009 05:12:36 -0500 (EST) References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> <87eio62cu7.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87eio62cu7.fsf@kelsey-ws.hq.ember.com> Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <278C5C8B-928A-4B01-BA9B-9ADD1CD41CC7@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Wed, 11 Nov 2009 05:12:33 -0500 To: Richard Kelsey X-Mailer: Apple Mail (2.1076) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.65 on 128.59.29.8 Cc: Michael.Stuber@itron.com, 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 10:12:15 -0000 The charter is presumably a draft, not a consensus. The numbers in the charter seem to lack rigorous justification, so I'm not comfortable with them as they stand. So, yes, I'm suggesting to either drop the numbers or make them more useful. In addition, memory size arguments are not terribly helpful unless each proposal will have a canonical implementation in the I-D. At least from my experience, people are very bad at estimating implementation complexity, except that one's own proposal by definition has lower complexity than any competing proposals. Henning On Nov 10, 2009, at 6:13 PM, Richard Kelsey wrote: > Date: Tue, 10 Nov 2009 11:13:24 -0800 > From: Kris Pister > > I think that today's things are being designed with > wonderful chips like your Ember EM351 and EM357 which > have 128kB and 192kB of flash and lots of RAM; like the > Jennic JN5148, the Freescale MC13224, the Dust DN2510. > They can run IP, they will run IP, and in many cases they > do run IP. > > Kris, > > Their wonderfulness aside, those chips are not what the > 6lowpan charter describes. Yes, I agree that rechartering > for bigger platforms would make our job easier, and could > reduce the number of new protocols needed. I am not arguing > for or against it, just asking you if you are proposing that > we amend the charter. If not, then we should use the specs > that it has. > -Richard Kelsey > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp > From zach@sensinode.com Wed Nov 11 04:26:39 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918EA28C20E for <6lowapp@core3.amsl.com>; Wed, 11 Nov 2009 04:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 H5Zgzb7W5-xF for <6lowapp@core3.amsl.com>; Wed, 11 Nov 2009 04:26:38 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 0520F3A688D for <6lowapp@ietf.org>; Wed, 11 Nov 2009 04:26:37 -0800 (PST) Received: from host-17-149.meeting.ietf.org (host-17-149.meeting.ietf.org [133.93.17.149]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nABCQrTA022137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Nov 2009 14:26:57 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <019f01ca6259$625528c0$26ff7a40$@sturek@att.net> Date: Wed, 11 Nov 2009 21:26:54 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2704E79A-634B-4677-A28A-3F9841CEE737@sensinode.com> References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> <019f01ca6259$625528c0$26ff7a40$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1076) Cc: 6lowapp@ietf.org Subject: Re: [6lowapp] Next steps X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:26:39 -0000 (again off the 6lowpan list, thread re-named) Hi from Hiroshima, I totally agree with Don below. There is a clear need for what CoRE is =20= aiming to achieve, which was confirmed here at the IETF as well. For =20 those of you that can and want to use HTTP, then please go ahead and =20 do that. CoRE is just augmenting the REST model with a different =20 realization. We had a really successful BOF here at the IETF, with helpful input to =20= update the charter and move forward. Please give us a chance here to =20 report back to the mailing list, and let you know what the next steps =20= are. Be sure we will take the feedback on the CoRE charter into =20 account from the mailing list as well. Thanks, Zach On Nov 11, 2009, at 7:58 , Don Sturek wrote: > Hi Kris, > > Prior to all of the wireless work I have done in the past 10 years, =20= > I worked > at a specialty edge router company. We worked in large data centers > migrating serial protocols (bisync, X.25, etc.) to IP. This work did > actually require new IETF protocols and extensions (MPLS, reliable > multicast, etc). > > I think for 6LowPAN to proliferate, we need to partially do what you =20= > suggest > (limit where possible creating new protocols) but augment existing =20 > IETF > standards as well. I really see the CoRE work aligning with that =20 > vision > since we are mapping it to a RESTfull HTTP deployment which has =20 > precedence > in current web services. Having CoRE re-use existing transports and > security is critical > > There was one thing missing from your note on new hardware: cost. > Lowering the bar on cost with CoRE will allow the technology to be =20 > deployed > in places where new ARM processors with 192K flash/etc are too =20 > expensive. > > Don > > > -----Original Message----- > From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On =20= > Behalf > Of Kris Pister > Sent: Tuesday, November 10, 2009 11:13 AM > To: Richard Kelsey > Cc: 6lowpan@ietf.org; 6lowapp@ietf.org > Subject: Re: [6lowpan] hardware trends, new vs. existing protocols =20 > [Re: 4861 > usage in LLNs] > > Richard - > I think that today's things are being designed with wonderful chips =20= > like > your Ember EM351 and EM357 > which have 128kB and 192kB of flash and lots of RAM; like the Jennic > JN5148, the Freescale MC13224, the Dust DN2510. > They can run IP, they will run IP, and in many cases they do run =20 > IP. We > all agree on that, and we're all excited about that. > The debate centers on how many new protocols we need to invent, vs. =20= > how > many we can adopt or adapt, with the existing hardware, and with an =20= > eye > toward where technology trends are taking us. My concern, like yours, > is over the rate of adoption. If the fastest path to broad adoption =20= > is > to create new protocols for routing, ND, transport, and applications, > then by all means let's do that. I'm concerned, however, that this =20= > has > not been a uniformly successful approach for wireless sensor =20 > networks in > the past. :) > Many of us believe that we will see the fastest adoption by minimizing > the number of new protocols. We might be wrong, and that's the =20 > debate. > > ksjp > > Richard Kelsey wrote: >> Date: Mon, 09 Nov 2009 22:12:03 -0800 >> From: Kris Pister >> >>> Abandoning the installed base just goes to reinforce the idea >>> that IP isn't an appropriate technology for things. >> >> Michael - I think that we have the same goal, but I disagree with =20= >> that >> statement. I think that re-writing every protocol from discovery >> through transport to applications, from scratch, is what =20 >> reinforces the > >> idea that IP isn't an appropriate technology for things. >> >> I realize that there are pressures from an installed base, but at =20= >> this >> point it's a tiny fraction of the overall potential. If we let =20 >> the 1% >> installed base dictate the path for the next 99%, we should do =20 >> our best > >> to ensure that it's the right path. >> >> Taking these two paragraphs together, you seem to be saying >> that IP is an appropriate technology for tomorrow's things, >> but not necessarily for today's. While the hardware will >> obviously improve over time, we still need to pick some >> target platform. The current 6lowpan charter gives 32K of >> flash as an example and mentions 802.15.4 repeatedly. Are >> you suggesting that we recharter? >> >> The increasing capabilities of the hardware does give us the >> reassuring prospect that the longer we take the solve the >> problems the easier it will be to so. >> >> -Richard Kelsey >> > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From richard.kelsey@ember.com Wed Nov 11 04:27:04 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1E228C307 for <6lowapp@core3.amsl.com>; Wed, 11 Nov 2009 04:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 PzPtwRXblSos for <6lowapp@core3.amsl.com>; Wed, 11 Nov 2009 04:27:03 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 986C628C20E for <6lowapp@ietf.org>; Wed, 11 Nov 2009 04:27:03 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.60]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 07:28:57 -0500 Date: Wed, 11 Nov 2009 07:24:15 -0500 Message-Id: <87639hs100.fsf@kelsey-ws.hq.ember.com> To: Henning Schulzrinne In-reply-to: <278C5C8B-928A-4B01-BA9B-9ADD1CD41CC7@cs.columbia.edu> (message from Henning Schulzrinne on Wed, 11 Nov 2009 05:12:33 -0500) From: Richard Kelsey References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com> <4AF9BB54.7070006@eecs.berkeley.edu> <87eio62cu7.fsf@kelsey-ws.hq.ember.com> <278C5C8B-928A-4B01-BA9B-9ADD1CD41CC7@cs.columbia.edu> X-OriginalArrivalTime: 11 Nov 2009 12:28:57.0523 (UTC) FILETIME=[8A369830:01CA62CA] Cc: Michael.Stuber@itron.com, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2009 12:27:04 -0000 From: Henning Schulzrinne Date: Wed, 11 Nov 2009 05:12:33 -0500 The charter is presumably a draft, not a consensus. Yes, for 6lowapp. 6lowpan has an agreed-on charter. My remarks concerned 6lowpan, and I should have taken 6lowapp off of the reply list. Mea Culpa. -Richard Kelsey From pthubert@cisco.com Thu Nov 12 01:33:37 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C303A6A58; Thu, 12 Nov 2009 01:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.521 X-Spam-Level: X-Spam-Status: No, score=-7.521 tagged_above=-999 required=5 tests=[AWL=-1.522, BAYES_00=-2.599, J_CHICKENPOX_63=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 frxETOcZiz4w; Thu, 12 Nov 2009 01:33:36 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 32C203A6927; Thu, 12 Nov 2009 01:33:36 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM9l+0qrR7Ht/2dsb2JhbADELZgBgj2BfwSBbIo1 X-IronPort-AV: E=Sophos;i="4.44,727,1249257600"; d="scan'208";a="430726816" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 12 Nov 2009 09:34:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAC9XvhQ026008; Thu, 12 Nov 2009 09:34:04 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Nov 2009 10:33:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Nov 2009 10:33:42 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D9D879A@XMB-AMS-107.cisco.com> In-Reply-To: <019f01ca6259$625528c0$26ff7a40$@sturek@att.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] Thread-Index: AcpiOeUcq/TvAEg9RCGWZ32RY3XEYwAHlhSgAEeZD+A= References: <87y6mfwbfk.fsf@kelsey-ws.hq.ember.com> <1257809361.11184.123.camel@dellx1> <4AF8C20C.3070905@eecs.berkeley.edu> <9256B623-E13C-4EB3-9DE9-F850F2E828AC@tzi.org> <6B8DDEBE-5550-4795-81E0-DC137114EF83@archrock.com> <4AF8D5A0.1020600@eecs.berkeley.edu> <05C6A38D732F1144A8C4016BA4416BFE0242D3B1@SPO-EXVS-02.itron.com> <4AF90433.30204@eecs.berkeley.edu> <87639il2fh.fsf@kelsey-ws.hq.ember.com><4AF9BB54.7070006@eecs.berkeley.edu> <019f01ca6259$625528c0$26ff7a40$@sturek@att.net> From: "Pascal Thubert (pthubert)" To: , "Kris Pister" , "Richard Kelsey" X-OriginalArrivalTime: 12 Nov 2009 09:33:56.0321 (UTC) FILETIME=[416C1510:01CA637B] Cc: 6lowpan@ietf.org, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 usage in LLNs] X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2009 09:33:37 -0000 I'd agree with Don: Adaptation is a survival trait. The radio paradigm is new and interesting enough for IPv6 to make a quantum leap. IPv6 will survive and it will adapt. The current ND work at 6LoWPAN is just that, a backward compatible adaptation extension. I see two schools, that I'd compare with WIFI infrastructure mode, and WIFI adhoc mode. In infra mode, the AP emulates the ethernet (transit link) behavior.=20 -------------- Pros: * L3 and above works as is. This feature was probably the key to radio adoption as a LAN alternative. Cons: * As an L2 solution, it is limited to a "link". You end up with the traditional hassle of broadcast domain, size of neighbor cache, etc... * And as it hides the topology to routing, it shows the whole network as one hop away. You end up with the traditional hassle of mixing mesh under and route over, like IP and ATM. * ESS only applies to radio MACs that can be bridged onto ethernet. The 802.11 was designed for this. The 802.15.4 MAC was not. * As a deployed and workable solution, infra mode is now an inhibitor to progress on adhoc mode. Most users do not even know that the alternative exists and what it is for. In ad-hoc mode, nodes are free to peer with whichever other nodes they care to -------------- Cons: * need adapt L3 for new link and metrics behaviors (instable, statistical, lossy, flapping rapidly) that L3 only approached and failed to handle properly in the past. Pros: * adhoc mode does not artificially limit the set of peers, so a better end to end path might be found, in and out. * it place L3 in charge end-to-end, for a better integration of the radio network within the larger IP network. My take is that though (obviously) we do not want a foo per radio MAC, we need a radio abstraction that looks like a radio, not like an ethernet.=20 This work has already started with 802.21, the metrics draft at ROLL, L2 adaptation draft at mobopts, etc...=20 ND at 6LoWPAN is contributing to that larger movement. And that movement must succeed, considering that radio fringe networks are key to connect a new order of magnitude devices onto the Internet. Pascal >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Don Sturek >Sent: mardi 10 novembre 2009 23:59 >To: 'Kris Pister'; 'Richard Kelsey' >Cc: 6lowpan@ietf.org; 6lowapp@ietf.org >Subject: Re: [6lowpan] hardware trends,new vs. existing protocols [Re: 4861 usage in LLNs] > >Hi Kris, > >Prior to all of the wireless work I have done in the past 10 years, I worked >at a specialty edge router company. We worked in large data centers >migrating serial protocols (bisync, X.25, etc.) to IP. This work did >actually require new IETF protocols and extensions (MPLS, reliable >multicast, etc). > >I think for 6LowPAN to proliferate, we need to partially do what you suggest >(limit where possible creating new protocols) but augment existing IETF >standards as well. I really see the CoRE work aligning with that vision >since we are mapping it to a RESTfull HTTP deployment which has precedence >in current web services. Having CoRE re-use existing transports and >security is critical > >There was one thing missing from your note on new hardware: cost. >Lowering the bar on cost with CoRE will allow the technology to be deployed >in places where new ARM processors with 192K flash/etc are too expensive. > >Don > > >-----Original Message----- >From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf >Of Kris Pister >Sent: Tuesday, November 10, 2009 11:13 AM >To: Richard Kelsey >Cc: 6lowpan@ietf.org; 6lowapp@ietf.org >Subject: Re: [6lowpan] hardware trends, new vs. existing protocols [Re: 4861 >usage in LLNs] > >Richard - >I think that today's things are being designed with wonderful chips like >your Ember EM351 and EM357 >which have 128kB and 192kB of flash and lots of RAM; like the Jennic >JN5148, the Freescale MC13224, the Dust DN2510. >They can run IP, they will run IP, and in many cases they do run IP. We >all agree on that, and we're all excited about that. >The debate centers on how many new protocols we need to invent, vs. how >many we can adopt or adapt, with the existing hardware, and with an eye >toward where technology trends are taking us. My concern, like yours, >is over the rate of adoption. If the fastest path to broad adoption is >to create new protocols for routing, ND, transport, and applications, >then by all means let's do that. I'm concerned, however, that this has >not been a uniformly successful approach for wireless sensor networks in >the past. :) >Many of us believe that we will see the fastest adoption by minimizing >the number of new protocols. We might be wrong, and that's the debate. > >ksjp > >Richard Kelsey wrote: >> Date: Mon, 09 Nov 2009 22:12:03 -0800 >> From: Kris Pister >> >> > Abandoning the installed base just goes to reinforce the idea >> > that IP isn't an appropriate technology for things. >> >> Michael - I think that we have the same goal, but I disagree with that >> statement. I think that re-writing every protocol from discovery >> through transport to applications, from scratch, is what reinforces the > >> idea that IP isn't an appropriate technology for things. >> >> I realize that there are pressures from an installed base, but at this >> point it's a tiny fraction of the overall potential. If we let the 1% >> installed base dictate the path for the next 99%, we should do our best > >> to ensure that it's the right path. >> >> Taking these two paragraphs together, you seem to be saying >> that IP is an appropriate technology for tomorrow's things, >> but not necessarily for today's. While the hardware will >> obviously improve over time, we still need to pick some >> target platform. The current 6lowpan charter gives 32K of >> flash as an example and mentions 802.15.4 repeatedly. Are >> you suggesting that we recharter? >> >> The increasing capabilities of the hardware does give us the >> reassuring prospect that the longer we take the solve the >> problems the easier it will be to so. >> >> -Richard Kelsey >> >_______________________________________________ >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 From fluffy@cisco.com Thu Nov 12 16:00:31 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7325D3A6AC9 for <6lowapp@core3.amsl.com>; Thu, 12 Nov 2009 16:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 d9LF+QE5VHb3 for <6lowapp@core3.amsl.com>; Thu, 12 Nov 2009 16:00:30 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id CE3C53A681A for <6lowapp@ietf.org>; Thu, 12 Nov 2009 16:00:30 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABMw/EpAaHte/2dsb2JhbAC9S5gjhDwEgmg X-IronPort-AV: E=Sophos;i="4.44,732,1249257600"; d="scan'208";a="103815594" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2009 00:01:00 +0000 Received: from tky-vpn-client-230-202.cisco.com (tky-vpn-client-230-202.cisco.com [10.70.230.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAD00waF002309 for <6lowapp@ietf.org>; Fri, 13 Nov 2009 00:00:59 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Fri, 13 Nov 2009 09:00:58 +0900 Message-Id: <5C099137-5F20-446B-A03F-50EDA16EC9DD@cisco.com> To: 6lowapp@ietf.org Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [6lowapp] Status of BOF X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 00:00:31 -0000 Hi, I just wanted to drop a preliminary status update note to the list. I think the BOF went very well and wanted to thank everyone for the work. Carsten and I are going to try and update the charter to reflect the the input from the BOF. We will bring that back to the list here and take it to our Area Director. From that point, the Area Director takes it to the IESG who look at it. If they are OK, they send it out to the whole IETF for a 2 week Last Call. After that the IESG makes the decision to approve the Working Group. If I had to guess, I think the BOF went very well and I expect that a Working Group will be formed in the near future. Thanks, Cullen From Colin.OFlynn@atmel.com Tue Nov 17 02:20:44 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46CFB28C0D7 for <6lowapp@core3.amsl.com>; Tue, 17 Nov 2009 02:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 cNW7LNTNOZGa for <6lowapp@core3.amsl.com>; Tue, 17 Nov 2009 02:20:42 -0800 (PST) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id 9EF5528C0E5 for <6lowapp@ietf.org>; Tue, 17 Nov 2009 02:20:42 -0800 (PST) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id nAHAId1e027489 for <6lowapp@ietf.org>; Tue, 17 Nov 2009 02:18:49 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA676F.8D94A05E" Date: Tue, 17 Nov 2009 03:20:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6LOWAPP Commissioning Method Thread-Index: Acpnb42S6GzHQESmSiaDBK6B1jNMMw== From: "Oflynn, Colin" To: <6lowapp@ietf.org> Subject: [6lowapp] 6LOWAPP Commissioning Method X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:20:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA676F.8D94A05E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All, I only just joined 6lowapp, so I caught up by reading the archives a = bit. I didn't see any previous discussion of commissioning, besides a = very quick security discussion. I apologize if this is thus already = discussed somewhere I missed! I was working on the commissioning problem = on the IPSO side, and was just directed to 6lowapp.=20 I had some questions on the fundamental assumptions of commissioning: > 1) Duckling mode. One Device is put in a "mother duck" mode where it > listens for broadcasts of Devices trying to imprint. I'm assuming this is based on http://www.cl.cam.ac.uk/~fms27/duckling/ = (The Resurrecting Duckling).=20 As described, the method isn=92t highly secure. The main problems are: 1) If you just add whoever is in =91imprint=92 mode, it is easy for an = attacker to add themselves to your network. 2) How to put nodes in duckling mode? The paper mentions maybe having a = =91master key=92 who can do this. Wi-Fi Protected Setup (WPS) helps get around some of these problems by = having a push-button and LED. The button puts the node into either = mother or duckling mode (depending on node type), and an LED lets the = user see which two nodes are going to connect.=20 >2) Out of Band Key mode. Each Device in manufactured with an initial > symmetric key physically printed on the side in numeric and barcode > form... This is similar to WPS=92s PIN-based entry. The issue with that was many = nodes which could run 6LoWPAN will physically be too small to have = labels legibly printed on them. Further having labels which must agree = with a preprogrammed key would increase manufacturing cost, and there is = a problem with labels being knocked off. WPS gets around this by having = nodes being able to generate their own PIN and displaying it on an LCD, = but most 6LOWPAN nodes would be too cheap for this. There is a security threat too: let=92s say you have a =91secure=92 = network. An attacker has physical access to your end nodes, but not to = the central station which authorizes new nodes to come online. For many = application this would be a reasonable assumption I would think. They = could just put a label with a different key on your end node, then drain = the batteries from the node or do something else that would force a = maintenance operation. When the node is being =91fixed=92 it will be put = back on the network, but really you=92ve just opened up your network to = an attacker. > 3) Certificate mode. Each Device is manufactured with a certificate > with an asymmetric key. The fingerprint of the certificate is = printed Similar issues to labels above, but since it=92s optional it could be = deployed where manufactures specifically see it as an advantage. The = issue with the first two is they are mandatory. > no public key cryptography to support > modes 1 and 2 and additional crypto profile with public key > cryptography for support of mode 3 I also see that only mode 3 will use Public-Private exchange. Should = method 1 not require a public-private exchange, as I know of no other = way to secure a hostile channel? You can use ECC encryption which is = pretty light-weight (less than 3K ROM, 300 bytes SRAM). If a node is too small to run ECC it has no business doing an In-Band = key exchange. Passive listening on RF networks is far too easy and = impossible to detect. Man In The Middle and other attacks at least need = the attacker to do something detectable mostly. It=92s not just an issue = of someone by chance listening when you do the setup. The problem is = they could easily purposely force one node off the network by selective = jamming, and waiting until maintenance personal reset or replace the = node and do a new key exchange.=20 Was any consideration given to an Out Of Band (OOB) exchange method? = Something like using IR (either IrDA or discrete IR), or even a very = simple physical connection. It would almost guarantee a secure key = exchange, have little code overhead, and physical connection can be used = to power parasitically-powered nodes which might not be able to go = through lengthy configuration processes. As well it would lend itself to = a small =91widget=92 being used to authorize nodes, such as a cheap = pen-sized tool with some smarts in it.=20 Regards, -Colin O=92Flynn PS: I have some information I wrote down for IPSO about Security = problems & Commissioning problems I could try to post somewhere 6LOWAPP = would have access to them as well. ------_=_NextPart_001_01CA676F.8D94A05E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 6LOWAPP Commissioning Method

Hello All,

I only just joined 6lowapp, so I caught up by reading the archives a = bit. I didn't see any previous discussion of commissioning, besides a = very quick security discussion. I apologize if this is thus already = discussed somewhere I missed! I was working on the commissioning problem = on the IPSO side, and was just directed to 6lowapp.

I had some questions on the fundamental assumptions of = commissioning:

> 1) Duckling mode. One Device is put in a "mother duck" = mode where it
>      listens for broadcasts of Devices = trying to imprint.

I'm assuming this is based on http://www.cl.cam.ac.uk= /~fms27/duckling/ (The Resurrecting Duckling).

As described, the method isn’t highly secure. The main problems = are:

1)      If you just add whoever is in = ‘imprint’ mode, it is easy for an attacker to add themselves = to your network.

2)      How to put nodes in duckling mode? The = paper mentions maybe having a ‘master key’ who can do = this.

Wi-Fi Protected Setup (WPS) helps get around some of these problems by = having a push-button and LED. The button puts the node into either = mother or duckling mode (depending on node type), and an LED lets the = user see which two nodes are going to connect.

>2) Out of Band Key mode. Each Device in manufactured with an = initial
> symmetric key physically printed on the side in numeric and = barcode
>  form...

This is similar to WPS’s PIN-based entry. The issue with that was = many nodes which could run 6LoWPAN will physically be too small to have = labels legibly printed on them. Further having labels which must agree = with a preprogrammed key would increase manufacturing cost, and there is = a problem with labels being knocked off. WPS gets around this by having = nodes being able to generate their own PIN and displaying it on an LCD, = but most 6LOWPAN nodes would be too cheap  for this.

There is a security threat too: let’s say you have a = ‘secure’ network. An attacker has physical access to your end = nodes, but not to the central station which authorizes new nodes to come = online. For many application this would be a reasonable assumption I = would think. They could just put a label with a different key on your = end node, then drain the batteries from the node or do something else = that would force a maintenance operation. When the node is being = ‘fixed’ it will be put back on the network, but really = you’ve just opened up your network to an attacker.

> 3) Certificate mode. Each Device is manufactured with a = certificate
 >  with an asymmetric key. The fingerprint of the = certificate is printed

Similar issues to labels above, but since it’s optional it could be = deployed where manufactures specifically see it as an advantage. The = issue with the first two is they are mandatory.

> no public key cryptography to support
> modes 1 and 2 and additional crypto profile with public key
> cryptography for support of mode 3

I also see that only mode 3 will use Public-Private exchange. Should = method 1 not require a public-private exchange, as I know of no other = way to secure a hostile channel? You can use ECC encryption which is = pretty light-weight (less than 3K ROM, 300 bytes SRAM).

If a node is too small to run ECC it has no business doing an In-Band = key exchange. Passive listening on RF networks is far too easy and = impossible to detect. Man In The Middle and other attacks at least need = the attacker to do something detectable mostly. It’s not just an = issue of someone by chance listening when you do the setup. The problem = is they could easily purposely force one node off the network by = selective jamming, and waiting until maintenance personal reset or = replace the node and do a new key exchange.

Was any consideration given to an Out Of Band (OOB) exchange method? = Something like using IR (either IrDA or discrete IR), or even a very = simple physical connection. It would almost guarantee a secure key = exchange, have little code overhead, and physical connection can be used = to power parasitically-powered nodes which might not be able to go = through lengthy configuration processes. As well it would lend itself to = a small ‘widget’ being used to authorize nodes, such as a = cheap pen-sized tool with some smarts in it.

Regards,

  -Colin O’Flynn

PS: I have some information I wrote down for IPSO about Security = problems & Commissioning problems I could try to post somewhere = 6LOWAPP would have access to them as well.

------_=_NextPart_001_01CA676F.8D94A05E-- From Colin.OFlynn@atmel.com Tue Nov 17 02:23:32 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABAE3A693A for <6lowapp@core3.amsl.com>; Tue, 17 Nov 2009 02:23:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 sahny6rDmuZp for <6lowapp@core3.amsl.com>; Tue, 17 Nov 2009 02:23:31 -0800 (PST) Received: from sjogate2.atmel.com (newsmtp5.atmel.com [204.2.163.5]) by core3.amsl.com (Postfix) with ESMTP id E62FD3A686D for <6lowapp@ietf.org>; Tue, 17 Nov 2009 02:23:31 -0800 (PST) Received: from csomb01.corp.atmel.com ([10.95.30.150]) by sjogate2.atmel.com (8.13.6/8.13.6) with ESMTP id nAHALocA027642 for <6lowapp@ietf.org>; Tue, 17 Nov 2009 02:21:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA6770.00ACC586" Date: Tue, 17 Nov 2009 03:21:30 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6LOWAPP Commissioning Method Thread-Index: Acpnb42S6GzHQESmSiaDBK6B1jNMMwAACz5Q References: From: "Oflynn, Colin" To: "Oflynn, Colin" , <6lowapp@ietf.org> Subject: Re: [6lowapp] 6LOWAPP Commissioning Method X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:23:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA6770.00ACC586 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >PS: I have some information I wrote down for IPSO about Security = problems & Commissioning problems > I could try to post somewhere 6LOWAPP would have access to them as = well. Also: the security paper I mention at the end there doesn't cover too = much that struik-6lowapp-security-considerations hasn't already hit on, = and Struik's paper is a better read anyway! ------_=_NextPart_001_01CA6770.00ACC586 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [6lowapp] 6LOWAPP Commissioning Method

>PS: I have some information I wrote down for IPSO = about Security problems & Commissioning problems
> I could try to post somewhere 6LOWAPP would have access to them as = well.

Also: the security paper I mention at the end there doesn't cover too = much that struik-6lowapp-security-considerations hasn't already hit on, = and Struik's paper is a better read anyway!

------_=_NextPart_001_01CA6770.00ACC586-- From arjunrc@gmail.com Tue Nov 17 08:40:48 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E14D3A68F4 for <6lowapp@core3.amsl.com>; Tue, 17 Nov 2009 08:40:48 -0800 (PST) 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 C6JddGJJnQW3 for <6lowapp@core3.amsl.com>; Tue, 17 Nov 2009 08:40:47 -0800 (PST) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 2E6B23A68EC for <6lowapp@ietf.org>; Tue, 17 Nov 2009 08:40:47 -0800 (PST) Received: by qyk41 with SMTP id 41so126859qyk.29 for <6lowapp@ietf.org>; Tue, 17 Nov 2009 08:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=P5+1d4Fri5bEYxbhP46UbBR/sLccrpH2fXwTxlwkhzw=; b=LrYNiJWrHU0Qn3L8UpmzRppg3kCeXlHOnZm0uQIgyimRN3vqpgycE59Qyl6OG+PV7c Xrc5MfooCw45OVj9z9Ku2k8fwQInY2J6RKZ5onWr+iUDbiXiarcK+IhgpPL07mEex5Y7 E/Sduws41PDH4x6lcMJCQXtnS/Bdqr651xr4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:from:date:x-google-sender-auth :message-id:subject:to:content-type; b=HlDWMiJj6fo5vU7jHreGONHSCJQn+bi26+GQRUKrF7i+ChiuQSFjk001N+n5sKArmQ PNEi+UI2PacLJIEdzMQ14FDkXy12FvaOlgOrkF9a4jy99/0oQV9xVuy3oKGHk/yDX29H PFWs6R9oAqdBGDPXVIuH1JoxPtuxA5SWqbhtU= MIME-Version: 1.0 Sender: arjunrc@gmail.com Received: by 10.224.36.142 with SMTP id t14mr5713506qad.17.1258476043132; Tue, 17 Nov 2009 08:40:43 -0800 (PST) From: Arjun Roychowdhury Date: Tue, 17 Nov 2009 11:40:23 -0500 X-Google-Sender-Auth: 59248252f2512c1b Message-ID: To: 6lowapp@ietf.org Content-Type: multipart/alternative; boundary=00c09f88ca5c82615f047893c91d Subject: [6lowapp] Question: applicability of OpenHAN requirements X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: arjun.lists@hsc.com List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 16:40:48 -0000 --00c09f88ca5c82615f047893c91d Content-Type: text/plain; charset=ISO-8859-1 Hi, does this group intend to map the 2008 OpenHAN requirements to the various nodes being defined (example CoGII, restricted devices, smart devices) etc. ? ( http://www.utilityami.org/docs/UtilityAMI%20HAN%20SRS%20-%20v1.04%20-%20080819-1.pdf) ? regds arjun -- Arjun Roychowdhury --00c09f88ca5c82615f047893c91d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, does this group intend to map the 2008 OpenHAN requirements to the vari= ous nodes being defined (example CoGII, restricted devices, smart devices) = etc. ?

regds
arjun
--
Arjun Roychowdhu= ry

--00c09f88ca5c82615f047893c91d-- From rstruik@certicom.com Thu Nov 19 05:40:40 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79D063A6B2E; Thu, 19 Nov 2009 05:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 rulYNc9ZloVN; Thu, 19 Nov 2009 05:40:39 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id D61B13A6816; Thu, 19 Nov 2009 05:40:38 -0800 (PST) X-AuditID: 0a401fcb-b7b71ae000002562-42-4b054ad2924c Received: from XCH39YKF.rim.net ( [10.64.31.40]) by mhs03ykf.rim.net (RIM Mail) with SMTP id D3.8B.09570.2DA450B4; Thu, 19 Nov 2009 08:40:35 -0500 (EST) Received: from XCH57YKF.rim.net ([10.64.31.54]) by XCH39YKF.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 08:40:34 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Date: Thu, 19 Nov 2009 08:40:12 -0500 Message-ID: <7E1DF37F1F42AB4E877E492C308E6AC4025EA8A4@XCH57YKF.rim.net> In-Reply-To: <20091118235822.GB7886@elstar.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [6lowpan] SNMP optimizations Thread-Index: AcpoqwfI1nGPctU3TdC+bUXVaDY1KQAcdwxw References: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> <20091118235822.GB7886@elstar.local> From: "Rene Struik" To: "Juergen Schoenwaelder" X-OriginalArrivalTime: 19 Nov 2009 13:40:34.0684 (UTC) FILETIME=[DED353C0:01CA691D] X-Brightmail-Tracker: AAAAAwAAAZERyCBQEctxlg== Cc: roll@ietf.org, 6lowpan <6lowpan@ietf.org>, 6lowapp@ietf.org Subject: Re: [6lowapp] [6lowpan] SNMP optimizations X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 13:40:40 -0000 Hi Juergen: I submitted a 6lowapp draft on security considerations precisely because one needs a description of the problem space and make sure it is not "forgotten". I do understand that people may wish and use some functionality that is already out there, but question is whether it supports the desired security functionality over the lifecycle of the system. Could you recommend an overview paper on SNMP that would make it easy to see what the supposed security features are suitable to sensor-type applications and how these are delivered (mechanisms, communication overhead, etc.). This should make it easier to provide a more quantitative assessment. Best regards, Rene -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, November 18, 2009 6:58 PM To: Ulrich Herberg Cc: manet@ietf.org; 6lowpan; roll@ietf.org Subject: Re: [6lowpan] SNMP optimizations On Wed, Nov 18, 2009 at 10:10:23PM +0100, Ulrich Herberg wrote: [... we should restrict this to one mailing list...] > However, it is unclear whether the code footprint of SNMP > implementations can fit into the memory of small devices. From > discussions with several persons from the MANET WG, I conclude that > for MANET the same problem exists. (and I think for ROLL, too?) > > I have several questions that came to my mind about this topic: > > - First of all, to which WG does this issue belong to? Or is it -- as > I suppose -- a common problem for the three working groups addressed > in this mail? I don't know. > - Is this really an issue? Are there implementations of SNMP (maybe > not open-source) that can be run on very small devices such as > considered in 6lowpan/ROLL/MANET? Is there any experimental (or > theoretical) analysis whether SNMP (or any other standardized > management protocol) can run on these devices? The question is under specified. What is a "very small device" and how much can a "very small device" devote to SNMP? And what is SNMP? The SNMPv3 specs are pretty modular. One of the more important questions is how you deal with security - the security code has the potential to be bigger than the rest of the SNMP engine. And it boils down to the question of how many MIB objects you support and to what extend you hardwire things. Remember that SNMP is a child of the late 80s and early versions were sometimes embedded into devices that could not afford TCP. Of course, the 80s version of SNMP did not care much about security... > - If SNMP cannot be used for small devices, how can we manage and > monitor these devices then? (e.g. using proxies, different message > formats such as proposed in 6lowapp, etc.). Do we need a different > lightweight protocol for management? Again, the big question is how to deal with the security aspect. SNMP originally was lightweight because there was no security. It took the IETF many years to find a workable security solution and even today people are working on utilizing transport layer security protocols within SNMP (see ISMS working group). > - Can we provide SNMP not only on a single device, but for a whole > network? That might need an aggregator device that runs full SNMP and > collects the data from the low power devices. This would imply to > monitor statistics of a whole network (e.g. number of links, average > throughput, average path-length, etc.) Sure, there are ways of doing this. For read-only objects, this is relatively easy - it can get a bit messy if you have read-write objects. Whether this direction is worthwhile to explore depends on how you solve the security issues and whether a dependency on a "gateway" is desirable in the first place. > - What kind of objects should be provided in a MIB running on a > MANET/6lowpan/ROLL device? This might be specific to the routing > protocol, but there can be commonalities. In general, the IETF tends to break MIB modules down along protocol functions. Following this approach, a ROLL MIB module would report data about the ROLL routing protocol. A 6LoWPAN MIB would report data about the 6LoWPAN layer, that is for example the list of supported 6LoWPAN protocol features and counters for 6LoWPAN processing failures (e.g. reassembly failures) that help to trouble shoot 6LoWPAN issues. I would hope that some IPv6 MIB objects apply as well and then there should ideally be an IEEE 802.15.4 MIB module for this particular radio technology. I do not think there is much overlap if things get structured well. This, however, might be difficult to achieve if work is spread over several WGs. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From j.schoenwaelder@jacobs-university.de Thu Nov 19 07:00:35 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6E6D3A6969; Thu, 19 Nov 2009 07:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 FawpsBOO2NNy; Thu, 19 Nov 2009 07:00:34 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B99DD3A6959; Thu, 19 Nov 2009 07:00:34 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11B80C003F; Thu, 19 Nov 2009 16:00:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id eIn3Rp3FP+H4; Thu, 19 Nov 2009 16:00:31 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AD0BC0009; Thu, 19 Nov 2009 16:00:31 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 2FE71E2C3FD; Thu, 19 Nov 2009 16:00:30 +0100 (CET) Date: Thu, 19 Nov 2009 16:00:30 +0100 From: Juergen Schoenwaelder To: Rene Struik Message-ID: <20091119150030.GB1545@elstar.local> Mail-Followup-To: Rene Struik , "6lowapp@ietf.org" <6lowapp@ietf.org>, 6lowpan <6lowpan@ietf.org>, "roll@ietf.org" References: <25c114b90911181310ue4eb67dkcdf83cd944a1632b@mail.gmail.com> <20091118235822.GB7886@elstar.local> <7E1DF37F1F42AB4E877E492C308E6AC4025EA8A4@XCH57YKF.rim.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E1DF37F1F42AB4E877E492C308E6AC4025EA8A4@XCH57YKF.rim.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "roll@ietf.org" , 6lowpan <6lowpan@ietf.org>, "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] [6lowpan] SNMP optimizations X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 15:00:35 -0000 On Thu, Nov 19, 2009 at 02:40:12PM +0100, Rene Struik wrote: > Could you recommend an overview paper on SNMP that would make it easy to > see what the supposed security features are suitable to sensor-type > applications and how these are delivered (mechanisms, communication > overhead, etc.). This should make it easier to provide a more > quantitative assessment. I can provide you with a draft of a paper discussing the impact of security on SNMP in general. http://cnds.eecs.jacobs-university.de/people/schoenw/drafts/snmp-security.pdf This paper requires some updates - some of the references etc. are meanwhile outdated. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From xvilajosana@uoc.edu Fri Nov 27 06:38:08 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EBA63A68D6 for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 06:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 b+TMPcsrpOuo for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 06:38:07 -0800 (PST) Received: from smtp.uoc.edu (tibet.uoc.es [213.73.40.45]) by core3.amsl.com (Postfix) with SMTP id 2DB283A6899 for <6lowapp@ietf.org>; Fri, 27 Nov 2009 06:38:06 -0800 (PST) Received: (qmail 19014 invoked from network); 27 Nov 2009 15:37:59 +0100 Received: from unknown (HELO polinya) (213.73.40.221) by tibet.uoc.es with SMTP; 27 Nov 2009 15:37:59 +0100 Received: from polinya (localhost [127.0.0.1]) by polinya (Postfix) with ESMTP id DD9A2FB26E for <6lowapp@ietf.org>; Fri, 27 Nov 2009 15:37:58 +0100 (CET) From: Xavi Vilajosana Guillen X-Uoc-From: "Xavi Vilajosana Guillén <xvilajosana@uoc.edu>" To: 6lowapp@ietf.org <6lowapp@ietf.org> Fcc: /$FOLDER_MISSATGES$/$FOLDER_ENVIATS$ X-Uoc-Subject: "the role of gateway nodes" Date: Fri, 27 Nov 2009 15:37:45 +0100 X-Uoc-UserType: PROFESSOR X-Uoc-Att: 0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--------------UOCGENERATED031070" Message-ID: <1220434074.5410511259332678903.JavaMail.root@polinya> Comments: localhost [127.0.0.1] X-Uoc-Hops: 1 Subject: [6lowapp] the role of gateway nodes X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 14:38:08 -0000 ----------------UOCGENERATED031070 Content-Type: multipart/alternative; boundary="--------------UOCGENERATED_multipart_alternative_boundary" ----------------UOCGENERATED_multipart_alternative_boundary content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everybody, I am addressing the problem of application level protocol compatibility b= etween Internet and 6LowPan networks. As you may know current Internet pr= otocols (http,xmpp...) make use of too heavy headers... my opinion is tha= t a protocol transformation is required at gateway level, that is, curren= t Internet protocols should be compressed/transformed once they reach a l= ow power losy network... what's the approach at 6LowApp? anyone knows ongoing work on that issue? regards, xavier ----------------UOCGENERATED_multipart_alternative_boundary-- ----------------UOCGENERATED031070-- From cabo@tzi.org Fri Nov 27 07:00:58 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39353A6939 for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 07:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 ejoYMpSN5F2T for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 07:00:57 -0800 (PST) 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 B7A6D3A682C for <6lowapp@ietf.org>; Fri, 27 Nov 2009 07:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nARF0fxl001056; Fri, 27 Nov 2009 16:00:41 +0100 (CET) Received: from [192.168.217.101] (p5489FD50.dip.t-dialin.net [84.137.253.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 274ABB5D6; Fri, 27 Nov 2009 16:00:41 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1220434074.5410511259332678903.JavaMail.root@polinya> Date: Fri, 27 Nov 2009 16:00:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1220434074.5410511259332678903.JavaMail.root@polinya> To: Xavi Vilajosana Guillen X-Mailer: Apple Mail (2.1077) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] the role of gateway nodes X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 15:00:58 -0000 On Nov 27, 2009, at 15:37, Xavi Vilajosana Guillen wrote: > what's the approach at 6LowApp? anyone knows ongoing work on that = issue? I would summarize the thinking that went into the BOF as follows: Some nodes in a CE (constrained environment) may actually be not that = constrained (as nodes and with respect to their network). These can = directly speak the appropriate application protocol (HTTP, SNMP, XMPP, = SIP) to some correspondent node outside (or inside) the CE. (We didn't = put this on the slides because that is nothing new.) Some nodes may want to run the constrained application protocol (called = CoAP on the BOF slides) right to a correspondent node on the outside. = See the bottom half of slide 13 in = http://www.ietf.org/proceedings/09nov/slides/6lowapp-0.pdf as well as = the use of CoAP inside the CE (if we had two CEs, this also could be = between CEs). In these two cases, no intermediary (above the IP layer) is involved. To connect constrained nodes that want to talk CoAP to correspondent = nodes outside the CE that want to speak established application = protocols, an intermediary is required. We purposely tried to avoid = calling this a gateway, proxy, translator, server, or whatever, because = each of these seems to invoke some inappropriate connotations of big = hunks of hardware. Instead we invented the name CoGII (Constrained-node = to General Internet Intermediary). In a 6LoWPAN, this could be the job = of a device as simple as an Edge Router, or it could be placed in a = quite different position (as CoAP is an Internet-based protocol, there = is no restriction on the placement of the CoGII). Gruesse, Carsten From jvasseur@cisco.com Fri Nov 27 08:00:30 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED863A694A for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 08:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.893 X-Spam-Level: X-Spam-Status: No, score=-7.893 tagged_above=-999 required=5 tests=[AWL=-1.294, 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 RMqbpBezfy03 for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 08:00:29 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AE5233A68D4 for <6lowapp@ietf.org>; Fri, 27 Nov 2009 08:00:29 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE+GD0urRN+J/2dsb2JhbAC9Bpc4hDEE X-IronPort-AV: E=Sophos;i="4.47,302,1257120000"; d="scan'208";a="54747025" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Nov 2009 16:00:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id nARG0C4Z007650; Fri, 27 Nov 2009 16:00:23 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 17:00:19 +0100 Received: from ams-jvasseur-8714.cisco.com ([10.55.201.133]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 17:00:18 +0100 Message-Id: From: JP Vasseur To: Carsten Bormann In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 27 Nov 2009 17:00:17 +0100 References: <1220434074.5410511259332678903.JavaMail.root@polinya> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 27 Nov 2009 16:00:19.0229 (UTC) FILETIME=[B7B55CD0:01CA6F7A] Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] the role of gateway nodes X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:00:30 -0000 On Nov 27, 2009, at 4:00 PM, Carsten Bormann wrote: > On Nov 27, 2009, at 15:37, Xavi Vilajosana Guillen wrote: > >> what's the approach at 6LowApp? anyone knows ongoing work on that >> issue? > > I would summarize the thinking that went into the BOF as follows: > > Some nodes in a CE (constrained environment) may actually be not > that constrained (as nodes and with respect to their network). > These can directly speak the appropriate application protocol (HTTP, > SNMP, XMPP, SIP) to some correspondent node outside (or inside) the > CE. (We didn't put this on the slides because that is nothing new.) > > Some nodes may want to run the constrained application protocol > (called CoAP on the BOF slides) right to a correspondent node on the > outside. See the bottom half of slide 13 in http://www.ietf.org/proceedings/09nov/slides/6lowapp-0.pdf > as well as the use of CoAP inside the CE (if we had two CEs, this > also could be between CEs). > > In these two cases, no intermediary (above the IP layer) is involved. > > To connect constrained nodes that want to talk CoAP to correspondent > nodes outside the CE that want to speak established application > protocols, an intermediary is required. We purposely tried to avoid > calling this a gateway, proxy, translator, server, or whatever, > because each of these seems to invoke some inappropriate > connotations of big hunks of hardware. Instead we invented the name > CoGII (Constrained-node to General Internet Intermediary). In a > 6LoWPAN, this could be the job of a device as simple as an Edge > Router, or it could be placed in a quite different position (as CoAP > is an Internet-based protocol, there is no restriction on the > placement of the CoGII). > Just a side note we may want to use the same terminology accross all WGs: 6LoWPAN refers to something specific, in ROLL we use LLN (Low power and Lossy Networks), I saw CEnet, ... how about using one terminology ? Thanks. JP. > Gruesse, Carsten > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From cabo@tzi.org Fri Nov 27 08:20:12 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8ED43A6988 for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 pWfMxbLU8co2 for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 08:20:12 -0800 (PST) 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 9C7453A6936 for <6lowapp@ietf.org>; Fri, 27 Nov 2009 08:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id nARGJsqH004437; Fri, 27 Nov 2009 17:19:54 +0100 (CET) Received: from [192.168.217.101] (p5489FD50.dip.t-dialin.net [84.137.253.80]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 295E7B61C; Fri, 27 Nov 2009 17:19:54 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: Date: Fri, 27 Nov 2009 17:19:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <96F04962-DA14-4735-B57B-31EB3217C732@tzi.org> References: <1220434074.5410511259332678903.JavaMail.root@polinya> To: JP Vasseur X-Mailer: Apple Mail (2.1077) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] the role of gateway nodes X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:20:12 -0000 On Nov 27, 2009, at 17:00, JP Vasseur wrote: > how about using one terminology Let's be careful about using the same term for different things. A CE does not necessarily connect via an LLN, just as not every LLN is a = LoWPAN. Gruesse, Carsten From jmani@comverge.com Fri Nov 27 08:47:32 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9173A6970 for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 08:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.572 X-Spam-Level: * X-Spam-Status: No, score=1.572 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_NUMERIC_HELO=2.067, RDNS_NONE=0.1] 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 nS+AI61I7JBJ for <6lowapp@core3.amsl.com>; Fri, 27 Nov 2009 08:47:32 -0800 (PST) Received: from newman.comverge.com (unknown [72.1.84.67]) by core3.amsl.com (Postfix) with ESMTP id D00523A684D for <6lowapp@ietf.org>; Fri, 27 Nov 2009 08:47:31 -0800 (PST) Received: from 24.6.83.145 ([24.6.83.145]) by NEWMAN.comverge.com ([192.168.1.5]) with Microsoft Exchange Server HTTP-DAV ; Fri, 27 Nov 2009 16:47:26 +0000 User-Agent: Microsoft-Entourage/12.14.0.081024 Date: Fri, 27 Nov 2009 08:47:24 -0800 From: John Mani To: Xavi Vilajosana Guillen , "6lowapp@ietf.org" <6lowapp@ietf.org> Message-ID: Thread-Topic: [6lowapp] the role of gateway nodes Thread-Index: AcpvgUtn/TlTTXzaf0G8Rc8iXyhExA== In-Reply-To: <1220434074.5410511259332678903.JavaMail.root@polinya> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [6lowapp] the role of gateway nodes X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 16:47:32 -0000 Are there similar issues and how have been addressed in other perhaps similar areas? E.g., UPnP or DLNA that uses similar stuff - IP/HTTP, etc. -john On 11/27/09 6:37 AM, "Xavi Vilajosana Guillen" wrote: > Hi everybody, > > I am addressing the problem of application level protocol compatibility > between Internet and 6LowPan networks. As you may know current Internet > protocols (http,xmpp...) make use of too heavy headers... my opinion is that a > protocol transformation is required at gateway level, that is, current > Internet protocols should be compressed/transformed once they reach a low > power losy network... > > what's the approach at 6LowApp? anyone knows ongoing work on that issue? > > regards, > xavier > > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp From xvilajosana@uoc.edu Mon Nov 30 03:21:48 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6465828C0E1 for <6lowapp@core3.amsl.com>; Mon, 30 Nov 2009 03:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.069 X-Spam-Level: X-Spam-Status: No, score=-5.069 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=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 v-6glDaWL4vv for <6lowapp@core3.amsl.com>; Mon, 30 Nov 2009 03:21:47 -0800 (PST) Received: from smtp.uoc.edu (tibet.uoc.es [213.73.40.45]) by core3.amsl.com (Postfix) with SMTP id A63F928C0E4 for <6lowapp@ietf.org>; Mon, 30 Nov 2009 03:21:46 -0800 (PST) Received: (qmail 21776 invoked from network); 30 Nov 2009 12:21:30 +0100 Received: from unknown (HELO llavaneres) (213.73.40.221) by tibet.uoc.es with SMTP; 30 Nov 2009 12:21:30 +0100 Received: from llavaneres (localhost [127.0.0.1]) by llavaneres (Postfix) with ESMTP id 5F9CD21E61; Mon, 30 Nov 2009 12:21:23 +0100 (CET) From: Xavi Vilajosana Guillen X-Uoc-From: "Xavi Vilajosana Guillén <xvilajosana@uoc.edu>" To: jmani@comverge.com , 6lowapp@ietf.org <6lowapp@ietf.org> Fcc: /$FOLDER_MISSATGES$/$FOLDER_ENVIATS$ X-Uoc-Subject: "RE: Re: [6lowapp] the role of gateway nodes" Date: Mon, 30 Nov 2009 12:21:22 +0100 X-Uoc-UserType: PROFESSOR X-Uoc-Att: 0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--------------UOCGENERATED031070" Message-ID: <1996290310.184231259580083390.JavaMail.root@llavaneres> Comments: localhost [127.0.0.1] X-UOC-PARENT_MAILID: 281256845 X-Uoc-Hops: 1 Subject: Re: [6lowapp] the role of gateway nodes X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 11:21:48 -0000 ----------------UOCGENERATED031070 Content-Type: multipart/alternative; boundary="--------------UOCGENERATED_multipart_alternative_boundary" ----------------UOCGENERATED_multipart_alternative_boundary content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John,.I know about some attempts to use DPWS to adreess comissioning of W= SN. The problems are the size of the messages and the expensive bidirecti= onal protocols. http://www.imd.uni-rostock.de/veroeff/Moritz_ETFA_2009.pd= fIn my opinion, comissioning should be done in two steps:1-CoGII (Constra= ined-node to General Internet Intermediary) comissioning2-Constrained nod= e to CoGII comissioning.1 can be addressed by existing protocols such as = Upnp, DPWS or others.2 has to be addressed with a restricted CoAP. Whethe= r this protocol should be new or a compression of an exiting one, I do no= t know yet. I think that should be better to adapt existing ones instead = of "re-inventing the wheel".--> Missatge original de John Mani (jmani@com= verge.com) per a Xavi Vilajosana Guill=E9n, 6lowapp@ietf.org enviat el 27= /11/2009 17:47:24###########Are there similar issues and how have been#ad= dressed in other perhaps#similar areas?##E.g., UPnP or DLNA that uses sim= ilar stuff - IP/HTTP,#etc.##-john###On 11/27/09 6:37 AM, "Xavi Vilajosana= Guillen"# wrote:##> Hi everybody,#>#> I am addressing the problem of app= lication level#protocol compatibility#> between Internet and 6LowPan netw= orks. As you may know#current Internet#> protocols (http,xmpp...) make us= e of too heavy#headers... my opinion is that a#> protocol transformation = is required at gateway level,#that is, current#> Internet protocols shoul= d be compressed/transformed#once they reach a low#> power losy network...= #>#> what's the approach at 6LowApp? anyone knows ongoing#work on that is= sue?#>#> regards,#> xavier#>#> __________________________________________= _____#> 6lowapp mailing list#> 6lowapp@ietf.org#> #HREF=3D"https://www.ie= tf.org/mailman/listinfo/6lowapp">https:#//www.ietf.org/mailman/listinfo/6= lowapp######Xavier Vilajosana GuillenUniversitat Oberta de CatalunyaEstud= is d'Inform=E0tica, Multim=E8dia i Telecomunicacions Rambla Po= blenou 156 08018 BarcelonaTel +34 93 326 37 07xvilajosana@uoc.edu ----------------UOCGENERATED_multipart_alternative_boundary content-type: text/html Content-Transfer-Encoding: 8bit John,.

I know about some attempts to use DPWS to adreess comissioning of WSN. The problems are the size of the messages and the expensive bidirectional protocols.

http://www.imd.uni-rostock.de/veroeff/Moritz_ETFA_2009.pdf

In my opinion, comissioning should be done in two steps:
1-CoGII (Constrained-node to General Internet Intermediary) comissioning
2-Constrained node to CoGII comissioning.

1 can be addressed by existing protocols such as Upnp, DPWS or others.
2 has to be addressed with a restricted CoAP. Whether this protocol should be new or a compression of an exiting one, I do not know yet. I think that should be better to adapt existing ones instead of "re-inventing the wheel".



--> Missatge original de John Mani (jmani@comverge.com) per a Xavi Vilajosana Guillén, 6lowapp@ietf.org enviat el 27/11/2009 17:47:24

#
#
#
#
#
#
#
#
#
#
#

Are there similar issues and how have been
#addressed in other perhaps

#similar areas?

#

#E.g., UPnP or DLNA that uses similar stuff - IP/HTTP,
#etc.

#

#-john

#

#

#On 11/27/09 6:37 AM, "Xavi Vilajosana Guillen"
#
#


#
#
#



Xavier Vilajosana Guillen
Universitat Oberta de Catalunya
Estudis d'Informàtica, Multimèdia i Telecomunicacions
Rambla Poblenou 156 08018 Barcelona
Tel +34 93 326 37 07
xvilajosana@uoc.edu ----------------UOCGENERATED_multipart_alternative_boundary-- ----------------UOCGENERATED031070-- From zach@sensinode.com Mon Nov 30 05:24:34 2009 Return-Path: X-Original-To: 6lowapp@core3.amsl.com Delivered-To: 6lowapp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66F03A6809 for <6lowapp@core3.amsl.com>; Mon, 30 Nov 2009 05:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 satD-joo-Sv0 for <6lowapp@core3.amsl.com>; Mon, 30 Nov 2009 05:24:33 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 3A23B3A6892 for <6lowapp@ietf.org>; Mon, 30 Nov 2009 05:24:32 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nAUDOGmS014856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Nov 2009 15:24:17 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Mon, 30 Nov 2009 15:24:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87321337-9927-4468-A03E-6FB3D086D682@sensinode.com> References: <1220434074.5410511259332678903.JavaMail.root@polinya> To: JP Vasseur X-Mailer: Apple Mail (2.1077) Cc: "6lowapp@ietf.org" <6lowapp@ietf.org> Subject: Re: [6lowapp] the role of gateway nodes X-BeenThere: 6lowapp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Application protocols for constrained nodes and networks <6lowapp.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2009 13:24:34 -0000 On Nov 27, 2009, at 18:00 , JP Vasseur wrote: >=20 > Just a side note we may want to use the same terminology accross all = WGs: 6LoWPAN refers to something specific, in ROLL we use LLN (Low power = and Lossy Networks), I saw CEnet, ... how about using one terminology ? >=20 This is good advice JP. In my opinion the CoRE WG should actually avoid = making terminology at all if possible, as in new acronyms for networks, = nodes etc. Carsten is right that constrained environments might be made = up of LoWPANs, LLNs (which are not always LoWPANs) but also will be run = over other IP networks. We can probably get away with CoRE and CoAP being the only acronyms used = here. CoRE describes the WG and the general set of requirements, but is = not any particular network. CoAP makes sense as the name for a protocol. The simplification of the charter suggested in the Hiroshima BOF hints = that we probably don't need to talk about CoGIIs at all, just that there = is an HTTP mapping. And I don't see a need for CE, CoNet and CoNode all = that. We can just talk about CoRE or write it out as constrained = environments?=20 Zach =20 > Thanks. >=20 > JP. >=20 >> Gruesse, Carsten >>=20 >> _______________________________________________ >> 6lowapp mailing list >> 6lowapp@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowapp >=20 > _______________________________________________ > 6lowapp mailing list > 6lowapp@ietf.org > https://www.ietf.org/mailman/listinfo/6lowapp --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20