|
|
Broadband Access Center for Cable (BAC) automates the configuration and provisioning of network devices supported by a broadband service provider. It is a flexible product that can be scaled to suit virtually any size network. BAC is designed to handle the rapid growth of the service provider. It targets broadband service providers (including multiple service operators), Internet, and voice service providers who want to deploy IP data, voice, and video on hybrid fiber and coaxial cable networks. BAC also provides such critical features as redundancy and failover protection, and can be integrated into new or existing environments through the use of a provisioning application program interface (API) that lets you control how BAC operates. The provisioning API can be used to enable BAC to register devices, device configurations, and configure the entire BAC provisioning system.
BAC lets multiple service operators (MSOs) meet the rapidly changing demands for data over cable services. Using BAC, you can realize these features and benefits of its architecture:
This release of Cisco's Broadband Access Center supports these technologies and equipment types:
This section describes the basic BAC architecture including:
See the "Regional Distribution Unit" section for additional information.
See the "Device Provisioning Engine" section for additional information.
See the "Provisioning Groups" section for additional information.
See the "Cisco Network Registrar" section for additional information.
See the "SNMP Agents" section for additional information.
The RDU is the primary server in the BAC provisioning system. The RDU also provides:
The RDU supports the addition of new technologies and services through an extensible architecture. The RDU also supports:
These sections describe these RDU concepts:
Device configurations can include customer required provisioning information, such as: DHCP IP address selection, bandwidth, data rates, flow control, communication speeds, and level of service. A configuration can contain DHCP configuration and TFTP files for any device. When an unprovisioned device is installed, and the boot operation performed, a default configuration for the appropriate technology is obtained from BAC and sent to the device, by means of either DHCP or TFTP. The default configuration can be changed for each supported technology.
BAC currently supports one RDU per installation. For failover support, use your own hardware redundant system or obtain a similar system with hot-swap capability.
The Cisco Device Provisioning Engine (DPE) communicates with the RDU to give devices their configurations. Each DPE caches information for up to 500 thousand devices. You can use multiple DPEs to ensure redundancy and scalability.
The DPE handles all configuration requests including providing configuration files for devices. It is integrated with the Cisco Network Registrar DHCP server to control the assignment of IP addresses for each device. Multiple DPEs can communicate with a single DHCP server.
The DPE manages these activities:
This section describes these major DPE components:
BAC supports multiple DPE servers. These servers communicate with devices, a DHCP failover server configuration, and the RDU. During installation, you must make these DPE server assignments:
The DPE's primary objective is to send configurations to customer devices whenever those devices are powered up or rebooted. To do this quickly, the DPE keeps a copy of the configuration for each device in a local cache database. Usually the DPE only has to add in a few minor pieces of information to the configuration, such as a current IP address of the device and one or more security checks, before it provides the configuration to the device.
The integrated TFTP server receives requests for files, including DOCSIS configuration files, both from device and non device entities. This server then transmits the file to the requesting entity.
A provisioning group is designed to be a regional grouping of servers usually consisting of a two or more DPEs and a failover pair of DHCP servers that can handle the provisioning needs of up to 500 thousand devices. As the number of devices grows past 500 thousand, 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 NOC. |
To support redundancy and load sharing each provisioning group can support any number of DPEs. As the requests come in from the DHCP servers, they are distributed between the DPEs in the provisioning group in a round-robin fashion so that any one DPE does not get overloaded with all the requests. The information stored on each DPE within a provisioning group is identical so as long as one remains, operational service will not be interrupted. Figure 1-1shows some typical provisioning group setups with varying numbers of DPEs.
The provisioning group at the bottom (C) shows the absolute minimum number of servers that can be used, one DPE and one DHCP. Cisco does not usually recommend that this be deployed as there is no redundancy or failover support and if one of the two servers stop functioning then all service is lost until it is back up again. This configuration could be used if the number of users being serviced in a particular region is so small that the additional hardware cost cannot be justified and the deployment is willing to live with an outage if a server stop functioning.
The provisioning group at the top (A) is the most commonly deployed one. A failover pair of DHCP servers and a redundant pair of DPEs. This provides enough load sharing and redundancy to support most regional deployments.
The provisioning group in the center (B) might be used in an area that has a higher constant rate of change to the devices being serviced or where large numbers of customer devices go up and down frequently. The addition of two DPEs allows the extra load to be shared over four DPEs, which allows greater numbers of devices to be serviced in the same amount of time or less.
Network Registrar provides Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS) functionality. It has a complete administrative user interface that, when coupled with customized BAC configuration screens, can be used within a larger enterprise management system.
|
Note For additional information on Network Registrar, refer to these documents: Network Registrar User's Guide, Network Registrar CLI Reference, and the Network Registrar Installation Guide. |
The DHCP server automates the process of configuring IP addresses on TCP/IP networks. This protocol performs many of the functions that a system administrator carries out when connecting a device to a network. DHCP automatically manages network policy decisions and eliminates the need for manual configuration. This in itself, adds flexibility, mobility, and control to networked device configurations.
DHCP failover allows pairs of DHCP servers to act in such a way that one can take over if the other stops functioning. The server pairs are known as the primary and backup server. Under normal circumstances the primary server performs all DHCP functions. Should the primary server be unavailable, the backup server will take over. In this way, DHCP failover prevents loss of access to the DHCP service should the primary fail.
The Domain Name System (DNS) is a server that contains information on hosts throughout the network, including IP address hostnames and routing information and DNS uses them primarily to translate between IP addresses and domain names. This conversion of names, such as www.cisco.com, to IP addresses simplifies accessing Internet-based applications. The DNS directory service consists of:
The key distribution center (KDC) is a central authentication server used to authenticate MTAs and grant security tickets to them.
The KDC has several default properties that get populated, during BAC installation, into a <BPR_HOME>/kdc/solaris/kdc.ini properties file. This file can be edited to change values as operational requirements dictate. Once changes have been made however, you must restart the KDC before any property file, key or certificate changes can take affect. The default properties are:
|
Note The interface address, Realm, and FQDN are entered through the KDC Realm Name screen during installation. Refer to the BAC for Cable Installation Guide for specific information. |
Using the example values shown above, a sample INI file might contain data similar to that shown in Example 1-1.
You can set the times for both minimum and maximum ticket duration to effectively smooth out excessive numbers of ticket requests that could occur during deployment. This is beneficial given that most deployments occur during traditional working hours and excessive loading may, from time to time, adversely affect performance.
|
Note Shortening the ticket duration forces the MTA to authenticate to the KDC much more frequently. Unfortunately, while this results in much greater control over the authorization of telephony endpoints, it also causes much heavier message loads on the KDC and increased network traffic. For most circumstances the default setting is appropriate and should not be changed. |
The default value is 168, or seven days, and Cisco recommends that you not change this value since this is the duration required to conform to the KDC security specification. For example:
The default value is 144, or six days, and Cisco recommends that you not change this value. For example:
The certificates used to authenticate the KDC, are not shipped with BAC. You must obtain the required certificates from Cable Television Laboratories Inc. (CableLabs) and the content of these certificates must match those that are installed in the MTA.
You may need to run these certificates through the PKCert tool to convert them to a format that is usable by the KDC. The certificate files are then copied into the required directory. See the "Managing KDC Certificates with the PKCert Tool" section for additional information.
|
Note To install a KDC licence file, you copy it into the <BPR_HOME>/kdc directory and name it kdc.license. After doing so, you run the bprAgent restart kdc command, from the /etc/init.d directory, to restart the KDC server and make the changes take effect. |
Once the certificates are installed, the MTA sends a pair of chained certificates to the KDC including the MTA device certificate and the MTA manufacturer certificate.
 |
Warning Without the certificates installed, the KDC will not function. |
The KDC ensures that both of these certificates correctly chained to the MTA root certificate. Consequently, it is extraordinarily important that the MTA manufacturer certificate corresponds to the public key found within the MTA root certificate that is provisioned on the KDC.
You obtain a KDC license from your Cisco representative and then have to install it in the correct directory. To do this:
Step 2 Copy that file to the <BPR_HOME>/kdc directory.
Step 3 Rename the file to kdc.license.
Step 4 Run the bprAgent restart kdc command, from the /etc/init.d directory, to restart the KDC server and make the changes take effect.
BAC supports basic SNMP based monitoring of both the DPE and RDU servers.
All SNMP agents described in this section support the SNMP version v2c. The SNMP agents do not perform any logging. You can enable these agents using either the DPE CLI or RDU SNMP configuration CLI commands. See the "Device Provisioning Engine Command Line Interface" for additional information on the DPE CLI and the "Using the rduSnmpAgent.sh Command" section for additional information on RDU SNMP configuration command line tool.
The SNMP agent does not communicate directly with the BAC process. Instead, all feature status information is sent to the SNMP agent through the BAC agent. The DPE SNMP agent is also RFC-1213 compliant.
The DPE SNMP agent supports these MIBs on the DPE-590:
SNMP traps are generated whenever the DPE process either goes up or down, and may also be generated if resource usage exceeds preset thresholds.
Table 1-1 identifies the SNMP traps that are generated. Note that some of these traps are triggered based on the resource usage level.
Table 1-1 DPE SNMP Agent Traps
|
There are several SNMP related CLI commands that are necessary to use the agent. These are described in the "SNMP Agent Commands" section.
The RDU SNMP agent monitors the RDU process and generates SNMP traps whenever the RDU process starts or stops.
Since the RDU is intended to be loaded on an open Solaris device, the RDU SNMP agent will not provide support for other MIBs like RFC 1213 (MIB II).
The RDU SNMP agent is intended for operation within the Solaris operating system only and, as such, offers no support for MIB-II. This agent does however, support the CISCO-NMS-APPL-HEALTH-MIB which defines the Cisco NMS application health status notifications and related objects. These notifications are sent to the OSS/NMS to inform them about the NMS application status. Status can include: started, stopped, failed, busy, or any abnormal exit of applications.
The RDU SNMP agent generates the traps listed in Table 1-2.
Table 1-2 RDU SNMP Agent Traps
The BAC agent is an administrative agent that monitors the run time health of all BAC processes. This watchdog process ensures that if a process stops unexpectedly, it is automatically restarted.
The BAC agent 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 agent server will wait a prescribed amount of time to attempt the restart again.
|
Note You do not have to use the BAC agent to monitor Network Registrar extensions. |
The period between restart attempts increases exponentially until it reaches a length of 5 minutes. After that, the process restart is attempted at 5 minute intervals until successful. Five minutes after a successful restart, the period is automatically reset to 1 second again.
The BAC agent automatically starts whenever the system boots up. Consequently, this agent also starts those BAC system components it is configured to control. The BAC agent can also be controlled through a simple command line interface. This is performed by running the bprAgent command from the /etc/init.d directory.
Table 1-3 describes the CLI commands available for use with the BAC agent. You can run the CLI from the etc/init.d directory.
Table 1-3 BAC Command Line Interface
|
|
Note The <process-name> mentioned in Table 1-3 can be one of the rdu, kdc, dpe, rduSnmpAgent, and jrun (which runs the administrators and sample user interface) processes. |
Posted: Tue Nov 25 06:41:17 PST 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
