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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
