|
Provisioning Strategy
Rethinking the way provisioning is done in order to bring to light
possible enhancements
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: March 27, 1998
Note: For help designing your provisioning system or developing tools to help test, automate, and deploy your system contact Birds-Eye.Net.
Overview:
The purpose of this document is to describe how an MSO currently configures
provisioning systems as well as describe how it would like to accomplish this in the
future. Since provisioning involves configuration of hardware, software, and processes,
the MSO would like to leverage as many current methods, procedures, and technology to
support future requirements of the provisioning system (DOCSIS, self-service, etc.) once
available.
Where we are today:
Today configuring provisioning systems is not a scalable process. Essentially it is
performed a number of different ways depending on the resources available in each region.
The only application currently available to manage this process is the Headend
Provisioning Agent (see Figure 1.0). Although this application is described in more detail
in another document, a short overview of the Headend Provisioning Agent (HPA) will help
explain the MSO’s needs in this particular area.
Figure 1.0 Provisioning Server Management
The goal of HPA is to simplify and automate the steps required to maintain the
provisioning server(s). HPA was developed so one person could manage the configurations of
the provisioning server(s) without needing root access to the box. In other words, an
application centric person could perform the on-going configurations of the server(s).
Below is a list of the most important tasks that HPA performs:
- Sanity check hand-typed data to ensure that it is both valid and does not conflict with
existing configurations. For example HPA will prevent a new network from being added which
overlaps an existing network.
- Standardizes input and naming conventions. Drop down fields for things like subnet mask,
city, and headend location avoid typing errors.
- Associates each network with its corresponding city, headend, and collection of headend
(fiber) nodes.
- Enables one-stop-shop approach to creating/maintaining a network configuration. All
aspects of network and frequency configuration is centralized enabling up to two servers
to be configured, MD5 files created, and DNS master lists updated. HPA also protects
against incomplete configurations by not allowing one to proceed until all required
information is entered.
- Enables various user levels of interaction based on need to know. For example headend
technicians (people that work in the MSO headends) can only use HPA to swap headend nodes
(change mac address entered for a headend node). Users with higher levels can make more
drastic changes but there are a fewer number of these accounts.
- HPA supports View, Modify, and Add transactions. Of these, Modify and Add are logged
indicating whom changed/added what and when.
- HPA also provides a backup of all server configurations on a separate physical box. This
enables an MSO to more quickly recover from a catastrophic failure since all critical
provisioning server configurations are on a separate box.
- Enables troubleshooting tool to associate Customer Premise Equipment (CPE) with
particular headends, cities, and fiber nodes.
- Also allows troubleshooting tool to look up static IP addressed devices (headend nodes,
servers, and custom cable modems).
Currently HPA is used in varying degrees. For example:
- Western region is using all the HPA capability including building modem TFTP files.
- SE region only uses HPA to register its headend nodes.
- MW uses HPA to register its headend nodes, and build and modify server(s) configuration
files.
- NE is using all the HPA capability including building modem TFTP files.
Although HPA is not pretty (consists of a collection of CGI and Perl scripts) the
functionality provides a layer of abstraction away from entering configurations directly
into some application’s Graphical User Interface (GUI) – which is complex and
not intuitive. Typical DHCP server GUIs involve any where from a dozen or so screens that
one must traverse in order to create a new network or entry. However, HPA serves as a kind
of humanized API into what ever an MSO chooses to use for a provisioning server(s). This
allows the MSO to use the best of breed components in their infrastructure without
re-training the people who maintain these systems – because their interface does not
change.
Dependencies:
- Still relies on some manual configuration of the provisioning server (cycling the
provisioning server).
- Installing the router interface and configuring is a manual operation.
- Configuring the ethernet switch to create a new VLAN and associate it with some number
of headend nodes is a manual operation.
Problems that mainly occur during renumbering as a result of dependencies:
- Router/switch configuration procedure is performed by regular (9-5) operations people at
a less than optimal time (4:00 am).
- Renumbering outage time is determined more by re-checking work and individual
modification of headend nodes rather than time needed to cycle the cable modems (3
minutes). Ideally, all these could be stored and swapped if prep work was done in advance.
Note that while standardization is included in the HPA functionality, it is often
altered by regions to form a variant of the intended result. While this does not
negatively effect HPA operation it does eliminate the MSO’s ability to maintain a
consistent product throughout the regions. The parameters that are modified in HPA effect
the Quality of Service (QOS) for each modem that a region provisions on the servers.
Where we want to go:
The MSO would like to leverage this model (HPA) to develop an enterprise-wide
provisioning system. This system must enable the MSO to standardize its infrastructure,
streamline its deployment of new products, and speed outage detection and correction.
Ideally, any type of outage, especially those that are planned, should be corrected in as
fast and efficient a manner as possible. In order to achieve this level of efficiency the
data aspects which describe our control and our infrastructure needs to be stored in a
"real" database available for periodic review, analysis, or maintenance. The
infrastructure elements that need to be stored in the database include:
- All router interfaces and associated router configurations.
- Networks, policies, and service group configurations (provisioning server components).
- Ethernet switches/configurations (CMTS may no longer require ethernet switches).
- All reserved static IP addresses and their associated information including hostnames.
- Supported CPE/CMTS equipment and their associated configurations.
- Service group definitions and their associated mappings to actual MSO products.
Once assembled this information must be made available for regional and corporate
analysis. This implies that the data must be distributed by region and accessible from any
location. Figure 2.0 shows how the MSO would organize such a database.
Figure 2.0 Database organization
Using this model, various database objects would reside in either the MSO or regional
space while the actual data would be located in each region. Included with each database
object would be the necessary business rules, applications, and workflow needed to enable
this new technology. This information would be used by provisioning support systems (i.e.
hsdtools, service order processors, etc.) so when they encounter this device they will be
able to intelligently process it (examine, provision, modify, deprovision, etc).
Modifications to this data would utilize an HPA-like interface that would be flexible and
grow with the database.
Figure 2.1 Company (MSO) database object
Within the MSO space objects like Customer, Product, and Device would be defined (see
Figure 2.1). These objects would describe things like active the MSO products, currently
supported CPE and Infrastructure equipment, and the MSO eligible customers. For example,
one device object might be a LANCity legacy cable modem. Within this object all the
LANCity specific characteristics, processes, and dependencies are defined. Once created,
the basic idea is that if it’s part of the MSO it would be available to all regions
instantly – so any region interested in using LANCity modems could use them because
the object informs the right systems how to process these devices. Another example would
be residential customer object. This object would describe all the necessary information,
which makes up a residential customer (LDAP fields, operations environment, etc.). Lastly
one of the most interesting components of the MSO space would be the product object.
Product objects should not be dependent on device objects (what types of devices a region
uses may limit the capability of a particular product object). Once defined it’s
available for company-wide use because all provisioning systems utilize this database for
their configuration (roll-out schedules would be now be dependent on developing/testing
the product objects rather than building end-to-end products). Obviously this type of
configuration change would proceed hand-in-hand with marketing efforts. In addition,
things like SNMP passwords and supported personal firewall options could be maintained
enterprise wide (i.e. in the MSO space) or regional objects could define these. Perhaps
the default would be to defer back to the MSO space unless defined regionally.
Figure 2.2 Regional database object
Within the regional space an example of an object would be Billing (see Figure 2.2).
This object would describe the interface to the regional billing system allowing various
other objects to interact with it. Pushing down this interface to the region space enables
higher level objects to contain non-billing-system specific information (such as what is
the cost associated with this object).
The bottom line is that MSO needs to be more agile and responsive in the ISP space.
Having a central/distributed configuration database would enable us to quickly bring
products to market and leverage this readily accessible information about our
infrastructure to build and maintain the highest quality of service achievable. Some
possible outcomes as a result of implementing this type of technology include:
- Global IP address management
- Centralized and standardized product definition and support
- Rapid centralized product development and deployment
- Regional and company-wide modeling
- Rapid renumbering through automated systems configuration
- Company-wide network diagram capability
- Company-wide frequency spectrum allocation
- Centralized remote network operations and management
- Centralized customer care support of all CPE and CMTS*
*Note this is possible with the existing combination of the web-based troubleshooting
tool and HPA however doesn’t scale much beyond the year 2000.
Description of Provisioning Model:
Once the business case for the model mentioned above has been established, the next
step is dissecting the components of each object and formalizing their relationship with
other objects. Because this model/method could be applied to many types of service related
business that has a dependency on innovation and product features, its best to keep the
description of the objects generic. Examples of their use will be specific to the MSO.
Note that it is important to describe the components of the provisioning method
without indicating the underlying technology that enables it. Restricting this model to
current technologies at this point may negatively influence the way it is designed and
arrayed.
Company (MSO) Object Defined:
One of the most important components of this system is the company (or the MSO) object.
This object enables a centralized definition of company supported customers, products,
hardware, and features. The company object does not store any data but rather provides a
data model for regions to begin using specific equipment in an manor that is approved by
the company (MSO). In this way, use of new equipment will not disrupt the flow of
information nor the functionality of the provisioning system. Rather, new equipment may
offer increased reliability for the system or additional services that future products can
leverage. The objective, however, is backward compatibility and inter-operability.
Regional Object Defined:
The regional object should consist of a small collection of objects (on loan from the
corporate object where they are defined) that provide specificity to the higher level
objects. One of the more useful objects defined at the regional level is the billing
system interface. This allows objects defined at the company level to interface with
regional specific billing systems.
Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white
papers hot off
the presses by adding our RSS feed to your reader.
|