wiki:BarBofs/IETF75/6LowApp

Version 11 (modified by cabo@…, 10 years ago) (diff)

--

IETF75 Bar Bof: 6LowApp: Applications in resource-constrained networks

Details

Topics

The 6LoWPAN and ROLL WGs are laying the groundwork to make the Wireless Embedded Internet a reality, but what application protocols will we use? Request-response protocols like HTTP are a poor fit to a communication model with battery-operated, mostly sleeping nodes. In addition, the usual data formats (both headers and body) are perceived to be too chatty for the 50-60 byte payloads possible in LoWPANs and to require too much code for the 8-bit and 16-bit processors dominating the Internet of Things. Still, it would be a mistake to start a new silo of application protocols that do not benefit from existing application area Internet experience.

Topics for possible considerating in 6LowApp:

  • An application protocol solution for embedded context transfer using appropriate interaction models and a compact binary format compatible with UDP, while still supporting key principles of the web such as resources (URLs), content types (MIME), statelessness, proxy support etc.
  • Protocol design support for the ZigBee?/IP effort, especially for the needs of Smart Energy and standardization in this area at the IEC.
  • Service discovery protocol optimization (e.g. SLP) or creation

Smart Grid HAN Application Needs

For Smart Grid Home Area Networking applications, getting IP connectivity to devices such as thermostats, in-home displays, load control wall plugs, refrigerators and plug-in electric vehicles solves the problem of introducing these devices onto the internet. To fully realize application deployment the following features are needed:

  1. Acknowledged and numbered packet delivery for lossy networks. TCP has historically had challenges with lossy links where retries are common. Application developers have resorted to using UDP with application specified sequence numbers, transmission timeouts and retries, though the loss of TCP services limits the availability of many protocols dependant on TCP.

  • Proposal: Investigate deployment of TCP services over ROLL.
  1. Service Discovery. Here is what is needed:
  • A Service Discovery repository for devices which sleep most of the time.
  • Application specified fields in the service discovery repository and in the search protocol that enable a device with specific application defined characteristics to be selectively discovered by other devices in the network.
  • An ability to set the scope of “the network” to produce bounded service discovery requests matching network resource capabilities.
  • A rich protocol for service discovery requests that wherever possible tries to limit resource usage of the network to support the request while supplying targeted responses.
  1. Security. Here is what is needed:
  • Small footprint security suite for deployment of network, transport and application layer security.
  • EAP appears to be a good framework to standardize on. However, work is needed on open security methods applicable to small footprint devices is needed.
  • For applications wanting to use certificates, enhancements to X.509 and IEEE 802.1x to support small footprint devices
  1. Roaming support. Plug-in electric vehicles will have the ability to roam between networks. It is not clear that MobileIP will solve this problem as there may not be a logical place to hold a forwarding registry. There will be relatively many such devices (assuming a global IP address per car).
  • Proposal: Review the ZigBee/HomePlug? MRD Use Cases, the SAE use cases around PEVs and create a proposal for roaming devices. Also, there is an IEC group (TC 22, Task Group 3) working on a similar solution so that work should be reviewed for requirements.

The above items are the “must have” requirements needed for immediate deployment of Smart Grid HAN applications. Provided below are additional needs for Smart Grid devices and their applications:

  1. Web services. The objective would be to enable deployment of simple web pages for small footprint devices interfaced with a compact exchange protocol.
  • Investigate deployment of a small footprint condensed HTTP.
  • Investigate use of tokenized XML in addition to condensed HTTP.
  1. SNMP. The objective would be to enable SNMP services, again for small footprint devices.
  • Investigate deployment of a compact version of SNMP that may need to use UDP.
  • Ensure that security services are available for the compact version of SNMP, even if it must be deployed using UDP.

add suggested topics of discussion as appropriate

Resources

add drafts and other links as appropriate

  • ...add more...

Attachments (1)

Download all attachments as: .zip