TR-069 Amendment 2：下一代家庭网络设备集中管理协议升级

需积分: 48 86 浏览量更新于2024-08-02 收藏 1.48MB PDF 举报

TR-069 Amendment 2 是DSL论坛制定的一份技术规范，它扩展了原版TR-069——CPE广域网管理协议（CPE WAN Management Protocol）的版本1.1，旨在提供一个通用的协议框架，以便于网络服务提供商（Network Service Provider, NSP）对家庭网络设备，如网关、路由器和机顶盒等进行远程、集中式的管理。这个修订版发布于2007年12月，标志着对原协议进行了重要更新和增强。 TR-069最初版本的设计目标是简化家庭网络设备的管理，通过统一的标准接口，使得NSP能够有效地控制和优化用户端设备的行为，包括软件升级、故障检测、性能监控以及设置调整等。随着网络技术的发展和智能家居的普及，TR-069 Amendment 2考虑到了更多新功能和扩展性，可能包括对物联网设备的支持，更强大的安全措施，以及对服务质量（Quality of Service, QoS）的精细化管理。在TR-069 Amendment 2中，值得注意的是，它遵循DSL论坛的非约束性原则，即这份技术报告不是强制性的，而是由论坛成员共同讨论和批准的结果。这意味着尽管它为业界提供了一种推荐的最佳实践，但各个制造商和开发者可以根据自己的需求和产品特性对其进行定制。此外，为了尊重知识产权，DSL论坛鼓励但不强制要求声明文档中涉及的任何专有技术，会员公司可以在www.dslforum.org找到相关声明列表。关于使用和分发，TR-069 Technical Reports如Amendment 2要求完整复制并保留版权通知，且禁止任何形式的篡改或无授权的再分发。这确保了标准的公正性和一致性，同时保护了各方的权益。 TR-069 Amendment 2是IT行业中用于家庭网络设备管理的关键标准，它提升了设备的可管理性，促进了网络服务的高效部署和维护，是现代家庭网络架构不可或缺的一部分。对于任何从事网络设备开发或服务提供的人来说，理解和掌握这一规范是非常重要的，因为它直接影响到设备与服务提供商之间的通信效率以及用户体验。

CPE WAN Management Protocol v1.1 TR-069 Issue 1 Amendment 2

December 2007

• If the CPE is unable to contact the ACS and the CPE originally (the first successful time after the

most recent factory default) obtained its ACS URL through DHCP.

This behavior enables the CPE to go back to the use of DHCP for finding the ACS if an ACS URL had

not been pre-configured in the CPE. For example, this can handle the situation of setting an incorrect

ACS URL on the CPE. This behavior is not meant as an ACS failover mechanism.

The CPE MUST remember the mechanism it used to locate the ACS the first time it successfully

contacted it. If the CPE did not use DHCP to discover the ACS URL, then it SHOULD NOT fall back

to using DHCP for ACS discovery. If the CPE originally used DHCP for ACS discovery, then when it

fails to contact the ACS, it MUST perform re-discovery via DHCP. The last requirement holds even if

the ACS URL has been subsequently set through a non-DHCP mechanism.

Table 2 – Encapsulated Vendor Specific Options

Encapsulated

Option

Encapsulated Vendor-

Specific Option number

Parameter

URL of the ACS 1 ...ManagementServer.URL

Provisioning code 2 ...DeviceInfo.ProvisioningCode

The specified URL MUST be an absolute URL. Both the URL and ProvisioningCode MUST NOT be

null terminated. If the CPE receives a URL or ProvisioningCode value that is null terminated, the CPE

MUST accept the value provided, and MUST NOT interpret the null character as part of the URL or

ProvisioningCode value.

3. The CPE MAY have a default ACS URL that it MAY use if no other URL is provided to it.

The ACS URL MUST be in the form of a valid HTTP or HTTPS URL [5]. Use of an HTTPS URL

indicates that the CPE MUST establish an SSL or TLS connection to the ACS.

Once the CPE has established a connection to the ACS, the ACS MAY at any time modify the ACS address

Parameter stored within the CPE (...ManagementServer.URL, as defined in [13]). Once modified, the CPE

MUST use the modified address for all subsequent connections to the ACS.

The “host” portion of the ACS URL is used by the CPE for validating the certificate from the ACS when

using certificate-based authentication. Because this relies on the accuracy of the ACS URL, the overall

security of this protocol is dependent on the security of the ACS URL.

The CPE SHOULD restrict the ability to locally configure the ACS URL to mechanisms that require strict

security. The CPE MAY further restrict the ability to locally set the ACS URL to initial setup only,

preventing further local configuration once the initial connection to an ACS has successfully been

established such that only its existing ACS is permitted subsequently to change this URL.

The use of DHCP for configuration of the ACS URL SHOULD be limited to situations in which the

security of the link between the DHCP server and the CPE can be assured by the service provider. Since

DHCP does not itself incorporate a security mechanism, other means of ensuring this security SHOULD be

provided.

The ACS URL MAY contain a DNS hostname or an IP address. When resolving the ACS hostname, the

DNS server might return multiple IP addresses. In this case, the CPE SHOULD randomly choose an IP

address from the list. When the CPE is unable to reach the ACS, it SHOULD randomly select a different

IP address from the list and attempt to contact the ACS at the new IP address. This behavior ensures that

CPEs will balance their requests between different ACSs if multiple IP addresses represent different ACSs.

The CPE MUST NOT cache the DNS server response beyond the duration of time to live (TTL) returned

by DNS server unless it cannot contact the DNS server for an update. This behavior is required by DNS

RFC 1034 and provides an opportunity for the DNS server to update stale data.

As defined in [13].

CPE WAN Management Protocol v1.1 TR-069 Issue 1 Amendment 2

December 2007

It is further RECOMMENDED that the CPE implements affinity to a particular ACS IP address. Affinity

to a given IP address means that the CPE will attempt to use the same IP address for as along as it can

contact the ACS at this address. This creates a more stable system and can allow the ACS to perform

better due to better caching. To implement the affinity the CPE SHOULD store to persistent storage the

last successfully used IP address and the list of IP addresses from which it was selected. The CPE

SHOULD continue to perform DNS queries as normal, but SHOULD continue using the same IP address

for as long as it can contact the ACS and for as long as the list of IP addresses returned by the DNS does

not change. The CPE SHOULD select a new IP address whenever the list of IP addresses changes or when

it cannot contact the ACS. This provides an opportunity for service providers to reconfigure their network.

Port 7547 has been assigned by IANA for the CPE WAN Management Protocol (see [17]), and the ACS

MAY use this port in its URL.

3.2 Connection Establishment

3.2.1 CPE Connection Initiation

The CPE MAY at any time initiate a connection to the ACS using the pre-determined ACS address (see

section 3.1). A CPE MUST establish a connection to the ACS and issue the Inform RPC method

(following the procedures described in section 3.7) under the following conditions:

• The first time the CPE establishes a connection to the access network on initial installation

• On power-up or reset

• Once every PeriodicInformInterval (for example, every 24-hours)

• When so instructed by the optional ScheduleInform method

• Whenever the CPE receives a valid Connection Request from an ACS (see section 3.2.2)

• Whenever the URL of the ACS changes

• Whenever a parameter is modified that is required to initiate an Inform on change.

• Whenever the value of a parameter that the ACS has marked for “active notification” via the

SetParameterAttributes method is modified by an external cause (a cause other than the ACS

itself). Parameter changes made by the ACS itself via SetParameterValues MUST NOT cause a

new session to be initiated. If a parameter is modified more than once before the CPE is able to

initiate a session to perform the notification, the CPE MUST perform only one notification.

If a parameter is modified by an external cause while a session is in progress, the change causes a

new session to be established after the current session is terminated (it MUST NOT affect the

current session).

In order to avoid excessive traffic to the ACS, a CPE MAY place a locally specified limit on the

frequency of parameter change notifications. This limit SHOULD be defined so that it is

exceeded only in unusual circumstances. If this limit is exceeded, the CPE MAY delay by a

locally specified amount initiation of a session to notify the ACS. After this delay, the CPE

MUST initiate a session to the ACS and indicate all relevant parameter changes (those parameters

that have been marked for notification) that have occurred since the last such notification.

• Whenever a download or upload completes (either successfully or unsuccessfully), provided that

CPE policy indicates that the ACS needs to be notified of the download or upload completion.

The ACS MUST always be notified of the completion of downloads or uploads that were

specifically requested by the ACS.

CPE policy MUST determine whether to notify the ACS of the completion of downloads or

uploads that were not specifically requested by the ACS.

CPE WAN Management Protocol v1.1 TR-069 Issue 1 Amendment 2

December 2007

Note – this CPE policy is expected to be remotely configurable. For example, the CPE might be

configured to notify the ACS only if a download or upload (not specifically requested by the ACS)

was of management-related content.

• Whenever an unsuccessfully terminated session is retried according to the session retry policy

specified in section 3.2.1.1.

The CPE MUST NOT maintain an open connection to the ACS when no more outstanding messages exist

on the CPE or ACS. Refer to section 3.7.1.4 for details of CPE session termination criteria.

3.2.1.1 Session Retry Policy

A CPE MUST retry failed sessions to attempt to redeliver events that it has previously failed to deliver and

to allow the ACS to make additional requests in a timely fashion. Section 3.7.1.5 details the rules for

successful event delivery, for retrying event delivery, and for discarding events after failing to deliver them.

The CPE MUST keep track of the number of times it has attempted to retry a failed session.

If the CPE fails to establish a session, this might be because the CPE supports CPE WAN Management

Protocol v1.1 (or later) and the ACS supports only v1.0. If this situation is suspected (see section 3.7.2.1),

the CPE MUST revert to v1.0 when retrying the failed session.

A CPE MUST retry a failed session after waiting for an interval of time specified in Table 3 or when a new

event occurs, whichever comes first. The CPE MUST choose the wait interval by randomly selecting a

number of seconds from a range given by the post-reboot session retry count. When retrying a failed

session after an intervening reboot, the CPE MUST reset the wait intervals it chooses from as though it

were making its first session retry attempt. In other words, if a session is retried when a new event other

than BOOT occurs, it does not reset the wait interval, although the continued occurrence of new events

might cause sessions to be initiated more frequently than shown in the table. Regardless of the reason a

previous session failed or the condition prompting session retry, the CPE MUST communicate to the ACS

the session retry count.

Beginning with the tenth post-reboot session retry attempt, the CPE MUST choose from a range between

2560 and 5120 seconds. The CPE MUST continue to retry a failed session until it is successfully

terminated. Once a session terminates successfully, the CPE MUST reset the session retry count to zero and

no longer apply session retry policy to determine when to initiate the next session.

Table 3 – Session Retry Wait Intervals

Post reboot session

retry count

Wait interval range (min-max seconds)

#1 5-10

#2 10-20

#3 20-40

#4 40-80

#5 80-160

#6 160-320

#7 320-640

#8 640-1280

#9 1280-2560

#10 and subsequent 2560-5120

3.2.2 ACS Connection Initiation

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.

CPE WAN Management Protocol v1.1 TR-069 Issue 1 Amendment 2

December 2007

This mechanism relies on the CPE having an IP address that is routable from the ACS. If the CPE is

behind a firewall or NAT device lying between the ACS and CPE, the ACS might not be able to access the

CPE at all. Annex G defines a mechanism that allows an ACS to contact a CPE connected via a NAT

device.

The Connection Request mechanism is defined as follows:

• The Connection Request MUST use an HTTP 1.1 GET to a specific URL designated by the CPE. The

URL value is available as read-only Parameter on the CPE. The path of this URL value SHOULD be

randomly generated by the CPE so that it is unique per CPE.

• The Connection Request MUST make use of HTTP, not HTTPS. The associated URL MUST be an

HTTP URL.

• No data is conveyed in the Connection Request HTTP GET. Any data that might be contained

SHOULD be ignored by the CPE.

• The CPE MUST use digest-authentication to authenticate the ACS before proceeding—the CPE

MUST NOT initiate a connection to the ACS due to an unsuccessfully authenticated request.

• The CPE MUST accept Connection Requests from any source that has the correct authentication

parameters for the target CPE.

• The CPE’s response to a successfully authenticated Connection Request MUST use either a “200

(OK)” or a “204 (No Content)” HTTP status code. The CPE MUST send this response immediately

upon successful authentication, prior to it initiating the resulting session. The length of the message-

body in the HTTP response MUST be zero.

• The CPE SHOULD restrict the number of Connection Requests it accepts during a given period of

time in order to further reduce the possibility of a denial of service attack. If the CPE chooses to reject

a Connection Request for this reason, the CPE MUST respond to that Connection Request with an

HTTP 503 status code (Service Unavailable). In this case, the CPE SHOULD NOT include the HTTP

Retry-After header in the response.

• If the CPE successfully authenticates and responds to a Connection Request as described above, and if

it is not already in a session, then it MUST, within 30 seconds of sending the response, attempt to

establish a session with the pre-determined ACS address (see section 3.1) in which it includes the

“6 CONNECTION REQUEST” EventCode in the Inform.

Note – in practice there might be exceptional circumstances that would cause a CPE to fail to

meet this requirement on rare occasions.

• If the ACS receives a successful response to a Connection Request but after at least 30 seconds the

CPE has not successfully established a session that includes the “6 CONNECTION REQUEST”

EventCode in the Inform, the ACS MAY retry the Connection Request to that CPE.

• If, once the CPE successfully authenticates and responds to a Connection Request, but before it

establishes a session to the ACS, it receives one or more successfully authenticated Connection

Requests, the CPE MUST return a successful response for each of those Connection Requests, but

MUST NOT initiate any additional sessions as a result of these additional Connection Requests,

regardless of how many it receives during this time.

• If the CPE is already in a session with the ACS when it receives one or more Connection Requests, it

MUST NOT terminate that session prematurely as a result. The CPE MUST instead take one of the

following alternative actions:

• Reject each Connection Request by responding with an HTTP 503 status code (Service

Unavailable). In this case, the CPE SHOULD NOT include the HTTP Retry-After header in the

response.

•

Following the completion of the session, initiate exactly one new session (regardless of how many

Connection Requests had been received during the previous session) in which it includes the

CPE WAN Management Protocol v1.1 TR-069 Issue 1 Amendment 2

December 2007

“6 CONNECTION REQUEST” EventCode in the Inform. In this case, the CPE MUST initiate

the session immediately after the existing session is complete and all changes from that session

have been applied.

This requirement holds for Connection Requests received any time during the interval that the CPE

considers itself in a session, including the period in which the CPE is in the process of establishing the

session.

• The CPE MUST NOT reject a properly authenticated Connection Request for any reason other than

those described above. If the CPE rejects a Connection Request for any of the reasons described

above, it MUST NOT initiate a session with the ACS as a result of that Connection Request.

This mechanism relies on the ACS having had at least one prior communication with the CPE via a CPE-

initiated interaction. During this interaction, if the ACS wishes to allow future ACS-initiated transactions,

it would use the value of the ...ManagementServer.ConnectionRequestURL Parameter (see [13]). 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 (see [13]), thus keeping the ACS up-to-date.

Port 7547 has been assigned by IANA for the CPE WAN Management Protocol (see [17]), and the CPE

MAY use this port in the Connection Request URL.

3.3 Use of SSL/TLS and TCP

The use of SSL/TLS to transport the CPE WAN Management Protocol is RECOMMENDED, although the

protocol MAY be used directly over a TCP connection instead. If SSL/TLS is not used, some aspects of

security are sacrificed. Specifically, SSL/TLS provides confidentiality and data integrity, and allows

certificate-based authentication in lieu of shared secret-based authentication.

Certain restrictions on the use of SSL/TLS and TCP are defined as follows:

• The CPE MUST support SSL 3.0 [10], TLS 1.0 [11] or both.

• If CPE supports both, it SHOULD communicate both capabilities to the ACS as specified in Appendix

E of RFC 2246, allowing the ACS to choose the protocol.

• If the ACS URL has been specified as an HTTPS URL, the CPE MUST establish connections to the

ACS using SSL / TLS.

• The CPE MUST support the following SSL / TLS cipher suites:

• RSA_WITH_3DES_EDE_CBC_SHA

• RSA_WITH_RC4_128_SHA

• A CPE MUST be able to initiate outgoing connections to the ACS.

• An ACS MUST be able to accept CPE-initiated connections.

• If SSL/TLS is used, the CPE MUST authenticate the ACS using the ACS-provided certificate.

Authentication of the ACS requires that the CPE MUST validate the certificate against a root

certificate, and that the CPE MUST ensure that the value of the CN (Common Name) component of

the Subject field in the certificate exactly matches the host portion of the ACS URL known to the CPE

(even if the host portion of the ACS URL is an IP address). This MUST be a direct string comparison

between the CN and the host portion of the ACS URL. If either of these is in the form of a hostname

(rather than an IP address), this comparison MUST NOT involve the IP address that the hostname

resolves to.

To validate against a root certificate, the CPE MUST contain one or more trusted root certificates that

are either pre-loaded in the CPE or provided to the CPE by a secure means outside the scope of this

specification.

剩余137页未读，继续阅读

ozkorea

粉丝: 0
资源: 1

TR-069 Amendment 2：下一代家庭网络设备集中管理协议升级

TR-069_Amendment-2.zip_specification_tr-069 amendment 2

tr-069Amendment2及schema file

TR-069Amendment2

TR-069 Amendment 2: CPE WAN Management Protocol

TR-069 Amendment2: CPE WAN管理协议详解

TR-069_Amendment-3.zip_TR-069_Amendment-3_tr_tr 069_tr-069

TR-069 Amendment 3

tr-069 amendment 5

TR-069_Amendment-2.rar_cpe_tr-069_tr069_tr069.zip

TR-069 Amendment-2: CPE WAN管理协议v1.1

最新资源