1. Introduction

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.

1.1. Standards Compliance

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.

IETF Standards
  • 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

Cablelabs® Standards
  • ANSI/SCTE 22-1 2002

  • CM-SP-RFIv1.1-C01-050907

  • SP-CMTRI-I01-970804

  • CL-SP-CANN-I01-070119

  • CL-SP-CANN-DHCP-Reg-I01-070119

1.2. Features

  • Hardened for un-trusted public access networks

  • Domain provisioning model

  • Online re-configuration

  • Multi-platform

  • OSS integration

  • Scalability

  • Clustering / Load balancing

  • ACID transactions

  • Supports millions of subscribers

  • SQL queries

  • Plugin architecture for customizations

  • Dynamic DOCSIS® configuration file generation

  • Auto-provisioning

  • Self-provisioning

  • Standards compliant

  • Full support for IPv6

  • Runtime expression evaluation

  • Auditing

  • Web-based management

  • Role-based operator login

  • Event publishing

  • Event triggers

  • Load balancing for external network services

  • High availability*

  • Reporting*

1.3. Supported Platforms

  • CentOS 5, x86 or x86_64

  • CentOS 6, x86 or x86_64

  • RHEL 5, x86 or x86_64

  • RHEL 6, x86 or x86_64

  • Solaris 10, UltraSparc

Microsoft Windows
  • Windows Server 2000

  • Windows Server 2003

1.4. System Requirements

  • CPU: 2GHz x86 or x86_64

  • RAM: 1GB

  • DISK: 2GB

Recommended (per million subscribers)
  • CPU: 2GHz quad-core x86_64

  • RAM: 8GB

  • DISK: 50GB

1.5. Installing on Linux®

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.

1.6. Installing on Solaris®

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.

1.7. Installing on Windows®

1.7.1. If you received a CD

Insert the CD into the drive. The installation should start automatically. Alternatively, run SETUP.EXE to begin installation.

1.7.2. If you received the software electronically

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.

1.8. Uninstalling the software

1.8.1. Linux

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.

1.8.2. Solaris

Open a su terminal and use pkgrm to remove each of the packages.

1.8.3. Windows

Click the uninstall icon in the Broadband Provisioner program group, or, alternately, use the Control Panel’s Add/Remove Programs applet.

1.9. Registering your product

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 activation@weird-solutions.com to receive a product serial number, otherwise obtain the serial number from your local support representative.

2. System Architecture

2.1. Domains

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

2.2. Resources

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 pools

  • Address bindings

  • Network pools

  • Network bindings

  • DHCP policies

  • TFTP policies

3. Provisioning Overview

3.1. Address Provisioning

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.

3.2. DOCSIS® Cable modem provisioning

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.

3.3. Fiber modem provisioning

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.

3.4. Automatic Provisioning

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.

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

3.6. Manual Provisioning

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.

3.7. Expressions

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.

4. Login

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.


5. DHCP Reference

5.1. Address Pools

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:

Field Description


The name of this address pool. Must be unique for all address pools in this DHCP context.


If this pool is for DHCP clients on the same network segment as the DHCP server, enter a value of 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.


The network number on which the IP address range resides, e.g. is the network for address

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.


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.


This field lists addresses within the pool range that should not be leased.


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.

  1. Find the relay agent address the client is booting through and search for all pools associated with that address.

  2. Using the security access token assigned by the provisioner subsystem, discard pools the client doesn’t have authorization for.

  3. Check the Allow and Deny expressions for each pool. Discard pools that are disallowed by these expressions.

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

5.2. Dynamic Address Bindings

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:

Field Description

Client identifier

The unique device identifier


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


The length of time this lease is valid


The relay agent the client booted through


The specific protocol the client used to obtain this address lease


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.

5.3. Fixed Address Bindings

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:

  • Commit time

  • Protocol

  • Pool

  • Trusted ID

  • Trusted ID type

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

5.4. Network Pools

Network pools are an emerging IPv6 standard and are currently under development.

5.5. Dynamic Network Bindings

Network bindings are an emerging IPv6 standard and are currently under development.

5.6. Fixed Network Bindings

Network bindings are an emerging IPv6 standard and are currently under development.

5.7. DHCP Options

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.

Suppose you have two geographical domains, Charlotte and Atlanta, and the policies belonging to these domains specify different DHCP option values. A device that belongs to the Charlotte domain would receive a different set of DHCP options than a device that belongs to the Atlanta domain.

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

5.7.1. Server Control Options

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.

For Example

The Control Option DDNS update server can be used to specify that a dynamic DNS update be directed to a specific DNS server on your network. If this option is defined in a policy, devices that use the policy will have their DNS updates sent to the DNS server defined in this option. Devices not using this policy will have their DNS updates sent to the system default DNS server.

5.7.2. Vendor-specific options

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.

5.8. Policies

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.

5.9. Option Types

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.


For every DHCP option the server receives there should be a corresponding Option Type that describes the option. If the DHCP server receives a packet that contains an unknown option, processing for that option is skipped.

Option types are quite complex because they describe in detail the complete characteristics of DHCP options. The fields of an option type are described below, with descriptions for each field.

Field Description


The option’s unique tag. For many options this may simply be a number, but for options that must be encoded inside other options this will be a path of option tags such as 43/1.


One of the predefined option type names. Type names are listed in the table below.


The official name of the option


An arbitrary name for grouping similar options


A human-readable description for this option


Whether or not a user can set a value for this option. Can be allowed, disallowed or required.


An integer specifying the maximum number of instances of this option that can be defined. 0 means unlimited. Default is 1.


A string representing the default value for this option, if there is one. The default value is used by the user interface when presenting the operator with a suggested value for this option.


A boolean value indicating whether or not more than one element can exist in the option. The default is false.


A string representing the unit of measurement for this option value. This text is displayed for operators when editing option values.


A boolean value for numeric types that indicates whether or not the elements are signed. The default is false.


A boolean value for string types indicating whether or not to use a null terminator on binary output. The default is false.


An integer value for numeric types that specifies the minimum allowed value this option may hold.


An integer value for numeric types that specifies the maximum allowed value this option may hold.


An integer specifying whether this option has a type field. This input setting is used when reading the option from raw binary format. If this value is -1 (the default), this option does not have a type-encoding field. A value of 0 or greater indicates that this option a specific type encoding, and the specified value denotes the type. Type encodings are option-specific.


An integer specifying whether this option has a type field. This output setting is used when writing the option to raw binary format. If this value is -1 (the default), this option does not have a type-encoding field. A value of 0 or greater indicates that this option a specific type encoding, and the specified value denotes the type. Type encodings are option-specific.


This field is for fixed_offset type options only. It specifies a set of offsets where each contained tag should be found. The format is tag/offset/width (where width is in bytes), and multiple offsets are separated with a comma.


An integer representing the IANA-registered vendor ID. When non-zero, this number indicates to any subencoded options that their metadata is specific to this vendor. The default value is 0, which indicates that any subencoded options are not vendor-specific.


A boolean value indicating whether this option defines a vendor-specific option-request-option (ORO). A vendor-specific ORO is used by a DHCP client to request a specific set of options from a DHCP server.


This option is used to indicate to the DHCP server that another option in the packet currently being processed holds information about the vendor identifier that should be used when reading suboptions of this option.


An integer that specifies whether each element in this option should be preceeded with a length field of this size (in bytes). The default value of 0 indicates that option elements are not length prefixed.


An integer value for options that hold options which specifies the width of the tag field for suboptions. The default value is the same as the DHCP protocol being used.


An integer value for options that hold options which specifies the width of the len field for suboptions. The default value is the same as the DHCP protocol being used.


An integer value for options that hold options which specifies the width of the type field for suboptions that are type-encoded. The default value is the same as the DHCP protocol being used.

An option may be declared as one of the following types:

Name Description


An 8 bit integer value


A 16 bit integer value


A 24 bit integer value


A 32 bit integer value


A 64 bit integer value


A 128 bit integer value


An ASCII string


An ip address


An ip endpoint (ip:port)


An 8 bit boolean value


A 32 bit time value


A sequence of arbitrary bytes


An option that can hold child options


An option that can hold top-level options


An RFC 1035 DNS name


An expression that evaluates to a value at runtime


A DHCP protocol-control option


An option that holds child options that are not tag/len/data encoded


An snmp variable binding. This may also be written as snmp_oid.

5.10. Vendor Classes

Vendor classes are a convenient way of organizing the different kinds of devices that may appear on your network.

DHCP packets typically contain information that describes the kind of device communicating with the server. Instead of writing an expression to fully analyze all possible combinations of a DHCP packet, you can call the $DEVICE.TYPEID() function. This function returns a number that indicates the exact type of device communicating with the server.

The $DEVICE.TYPEID() function uses vendor classes to determine the type of device that is requesting DHCP service.