Question regarding Vendor Config File

[Manny Veloso]

The vendor config file in TR-069 represents different things depending on the model and the vendor.

Are you talking about InternetGatewayDevice.DeviceInfo.Vendor-ConfigFile? Or IGD.DeviceConfig.ConfigFile? Or config files in general?

In general, the config file is a static list of device parameters. A config file that’s pushed to 50 devices will make all the devices the same, mostly*.

In TR-069, you can tell the device to download and upload the config file. Downloading the config will replace the current running configuration with whatever configuration is in the config file. Devices will generally totally overwrite the running config with the config file settings (ie: generally the device won’t merge the running config and the downloaded config - it’ll use the downloaded config as the running config, and throw the old running config away). Uploading the config tells the CPE to POST the config file to somewhere you specify.

Depending on the device, you can see the config file name and some other data in the IGD.DeviceInfo.Vendor-ConfigFile. The info there isn’t really that useful.

In some devices you can grab the running config file by using IGD.DeviceConfig.ConfigFile. Theoretically you can take that and push it back onto the device.

In an ACS, the config file usually is a blob.

The format is pretty much implementation dependent. In our devices it’s the running config, but values that are default values are not in the file.

Usually ACSs don’t manage config files, they manage settings. Settings can be dynamic per device, which makes them valuable. Config files are usually pushed at the factory, and contain the static plant stuff. Of course, everyone can do things differently. I know of one customer that generates config files on the fly and pushes them to a device via an ACS. There are other customers who use the ACS to manage everything, and the config file is totally generic.

You can do lifecycle management for a config file, but at a minimum that requires that you version the config file and have a way of getting that version in the ACS. Then you can start using the ACS to detect when things are out-of-date.

As Dan says, config files are useful, but dynamic data is probably better managed via an ACS - unless your back-end service already generates config-file friendly output.
--
Manny Veloso
Sr. Solutions Engineer
Smartrg.com

From: Users <users-bounces at lists.genieacs.com<mailto:users-bounces at lists.genieacs.com>> on behalf of Dan Morphis <dan at milkcarton.com<mailto:dan at milkcarton.com>>
Reply-To: Community support for GenieACS users <users at lists.genieacs.com<mailto:users at lists.genieacs.com>>
Date: Tuesday, July 21, 2015 at 12:51 PM
To: Community support for GenieACS users <users at lists.genieacs.com<mailto:users at lists.genieacs.com>>
Subject: Re: Question regarding Vendor Config File

I can shed some light. The vendor config file is the configuration file you upload to the CPE usually through the GUI on the CPE. The format of the file will be specific to the CPE vendor. The config file for SmartRG (and other Broadcom based CPEs) is an XML representation of the TR069 object model of the device. While the older Thomson's its in ini file format.

Currently, you have to manually tell the CPE to download the configuration file. Be aware though, when the CPE applies the config file, it will be factory defaulted. So if you send the config file to any CPE's that have customers assigned to it, you will need to set the pppoe credentials and other settings specific to your environment.

On Tue, Jul 21, 2015 at 2:05 AM, Prashant Upadhyaya <praupadhyaya at gmail.com<mailto:praupadhyaya at gmail.com>> wrote:
Hi,

I have a few questions regarding the concept of Vendor Config File in TR-069.
What does it exactly represent for ACS ?
Is it a snapshot of _all_ the parameters of a CPE at a single place (the root model supported by CPE as well as vendor specific extensions) ?
How is the lifecycle of this config file managed.
Eg. if the version at CPE and ACS mismatch, then ACS should ask CPE to download it.
But how would the version typically change at the ACS itself ? Eg. should the ACS bump up the version everytime the operator changes some CPE parameter at ACS or is there some different scenario.
Can the version change at CPE automatically and in that case, should the CPE ask the ACS to upload it.

Basically, if somebody can shed more light on this concept in TR-069 from their practical experience, that will be great.

Regards
-Prashant


_______________________________________________
Users mailing list
Users at lists.genieacs.com<mailto:Users at lists.genieacs.com>
http://lists.genieacs.com/mailman/listinfo/users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genieacs.com/pipermail/users/attachments/20150723/f57b412d/attachment.html>