Applications

Working Group Update: LWIG – Building Minimal yet Interoperable IP Stacks on Tiny Devices

By: Zhen Cao

line break image

Building minimal yet interoperable IP-capable devices for the most constrained environments isn’t easy. The IETF, as the home community for sharing engineering experiences, observed this issue and, in response, chartered the LWIG (Light-weight Implementation Guidance) Working Group (WG) to collect the implementation experiences of IP stacks in constrained environments.

Background

Lower-power and constrained devices connected with lossy links are increasingly seen in today’s Internet. Ensuring that these devices are IP-capable is critical to avoiding a fragmented Internet. Before the LWIG WG, the IETF was working on lightweight IPv6 (6Lowpan WG, now continued by 6Lo), routing protocols (ROLL WG) and constrained application protocols (Core WG). This work has helped move constrained networks toward global interconnectivity (Figure 1).

Figure.1 Light-weight Protocol Suite

In addition to protocol design, there are various implementation challenges stemming from limited computational space, cost-efficient discovery and security, and low-power operation mode when building a minimal but compliant protocol stack. Sharing these implementation experiences can support interoperation, as well s the avoidance of engineering pitfalls.

LWIG Activities

LWIG started by classifying constrained devices by various aspects, including computing and power efficiency. This work has been summarized into the constrained network terminology document RFC 7228 [1], where the device capabilities are roughly classified into three categories: Class 0/1/2 respectively. Categories represent data/code size and range from very constrained (Class 0, <10 KB Data, <100 KB code size), constrained (Class 1, around 10 K data and 100 KB code), and less constrained (Class 2, 50 KB data and 250 KB code size). While this consensus was finalized three years ago, most terms are still useful in related WG conversations. An updated version of this document [2] is also available and under discussion within the group, which plans to include recent insights from the community on topics such as MTU size implications and lower-power WAN devices.

When designing and implementing the stack on nonconstrained Internet devices, it is generally assumed that they are reachable (at least as the server role) and that the maintenance of the always-on connection by sending periodic keep-alive beacons are not too costly to be employed. But these assumptions cannot be taken for granted in a constrained environment, as tiny devices have been built duty-cycled and may switch to sleeping mode for the sake of power efficiency. The draft by Arkko et al. on building power-efficient CoAP devices for cellular networks [3] examines this issue and makes a number of recommendations. The key to enabling network applications on top of sleepy nodes is to inform the other participating nodes of the existence of the sleepy devices and the locations of their data through a discoverable delegator. While data delegation infrastructure has been specified by the CoRE-RD [4], limited support is available for the discovery of the resource directory or other registration services. Arkko et al.[4] point out that multicast discovery over cellular alike point-to-point link is not feasible, and they suggest a number of ways for such initial discovery, including manual configuration, manufacturer server hardwiring, delegated manufacturer server hardwiring, and common global resolution infrastructure. For those implementing their services over cellular devices, Arkko et al.’s draft is a must read.

CoAP is an important component for constrained applications. Many open source projects are available, but seldom do they consider how to implement CoAP service in a cost-efficient way. Kovatsch et al. [5] provide lessons learned from implementing CoAP for tiny devices. This document covers many details of CoAP implementation that engineers usually encounter repeatedly but have not been covered by the specification. There are many insights shared, and the authors provide detailed recommendations on Message ID Usage, Duplication Detection/Rejection, Token Usage, (re)transmission state management, and foreseen optimization. One concrete example is about an insight and clever finding on the Token Usage in CoAP observation model. Instead of constantly polling the sensor device to fetch most updated information, CoAP enables an observer to register its interest in a certain resource and subsequently be notified with the most recent data representation, which is called observation model. The observation relationship, represented by URI, IP, Port and Token value (of the observer), is usually kept on the tiny sensors. However, CoAP supports duplicate registrations from one endpoint on the same URI with different Token values, which may add additional cost. Kovatsch et al. instead recommend to assign and reuse a dedicated token value space (8 bytes) for each observe relationship, by keeping four bytes constant and iterating the rest four byte space to avoid replay and spoofing attacks. This method not only saves resources to support CoAP observation, but also is protocol compliant. It is also recommended that retransmission buffers are assigned per observable resource instead of per observer (Section 3.3. [5]), which consequently saves additional state.

Specific guidelines of power-efficient protocol design are discussed by Gomez et al. [6], who offer insights about broadcast and nonsynchronized transmissions consuming more than other Tx/Rx operations. If protocols must use these ways to collect information, reducing their usage by aggregating similar messages will help save power. What’s more, operations, such as retransmission management, duplicate detection, and observable conversation turn out to be both memory consuming and power inefficient. Reduction of such states in protocol design is a recommended way to be energy efficient.

Security components are generally considered costly, but their absence is a huge risk. Valuable practical considerations and experiences are provided by Sethi et al. [7], who detail the available cryptography libraries and evaluate their performance in terms of execution time and memory footprint. This is an interesting document for implementers to reference before evaluating the computational cost of a relevant security solution. Most important, the authors positively conclude that with the help of an informed selection of algorithms and security protocol exchange, the additional cost (e.g., execution time and memory consumption) can be controlled so as to fit most application scenarios.

In addition, Kivinen shares a very small IKEv2 initiator implementation in RFC 7815 [8]. The thinking is that a typical IoT device is deployed to communicate with only one server endpoint, so certain portions of the payload contained in the protocol exchange will be static and duplicate validations will be avoided by the minimal implementation. Kivinen also offers a list of optional payloads (e.g., multiple status notifications) that are only useful for multiple peer cases and can be ignored by such minimal implementation. The minimal initiator protocol described is interoperable with a full backend IKEv2 implementation and, therefore, is quite useful on tiny end points.

Conclusion

This article listed just some of the activities of the LWIG WG. Topics that were not covered here, but are taking place in the WG day to day, include minimal TCP, TLS and DTLS, ESP, and neighbor management implementation. Please drop by the group page at https://tools.ietf.org/wg/lwig to learn more. We are grateful to all contributors who are willing to share their experiences of crafting minimal implementations.

References

1. Bormann, C., Ersue, M., and A. Keranen, “Terminology for Constrained-Node Networks”, RFC 7228, May 2014.

2. Bormann, C., Gomez, C., “Terminology for Constrained-Node Networks”, draft-bormann-lwig-7228bis-00 (work in progress), 2017.

3. Arkko, J., Eriksson, A., Keranen, A., “Building Power-Efficient CoAP Devices for Cellular Networks”, draft-ietf-lwig-cellular-06(work in progress), 2016

4. Shelby, Z., Koster, M., Bormann, C., and P. Stok, “CoRE Resource Directory”, draft-ietf-core-resource-directory-09(work in progress), 2016.

5. Kovatsch, M., Bergmann, O., and Bormann, C., “CoAP Implementation Guidance”, draft-ietf-lwig-coap-03 (work in progress), 2015.

6. Gomez, C., Kovatsch, M., Tian, H., and Cao, Z., “Energy-Efficient Features of Internet of Things Protocols”, draft-ietf-lwig-energy-efficient-06 (work in progress), 2017.

7. Sethi, M., Arkko, J., Keranen, A., Back, H., “Practical Considerations and Implementation Experiences in Securing Smart Object Networks”, draft-ietf-lwig-crypto-sensors-02 (work in progress), 2017.

8. T. Kivinen, “Minimal Internet Key Exchange Version 2 (IKEv2) Initiator Implementation”, RFC 7815, 2016.

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *