*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
没有评论:
发表评论