Broadband Access Center Architecture
This chapter describes the system architecture implemented in this Cisco Broadband Access Center (BAC) release.
This chapter describes:
Cisco BAC provisions devices based on the TR-069, TR-098, TR-104, and TR-106 standards. This includes Ethernet and ADSL gateway devices, wireless gateways, VoIP ATAs, and other devices compliant with the CPE WAN Management Protocol (CWMP).
Figure 2-1 represents a typical, fully redundant, CWMP deployment in a Cisco BAC network.
Figure 2-1 CWMP Deployment in BAC
This section describes the basic Cisco BAC architecture including:
•Regional Distribution Unit (RDU) that provides:
–The authoritative data store of the BAC system.
–Support for processing application programming interface (API) requests.
–Monitoring of the system's overall status and health.
See Regional Distribution Unit, for additional information.
•Device Provisioning Engines (DPEs) that provide:
–Interface with customer premises equipment (CPE).
–Configuration and firmware policy instructions cache.
–Autonomous operation from the RDU and other DPEs.
–CPE WAN Management Protocol (CWMP) service.
–IOS-like command line interface (CLI) for configuration.
–Hypertext Transfer Protocol (HTTP) file service.
See Device Provisioning Engines, for additional information.
•Client API that provides total client control over the system's capabilities.
•Provisioning Groups that provide:
–Logical grouping of DPE servers in a redundant cluster.
–Redundancy and scalability
See Provisioning Groups, for additional information.
•The Cisco BAC process watchdog that provides:
–Administrative monitoring of all critical Cisco BAC processes.
–Automated process restart capability.
–Ability to start and stop Cisco BAC component processes.
See BAC Process Watchdog, for additional information.
•An administrator user interface that provides:
–Support for adding, deleting, and modifying CWMP devices; searching for devices, retrieving device details, and executing device operations.
–Support for configuring global defaults and defining custom properties.
–Ability to view additional performance statistics.
–Management of firmware rules and configuration templates.
See Administrator User Interface, page 9-3, for additional information.
•An SNMP agent that supports:
–Third-party management systems.
–SNMP version v2.
See SNMP Agent, for additional information.
Regional Distribution Unit
The Regional Distribution Unit (RDU) is the primary server in the Cisco BAC provisioning system. It is installed on a server running the Solaris 10 operating system.
The functions of the RDU include:
•Managing preprovisioned and discovered data from devices.
•Generating instructions for DPEs and distributing them to DPE servers for caching.
•Cooperating with DPEs to keep them up to date.
•Processing API requests for all Cisco BAC functions.
•Managing the Cisco BAC system.
The RDU supports the addition of new technologies and services through an extensible architecture.
Cisco BAC currently supports one RDU per installation. Use of clustering software from Veritas or Sun is recommended for providing RDU failover. Use of RAID (Redundant Array of Independent Disks) shared storage is recommended in such a setup.
Device Provisioning Engines
The Device Provisioning Engine (DPE) communicates with the CPE on behalf of the RDU to perform provisioning or management functions.
The RDU generates instructions that the DPE must perform on the device. These instructions are distributed to the relevant DPE servers, where they are cached. These instructions are then used during interactions with the CPE to perform tasks, such as configuration of devices, firmware upgrades, and data retrieval.
Each DPE caches information for up to 500,000 devices, and multiple DPEs can be used to ensure redundancy and scalability.
The DPE manages these activities:
•Synchronization with RDU to retrieve the latest set of instructions for caching.
•Communication with CPE using HTTP and HTTPS for file download service.
•Authentication and encryption of communication with CPE.
The DPE is installed on a server that is running the Solaris 10 operating system. The DPE is configured and managed by using the CLI, which you can access locally or remotely via Telnet. See the Cisco Broadband Access Center DPE CLI Reference, Release 3.5, 3.5.1, 3.5.2, for specific information on the CLI commands that a DPE supports.
See these sections for other important information:
•DPE-RDU Synchronization, page 18-3
Also, familiarize yourself with the concept of instruction generation, which is described in Instruction Generation and Processing, page 4-5.
Licensing controls the number of DPEs (nodes) that you can use. If you attempt to install more DPEs than you are licensed to have, those new DPEs will not be able to register with the RDU, and will be rejected. Existing licensed DPEs remain online.
Note For licensing purposes, a registered DPE is considered to be one node.
Whenever you change licenses, by adding a license, extending an evaluation license, or through the expiration of an evaluation license, the changes take immediate effect.
When you delete a registered DPE from the RDU database, a license is freed. Since the DPEs automatically register with the RDU, you must take the DPE offline if the intention is to free up the license. Then, delete the DPE from the RDU database by using the RDU administrator user interface.
Note The functions enabled via a specific license continue to operate even when the corresponding license is deleted from the system.
DPEs that are rejected during registration because of licensing constraints, do not appear in the administrator user interface. To determine the license state, you need to examine the log files of the RDU and the DPE.
A provisioning group is designed to be a logical (typically geographic) grouping of servers that usually consist of one or more DPEs. Each DPE in a given provisioning group caches identical sets of instructions from the RDU; thus enabling redundancy and load balancing. A single provisioning group can handle the provisioning needs of up to 500,000 devices. As the number of devices grows past 500,000, you can add additional provisioning groups to the deployment.
Note The servers for a provisioning group are not required to reside at a regional location, they can just as easily be deployed in the central network operations center.
For more information, refer to:
•Discovery of ACS URL
•Provisioning Group Scalability
Discovery of ACS URL
In the distributed architecture that Cisco BAC provides, the RDU is the centralized aggregation point that never directly interacts with a CPE. Any required interactions with the CPE are delegated to the provisioning group. Each device identifies the provisioning group to which it connects by the URL of a single autoconfiguration server (ACS); in other words, the DPE. Until the URL is updated, the device contacts the DPE at the same URL.
All redundant DPEs in a given provisioning group must share a single ACS URL. The RDU has to be aware of the URL that is associated with each provisioning group and, by extension, of all DPEs in that provisioning group. The RDU uses its knowledge of the provisioning group's ACS URL to redirect devices to a new provisioning group, when required.
The RDU automatically learns the provisioning group's ACS URL from DPE registrations, or the ACS URL is configured on the provisioning group object via the API or the administrator user interface. For information on configuring the ACS URL, see Provisioning Group Configuration Workflow, page 3-7.
The CPE can determine the ACS (DPE) URL in one of two ways:
•By preconfiguring the URL on the device. This ACS URL is the configured URL of the Cisco BAC server that is associated with each provisioning group. The URL is preconfigured on the device before it is shipped to the customer, and is also known as the assigned URL.
•By discovering the URL via DHCP. This ACS URL is returned in response to a DHCP Discover, a DHCP Request, or a DHCP Inform. This mechanism is limited to deployments of primary Internet gateway devices, because it requires the ability to make DHCP requests to the WAN side.
Note Assigning a URL via preconfiguration is a more secure mechanism than one discovered via DHCP.
Provisioning Group Scalability
Provisioning groups enhance the scalability of the Cisco BAC network by making each provisioning group responsible for only a subset of devices. This partitioning of devices can be along regional groupings or any other policy that the service provider defines. When the size of the provisioning group is restricted, the DPEs can be more effective in caching the necessary information.
To scale a deployment, the service provider can:
•Upgrade existing DPE server hardware.
•Add DPE servers to a provisioning group.
•Add provisioning groups.
BAC Process Watchdog
The Cisco BAC process watchdog is an administrative agent that monitors the runtime health of all Cisco BAC processes. This watchdog process ensures that if a process stops unexpectedly, it is automatically restarted.
The Cisco BAC process watchdog can be used as a command line tool to start, stop, restart, and determine the status of any monitored processes.
If a monitored application fails, it is restarted automatically. If, for any reason, the restart process also fails, the Cisco BAC watchdog process server will wait a prescribed amount of time before attempting to restart again.
See BAC Process Watchdog, page 9-1, for additional information on how to manage the monitored processes.
Cisco BAC provides basic SNMP v2-based monitoring of the RDU and the DPE servers. The Cisco BAC SNMP agents support SNMP informs and traps. You can configure the SNMP agent on the DPE by using snmp-server CLI commands, and on the RDU by using the SNMP configuration command-line tool.
See Monitoring Servers by Using SNMP, page 11-4, for additional information on the SNMP configuration command line tool, and the Cisco Broadband Access Center DPE CLI Reference, Release 3.5, 3.5.1, 3.5.2, for additional information on the DPE CLI.
Logging of events is performed at the DPE and the RDU, and in some unique situations, DPE events are additionally logged at the RDU to give them higher visibility. Log files are located in their own log directories and can be examined by using any text processor. You can compress the files for easier e-mailing to the Cisco Technical Assistance Center or system integrators for troubleshooting and fault resolution. You can also access the RDU and the DPE logs from the administrator user interface.
For detailed information on log levels and structures, and how log files are numbered and rotated, see Logging, page 20-2.