Broadband Provisioner is a carrier-grade broadband access provisioning platform that offers network service providers a unified approach to subscriber management. Built on a set of hardened core provisioning engines, Broadband Provisioner simplifies subscriber authentication by presenting a role-based authentication model using a powerful domain membership system.
This package contains a wide array of features for Service Providers and Multiple Service Operators, including enhanced support for broadband networks operating over HFC/CATV and FTTH/FTTN.
Broadband Provisioner is compliant with more than 50 IETF standards, as well as standards from the Cablelabs® Consortium and various other entities. This list is not exhaustive, as new standards are added regularly.
RFC 951, Bootstrap Protocol
RFC 1350, The TFTP Protocol
RFC 2131, Dynamic Host Configuration Protocol
RFC 2132, DHCP Options and BOOTP Vendor Extensions
RFC 2241, DHCP Optios for Novell Directory Services
RFC 2242, Netware/IP Domain Name and Information
RFC 2347, TFTP Option Extension
RFC 2348, TFTP Blocksize Option
RFC 2349, TFTP Timeout Interval and Transfer Size Options
RFC 2485, DHCP Option for the Open Group's User Authentication
RFC 2563, DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
RFC 2610, DHCP Options for Service Location Protocol
RFC 2865, Remote Authentication Dial-In User Service (RADIUS)*
RFC 2937, The Name Service Search Option for DHCP
RFC 3004, The User Class Option for DHCP
RFC 3011, The IPv4 Subnet Selection Option for DHCP
RFC 3046, DHCP Relay Agent Information Option
RFC 3074, DHCP Load Balancing Algorithm
RFC 3164,The BSD Syslog Protocol
RFC 3256, The DOCSIS® Device Class DHCP Relay Agent Information Sub-option
RFC 3315, Dynamic Host Configuration Protocol for IPv6
RFC 3361, DHCPv4 Option for SIP servers
RFC 3397, DHCP Domain Search Option
RFC 3442, The Classless Static Route Option for DHCPv4
RFC 3495, DHCP Option for CableLabs Client Configuration
RFC 3527, DHCPv4 Link Selection Suboption for the Relay Agent Information Option
RFC 3736, Stateless DHCP Service for IPv6
RFC 3825, DHCP Option for Coordinate-based Location Configuration Information
RFC 3925, Vendor-Identifying Vendor Options for DHCPv4
RFC 3993, Subscriber-ID Suboption for the DHCP Relay Agent Option
RFC 4014, RADIUS Suboption for the DHCP Relay Agent Information Option
RFC 4174, The IPv4 Option for Internet Storage Name Service
RFC 4243, Vendor-Specific Information Suboption for the DHCP Relay Agent Option
RFC 4280, DHCP Options for Broadcast and Multicast Control Servers
RFC 4388, DHCPv4 Leasequery
RFC 4578, DHCP Options for the Intel Preboot Execution Environment (PXE)
RFC 4649, DHCPv6 Relay Agent Remote-ID Option
RFC 4702, DHCPv4 Client Fully Qualified Domain Name Option
RFC 4704, DHCPv6 Client Fully Qualified Domain Name Option
RFC 4776, DHCPv4 and DHCPv6 Option for Civic Addresses Configuration Information
RFC 4833, Timezone Options for DHCP
RFC 5007, DHCPv6 Leasequery
RFC 5010, The DHCPv4 Relay Agent Flags Suboption
draft-ietf-dhc-failover-12,The DHCPv4 Failover Protocol
ANSI/SCTE 22-1 2002
Hardened for un-trusted public access networks
Domain provisioning model
Clustering / Load balancing
Supports millions of subscribers
Plugin architecture for customizations
Dynamic DOCSIS® configuration file generation
Full support for IPv6
Runtime expression evaluation
Role-based operator login
Load balancing for external network services
Solaris 10 x86_64
Windows Server 2000
Windows Server 2003
CPU: 2GHz dual-core x86_64
CPU: Four quad-core x86_64
The software ships as a single tar.gz file containing RPMs for each daemon. You may install all of the packages, or any combination for the services you require.
To install the packages, first untar the distribution file, then install the prerequisites, and afterwards install the services and plugins you require.
The daemons are registered automatically during installation, but the services are not automatically started. Use the /etc/init.d scripts to start the services.
Before installing this product you must ensure that the libgcc and firebird packages are installed. The libgcc package can be obtained from www.sunfreeware.com, and the firebird package is distributed with this software.
The software ships as a single tar.gz file containing Solaris package files for each service. You may install all of the packages, or any combination for the services you require.
To install the packages, first untar the distribution file. Then install the prerequisites, and afterwards install the services and plugins you require using the pkgadd command.
You may want to create a startup script to launch the daemons (todtd, tftptd, syslogtd and dhcptd, located in /usr/local/sbin) each time the machine is started.
Insert the CD into the drive. The installation should start automatically. Alternatively, run SETUP.EXE to begin installation.
The Broadband Provisioner software package is transmitted as a single file. Copy this file to a temporary directory on your hard drive, then double-click the file to start the installation process. Setup allows you to specify Full or Custom installations. If this is your first time installing theBroadband Provisioner package you'll want to choose a Full install.
After selecting the installation directory and program group, the setup program copies the necessary files to your hard disk and registers the services. Once this is complete you should configure the software by clicking theBroadband Provisioner icon on your desktop.
Use the distribution specific add/remove software utility or open a super-user terminal window and use rpm -e to remove each of the packages.
Open a su terminal and use pkgrm to remove each of the packages.
Click the uninstall icon in the Broadband Provisioner program group, or, alternately, use the Control Panel's Add/Remove Programs applet.
When you first start the user interface, Broadband Provisioner will ask you to activate your product. If you are deploying the product yourself, mail your activation code to email@example.com to receive a product serial number, otherwise obtain the serial number from your local support representative.
Broadband Provisioner uses a domain system for provisioning the devices on your network. A domain is simply a logical grouping to which resources and device accounts are assigned. An easy way to understand how domains work is to view a domain as a partition in the server's configuration. Two different devices having identical properties on your network, but belonging to different domains, may "see" Broadband Provisioner as having two completely separate configurations.
By tailoring the domain classifications for your network, Broadband Provisioner allows you to:
group similar classes of devices
provision devices in bulk by provisioning the domain itself
provision single devices through device-specific domains
re-provision devices by moving them between domains
provision devices into multiple domains to provide for different device roles
partition the server for MSO environments
A resource is anything that Broadband Provisioner is configured to manage. Resources are carefully guarded by the server, and provisioned for use by devices on your network using a system of domain memberships.
Examples of resources include:
Address provisioning is what happens when Broadband Provisioner decides which IP address a device can use. When a device first boots in your network, Broadband Provisioner classifies the device, associates it with one or more domains, then determines which address pools are available to the domain(s) with which the device is associated. Although the device's domain membership determines the set of pools available, additional checks may limit this set of pools based on the network topology and other factors.
After the device has obtained its address, it must periodically extend the lease on that address. If the binding and the pool belong to domains to which the device has access, the lease can be extended. If, however, the device has been moved to a different domain, the lease cannot be extended. In this case the device may attempt to get another address from a different pool.
The Cablelabs® Data-Over-Cable-Service-Interface-Specification, DOCSIS®, defines a standard whereby a modem operating over cable-tv cabling can support a TCP/IP network. Broadband Provisioner fully supports DOCSIS cable modems by being able to automatically classify new cable modems on your network, assign them to domains, lease them addresses and build dynamic configuration files that configure all aspects of the modem.
Provisioning a cable modem takes place in two steps: first the modem receives an IP address, and second it receives a configuration file dictating its operating parameters, including settings such as upstream and downstream bandwidth and quality of service.
Cable modems can be automatically provisioned by configuring the DHCP server to first recognize the new devices as a cable-modem, then to assign the device to a domain that delivers the necessary DHCP options for the modem to download its configuration file. Once the cable modem has a working IP address, the TFTP server identifies the cable modem and proceeds to build and deliver a DOCSIS configuration file for the device.
Most fiber modems, like every other device on your network, require an IP address to operate.Broadband Provisioner can manage the IP addresses of every fiber-modem on your network, and can provision DHCP options to fiber modems using the same account/domain model that's used for your other network devices.
Some fiber modems also support the ability to download a configuration file over TFTP. For these modems, Broadband Provisioner can be configured to easily manage the modem configurations by simply moving the modem accounts into and out of a domain. Modem configuration files are dynamically generated based on the domains to which the subscriber belongs.
Broadband Provisioner can be configured to automatically classify new devices when they first come online. You can use site-specific logic to probe for information about the new device and, based on the results, classify the new device into one or more domains.
See the individual module references for details about configuring automatic provisioning.
A self-provisioning system is one in which the subscriber actively chooses the services to which he or she wishes to subscribe. Broadband Provisioner ships with a rich web-services gateway that can be used to easily implement a web-based self-provisioning system.
The web-services gateway is covered in detail the Web-Services reference section.
Manual provisioning can be tedious for human operators. To manually provision a new device:
create a new account for this device
creating access controls mapping the account to one or more domains
For more information on manual provisioning, see the section covering the web-services gateway.
The expression syntax in Broadband Provisioner provides unlimited flexibility for configuring devices on your network. Instead of simply defining static values, expressions allow you to calculate values at runtime using many different criteria.
You can supply expressions in many places where you would normally use a literal value. For example, instead of defining option 12, Hostname as a literal string, you can write an expression that generates a unique host name from information the device sent to the server.
You can use expressions in the following places:
Anywhere you define a DHCP option value
In the auto-provision domains list when calculating domains to which new machines should belong
In the TFTP virtual root folder, access mode and overwrite mode
In the syslog triggers
Refer to the individual protocol engine references for a complete description of the expression syntax.
To log into the system, open your web browser and enter http://localhost:5000 in the location bar. If this is a first-time installation, the user name is admin, and the password is admin.
After login, you are presented with the main interface for managing your server. This interface can be used to add and remove address pools, device accounts, option policies, users, and much more.
An address pool is a resource that identifies a range of addresses that the server can lease to your devices. This is the primary means of automatically managing the IP addresses on your network.
To create an address pool, choose File→New→Address Pool in the user interface.
The fields for an address pool are:
|Name||The name of this address pool. Must be unique for all address pools in this DHCP context.|
|Relay||If this pool is for DHCP clients on the same network segment as the DHCP server, enter a value of 0.0.0.0. If this pool is for clients on a remote network segment, enter the IP address of the interface on the relay agent that's closest to the client. Specify multiple relay agent addresses by separating them with a comma.|
|Range start||The first IP address in the range of addresses to be leased.|
|Range stop||The last IP address in the range of addresses to be leased.|
|Prefix||The network number on which the IP address range resides, e.g. 192.168.1.0 is the network for address 192.168.1.1/24.|
|Prefix length||The number of significant bits in the prefix part of the network. 8, 16 and 24 are common prefix lengths.|
|Valid lifetime||The total amount of time, in seconds, that an address from this range can be leased. Leases that have been inactive for this amount of time are considered abandoned.|
|Preferred lifetime||The amount of time, in seconds, before an address leased from this pool must have the lease extended.|
|Weight||A DHCP client may be able to pick from multiple pools for a specific network segment. Setting the pool weight allows you to induce the server to prefer some pools over others. Use a higher number to give the pool preference over other available pools. The default weight is 0.|
|Exclusions||This field lists addresses within the pool range that should not be leased.|
|Policies||A comma-delimited list of policies to be used for every device that receives an address from this pool|
For each pool there is also a pool-specific policy that can hold configuration information specific to the network on which this pool resides. The most common use of the pool-specific policy is to define the Gateways option (default gateway).
The server chooses a pool for a DHCP client device by using a four stage process of reduction.
Find the relay agent address the client is booting through and search for all pools associated with that address.
Using the security access token assigned by the provisioner subsystem, discard pools the client doesn't have authorization for.
Check the Allow and Deny expressions for each pool. Discard pools that are disallowed by these expressions.
Of the remaining pools, choose the one with the highest weight that still has available addresses.
If a pool belongs to the All devices domain (the default), step 2 will not discard the pool. By moving the pool from the All devices domain to a more restricted domain you can effectively allow or deny access to the pool based on the domains to which the DHCP client belongs.
Dynamic address bindings are resources that are automatically created by the DHCP server using the information provided from your address pools. A dynamic address binding is a DHCP lease that allots an IP address to a specific device for a certain amount of time.
A dynamic address binding contains these fields:
|Client identifier||The unique device identifier|
|Fixed||This setting is false for dynamic bindings|
|IP address||The leased address|
|Commit time||The time at which this lease was last obtained or extended|
|Duration||The length of time this lease is valid|
|Relay||The relay agent the client booted through|
|Protocol||The specific protocol the client used to obtain this address lease|
|Pool||The name of the address pool used to create this lease|
|Trusted ID||An identifier for the device or circuit provided by the relay agent|
|Trusted ID type||The type of trusted identifier provided by the relay agent|
The DHCP server automatically associates dynamic address bindings with one or more domains. If a device is able to obtain a lease from an address pool, it will be able to extend the lease created from that pool as long as the device belongs to the same domain used to obtain the original lease.
A fixed address binding is a specific kind of DHCP lease that guarantees that the recorded IP address will always be associated with the device named in the lease. Once a fixed address binding is made, the DHCP server will never use the binding's address with another client until you delete the binding or convert it to a dynamic binding.
You can create fixed address bindings manually or you can convert a dynamic binding to a fixed binding. To convert a dynamic binding to fixed, simply change the Fixed field in the binding to true.
When creating a fixed address binding you must specify the relay agent address to be associated with the binding. You can create different bindings for the same device on different network segments by specifying different relay addresses.
The following fields are not required when creating a fixed address binding:
Trusted ID type
|A fixed address binding is not required to be associated with any address pool. It is a perfectly acceptable configuration to create fixed bindings without having any address pools.|
Network pools are an emerging IPv6 standard and are currently under development.
Network bindings are an emerging IPv6 standard and are currently under development.
Network bindings are an emerging IPv6 standard and are currently under development.
DHCP options are operational settings that the DHCP server can distribute to devices on your network. The system is pre-configured with a wide array of IETF-standard DHCP options, as well as a set of Control Options that can alter the DHCP server's runtime behavior. In addition, the system allows you to define your own site-specific options.
DHCP options are defined in a policy, address pool or network pool.
Because policies belong to domains, it's easy to provision a set of DHCP options to a device: simply associate the device account with the domains that contain the policies the device should use.
Of course, a network device may belong to as many domains as you require, so you are free to mix and match domains to suit your provisioning model. Having Class-of-Service domains combined with geographical domains is one approach.
Assigning a device to a domain isn't the only way to provision DHCP options. Each option has an associated value, and that value can be a literal, such as 192.168.1.1 or it can be an expression that's dynamically calculated based on criteria you choose. For example, the "TFTP server" option could be calculated as:$RELAY.ADDRESS() + 1. This expression simply assumes that the address of a client's closest TFTP server is the next address in sequence after the relay agent's address.
The DHCP server recognizes a set of Control Options that are not standard DHCP options. These options can be used to control various aspects of the DHCP server's behavior. Control Options are never transmitted to a device.
To define a Control Option in a policy or pool, select the Server Control class of options, then add the option you require.
Control Options can be defined in any resource that accepts standard DHCP options. If a device on your network uses a policy or pool that contains a Control Option, the DHCP server will alter its behavior for that device according to the option setting.
Vendor-specific options are a special class of DHCP options that are specific to a particular kind of device, model or vendor. The system supports a range of vendor-specific options, and new options can be easily added.
For DHCPv4, you can add a vendor-specific option to a policy by first adding the Class Identifier option and setting its value to anything that matches the vendor class. You can then add vendor-specific options to the policy.
When using vendor-specific options in DHCPv4, only one class of vendor-specific options can be added to any given policy. The system does not support adding vendor-specific options from different vendors to a single DHCPv4 policy.
For DHCPv6, you can add a vendor-specific option to any policy you deem appropriate. Multiple kinds of vendor-specific options can be added to a single policy, but a device will only receive the vendor-specific options that it is capable of understanding.
A DHCP policy, which is simply a collection of DHCP options, is the primary means for giving a device extra configuration settings. A policy can hold any number of DHCP options, and any number of policies can be applied to a given device. There are two basic kinds of policies: Enforced and Optional.
When a DHCP client device contacts the server, the provisioner module determines the domains the device belongs to, and the DHCP engine uses this information to locate all policies for the device.
For every enforced policy applicable to the device, the DHCP server provides the device with every option in all enforced policies.
Devices are only provided with options from optional policies when the device explicitly requests values for those options.
Every domain you create with the web-based interface has one enforced policy and one optional policy. Having these two policies associated with the domain creates a set of common response options for devices using this domain, with certain options only provided when asked for.
For example, suppose you do the following:
Create a domain named Cablemodems
Insert option 4, Time servers into the domain's enforced policy and set an appropriate value
Insert option 6, Domain name servers into the domain's optional policy and set an appropriate value
With this configuration, every will be given the Time servers option, but only cable modems that request the Domain name servers option will receive that information.
Since policies are associated with domains, it's straightforward to cause a device to receive one set of options or another by moving the device account between domains.
Option types are declarations of DHCP options. They are not actual options, merely descriptions of options the server should be prepared to encounter. Option types specify a full range of details for DHCP options, including the tag number, data type, value limits, etc.