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

[Robert Cragie <[e-mail]>]

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:[e-mail]]
> *Sent:* mercoledì 4 novembre 2009 17.35
> *To:* Adriano Pezzuto (apezzuto)
> *Cc:* Paul Duffy (paduffy); [e-mail]; [e-mail]
> *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
>  
> -----Original Message-----
> From: [e-mail] <mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Paul Duffy (paduffy)
> Sent: mercoledì 4 novembre 2009 13.50
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> 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 <[e-mail]> <mailto:[e-mail]> sur Sat, 31 
>
>     Oct 2009 11:29:41 -0600 -----
>
>         >Pour:        [e-mail] <mailto:[e-mail]>
>
>         >cc:        Don Sturek <[e-mail]> <mailto:[e-mail]>, [e-mail] <mailto:[e-mail]>
>
>         >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
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/6lowapp
>
>       
>
>         
>
>  
> _______________________________________________
> 6lowapp mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/6lowapp
> _______________________________________________
> 6lowapp mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/6lowapp
>  
>