Broadband Access Center Architecture

Table Of Contents

Broadband Access Center Architecture

BAC Deployment

Architecture

Regional Distribution Unit

Device Provisioning Engines

Provisioning Groups

BAC Process Watchdog

SNMP Agent

Logging

Broadband Access Center Architecture

This chapter describes the system architecture implemented in this Broadband Access Center (BAC) release.

This chapter describes:

• BAC Deployment

• Architecture

BAC Deployment

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 BAC network.

Figure 2-1 CWMP Deployment in BAC

Architecture

This section describes the basic 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 BAC process watchdog that provides:

–Administrative monitoring of all critical BAC processes.

–Automated process restart capability.

–Ability to start and stop 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.

–SNMP Notification.

See SNMP Agent, for additional information.

Regional Distribution Unit

The Regional Distribution Unit (RDU) is the primary server in the BAC provisioning system. It is installed on a server running the Solaris 9 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 BAC functions.

•Managing the BAC system.

The RDU supports the addition of new technologies and services through an extensible architecture.

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 CPE on behalf of the RDU to perform any provisioning or management functions.

The RDU generates instructions for the DPE that dictate the actions that the DPE must carry out on the device. These instructions are distributed to the relevant DPE servers, where they are cached. The instructions are then used during interactions with CPE to accomplish 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 CWMP and HTTP for file download service.

•Authentication and encryption of communication with CPE.

The DPE is installed on a server that is running the Solaris 9 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.0, for specific information on the CLI commands that a DPE supports.

See these sections for other important information:

• DPE Licensing

• DPE-RDU Synchronization

Also, familiarize yourself with the concept of instruction generation, which is described in Instruction Generation and Processing.

DPE Licensing

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 due to exceeding licensing constraints do not appear in the administrator user interface. You can determine the license state only by examining the log files of the RDU and the DPE.

DPE-RDU Synchronization

BAC supports multiple DPEs. The DPEs communicate with devices and the RDU. During installation, you must configure the following for each DPE:

•Name of the provisioning group to which this DPE belongs; this name determines the logical group of devices services by this DPE.

•The IP address and port number of the RDU.

The DPE-RDU synchronization is a process of automatically updating the DPE cache to be consistent with the RDU. The DPE cache comprises the instruction cache, with instructions for devices, and the file cache, with files required for devices.

Under normal conditions, the RDU generates the events with instruction updates and sends them to all relevant DPEs to keep them up to date. Synchronization is needed if the DPE is missing some events due to connection loss. Such loss could be due to a network issue, the DPE server going down for administrative purposes, or a failure. Synchronization also covers the special case when the RDU database is restored from backup. In this case, the DPE cache database must be returned to an older state to be consistent with the RDU.

Note The RDU and DPE synchronization process is automatic and requires no administrative intervention. Throughout the synchronization process, the DPE is still fully capable of performing provisioning and management operations on the CPE.

The DPE triggers the synchronization process every time it establishes a connection with the RDU.

When the DPE first starts up, it establishes the connection to the RDU and registers with the RDU to receive updates of instruction changes. The DPE and RDU then monitor the connection by using heartbeat message exchanges. When the DPE determines that it had lost its connection to the RDU, it automatically attempts to re-establish it. It continues attempting to do this with a backoff-retry interval until it is successful. The RDU also detects the lost connection and stops sending events to this DPE. Since the DPE may miss the update events from the RDU when the connection is down, the DPE performs synchronization every time it establishes a connection with the RDU.

During the process of connection establishment and registration with the RDU, the DPE is in the Registering state.

The DPE requests a list of all the instructions it should have from the RDU. This list contains the identifiers for instructions and revision numbers, but not the actual instruction content. By using this list, the DPE determines which instructions in its store are inconsistent (wrong revision number), which ones are missing, and which ones to delete. Throughout the process of obtaining the synchronization list and comparing it to its store, the DPE is in the Synchronizing state.

As soon as the DPE finishes determining what to obtain from the RDU, it starts obtaining the instructions from the RDU. The DPE only obtains missing or out-of-date instructions. During this process, the DPE is in the Populating state.

The DPE populates at a fixed rate to ensure that the RDU is not overloaded with its requests. If multiple DPEs in the provisioning group are populating, the population time may be decreased as the requested instructions are sent to all DPEs in the provisioning group. After the DPE finishes populating, it is in the Ready state and fully synchronized with the RDU.

You can view the DPE state from the administrator user interface (see Viewing Device Provisioning Engines, page 16-21) or from the DPE CLI (by using the show dpe command).

Provisioning Groups

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 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.

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 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 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 BAC process watchdog is an administrative agent that monitors the runtime health of all BAC processes. This watchdog process ensures that if a process stops unexpectedly, it is automatically restarted.

The 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 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.

SNMP Agent

BAC provides basic SNMP v2-based monitoring of the RDU and the DPE servers. The 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.0, for additional information on the DPE CLI.

Logging

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 19-2.