（转载）
家庭网络设备的远程管理需要解决的技术问题主要是管理通道和管理协议。远程管理的信息承载在IP包上，管理通道问题主要是解决如何传送承载管理信息的IP 包，这主要与具体的接入技术相关。如何保证管理通道的可用性和管理通道的带宽是目前相关接入技术需要解决的问题。管理协议主要是指IP层之上的管理内容传送协议，目前主要有IETF制定的SNMP和DSLFORUM制定的TR-069。管理协议的选择主要需要权衡安全性和协议复杂性。
TR-069协议栈的基本思路是利用Web服务中广泛使用的基于S0AP的RPC方法，其会话协议使用的是HTTP1.1协议，因此TR-069可以方便地应用在Web中应用的传送层安全技术（如SSL/TLS）。TR-069协议栈的下面几层充分利用目前Internet上广泛使用的通信协议，比如TCP、HTTP、SOAP等。通过这些成熟的协议，ACS和家庭网络设备之间可以方便地建立通信的基本通道。TR-069在SOAP之上定义了用于配置、查询、诊断等操作的特定RPC方法，通信的两端（ACS和用户设备）都可以通过RPC调用来完成某个特定功能的执行和得到返回的结果。
以传输为导向的简单网络管理协议 (SNMP)
对基于IP的传输网络而言，我们广泛部署了 SNMP 以监控交换机、路由器、服务器以及系统的性能、负载和其他运行参数，这对因特网的主干网以及大型企业级虚拟专用网 (VPN) 都非常重要。SNMP 生成的数据对网络管理员很有用，可用来评估网络的性能并发现流量瓶颈或潜在的瓶颈。此外，这种信息还有助于网络的设计或再设计。
以 PC 为中心的本地网络通用即插即用技术 (UpnP)
在因特网主干网的另一端，基于IP 的小型家庭网络常采用 UPnP 技术作为控制机制。PnP 最早的设计用于PC与外设之间的透明连接，目前已发展成为一种点对点架构。对消费者来说，UPnP 的优势之一在于使用方便。新型设备自动与家庭或办公室小型网络连接，并能被网络中的其他已加入设备"检测"到。（千万不要认为UPnP只能在LAN的范围内工作!!!）有些UPnP网络不受控制，因为网络中没有动态主机配置协议 (DHCP) 服务器。如果这样的话，那么连接UPnP网络的设备必须给自己分配一个IP地址。此外，安全性也是基于UPnP的家庭网络的一个问题。
有些服务供应商需要的远程管理工具不仅可以跨因特网工作，而且还能实现对家庭网络乃至终端设备的可视性，在这种情况下 SNMP 技术就难以胜任了。从一定程度上说，SNMP能对 TR-069 的功能有所补充，但不能满足当前及今后的控制、配置与管理特性的要求。另一方面，UPnP 只能解决局域网 (LAN) 的问题，而对广域传输网络问题却束手无策。
由 DSL 论坛定义的名为"CPE WAN 管理协议"的 TR-069 规范明确表示，其不仅提供覆盖运营商广域网 (WAN) 的管理机制，而且还将作为桥接 CPE 设备（其中许多 CPE 设备位于家庭或小型办公 LAN 中）的机制。
TR-069 规范的扩展系列目前正由 DSL 论坛开发，有关文件定义了 TR-069 如何通过 DSL CPE 对某些类型的设备进行远程管理。TR-069 中的自动配置与管理功能等服务也将通过 DSL CPE 提供给相连的设备，如 VoIP 电话与系统（TR-104 与 TR-110）、STB 以及掌上游戏机等。
（转载）
2007年10月11日星期四
2007年9月12日星期三
TR064: LAN-Side DSL CPE Configuration
/*
*A summary of TR064 during my projects
*/
官方Abstract:
This Working Text will specify the method for configuring DSL CPE through software on PCs inside the LAN.
最新的TR-064技术报告：
TR-064
http://www.dslforum.org/techwork/tr/TR-064.pdf
TR-133 DSLHomeTM TR-064 Extensions for Service Differentiation
http://www.dslforum.org/techwork/tr/TR-133.pdf
As residential gateways offer increasingly complex services, customer premise installation and configuration increase the operators' operational costs. DSL Forum's LAN-Side DSL CPE Configuration protocol, known as TR-064, provides a zero-touch solution for automating the installation and configuration of gateways from the LAN side.
/* Summary of LAN-side Configuration Interface */
+++ Discovery +++
TR064 use Simple Service Discovery Protocol (SSDP) to discover LAN devices.
SSDP: http://quimby.gnus.org/internet-drafts/draft-cai-ssdp-v1-03.txt
关于SSDP协议的具体内容可以参考UPnP的其他相关文档
/*
The Simple Service Discovery Protocol (SSDP) provides a mechanism
where by network clients, with little or no static configuration,
can discover network services. SSDP accomplishes this by providing
for multicast discovery support as well as server based notification
and discovery routing.
*/
1. When started the CPE MUST broadcast SSDP discovery advertisement (NOTIFY) messages as specified in the UDA. In summary, the requirements are as follows:
3. CPE Discovery and Communications
+++ Security +++
Security is important in order to protect CPE from intentional or unintentional misconfiguration. The main objective is to provide authentication in order to prevent unauthorized configuration.
1. Access Restriction
Access to any action that allows configuration changes to the CPE MUST be password protected.
2. Authentication
Access to any password-protected action MUST require HTTP digest authentication.
3. Password Initialization
Two distinct states are defined for the CPE with respect to authentication: Factory state and Normal state. The Factory state is defined to allow the ConfigPassword to be set for the first time without requiring the user to have knowledge of some other password to do so.
4. Encryption
Access to the LANConfigSecurity service SHOULD occur over an encrypted https link using either SSL 3.0 or TLS 1.0.
5. Co-existence with UPnP IGD
If the CPE implements both UPnP IGD and DSL CPE Management, it may share protocol stacks and information models but the DSL CPE management method MUST be secured as described in the above sections. This approach provides the flexibility to allow UPnP IGD to operate as-is while also providing the security required for CPE configuration management.
The use of the URN prefix “dslforum-org” for this DCP indicates the following differences from the standard UPnP gateway IGD DCP:
• Actions marked as secure will be authenticated using HTTP digest authentication.
• Variables defined within this document(TR-064 technical report) have no defined events.
• The services in this DCP exist in the DSL Forum schema namespace so that non-IGD variables and services do not require the X_ prefix.
+++ Protocols +++
+++ XML Parameters +++
UPnP devices and services are shown in black (solid line). New services that are defined in this document are shown in blue (dashed line).
Complex action sequences (e.g read-modify-write sequences) SHOULD make use of a locking mechanism. Before the first action in a logical series, the Control Point SHOULD issue the ConfigurationStarted action, which initiates a lock. After the sequence of actions is complete, the Control Point MUST issue the ConfigurationFinished action, which frees the lock.
The Control Point MUST generate a unique session ID, which it passes as an argument to the CPE in the ConfigurationStarted action.
A uniform structure is utilized in defining new Tables for access via the LAN CPE configuration Management. Each table is REQUIRED to identify the KEY, which is a variable or set of variables that uniquely identify the row in the table.
Layer3Forwarding service allows the handling of the routing and forwarding configuration of the device.
QueueManagement Service contains queue management functions including classification, queuing, policing, and application-specific flows. This service enables the ability to read and set the current classification and hierarchical queuing settings. This service is required for TR-059 compliance.
Layer2Bridging service specifies layer-2 bridges between LAN and/or WAN interfaces. Bridges can be defined to include layer-2 filter criteria to selectively bridge traffic between interfaces.
LANDevice：
A LANDevice corresponds to a physically attached network to the DSL CPE; each LANDevice has at most one MAC address.
In this example, 4 Ethernet ports and 1 wireless interface are bridged together on one physiacal network. All attached clients would receive IP addresses in the same subnet, and no routing is required in order for these ports to pass traffic to one another. This device would have 1 LANDevice that contains 1 WLANConfiguration service and 1 LANEthernetInterfaceConfig service. The IP interfaces table in LANHostConfigManagmenet would have exactly 1 entry to indicate the IP address of the LAN interface of the gateway.
Note that there may be more than one LANEthernetInterfaceConfig service within a given LANDevice if required. For example, 2 LANInterfaces with 2 different bit rates would require 2 services.
This device supports one physically attached network through the Ethernet hub and another physically attached network through the wireless interface. Traffic from one network must be routed through the gateway to communicate with devices on the other. Modeling this CPE requires 2 LANDevices: one with an LANEthernetInterfaceConfig service and one with a WLALANHostConfigManagement service. The LANHostConfigManagement service on each LANDevice has exactly 1 entry in the IPInterfaces table to dicate the IP address of the LAN interface of the gateway.
This device has 2 Ethernet ports that comprise a managed switch. In this configuration, each port is modelled by a separate LANEthernetInterfaceConfig service within a single LAN device. This configuration allows for management of each individual Ethernet port.
This device has 2 Ethernet ports supporting 2 separate attached physical networks with 2 separate IP pools. As above, these would be modelled with 2 LANDevices, each with a LANEthernetInterfaceConfig service.
In addition, the network on the left is setup as a VLAN, combining two different address ranges together into a single physical LAN. In the LANHostConfigManagement service of that LANDevice, the IP interfaces table contains two entries corresponding to the 2 IP addresses of the VLAN.
+++ User Cases +++
+++ Concurrency Diagrams +++
The first diagram represents the scenario in which Control Point one is making changes to the CPE and does not need a reboot to commit the changes.
The next diagram represents the scenario in which the CPE must reboot to apply the changes.
The next diagram illustrates the timeout for a CPE that requires no reboot:
+++ Queuing and Bridging +++
The queuing and bridging model for an Internet Gateway Device. This model relates to the QueueManagement object as well as the Layer2Bridging and Layer3Forwarding objects.
//to be continue
*A summary of TR064 during my projects
*/
官方Abstract:
This Working Text will specify the method for configuring DSL CPE through software on PCs inside the LAN.
最新的TR-064技术报告：
TR-064
http://www.dslforum.org/techwork/tr/TR-064.pdf
TR-133 DSLHomeTM TR-064 Extensions for Service Differentiation
http://www.dslforum.org/techwork/tr/TR-133.pdf
As residential gateways offer increasingly complex services, customer premise installation and configuration increase the operators' operational costs. DSL Forum's LAN-Side DSL CPE Configuration protocol, known as TR-064, provides a zero-touch solution for automating the installation and configuration of gateways from the LAN side.
/* Summary of LAN-side Configuration Interface */
- Management Protocol - standards based XML over SOAP protocol
- Parameter Model - Parameters defined using UPnP model as base, disallowing values and parameters that are inconsistent with DSL model, and adding objects as needed for DSL CPE.
- Security - HTTP Digest Authentication; optional SSL 3.0 or TLS 1.0 encryption.
- CPE Type - Supports Bridge/Router/PPPoE on-board IP pass-thru CPEs.
- Management Usage - CPE turn-up, status determination, monitoring, diagnostics.
- CPE discovery - Standards-based DHCP and SSDP device discovery.
- OS support - CPE management app with integrated XML over SOAP stack to operate on any OS, native XML/SOAP OS support is not required or desired.
+++ Discovery +++
TR064 use Simple Service Discovery Protocol (SSDP) to discover LAN devices.
SSDP: http://quimby.gnus.org/internet-drafts/draft-cai-ssdp-v1-03.txt
关于SSDP协议的具体内容可以参考UPnP的其他相关文档
/*
The Simple Service Discovery Protocol (SSDP) provides a mechanism
where by network clients, with little or no static configuration,
can discover network services. SSDP accomplishes this by providing
for multicast discovery support as well as server based notification
and discovery routing.
*/
1. When started the CPE MUST broadcast SSDP discovery advertisement (NOTIFY) messages as specified in the UDA. In summary, the requirements are as follows:
- Three announcements for the root device
- Two announcements for each embedded device
- One announcement for each service type in each device
- Each announcement specifies a lease time; each of the above announcements must be re-sent prior to the expiry of the lease.
3. CPE Discovery and Communications
+++ Security +++
Security is important in order to protect CPE from intentional or unintentional misconfiguration. The main objective is to provide authentication in order to prevent unauthorized configuration.
1. Access Restriction
Access to any action that allows configuration changes to the CPE MUST be password protected.
2. Authentication
Access to any password-protected action MUST require HTTP digest authentication.
3. Password Initialization
Two distinct states are defined for the CPE with respect to authentication: Factory state and Normal state. The Factory state is defined to allow the ConfigPassword to be set for the first time without requiring the user to have knowledge of some other password to do so.
4. Encryption
Access to the LANConfigSecurity service SHOULD occur over an encrypted https link using either SSL 3.0 or TLS 1.0.
5. Co-existence with UPnP IGD
If the CPE implements both UPnP IGD and DSL CPE Management, it may share protocol stacks and information models but the DSL CPE management method MUST be secured as described in the above sections. This approach provides the flexibility to allow UPnP IGD to operate as-is while also providing the security required for CPE configuration management.
The use of the URN prefix “dslforum-org” for this DCP indicates the following differences from the standard UPnP gateway IGD DCP:
• Actions marked as secure will be authenticated using HTTP digest authentication.
• Variables defined within this document(TR-064 technical report) have no defined events.
• The services in this DCP exist in the DSL Forum schema namespace so that non-IGD variables and services do not require the X_ prefix.
+++ Protocols +++
- The HTTP protocol is also required to support an HTML based CPE management GUI.
- Management and monitoring of CPE parameters and status is conveyed using XML. XML is a flexible text based format to describe the services supported on a CPE and the parameters and values which can be read or written. However, XML is almost free-form and therefore a standard schema must be defined for its use. For this purpose, the Simple Object Action Protocol (SOAP) [3] protocol is used so that messages can be constructed to define actions to perform along with associated parameters and responses which contain status and return parameters. So, SOAP is like a message based remote procedure call.
- SSDP is used for device discovery if the CPE IP address is unknown or misconfigured. SSDP provides the means to discover and identify the CPE and services.
- The CPE Management Application uses multicast HTTP over UDP to send a SSDP discovery request message to the LAN to discover the CPE.
- The CPE then uses a HTTP over UDP message to send the SSDP discovery request response back to the Management Application.
+++ XML Parameters +++
UPnP devices and services are shown in black (solid line). New services that are defined in this document are shown in blue (dashed line).
Complex action sequences (e.g read-modify-write sequences) SHOULD make use of a locking mechanism. Before the first action in a logical series, the Control Point SHOULD issue the ConfigurationStarted action, which initiates a lock. After the sequence of actions is complete, the Control Point MUST issue the ConfigurationFinished action, which frees the lock.
The Control Point MUST generate a unique session ID, which it passes as an argument to the CPE in the ConfigurationStarted action.
A uniform structure is utilized in defining new Tables for access via the LAN CPE configuration Management. Each table is REQUIRED to identify the KEY, which is a variable or set of variables that uniquely identify the row in the table.
Layer3Forwarding service allows the handling of the routing and forwarding configuration of the device.
QueueManagement Service contains queue management functions including classification, queuing, policing, and application-specific flows. This service enables the ability to read and set the current classification and hierarchical queuing settings. This service is required for TR-059 compliance.
Layer2Bridging service specifies layer-2 bridges between LAN and/or WAN interfaces. Bridges can be defined to include layer-2 filter criteria to selectively bridge traffic between interfaces.
LANDevice：
A LANDevice corresponds to a physically attached network to the DSL CPE; each LANDevice has at most one MAC address.
In this example, 4 Ethernet ports and 1 wireless interface are bridged together on one physiacal network. All attached clients would receive IP addresses in the same subnet, and no routing is required in order for these ports to pass traffic to one another. This device would have 1 LANDevice that contains 1 WLANConfiguration service and 1 LANEthernetInterfaceConfig service. The IP interfaces table in LANHostConfigManagmenet would have exactly 1 entry to indicate the IP address of the LAN interface of the gateway.
Note that there may be more than one LANEthernetInterfaceConfig service within a given LANDevice if required. For example, 2 LANInterfaces with 2 different bit rates would require 2 services.
This device supports one physically attached network through the Ethernet hub and another physically attached network through the wireless interface. Traffic from one network must be routed through the gateway to communicate with devices on the other. Modeling this CPE requires 2 LANDevices: one with an LANEthernetInterfaceConfig service and one with a WLALANHostConfigManagement service. The LANHostConfigManagement service on each LANDevice has exactly 1 entry in the IPInterfaces table to dicate the IP address of the LAN interface of the gateway.
This device has 2 Ethernet ports that comprise a managed switch. In this configuration, each port is modelled by a separate LANEthernetInterfaceConfig service within a single LAN device. This configuration allows for management of each individual Ethernet port.
This device has 2 Ethernet ports supporting 2 separate attached physical networks with 2 separate IP pools. As above, these would be modelled with 2 LANDevices, each with a LANEthernetInterfaceConfig service.
In addition, the network on the left is setup as a VLAN, combining two different address ranges together into a single physical LAN. In the LANHostConfigManagement service of that LANDevice, the IP interfaces table contains two entries corresponding to the 2 IP addresses of the VLAN.
+++ User Cases +++
+++ Concurrency Diagrams +++
The first diagram represents the scenario in which Control Point one is making changes to the CPE and does not need a reboot to commit the changes.
The next diagram represents the scenario in which the CPE must reboot to apply the changes.
The next diagram illustrates the timeout for a CPE that requires no reboot:
+++ Queuing and Bridging +++
The queuing and bridging model for an Internet Gateway Device. This model relates to the QueueManagement object as well as the Layer2Bridging and Layer3Forwarding objects.
//to be continue
2007年9月7日星期五
TR069: CPE WAN Management Protocol
/*
* A summary about TR069 during my projects
*/
TR69是由DSL论坛定义的用户终端广域网管理协议。
最新的TR069标准：
TR-069 Amendment2
http://www.dslforum.org/techwork/tr/TR-069Amendment2.pdf
与TR069相关的几个技术报告：
TR098 - Internet Gateway Device Data Model for TR-069 (used for QoS)
http://www.dslforum.org/techwork/tr/TR-098%20Amendment%201.pdf
TR104 - DSLHomeTM Provisioning Parameters for VoIP CPE
http://www.dslforum.org/techwork/tr/TR-104.pdf
TR106 - Data Model Template for TR-069 Enabled Devices
http://www.dslforum.org/techwork/tr/TR-106%20Amendment%201.pdf
TR140 - TR-069 Data Model for Storage Service Enabled Devices
http://www.dslforum.org/techwork/tr/TR-140.pdf
TR111 - DSLHomeTMApplying TR-069 to Remote Management of Home Networking Devices
http://www.dslforum.org/techwork/tr/TR-111.pdf
DSL论坛定义的其他技术报告：
http://www.dslforum.org/trlist/trlist.php
+++ Introduction +++
A protocol for communication between a CPE and Auto-Configuration Server (ACS) that encompasses secure auto-configuration as well as other CPE management functions within a common framework.
TR069的主要功能:
The position of TR069 in the Auto-Configuration Architecture:
The position of TR069 in the End-to-End Architecture:
TR069 Family:
Connectivity model of TR069:
• Allow both CPE and ACS initiated connection establishment, avoiding the need for a persistent connection to be maintained between each CPE and an ACS.
• The functional interactions between the ACS and CPE should be independent of which end initiated the establishment of the connection. In particular, even where ACS initiated connectivity is not supported, all ACS initiated transactions should be able to take place over a connection initiated by the CPE.
• Allow one or more ACS servers to serve a population of CPE, which may be associated with one or more service providers.
• Optimize the use of connections that are established to minimize connection overhead by allowing multiple bi-directional transactions to occur over a single connection.
+++ Architecture +++
Protocol Stack of TR069:
Security Mechanisms:
The following security mechanisms are incorporated in this protocol:
• The protocol supports the use of SSL/TLS for communications transport between CPE and ACS. This provides transaction confidentiality, data integrity, and allows certificate-based authentication between the CPE and ACS.
• The HTTP layer provides an alternative means of CPE and ACS authentication based on shared secrets. Note that the protocol does not specify how the shared secrets are learned by the CPE and ACS.
CPE Initiated Sessions/
Asynchronous ACS Initiated Sessions:
The basic mechanism defined in the CPE WAN Management Protocol to enable asynchronous ACS initiated communication assumes direct IP addressability of the CPE from the ACS. An alternative mechanism is defined in Annex G, which accommodates CPE operating behind a NAT gateway that are not directly addressable by the ACS.
+++ Procedures/Requirements +++
ACS Discovery:
1. The CPE MAY be configured locally with the URL of the ACS. For example, via TR064.
2. As part of the IP layer auto-configuration, a DHCP server on the access network MAY be configured to include the ACS URL as a DHCP option.
3. The CPE MAY have a default ACS URL that it MAY use if no other URL is provided to it.
Connection Establishment:
1. The CPE MAY at any time initiate a connection to the ACS using the pre-determined ACS address. A CPE MUST establish a connection to the ACS and issue the Inform RPC method
under some specific conditions (see TR069).
2. The ACS MAY at any time request that the CPE initiate a connection to the ACS using the Connection Request mechanism. Support for this mechanism is REQUIRED in a CPE, and is RECOMMENDED in an ACS.
(This mechanism relies on the ACS having had at least one prior communication with the CPE via a CPE initiatedinteraction. During this interaction, if the ACS wishes to allow future ACS-initiated transactions, it would use the value of the "ManagementServer.ConnectionRequestURL" Parameter. If the URL used for management access changes, the CPE MUST notify the ACS by issuing an Inform message indicating the new management IP address, thus keeping the ACS up-to-date.)
Use of HTTP:
SOAP messages are carried between a CPE and an ACS using HTTP 1.1, where the CPE acts as the HTTP client and the ACS acts as the HTTP server.
The CPE WAN Management Protocol also uses HTTP for Connection Requests, where the ACS acts as the HTTP client and the CPE acts as the HTTP server.
Use of SOAP:
The CPE WAN Management Protocol defines SOAP 1.1 as the encoding syntax to transport the RPC method calls and responses.
Transaction Session Procedures：
+++ Signed Vouchers +++
An optional mechanism for securely enabling or disabling optional CPE capabilities.Unlike Parameters, the Voucher mechanism provides an additional layer of security for optional capabilities that require secure tracking (such as those involving payment).
A Voucher is a digitally signed data structure that instructs a CPE to enable or disable a set of Options. An Option is any optional capability of a CPE. When an Option is enabled, the Voucher can specify various characteristics that determine under what conditions that Option persists.
+++ Web Identity Management +++
To support web-based applications or other CPE-related web pages on a back-end web site for access from a browser within the CPE’s local network, the CPE WAN Management Protocol provides an optional mechanism that allows such web sites to customize their content with explicit knowledge of the customer associated with that CPE. That is, the location of users browsing from inside the CPE’s LAN can be automatically identified without any manual login process.
The protocol defines a set of optional interfaces that allow the web site to initiate communication between the CPE and ACS, which allows a web site in communication with that ACS to identify which CPE the user is operating behind. This allows the web site to customize its content to be specific to the associated broadband account, the particular type of CPE, or any other characteristic that is known to the ACS.
Note—this identification mechanism does not distinguish among different users on the same network behind a single CPE. In situations where identification of a specific user is required, a separate identity management mechanism, such as manual login, would be needed.
The CPE WAN Management Protocol defines an optional Kicked RPC method in Annex A, which can be used to support web identity management functionality.
+++ Signed Package Format +++
A signed package format that MAY used to securely download files into a recipient device.The format allows one or more files to be encapsulated within a single signed package. The package format allows the recipient to authenticate the source, and contains instructions for the
recipient to extract and install the contents.
+++ Device-Gateway Association +++
The CPE WAN Management Protocol can be used to remotely manage CPE Devices that are connected via a LAN through a Gateway. When an ACS manages both a Device and the Gateway through which the Device is connected, it can be useful for the ACS to be able to determine the identity of that particular Gateway.
The procedures defined in this Annex allow an ACS to determine the identity of the Gateway through which a given Device is connected.
The specific scenario that the defined mechanism is intended to accommodate is where both the Gateway and Device are managed via the CPE WAN Management Protocol, and both are managed by the same ACS (or by distinct ACSs that are appropriately coupled).
The defined mechanism relies on the Device’s use of DHCP.
+++ Connection Request via NAT Gateway +++
RFC3489 - STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) http://www.ietf.org/rfc/rfc3489.txt?number=3489 To accommodate the ability for an ACS to issue the equivalent of a Connection Request to CPE allocated a private address through a NAT Gateway that might not be CPE WAN Management Protocol capable, the following is required:
//
* A summary about TR069 during my projects
*/
TR69是由DSL论坛定义的用户终端广域网管理协议。
最新的TR069标准：
TR-069 Amendment2
http://www.dslforum.org/techwork/tr/TR-069Amendment2.pdf
与TR069相关的几个技术报告：
TR098 - Internet Gateway Device Data Model for TR-069 (used for QoS)
http://www.dslforum.org/techwork/tr/TR-098%20Amendment%201.pdf
TR104 - DSLHomeTM Provisioning Parameters for VoIP CPE
http://www.dslforum.org/techwork/tr/TR-104.pdf
TR106 - Data Model Template for TR-069 Enabled Devices
http://www.dslforum.org/techwork/tr/TR-106%20Amendment%201.pdf
TR140 - TR-069 Data Model for Storage Service Enabled Devices
http://www.dslforum.org/techwork/tr/TR-140.pdf
TR111 - DSLHomeTMApplying TR-069 to Remote Management of Home Networking Devices
http://www.dslforum.org/techwork/tr/TR-111.pdf
DSL论坛定义的其他技术报告：
http://www.dslforum.org/trlist/trlist.php
+++ Introduction +++
A protocol for communication between a CPE and Auto-Configuration Server (ACS) that encompasses secure auto-configuration as well as other CPE management functions within a common framework.
TR069的主要功能:
- Auto-configuration and dynamic service provisioning
- Software/firmware image management
- Status and performance monitoring
- Diagnostics
The position of TR069 in the Auto-Configuration Architecture:
The position of TR069 in the End-to-End Architecture:
TR069 Family:
Connectivity model of TR069:
• Allow both CPE and ACS initiated connection establishment, avoiding the need for a persistent connection to be maintained between each CPE and an ACS.
• The functional interactions between the ACS and CPE should be independent of which end initiated the establishment of the connection. In particular, even where ACS initiated connectivity is not supported, all ACS initiated transactions should be able to take place over a connection initiated by the CPE.
• Allow one or more ACS servers to serve a population of CPE, which may be associated with one or more service providers.
• Optimize the use of connections that are established to minimize connection overhead by allowing multiple bi-directional transactions to occur over a single connection.
+++ Architecture +++
Protocol Stack of TR069:
Security Mechanisms:
The following security mechanisms are incorporated in this protocol:
• The protocol supports the use of SSL/TLS for communications transport between CPE and ACS. This provides transaction confidentiality, data integrity, and allows certificate-based authentication between the CPE and ACS.
• The HTTP layer provides an alternative means of CPE and ACS authentication based on shared secrets. Note that the protocol does not specify how the shared secrets are learned by the CPE and ACS.
CPE Initiated Sessions/
Asynchronous ACS Initiated Sessions:
The basic mechanism defined in the CPE WAN Management Protocol to enable asynchronous ACS initiated communication assumes direct IP addressability of the CPE from the ACS. An alternative mechanism is defined in Annex G, which accommodates CPE operating behind a NAT gateway that are not directly addressable by the ACS.
+++ Procedures/Requirements +++
ACS Discovery:
1. The CPE MAY be configured locally with the URL of the ACS. For example, via TR064.
2. As part of the IP layer auto-configuration, a DHCP server on the access network MAY be configured to include the ACS URL as a DHCP option.
3. The CPE MAY have a default ACS URL that it MAY use if no other URL is provided to it.
Connection Establishment:
1. The CPE MAY at any time initiate a connection to the ACS using the pre-determined ACS address. A CPE MUST establish a connection to the ACS and issue the Inform RPC method
under some specific conditions (see TR069).
2. The ACS MAY at any time request that the CPE initiate a connection to the ACS using the Connection Request mechanism. Support for this mechanism is REQUIRED in a CPE, and is RECOMMENDED in an ACS.
(This mechanism relies on the ACS having had at least one prior communication with the CPE via a CPE initiatedinteraction. During this interaction, if the ACS wishes to allow future ACS-initiated transactions, it would use the value of the "ManagementServer.ConnectionRequestURL" Parameter. If the URL used for management access changes, the CPE MUST notify the ACS by issuing an Inform message indicating the new management IP address, thus keeping the ACS up-to-date.)
Use of HTTP:
SOAP messages are carried between a CPE and an ACS using HTTP 1.1, where the CPE acts as the HTTP client and the ACS acts as the HTTP server.
The CPE WAN Management Protocol also uses HTTP for Connection Requests, where the ACS acts as the HTTP client and the CPE acts as the HTTP server.
Use of SOAP:
The CPE WAN Management Protocol defines SOAP 1.1 as the encoding syntax to transport the RPC method calls and responses.
Transaction Session Procedures：
+++ Signed Vouchers +++
An optional mechanism for securely enabling or disabling optional CPE capabilities.Unlike Parameters, the Voucher mechanism provides an additional layer of security for optional capabilities that require secure tracking (such as those involving payment).
A Voucher is a digitally signed data structure that instructs a CPE to enable or disable a set of Options. An Option is any optional capability of a CPE. When an Option is enabled, the Voucher can specify various characteristics that determine under what conditions that Option persists.
+++ Web Identity Management +++
To support web-based applications or other CPE-related web pages on a back-end web site for access from a browser within the CPE’s local network, the CPE WAN Management Protocol provides an optional mechanism that allows such web sites to customize their content with explicit knowledge of the customer associated with that CPE. That is, the location of users browsing from inside the CPE’s LAN can be automatically identified without any manual login process.
The protocol defines a set of optional interfaces that allow the web site to initiate communication between the CPE and ACS, which allows a web site in communication with that ACS to identify which CPE the user is operating behind. This allows the web site to customize its content to be specific to the associated broadband account, the particular type of CPE, or any other characteristic that is known to the ACS.
Note—this identification mechanism does not distinguish among different users on the same network behind a single CPE. In situations where identification of a specific user is required, a separate identity management mechanism, such as manual login, would be needed.
The CPE WAN Management Protocol defines an optional Kicked RPC method in Annex A, which can be used to support web identity management functionality.
+++ Signed Package Format +++
A signed package format that MAY used to securely download files into a recipient device.The format allows one or more files to be encapsulated within a single signed package. The package format allows the recipient to authenticate the source, and contains instructions for the
recipient to extract and install the contents.
+++ Device-Gateway Association +++
The CPE WAN Management Protocol can be used to remotely manage CPE Devices that are connected via a LAN through a Gateway. When an ACS manages both a Device and the Gateway through which the Device is connected, it can be useful for the ACS to be able to determine the identity of that particular Gateway.
The procedures defined in this Annex allow an ACS to determine the identity of the Gateway through which a given Device is connected.
The specific scenario that the defined mechanism is intended to accommodate is where both the Gateway and Device are managed via the CPE WAN Management Protocol, and both are managed by the same ACS (or by distinct ACSs that are appropriately coupled).
The defined mechanism relies on the Device’s use of DHCP.
+++ Connection Request via NAT Gateway +++
RFC3489 - STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) http://www.ietf.org/rfc/rfc3489.txt?number=3489 To accommodate the ability for an ACS to issue the equivalent of a Connection Request to CPE allocated a private address through a NAT Gateway that might not be CPE WAN Management Protocol capable, the following is required:
- The CPE MUST be able to discover that its connection to the ACS is via a NAT Gateway that has allocated a private IP address to the CPE.
- The CPE MUST be able to maintain an open NAT binding through which the ACS can send unsolicited packets.
- The CPE MUST be able to determine the public IP address and port associated with the open NATbinding, and communicate this information to the ACS.
//
订阅：
博文 (Atom)
博文
