TR-069 Amendment 2: CPE WAN Management Protocol

需积分: 33 116 浏览量更新于2024-07-24 1 收藏 1.48MB PDF 举报

"TR-069 Amendment 2 - CPE WAN Management Protocol v1.1" TR-069 Amendment 2 是针对TR-069（Customer Premises Equipment - Wide Area Network Management Protocol，即客户驻地设备广域网管理协议）的更新版本，主要面向TR-069的开发人员，旨在提升和扩展TR-069协议的功能和性能。这个技术报告由DSL论坛（DSLForum）在2007年12月发布，是TR-069协议的v1.1版的第二个修正案。 TR-069是一种基于HTTP/HTTPS的安全协议，最初设计用于远程管理和配置宽带网络设备，如DSL调制解调器、路由器、VoIP电话等CPE（Customer Premises Equipment）。它的主要目标是简化和服务提供商自动化家庭和小型企业网络设备的部署、配置、故障诊断和更新过程。在Amendment 2中，可能包括了以下关键知识点： 1. **增强安全特性**：随着网络安全威胁的增加，TR-069 Amendment 2可能会强化身份验证、加密和安全传输机制，以确保CPE设备与管理服务器之间的通信更加安全。 2. **新功能和API**：可能引入新的管理接口或API，允许更复杂的设备配置和监控，例如支持新的服务如IPTV、VoIP和智能家居设备的集成。 3. **性能优化**：可能改进了协议的效率，减少了延迟和带宽使用，提高了大规模设备管理的性能。 4. **故障检测和恢复**：可能增强了故障检测和自动恢复机制，使得服务提供商可以更快地识别并解决用户设备的问题。 5. **扩展设备支持**：随着物联网（IoT）设备的普及，TR-069 Amendment 2可能增加了对更多类型CPE设备的支持，包括智能家电、安全系统等。 6. **数据模型和XML定义**：可能更新了数据模型，以适应新型服务和设备的需求，同时也可能优化了XML配置文件的结构和语法。 7. **服务质量（QoS）管理**：改进了QoS策略的实施，以确保关键应用的流量优先级和带宽保证。 8. **软件升级和远程维护**：可能会加强软件升级过程的自动化和可靠性，简化远程固件更新，同时提高用户体验。 9. **隐私保护**：考虑到用户隐私日益重要的问题，Amendment 2可能包含了更严格的隐私保护措施，限制不必要的数据收集和传输。 TR-069 Amendment 2是DSLForum成员对原始协议的持续改进，旨在提供更高效、安全和全面的CPE设备管理解决方案，以满足不断变化的网络环境和用户需求。对于TR-069的开发人员来说，理解和掌握这一修正案的内容至关重要，以便能够开发出符合最新标准的产品和服务。

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页未读，继续阅读

菲娜Feena

粉丝: 0
资源: 1

TR-069 Amendment 2: CPE WAN Management Protocol

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

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

TR-069Amendment2

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

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

BroadbandForum TR-069 Amendment 5: CPE WAN Management Protocol

TR-181_Issue-2_Amendment-2：TR-069设备数据模型

tr-069 amendment 5

802.1qav pdf

IEEE 802.11n标准名称

最新资源