TR-069

From Wikipedia, the free encyclopedia
Jump to: navigation, search

TR-069 (Technical Report 069) is a DSL Forum (which was later renamed as Broadband Forum) technical specification entitled CPE WAN Management Protocol (CWMP). It defines an application layer protocol for remote management of end-user devices. As a bidirectional SOAP/HTTP-based protocol, it provides the communication between customer-premises equipment (CPE) and Auto Configuration Servers (ACS). It includes both a safe auto configuration and the control of other CPE management functions within an integrated framework. The protocol addressed the growing number of different Internet access devices such as modems, routers, gateways, set-top box, and VoIP-phones. for the end-users. The TR-069 standard was developed for automatic configuration of these devices with Auto Configuration Servers (ACS). The technical specifications are managed and published by the Broadband Forum. TR-069 was first published in May 2004, with amendments in 2006, 2007, and November 2010 to version 1.2.[1]

Other fora, such as the Home Gateway Initiative (HGI), Digital Video Broadcasting (DVB) and WiMAX Forum endorsed CWMP as the protocol for remote management of home network devices and terminals (such as the DVB IPTV set-top box). There is a growing trend to add TR-069 management functionality to home networking devices such as powerline adapters[2] used for distribution of IPTV content inside customer premises, as well as many other access devices like FTTH CPE/ONTs, WIMAX CPE[3] and other carrier access equipment


Contents

[edit] Communication between the device and ACS

[edit] Transport Details

CWMP is a text based protocol. Orders send between the device (CPE) and configuration server (ACS) are transported over HTTP (or more frequently HTTPS) protocol. At this level (HTTP) CPE is behaving in the role of client and ACS in the role of HTTP server. This essentially means that control over the flow of the provisioning session is the sole responsibility of the device.

Remote CPE Control via TR-069.jpg

[edit] Provisioning Session

All communications and operations are performed in the scope of the provisioning session. Session is always started by the device and begins by transmission of Inform message. Its reception and readiness of the server for the session is indicated by InformResponse message. That concludes session initialization stage. Order of the next two stages depends on the value of the flag holdRequests. In case value is false initialization stage is proceeded by transmission of device requests, otherwise ACS orders are transmitted first. Following description assumes value to be false.

In the second stage orders are transmitted from the device to the ACS. Even though protocol defines multiple methods that may be invoked by the device on the ACS, only one is commonly found - TransferComplete. This stage is finalized by transmission of empty HTTP-request to the ACS.

In the third stage roles change on the CWMP level. HTTP-response for the query by the device will contain CWMP-request from the ACS. This will be subsequently followed by HTTP-request containing CWMP-response for the previous CWMP-request. Multiple orders may be transmitted one-by-one. Stage (and the whole provisioning session) is terminated by empty HTTP-responce indicating that no more orders are pending.

[edit] Security and Authentication

As vital data (like user names and passwords) may be transmitted to CPE via TR-069 protocol it is essential to provide secure transport channel and always authenticate CPE against ACS. Secure transport and authentication of ACS identity may be easily provided by usage of HTTPS and verification of ACS certificate. Authentication of CPE is more problematic. Identity of the device is verified based on shared secret (password) at HTTP level. Passwords may be negotiated between the parties (CPE-ACS) at every provisioning session. When device contacts ACS for the first time (or after factory-reset was performed) default passwords are used. In large networks it is the responsibility of the procurement to ensure each device is using unique credentials, their list is delivered with the devices themselves and secured.

[edit] Connection Request

Because initialization and control over provisioning session flow is the sole responsibility of the device it is necessary for the ACS to be able to request a session start from the device. Connection request mechanism is also based on HTTP. In this case the device (CPE) is put in the role of HTTP-server. ACS requests connection from the device by visiting negotiated URL and performing HTTP Authentication. Shared secret is also negotiated with the device in advance (ex. previous provisioning session) to prevent usage of CPE's for DDoS attack on the provisioning server (ACS). After confirmation is send by the device provisioning session should be started as soon as possible and not later than 30 seconds after confirmation is transmitted.

[edit] CR over NAT

CWMP protocol also define mechanism of reaching the devices that are connected behind NAT (ex. IP-Phones). Mechanism based on STUN and UDP NAT traversal is defined in document TR-111. This document also amends basic data models (to versions Device:1.1 and InternetGatewayDevice:1.2) defining parameters allowing feature configuration and exchange of relevant data between CPE and ACS.

[edit] Data-model

Most of the configuration and diagnostics is performed through setting and retrieving the value of the device parameters. These are organized in well defined hierarchical structure that is more or less common to all device models and manufacturers. Broadband Forum is publishing its data model standards in two formats - XML files containing detailed specification of each subsequent data-model and all of the changes between their versions and PDF files containing human-readable details. Supported standards and extensions should be clearly marked in device data-model. This should be in the field Device.DeviceSummary or InternetGatewayDevice.DeviceSummary which is required starting from Device:1.0 and InternetGatewayDevice:1.1 respectively. If the field is not found InternetGatewayDevice:1.0 is implied. As of Device:1.4 and InternetGatewayDevice:1.6 new field ( '<RO>'.SupportedDatamodel) for supported standard specification was introduced.

Model is always rooted in the single key named Device or InternetGatewayDevice depending on the manufacturers choice. At each level of the structure objects and parameters (or array-instances) are allowed. Keys are constructed by concatenating the names of objects and parameter and using '.'(dot) as a separator. Ex. InternetGatewayDevice.Time.NTPServer1 .

Each of the parameters may be marked as writable or non-writable. This is reported by the device in GetParameterNamesResponse message. Device should not permit the change of any parameter marked as read-only. Data-model specifications and extensions clearly marked required status of the most of the parameters.

Values applicable for the parameter, their type and meaning are also precisely defined by the standard.

[edit] Arrays

Some parts of the data model requires existence of multiple copies of the subtree. The best sample are those describing tables ex. Port Forwarding Table. Object representing array will only have instances (identified by integers) as its children. Commonly at the same level as the array parameter indicating current number of instances could be found.

Array could be writable (enabling dynamic creation and/or removal of its children) or read-only depending on the data represented. If for example array instances represents four ports on build-in switch it should not be possible to add or remove them from data-model. If an instance is added to an array integer identifier is assigned. After being assigned identifiers may not change during life-cycle of the device except for factory-reset and application of the configuration file.

[edit] Common Problems

Even though list of the parameters and their attributes is well defined most of the devices do not follow standards completely. Most common problems includes missing parameters, omitted instance numbers (for the arrays where only instance is present), wrong parameter access level and understanding of the value meaning. For example for the field indicating supported standard of access point value 'g' should indicate support of 802.11b and 802.11g and 'g-only' support only form 802.11g. Even though values as 'bg' or 'b/g' are not legal as to Broadband Forum standards they are very commonly found in device data models.

[edit] Common Operations

Whole provisioning is build on top of defined set of simple operations. Each order is considered atomic, though there is no support of transactions. If the device cannot fulfill the order proper error needs to be returned to the ACS - device should never break the provisioning session.

Abr Message Description
GPN GetParameterNames Used to retrieve list of supported parameter keys from the device.
GPV GetParameterValues Retrieve current value of the parameters identified by keys. Could be used to retrieve one or multiple parameters at once. Version of the call with object as the key allows for retrieval of all of the parameters associated with that object
SPV SetParameterValues Sets the value of one or multiple parameters
GPA GetParameterAttributes Retrieves attributes of one or multiple parameters
SPA SetParameterAttributes Sets attributes of one or multiple parameters
- Download Orders CPE to download the file specified by URL and use it (depending on specified file type) as Firmware Image, Configuration File, Ringer file etc.
- Upload Orders CPE to upload specified file type to the specified destination. This could cover for ex. current configuration file, log files etc.
ADD AddObject Adds new instance to an array
DEL DeleteObject Removes instance from and array

[edit] Hi-level operations possible through TR-069

  • Service activation and reconfiguration
    • Initial configuration of the service as part of zero-touch of one-touch configuration process
    • Service reestablishment (ex. after device is factory-reseted, exchanged)
  • Remote Subscriber Support
    • Verification of the device status and functionality
    • Manual reconfiguration
  • Firmware and Configuration Management
    • Firmware upgrade/downgrade
    • Configuration backup/restore
  • Diagnostics and monitoring
    • Throughput (TR-143) and connectivity diagnostics
    • Parameter value retrieval
    • Log file retrieal

[edit] External links

[edit] References

Personal tools
Namespaces
Variants
Actions
Navigation
Interaction
Toolbox
Print/export
Languages