[LEDE-DEV] [OpenWrt] TR-069 for OpenWrt

[Wouter Cloetens]

Weighing in on the discussion with what we have.

The SoftAtHome TR-069 client solution, that we have recently offered, 
has several layers.

The first is the TR-069 protocol layer. It supports TR-069 as well as 
TR-181.

Most of our customer base consists of Tier 1 Internet Service Providers, 
who use TR-069 intensively for monitoring and configuration, with an 
extensive level of custom objects and parameters which cannot be found 
in the BBF data model. To deal with the need for extreme 
configurability, we have a layer that takes care of data model translation.

There is some development being done to make that layer applicable not 
only to TR-069, but to anything. We have, for example, an IPC bridge to 
D-Bus, a web server that can handle both web services calls and REST, 
and various custom translations to customer-specific protocols. The 
ability to customise what is exposed through these protocol terminations 
gives us a huge amount of flexibility, in an isolated manner, i.e. 
without having to resort to hacking the protocol code itself. This would 
also work for SNMP, Netconf, CoAP, ...
The early version of this code uses XML for configuration (but it could 
be JSON for all we care). We have another pass through the code planned, 
where we will check if a pure configuration interface provides enough 
flexibility, or if code is required. Our old mechanism is based on code, 
which means that it can do anything; do queries to find where mappings 
need to terminate, translate object paths, parameters, parameter values, 
spread the parameters of object instances across multiple back-end 
services, add additional, calculated parameters, ...

The final layer is, of course, the IPC mechanism.

Another final note is that TR-069 itself is not entirely cleanly 
separated from the data model (as defined in TR-098, TR-181, TR-104). 
This limits the admirable goal of being back-end agnostic somewhat.
There is a basic assumption that 
{InternetGatewayDevice|Device}.DeviceInfo is present.
For manageable devices behind the gateway, 
ManagementServer.ManageableDevice must be present. ACS's demand specific 
behaviour to set up port forwardings for these devices, which has 
firewall implications.
The ConnectionRequest mechanism also has a firewall implication.
Software upgrade functionality, as well as other file upload/download, 
is mostly managed outside the data model.

bfn, Wouter