CORECONF: Managing IoT Devices with YANG Models

Introduction This short paper provides an overview over the CORECONF architecture for employing YANG models in managing IoT devices. CORECONF is based on CoAP as a transfer protocol and YANG-CBOR as its data representation format, analogous to the way the original RESTCONF was defined to use HTTP and YANG-XML or YANG-JSON , and the way NETCONF uses SSH and YANG-XML . The mapping of the CORECONF interactions to CoAP is described in . In support of CORECONF, early contributions exist for supporting YANG metadata in YANG-CBOR and for a significant performance optimization further shedding the text-based heritage of YANG .

Background

IoT One definition of the Internet of Things is that it aims to connect devices ("Things") via the Internet that are embedded in everyday physical items, making them "available for interaction over a network, thereby enabling digital interaction with the physical world for humans, services, and/or other Things" . The number of Internet nodes that could be called "Things" in this sense has been steadily growing, and is currently estimated to be on the order of 20 billion, possibly doubling in the next eight years . While Things vary wildly in their technical characteristics, the scale of their deployment creates a practical limit to the power resources available to them: If we were willing to spend 1 % of the global electricity generation just on the connectedness of those Things, we would have a total power budget of about 35 GW for all of them , leaving less than 2 W on average for each of them. Since there will be many Things that need significantly more than 2 W (and 1 % is maybe too spendy at an energy cost of several dollars per year per Thing), the majority of the Things will need to get by with significantly less than 1 W average sustained power each. If operation from primary batteries is essential to the function of the Thing and battery lifetimes of a few years are desired, this upper boundary shrinks to the order of a few 10s or 100s of µW (for a single CR2032 button cell or 2 AA batteries, respectively). Together with the need to also limit the non-energy per-device cost of ownership at this scale, this turns a significant part of the Things into devices with low resources available to them, or constrained devices . Architectures that aim to support IoT therefore need to be able to accommodate constrained (low-resource) devices, even if not all IoT devices are subject to the same constraints.

IETF Network Management In the late 1980s, at a time when the Internet Protocol Suite was still in active competition with OSI-based proposals, the IETF converged on a simple network management solution, SNMP (Simple Network Management Protocol, ). As with the proposals it initially competed with , SNMP based its data modeling language on ASN.1 (standardized as at the time, also known as ISO 8824, previously as the X.409 component of the X.400 messaging standardization project). SNMP employed ASN.1 macros as a textual convention to create the SMIv2 data modeling language as a specialization of ASN.1's eponymous datatype declaration language . (In ISO, ASN.1 macros were not much later deprecated in favor of ASN.1 Information Objects, which could not easily be adapted to SNMP's needs; as a result, SNMP continued to stay tied to the 1988 version of ASN.1.) SMIv2 has been criticized for requiring significant, non-trivial transformations of the intended information model into the limited expressiveness of its generic data model (such as constructing conceptual tables from columnar data objects, see for a description of recovering the structure in an inverse process). With its data model specification language, SNMP imported the concept of ASN.1 Object Identifiers (OIDs), identifiers represented as sequences of unsigned integers, each of which addresses one level of a hierarchy of potentially delegated registries. The representation of OIDs in ASN.1's Basic Encoding Rules (BER, ) can be reasonably efficient, and the more human-readable presentation is a simple sequence of decimal unsigned integers separated by dots. OIDs' delegation technique allows anyone to coin OIDs, once they have received the delegation of an OID prefix ("arc") somewhere in the OID hierarchy. This keeps OIDs popular in many environments, such as in the IETF Security area, but also makes it hard to enforce any structure or semantics on namespaces represented by OIDs. When IETF standardization of network management for IoT began in earnest in the early 2010s, SNMP was already in the process of being obsoleted by NETCONF for many applications, in particular those involving remote configuration and not just monitoring. However, the simplicity and low resource requirements of the SNMP protocol compared to the XML-based NETCONF were a good match for constrained nodes, and SNMP MIBs (SMIv2 modules) were widely available for many areas of application relevant to IoT. This caused initial efforts in the IoT network management space to be based on SNMP (for example, the 6LoWPAN MIB ). At the same time, the NETCONF protocol (, originally ) was getting established in the wider Internet, and with it the modeling language YANG . Both efforts were closely tied to the idiosyncrasies of XML, which was popular at the time as a framework for text-based data representation formats, even though its predecessor SGML was originally created for document interchange . In addition to allowing the monitoring of state data, NETCONF was specifically addressing the configuration of network devices, which was supported by SNMP implementations only in a limited way. NETCONF was designed to allow "the functionality of the management protocol to closely mirror the native functionality of the device" (). "The YANG data modeling language has been developed for specifying NETCONF data models [...]" (). Instead of employing the ASN.1 macro language used for SMIv2, YANG has been designed as a new (directly human-readable) computer language, initially with an XML-based representation format and thus generic data model (which we call YANG-XML). Since YANG was created, the popularity of XML has faded away towards an increased popularity of JSON . A JSON-based representation (which we call YANG-JSON, ) has been added to YANG with YANG 1.1 , for use as an alternative format that can be used with the RESTCONF protocol . This has to work around both JSON's own interoperability problems and the need to be bug-compatible with XML idiosyncrasies (for instance, see ). Both YANG-XML and YANG-JSON build an identifier from names that resemble XML QNames (Qualified Names, i.e., colon-separated pairs of an optional prefix and a name; the prefix is usually registered). Instance-identifiers, i.e., pointers into a data tree, are constructed by separating a sequence of (qualified) names and index values with slash characters and square brackets, respectively. This is similar in concept as, but dramatically less efficient (both in space and processing time) than, the ASN.1 BER representation of OIDs known from SNMP.

CoAP The Constrained Application Protocol (CoAP, ) was designed as an application protocol for constrained nodes that is based on the Representational State Transfer architecture it has in common with HTTP. Initially, CoAP provided the usual basic complement of methods known from HTTP (GET, PUT, POST, DELETE). This was later extended by three additional methods: FETCH to perform the equivalent of a GET with additional parameters sent in the body of the request, and PATCH/iPATCH (idempotent PATCH) for updating a resource based on data in the body of the request . CoAP's "observe" extension can be used to automatically obtain updates to a previously obtained representation of a resource . The "block-wise" extension enables the transfer of data items that would not fit into (or are otherwise considered too large for) a single packet . Independent of the discussion here, CoAP is already used by ecosystem-specific IoT management protocols such as OMA's Lightweight M2M (LwM2M) .

CORECONF: Approach In 2012, Ersue, Romascanu and Schönwälder described eight IoT use cases and derived requirements for "Management of Networks of Constrained Devices" . The CORECONF effort was started in 2013 by van der Stok as "CoAP Management Interfaces" (COMI) , initially focused on the simpler SNMP ecosystem, replacing just the SNMP protocol (and its security solution) by CoAP, but keeping the data model. This enabled a device to share code and complexity between the network management and the device's application protocol. Veillette and Pelov, among others, joined the effort soon with the "Constrained Objects Language" (CoOL) proposal . At the time, the management community had started work on RESTCONF , replacing the custom NETCONF protocol by a simplified REST-based architecture (i.e., employing HTTP), which lent itself to realizing a further simplified variant over CoAP as well. CoOL provided a first representation of YANG data structures in the Concise Binary Object Representation (CBOR) format (, now ). This allowed leaving behind the inefficient text-based representation formats on which YANG-XML (and later YANG-JSON) were built. CoOL also pioneered the idea of a Fully-qualified data node ID (FQDNID), which was a 31-bit integer standing in for the (text-based) YANG data name. The intention was to annotate YANG models by information that would allow deriving FQDNIDs and related numbers. The CoAP protocol would be extended by a Fields Option, which would extend the URI by descending into the YANG tree based on a list of FQDNIDs. (This was later replaced by a special syntax that could be used within the request URI, and ultimately by switching to CoAP's FETCH and iPATCH methods instead of GET/PUT, supplying the identifying information in the CoAP request payload.) Discussion about the best way to derive an efficient form of the YANG data name dominated the early discussion about CORECONF. Briefly, a hash-based approach was favored , but it turned out to be too hard to manage the collisions during model evolution, and hash values also didn't provide a main benefit of a more structured allocation of integer IDs: Since related IDs usually occur in a cluster, a simple delta encoding of the IDs can provide excellent encoding efficiency. A hierarchical delta encoding of IDs is the basis of today's YANG-CBOR representation . To obtain an integer ID that exhibits good locality, boosting the benefits from delta-encoding, the community arrived at large (63-bit) unsigned integers. These integers are called YANG SIDs, YANG Schema Item iDentifiers, and can identify YANG schema nodes, YANG identities, YANG modules, or YANG features. The huge linear SID space is managed by employing a hierarchy of IANA registries , first carving up the large space into million-plus "mega-ranges", then, for an individual YANG model, allocating out of a chosen mega-range a SID range of, say, 100 integers. Each YANG model can in turn assign its individual SIDs from its SID range automatically (or even have them assigned automatically after the fact via a designated expert) or make use of an optimized assignment method tailored to the individual model .

Discussion The complete CORECONF architecture is built from four specifications:

YANG-CBOR , published July 2022. This maps YANG data into CBOR as a representation format, similar to how YANG-XML maps into XML and YANG-JSON maps into JSON. It is itself quite efficient, but carries data in text form that YANG modules (such as those exported from ) define as text-based (such as date/time or IP/MAC addresses). proposes a remedy. Discussion is ongoing on whether this should be added in the transparent way the current document chooses (so it can be seamlessly applied to existing modules such as those from ) and/or by adding information to the YANG modules in a future YANG extension. proposes a way to represent YANG metadata , which essentially offer compatibility to the use of XML attributes in YANG-XML, efficiently and in a much less contorted way than that defined for JSON.
YANG-SID , published July 2024. This defines the registration and assignment processes for YANG-SIDs, the efficient binary unsigned integer representation for the text-based names found in YANG-XML and YANG-JSON, as well as a representation format ("SID file") for recording the mapping between YANG names and YANG SIDs that applies to each YANG module in use. These detailed processes need to take into account that YANG SIDs will be needed for many existing YANG modules, as well as YANG modules that are newly being developed and stay in this stage for a while.

Both YANG-CBOR and YANG-SID are designed so they can be used in any YANG environment, including outside CORECONF, e.g., in a RESTCONF environment to provide an efficient binary representation there as well.

COMI (CoAP Management Interface for CORECONF, ). COMI employs YANG-CBOR, YANG-SID, and CoAP to provide simplified network management operations for constrained devices. The datastore model supported today is that of a single unified datastore (with potential later extensions possible; e.g., for obtaining some of the benefits discussed in ). As a replacement for SNMP's traps and special YANG notification protocols, COMI employs CoAP's "observe" mechanism, applied to "event stream resources". A potential extension to be added in a separate document could handle the remaining problem of how to control the amount of data that may be in a response to a request operating on a non-trivial data tree, potentially including, but not limited to, pagination . Revision -16 has passed Working Group Last Call (WGLC) on 2023-09-15. This (and previous revisions) has been implemented in several research environments and, during discussions in conjunction with the May 2024 T2TRG interim meeting in Paris, was considered to meet the goals these environments planned to achieve. Based on implementation experience, the WG has since explored a number of further rounds of simplification, one of which is still outstanding; completion is considered imminent.
Constrained YANG Module Library . This document describes a simplified constrained version of the YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a constrained network management server (e.g., a CORECONF server). This document has passed Working Group Last Call (WGLC) already in 2020, but has been in hibernation since, while the other parts of CORECONF were completed. With renewed discussion about the "big" YANG library , some fallout can be expected for the constrained version as well. (Note that basic resource discovery is already provided in the CoRE ecosystem by /.well-known/core, the Link format employed there , as well as the CoRE Resource Directory .)

In summary, CORECONF makes the use of YANG models accessible for managing low-resource devices. Beyond this immediate objective, there is a more general discussion about the use of data/interaction modeling languages for IoT in general, not just for network management. For instance, IETF's ASDF WG has specified the Semantic Definition Format (SDF, ). SDF describes Things in terms of their interaction opportunities ("affordances"), structured into properties, actions, and events, as well as the data models behind these. It is just a convention that YANG is used for modeling network management affordances and SDF for application-level affordances. To potentially cross-pollinate between these techniques, Kiesewalter explored bidirectional automatic translation between SDF and YANG based forms of a data/interaction model . To obtain productive interworking between YANG, other relevant modeling techniques, and different fields of application, one discussion that will become necessary is how to consolidate support for the rather different evolution patterns used by network management specifications and application interactions (APIs).

Security Considerations CORECONF uses CoAP, which can be protected using DTLS or OSCORE with EDHOC . While both SNMP and NETCONF/RESTCONF came with elaborate network-management-focused security data models, CORECONF acknowledges that the security models for network management of constrained devices will often need to align with application security models, such as or the specific security model used in an IoT ecosystem and its approach to commissioning .

IANA Considerations This document has no IANA actions.