|
Open
Access: A step-by-step Example
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: October 26, 2000
Note: For help designing your provisioning system or developing tools to help test, automate, and deploy your system contact Birds-Eye.Net.
The following is a detailed description of how one could possibly
activate a customer in an open access system. The system as described uses only currently
available technology such that it would be immediately feasible to build such a system
based on the descriptions within.
There
are currently four different ways that open access could be facilitated. The first way
would be to create multiple radio-frequency (RF) local area networks (LANs) off each
hybrid fiber coax (HFC) node. An RF LAN consists of a network that is created as a result
of a Cable Modem Termination System (CMTS) utilizing a pair of frequencies (one for
transmit and one for receive) on the HFC. The RF LAN provides an environment that allows
one or more cable modems CMs along an HFC segment to utilize the frequency pair to form a
LAN. However, since this is not a traditional LAN connected by fiber or category 5 wire
but rather by HFC (more specifically two frequencies within the HFC) it is being referred
to as an RF LAN. In a multiple RF LAN HFC, there would be 2 or more independent LANs each
using their own unique frequency pairs (e.g. two RF LANs would require four HFC
frequencies). This method would be the most costly of the all methods as it would require
separate CMTS gear for each Internet service provider (ISP) as well as require additional
frequency pairs for each ISP on the HFC. Since headend, rack, and frequency spectrum space
are all extremely tight this method of facilitating open access has not received much
attention. However, from purely an operations standpoint it is the cleanest of all methods
in providing total separation among open access choices. This separation comes out of the
fact that once the customer selects which ISP they want, their CM can be provisioned to
join that ISP’s designated RF LAN. This action pulls anything behind the CM along
with it (similar to a renumbering event). Once on the new RF LAN, the traffic,
provisioning, etc. are totally isolated among ISPs on the most critical portion of the
network – the last mile (also called the local loop).
The
second way to provide open access is by highly leveraging the dial-up
model/infrastructure. Essentially, the idea here is to have the cable modem provide basic
network connectivity back to a central Remote Authentication Dial-In User Service (RADIUS)
server used by all ISPs for network access authorization. Subscribers would then utilize a
Point-to-Point Protocol over Ethernet (PPPoE) client to connect to their respective ISP.
Using this method would eliminate the use of an extremely complex Dynamic Host
Configuration Protocol (DHCP) server and greatly simplify IP address management as well as
greatly reduce the overall number of IP addresses required to implement open access. Once
more, since RADIUS this is already used by dial-up ISPs they would be able to easily
leverage their existing infrastructure (capability) to begin offering open access. The
drawbacks of using RADIUS and PPPoE as a means of supplying open access over broadband
mainly center around two key points. The first drawback is that this way prevents the
broadband operator (last mile provider) from being anything more a pipe. Becoming solely a
transport is something broadband operators do not want – especially since they have
always been a transport as well as a content provider. This way prevents them from running
caching servers at the network edge and managing content. The second drawback is that most
broadband customers have enjoyed session-less access for so long that this may force them
to change. A session-less access is one that does not require the subscriber to log in or
start some application or service before they can use the Internet. Broadband operators
offer a service they claim is “Always On” but introducing a session to this may
not be palatable to their subscribers.
Note that client side
tunneling could fall into the same category as PPPoE only with further requirements from
the broadband operator’s DHCP server to provide the CPE with initial IP address that
it would in turn use to connect to the ISP’s gateway. The use of client side
tunneling also does not require any additional networking hardware.
The third way to provide open access is through the use of policy
based routing. Policy based routing seeks to associate each subscriber with some kind of
routing policy or service id. Based on this service id, the subscriber’s IP traffic
will be routed to and from their current ISP selection only. From the subscribers’
perspective, all the complexity is masked using this method – they just benefit from
the use of their selected ISP. Policy based routing is more efficient than source based
routing (yet another method of open access that will be explained next) because routing
decisions regarding each IP packet can be made without having to dig further into each IP
packet to find information. The drawbacks of using policy based routing are significant
– however. They include:
- Negates
redundant routes of traditional IP networks
- Requires
advanced routing software and/or new routers that support Multi-Protocol Label Switching
(MPLS)
- Does
not permit broadband operators to have visibility to the subscriber content
Even
with these significant drawbacks, policy based routing is receiving a lot of attention as
the best way to provide open access.
The forth way to provide open access is to add a secondary
interface off each RF LAN for each ISP (this method has become known as source based
routing). This method does not require any additional equipment or ISP presence in the
headend but would require large numbers of IP addresses from ISPs to cover all possible
customer locations. Although the concern for limited numbers of IP addresses is valid, it
does not defeat this method as a viable alternative as it’s the easiest and cheapest
method to implement. This method will be explained in more detail below:
Initialization of New CM on the Network:
Before
a CM can provide customers with access to the Internet via open access, it must first be
introduced (initialized) to the network. This process starts as shown in Figure 1.0 and
involves the CM interacting with a CMTS and a dynamic host configuration protocol (DHCP)
server. The CM being closely associated with the transport/demark does not make it a
likely candidate for open access inclusion (i.e. there is not a selection of who/what
provisions the CM rather, once the CM is activated then open access associated choices are
made available).
Figure
1.0 Cable Modem Initialization
For the purpose of this method of open access, the CM is property
of either the Multiple Subscriber Organization (MSO i.e. Cable Operator) or the Customer
(via retail availability of the CM). Because it is property of the either of these
parties, the MSO should oversee the general operation of the CM including its
configuration (i.e. traps, filters, etc.). Even if the network provider manages the DHCP
server and configures the working networks, the MSO should be in charge of maintaining the
configurations supplied to the CM. Since the CM is MSO driven rather than network provider
driven, it is not a component of open access but rather a medium that enables it. Once
configured, a functional CM that has joined the network can then supply the facilities for
customers to select among ISPs.
At
the moment the CM is plugged into a power source and an active cable television outlet* it
is initially void of configuration. As a result it begins to range. This process allows
the CM to find the transmit and receive frequencies of a CMTS. Once the CM locks onto
these frequencies it is able to announce its presence on the network. This is accomplished
by sending a DHCP Discover message on its RF LAN segment.
*Open access requires connectivity. A dead line to a
customer’s prohibits open access and/or self activation of services. Therefore, the
MSO must activate services prior to self activation or the customer must be currently a
video customer (a minimum requirement for service) before self service can provide open
access.
Connected
to this RF LAN is some kind of router (shown in Figure 1.0 as the box containing the words
relay agent). The router is configured with one or more interface address(es) that it uses
to communicate with other routers and network hosts. The router’s purpose is it links
the RF LAN to other nearby networks that in turn link it to the Internet. Because the CM
does not need Internet access directly, it is generally configured with a private IP
address for security and for the conservation of public IP addresses. The router is
configured with an interface address and network in the private IP address space to
accommodate the RF LAN. This private interface address supports all CMs connected to its
RF LAN segment.
When
the DHCP Discover is heard by the CMTS it is passed on to the DHCP server through the use
of what is called a relay agent (or helper address). The relay agent captures BOOTP type
broadcast messages and then forwards them to a specific IP address. Note that one can
helper the same broadcast to one or more IP addresses.
There
are actually two flavors of CMTS. One type of CMTS works like a bridge and the other like
a router. A bridging type CMTS (as shown in Figure 1.0) requires a nearby router to
perform this relay where as the router CMTS performs the relay internally. Regardless, the
relay agent does one important thing beside relay the request – it stamps its
interface address into the relayed message. This allows the receiver of the message to
locate the source of the message – which is important as in a DHCP Discover, the
source does not yet have an IP address. Rather the source only has a Media Access Control
(MAC) address and only the router connected to that RF LAN knows how to get to that MAC
address.
Once
this broadcast is forwarded to the DHCP server, one of several things will happen
depending on the provisioned state of the source (CM). There are several possible
provisioning states that are known at this time. Each of these provisioning states have a
distinct meaning that is necessary to provide both security and self-service capability on
the network.
-
Unprovisioned
CM – Brand new to the system
-
DHCP
server processes as a possible new customer. Note that it could also be an existing
customer that has just upgraded/replaced their CM so self-service must ensure customers
have the ability to swap out a bad CM as well as activate a new account (both come across
looking like a brand new CM being added to the system however both must be handled
differently).
-
Unprovisioned
CM – Old customer (possible reconnect)
-
DHCP
server processes as a reconnect (i.e. self activate). Perhaps even gives option to recall
previous account parameters from the data warehouse.
-
Provisioned
CM – Working customer
-
DHCP
server processes as normal to permit currently selected operational parameters to become
active on the CM.
-
Provisioned
CM – Deactive (3 strikes violator)
-
A
DHCP server process as a normal customer only provides the CM with a no access
configuration file. This prevents the CM from continuously babbling on the network and
also prevents the user of the CM from attempting to self activate.
IDEA: DHCP server could provide for three
different registry options. The first option is a unregistered MAC. In this case, which is
normal DHCP activity on a “friendly network” (i.e. answer everyone who asks).
The second option is a registered option which allows the DHCP server to treat those MAC
addresses that have been registered differently than the first option. The third option
allows the DHCP server to handle MAC addresses that have been previously registered,
acquired a lease, and then deregistered. These decommissioned MAC addresses flow into this
pool as a means of permitting the DHCP server to treat them differently when they reenter
the network at a later time. All three options have the ability to send different DHCP
options to their associated MAC addresses as well as assign IP addresses from different
pools of available IP addresses.
However,
since the CM is brand new to the system, the DHCP server categorizes it as such and
provides it with default settings and IP addressing. These default settings permit a
private IP address and minimal DCHP options to be sent to the CM.
Figure
2.0 DHCP Offer to CM
Continuing
with the Unprovisioned CM that is brand new to the system and assuming the customer is
brand new as well. The CM is provided with a DHCP Offer as shown in Figure 2.0. This offer
is the result of the DHCP Discover message running through some internal logic in the DHCP
server. This logic includes determine which pool of IP addresses are affiliated with the
CM’s relay agent, the provision state of the CM MAC address, and possibly the state
of the IP address to be assigned to the CM. DHCP servers can get further logic by placing
certain CMs into groups as well as groups of groups. In this way the combination of
inclusion in specific provisioning status or group status(s) dictate the DHCP options
assigned to the CM. Once the offer has be created within the DHCP server it is sent* down
to the relay agent. The configuration sent to Unprovisioned/New CM provides the CM with
minimal operational parameters it needs to join the network. This information includes the
following:
-
IP
Address – A temporarily assigned dynamic IP address (typically in the private IP
address space). For example and address on the 10 net (i.e. 10.1.1.3) is most common.
-
Subnet
Mask – A subnet mask that corresponds to the RF LAN network size that the CM resides.
-
Gateway
Address – The IP address of the gateway on which the CM resides – this is
usually the same as the relay agent IP address.
-
Time
of day (TOD) Address – The IP address of a standard TOD server. Some CMs require a
successful interaction with TOD server before they will properly boot.
-
Lease
parameters (expiration, renew, rebind). These times define the terms of the temporary
dynamic IP address above. The expiration time is the full term of the lease after which
time it will be come invalid or unusable. The renew time is the period of time after which
the CM should ask the last known server for a new lease. The rebind time is the period of
time after which the CM should ask any server for a new lease. Both the renewal and rebind
times are less than the duration of the lease where by allowing the DHCP client (i.e. CM)
to renew the lease before it expires.
NOTE that lease times will vary based on several things
including the provisioning state and the number hosts being supported on the network.
Typically, the lease time of unprovisioned hosts is extremely short allowing them to
obtain a new IP address and longer lease once provisioned. As the number of hosts that any
one DHCP server supports increases this should increase the length of leases across the
board. Increasing least times reduce the load on the DHCP server.
-
Boot
file – The path/file name of the configuration file the CM should download to obtain
its operational parameters.
-
Boot
server – The IP address of the TFTP server where the CM should ask for its boot
configuration file.
*Note that during the offer phase of the DHCP transaction there is
no guarantee that the CM will accept the DHCP server’s offer. This is because there
could be several DHCP servers on the network (each having overlapping IP ranges capable of
covering for one another in the event of an outage or overloading). Regardless, in a
multi-DHCP server network, several servers could send offers to the CM. Therefore the
process immediately following the DHCP offer is critical to the CM as that is where it
selects which DHCP server it will use for the source of its IP address lease. During this
process (called the DHCP reply) the CM sends a broadcast message containing the
information about the lease it would like to use along with the DHCP server IP address
that provided it. When this broadcast hits the relay agent it is forwarded to all the
other DHCP servers providing service to that CM. Since only one DHCP server will be able
to provide the CM with a lease, all the other DHCP servers (who were not selected) will
free the IP address they allocated to the CM. The server that was selected will commit the
lease to its database and then send a DHCP Ack back to the CM to confirm the lease
agreement.
There are some variations to the
assignment of a DHCP lease in that the server may perform additional tasks before it
initially assigns the lease. For example, the DHCP server may attempt to ping the lease
before it assigns it to the CM. This process ensures the IP address to be handed out to
the CM is valid on the network (i.e. not currently in use). However this has other
purposes as well. Associated with ping of these IP addresses is a timeout. The timeout is
how long the DHCP server will wait for a device to respond to its ping before it considers
the IP address available. This timeout can also be used to delay overlapping DHCP server
responses to CMs (i.e. forcing the selection of particular DHCP servers over others). The
primary DHCP server would have the fastest timeout (say 100 ms), and the secondary DHCP
server would have a slower timeout (say 250 ms). In this way, the primary DHCP server
would always offer first unless it was overloaded. While the ping/timeout feature is
useful for multiple DHCP server configurations, its value in single DHCP server settings
is negligible and often causes performance problems in larger serving areas. This is
because it slows down the DHCP server’s ability to take on new work – without
the ping/timeout, the server more quickly handles each DHCP transaction.
Figure
3.0 DHCP Reply from CM
Upon
receiving the DHCP Offer the CM responds by sending a DHCP Reply. This message looks
similar to its initial DHCP Discover, only it now contains all the information in the
lease it received as an offer including the IP address of the DHCP server that provide
this information. The relay agent forwards this message on to the DHCP server(s) it has
configured as helper address(es).
*Note at this point it is important to understand that even though
the CM has received a DHCP offer it does not yet have a valid IP address lease from the
server and cannot be pinged on the network. Instead, the lease it received from the DHCP
server is considered temporary and not useable (i.e. suggested for use). Not until it
receives a handshake can it join the network with that IP address. Thus it is during the
reply process where the CM confirms the lease information it was given. Only after this
process can the CM join the network.
At
the DHCP server, the DHCP reply informs the DHCP server whether or not the CM selected it
as the provider of its IP address lease. If it did not (a different DHCP server was
selected as in the case of where multiple DHCP servers are in production), the server
takes the IP address it currently has in reserve for the CM and frees it up for use by the
next available IP address by some CM off that CM’s RF LAN. However, if it was
selected (i.e. its IP address is in the Reply as the server IP), it begins the process of
activating the lease. This process includes updating any parameters associated with the
lease (i.e. last transaction time), committing the lease to its database, and then sending
a response back to the CM informing it that the lease is now valid and ready for use.
IDEA: Another use of the reply may also be to identify rouge DHCP
servers on the network. A rouge DHCP server is an unwanted DHCP server introduced on to a
network that can directly compete with another DHCP server. Since the rouge DHCP server is
unlikely to have the same configuration as the production server, any information it gives
out will cause CMs and the like to fail. Competing with these servers is difficult as they
typically occur within a specific RF LAN and can easily respond to those hosts faster than
any remote server. However, because of the DHCP Reply, these servers can be found
relatively quickly if only the DHCP server was told to look for them. Thus when it sees
cases where some other DHCP server has been selected, it should provide an option for that
transaction to be saved/trapped such that others can track down the culprit – to do
so all they would need is the IP address of the server selected in the DHCP reply and the
IP address of the relay agent. If this was formed as a SNMP trap and sent to a network
management system (NMS) an immediate reaction could take place. Note that some of the need
for this is defused out of the use of directional port filters on the CM. Directional port
filters prevent anything other than DHCP client operation through a customer CM where by
blocking all other types of DHCP traffic (i.e. customer DHCP server traffic) from spilling
out on to the RF LAN.
Figure
4.0 DHCP Ack from DHCP Server
Figure
4.0 shows the DHCP Ack which represents the process by which the DHCP server informs the
CM that the IP address lease it currently has (which it asked for a confirmation of) is
now valid and ready for use. This process is forwarded down to the client via the relay
agent as the previous DHCP Offer.
When the CM receives the ACK, it performs an address resolution
protocol (ARP) on the IP address it received in the lease from the DHCP server. If the ARP
was unsuccessful (i.e. another devices holds its IP address on the RF LAN) the CM
initialization process is interrupted. This causes the CM to fall into a cycle of
attempting to initialize, waiting and then attempting again. This process repeats itself
until the CM is able to complete the initialization. If the ARP is successful, the CM
commits the lease information and joins the network using the IP address information in
the lease. Upon entering the network, the CM performs two important functions. They are to
sync with the time of day (TOD) server and to download its operating configuration via
trivial file transfer protocol (TFTP).
Figure
5.0 CM Syncs with TOD Server
Syncing with TOD server as shown in Figure 5.0
keeps the CM time the same as all other CMs. This is important for reporting events via
simple network management protocol (SNMP) traps or when viewing the operation history logs
on the CM. Note that while all CMs check the presence of a TOD server during this
initialization stage some CM vendors place more emphasis on this information. In these
cases, the CM will not properly boot without the presence of a working TOD server. Other
CM vendors will still attempt to sync with a TOD server but if the attempt
times out (i.e. fails for some reason or other) they will still continue
with the initialization process and boot normally.
Figure
6.0 CM downloads Running Configuration via TFTP
After
the TOD is complete, the CM next attempts to download its working configuration file via
TFTP as shown in Figure 6.0. It uses information contained in the lease (i.e. the boot
file/path name and the boot server IP address) to perform this task. This process is very
simple and involves the CM asking a TFTP server for a specific file. The TFTP server
responds by sending down the contents of the file. Upon receiving the file, the CM aligns
itself to the parameters defined within the configuration file and becomes completely
operational*.
*Note that completely
operational has different meanings depending on the state of the customer behind the CM.
For example, a paying customer will have full access through the CM where as a non-paying
customer will not have any access at all (or perhaps restricted access). Regardless of
what kind of access the CM permits, in all cases the CM is fully operational having
successfully joined the network, synced with the timeserver, and downloaded its running
configuration. One should also note that it is possible to further restrict which IP
addresses the CM will allow the Customer Premise Equipment (CPE) connected behind it to
communicate with. As a result, maximum security can be maintained such that new CMs must
be registered through self service site before they will permit any useful network access.
Initialization of New CPE on the Network:
Only
after the cable modem has successfully joined the network will it permit anything
connected to it to also join the network. The CPE joins the network in a manner similar to
the CM (i.e. via DHCP) only the CPE does not require interaction with the TOD and TFTP
servers. Instead it requires additional information known as Domain Name Servers (DNS) to
provide its applications with a means to resolve names such as www.iastate.edu to their associated IP address. DNS is a
server application (located remote from the CPE but is accessible via the network) that
most CPE applications require to work properly.
Before
the CPE can interact with the network it must have proper facilities to negotiate the
connection. These facilities include a Network Interface Card (NIC), software drivers, protocol support, and a browser.
While all these are readily available, they often are not all standard equipment on most
consumer grade equipment. Thus they must be either purchased separately or requested
custom. Regardless of how they are obtained, there is also the matter of compatibility and
minimum specifications that may further restrict which CPEs can be used with which
broadband Internet service. Minimum specifications are in place to ensure optimum
performance and reduce the complexity of supporting legacy hardware/software.
Assuming
the CPE has been properly qualified a NIC and browser are installed and configured to use
dynamic IP addressing. Depending on the skill of the CPE owner, this phase may be
completed by the owner, a retail store, or someone qualified that is requested on site.
Regardless of who performs this phase, it is likely that it could take some considerable
amount of time – perhaps up to a few days (in the event the owner dropped it off at a
retail store). If the CPE is older yet still meets minimum qualifications it may require a
browser to be installed or upgraded. There may also be minimum qualifications on the
browser depending on the preference* of the ISP. Thus much of the CPE configuration is
driven by the ISP. Once this phase is complete the CPE is now ready to activate Internet
service.
*Note that minimum CPE qualifications may be a sticky point
regarding self activation in a open access environment. This is because various ISP’s
use different browsers (some specifically customized for their service) and each likely
maintain varying support for newer operating system platforms (i.e. Solaris, Linux),
legacy operating system platforms (Windows 95), high end CPE hardware (i.e. Sun), and/or
special purpose operating systems (i.e. BeOS, OpenVMS). The combination of these may limit
ones choices as far as which ISPs will even take which CPEs as little as two years old. It
could also cause confusion to the person attempting to self activate as they may attempt
to select a package of services from various ISPs only to later find out that because of
their CPE they will not be supported (or worst, they are denied service).
Plugging the CPE into the back of the CM (as shown in Figure 7.0)
accomplishes two things. First it allows the CM to learn the MAC address of the CPE’s
NIC which it stores. Second it allows the CPE to find a suitable DHCP server to obtain an
IP address from. The timing of the plugging in is somewhat important as if CPE operator
does this when the CPE is already running it may take some time before the CPE runs
through another cycle of attempting to find a suitable DHCP server. If instead, the CPE is
turned on after it is plugged into the CM this process is sped up considerably. However,
to the average person, it will not be obvious that there is a sequence of events that must
take place in order for the self activation to work the first time. Therefore, the CPE
operator may hang on this point unless they attempt to reboot the CPE. Should the CPE
operator reboot the CPE, the problem will be corrected – even if it is not understood
exactly why it corrected the problem.
Figure 7.0
Connecting CPE to CM
When the CPE attempts to find a DHCP server it
proceeds in a way similar to when the CM. In fact the steps are identical in that the CPE
begins with a broadcast DHCP Discover, followed by a DHCP Offer from the DHCP server,
followed by a DHCP Reply by the CPE, and then finally a DHCP Ack by the DHCP
server completes the process.
Since the CPE is new to the RF LAN and new to
the MSO, it receives a similar IP address to that of the CM. Therefore, during the
initialization (or pre-self activate stage) the CM and CPE receive an IP
address from the same pool of free IP addresses. However they use this IP
address differently. The CM uses this IP address to facilitate follow on
initialization tasks as well as provide access to its configuration via
remote network management. One should note that CM only transmits SNMP traps
? that is the only kind of traffic that originates from the CM. The CPE, on the other hand, both transmits and
receives information based on what applications the CPE owner is running. This demands
address resolution via the domain name system (DNS) to work properly. DNS resolves domain
names such bruce.com into their associated IP address on the Internet. The CPE therefore
is routed (via DNS) where ever based on how DNS resolves the hostnames that are provided
to it by the CPE operator. This ability to route is one of the principle means of making
self activation work. That is, once the CPE receives its DHCP lease and makes it active,
the information contained in the lease direct the CPE to a controlled web site that only
allows self service. The CPE operator is powerless to go anywhere other than the IP
address of the self service site as the CM blocks access to all other IP addresses and the
DNS server assigned to the CPE resolves every hostname to the self service
site.The self service site then becomes the gateway
for the CPE operator to activate, modify, and terminate service. To self activate, the CPE
operator simply invokes a web browser. As part of the web browser startup, it attempts to
display a home (launch) page that is configured in its settings. However, since the DNS
used by the CPE is doctored, the self service site will be displayed instead of the
desired home page. Only, there is some doubt** as to what kind of customer the self
service site is dealing with. For example, the CPE could be an existing customer who has
just swapped out his/her CPE for a new one. They could also be a brand new customer
interested in possibly activating the service. In the case of the latter, a mechanism must
be in place to permit existing customers to log in and add their new CPE to
their account (this is known as self maintenance). Likewise, there needs to
be facilities to enable someone who doesn?t know much about the service to
learn what it has to offer so as to convince them to sign-up or try* out the
service. A demo or trial period may be an option to provide these customers
in an attempt to win them over.
*If one
could utilize scheduling of service provides a way for prospective customers to test drive
the service for some pre-determined amount of time – after which they would only be
allowed to activate.
**Note
that one should be able to detect a previous customer by either their previously
provisioned CM or CPE. Since it is unlikely that both would be new (however still possible
– as a result of a power surge or lightning strike) the self service site should
attempt to provide automation in determining what kind of customer the self service site
is dealing with. This would prompt a more speedy way of accessing account information and
perhaps even having the self service site go directly to the needed modify page.
Any trial period should be tightly coupled and
coordinated with customer care so as to follow up with the CPE operator via the phone
and/or survey in the event they do not elect to proceed with signing up for service.
Additionally, a some type of leads tracking system may need to be woven into the self
service site so as to track its use as well as the types of CPE operators who elect the
trial. While most of this coupling with customer care and interweaving of leads tracking
is likely part of the MSO product web site, some portion of this functionality should also
be part of self service site. Thus some interface or mechanism is needed within the self
service site to push customer care and leads tracking info back to the MSO. The scope and
depth of the information pushed will be dictated* by the MSO.*Note
providing varying data back to the MSO requires all possible information to be stored in
the master database. From this master set of data, subsets of it can be shipped off to the
MSO depending on their needs. The critical piece of this is that all raw data must be
gathered and stored before the MSO can have an option to customize how much of it they
actually need. Using templates would provide MSOs with a framework of how to obtain basic
information from which they could build and administer additional information as needed.
The templates may closely match various types of customer care, billing, and network
management systems to speed MSO access to basic information from the self service site.
Customization of these templates would allow the MSO to tailor what exactly is passed back
to their systems.
At this point, the CPE operator must make a
decision (do they want to sign up for service or not?). If they do not want
to sign up for the service the self service site should ship off this
information to customer care and/or leads tracking for follow up. How
exactly this is done needs to be further researched and/or refined.
If the CPE operator elects to sign up for
service, they should be given this option in the initial display, within any general
information area, and within the trial area. Selecting the sign up option should guide the
CPE operator through a minimum number of pages that permit them to activate their service.
At this point, it should also be possible for the CPE operator to download and print
step-by-step companion documentation. This documentation would help speed the self
activation process while providing the CPE operator to see what is coming and even prepare
by reading the process before they attempt it. The sign up area should be workflow driven
such that any qualifiers (dwelling, financials, whether they already have Cable, etc.) are
questioned and validated prior to allowing the CPE operator to proceed on to provisioning.
In order to check these qualifiers a minimal set of information should be requested of the
CPE operator (e.g. First/Last Name, Address, City, Zip). This information will be used to
validate the qualifiers and bless* the CPE operator as far as allowing them
to continue on with self activation.
*Blessing
the CPE operator may involve one or more checks with MSO and or 3rd parties.
Therefore one should spec out its needs as far as performing qualifier validation checks.
These checks may range from simple look ups to an MSO provided interface to potentially a
credit check that is not provided by the MSO (should check if customers will one day
require this). Successful completion of these checks are needed to determine whether to
proceed in allowing the CPE operator to continue with self activation. The MSO may also
require one to return various information or escalate issues based on the exit states of
the validation. This area needs more information and MSO requirements. After the CPE operator has passed the
qualification checks, they are allowed through the self activation workflow to proceed on
to provisioning. Here the CPE operator selects the type of service they want
from a list of those services that meet their qualifications.
NOTE
service options should be based on a matrix that allows the self service site to quickly
obtain a list of service options compatible with the CPE operator’s qualifications.
For example, some CPE operators may not qualify for higher priced services based on
location because the service requires a business address rather than a residential
address. One may want to develop a kind of profile for CPE operator. The profile should
contain a list of the various qualifiers and provide facilities to quickly determine
eligibility for services.
Selecting the service may also require MSO
intervention when various service features are not directly provisioned (i.e. same day
service calls or elevated customer status). When these features are offered as part of an
overall service package (i.e. home office), the CPE operator may request additional
information before selecting such a service. Thus one should anticipate various spring
boards within the self service site for the CPE operator to step off into
supporting information about service features.
It would also be helpful if the profile
explained above allowed for dynamic price adjustments. These would take advantage of
bundling as the self service site provides access to increasingly more service types
(video, telephony) and features (caller ID, voice mail, History Channel). Also, it is not
certain what determines price. Does the self service site calculate price or does the self
service site look up this information from the MSO or does the self service site just
provide CPE operator selections to the MSO and then it reports back the price. Any of
these options may be desirable depending on the MSO so further information should be
collected to determine which options are needed by the MSO. Regardless, the self service
site should be capable of provisioning multiple services and in any order the MSO chooses.
Alternatively, self service site may just list the various services it maintains and then
allow the CPE operator to provision them in any order they choose. Once the CPE operator has selected which
service they would like to provision. The next step is to provision the base components
(i.e. CM, NIC, phone number, STB, etc.) of the service. Provisioning the base component
should be as painless as possible. To facilitate this, the self service site may automate
the gathering of MAC addresses for example to avoid having the CPE operator hand type them
in. The DHCP information option* provides a handy way to associate the CM and CPE MAC
addresses. Since these are related and the self service site knows the IP address of the
CPE (from the CGI key value pairs), the CPE and CM MAC addresses do not have
to be hand typed during the provisioning of the base components.
*Note
the DHCP information option is part of CMTS functionality that changes the DHCP packets
coming from CPEs. As part of this functionality, the CMTS takes the MAC address of the CM
associated with a CPE and places it in DHCP option 62 of the CPE DHCP packets. This option
has been named the DHCP information option and is typically placed in the CPE lease which
is stored in the DHCP server. Since the self service site knows the IP address of the CPE,
one can obtain the MAC address of both the CPE and the CM it uses by looking up the lease
of the CPE by its IP address.
Provisioning the CM and CPE MAC addresses
allows them to receive different information (DHCP options) from the DHCP server. This
happens as a result of being placed in the DHCP server’s registry. The registry is a
pool of MAC addresses that have been made known to the DHCP server. Each registered entry
can have individual DHCP options assigned to it (e.g. WINS = 1.1.1.1). Individual DHCP
registry entries can also be associated with an IP pool as well as one or more policies.
As a result, the CPE or CM that is now registered can be customized to the point where it
is unique to all other registry entries or be placed into one or more groups. When it is
placed into multiple groups, an internal hierarchy within the DHCP server
handles which values have prescience over others when the same option is set
differently across multiple groups.However placing the MAC address into the
registry is will not cause the DHCP client (CM or CPE) to immediately assume the new DHCP
options associated with its entry. This is because the DHCP server does not initiate
contact with its DHCP clients – rather it just responds to requests from the clients.
Therefore, the DHCP server cannot disseminate new options until the DHCP client asks for
an update. This update could take place at the next lease renewal when the DHCP client
inquires about the lease. But in terms of self service, it would be best if this was
triggered somehow during the provisioning of the service. Unfortunately, there is no way
to trigger the DHCP client to dispose of its lease and request a new one (at least not
from a remote web server). Therefore, the self service site must require two things to
make this transition happen smoothly. The first is that temporary IP address leases (those
given to new, never provisioned MAC addresses) be extremely short – say around 60
seconds. Having a short lease allows the lease to quickly expire once the MAC address that
it belongs to becomes provisioned. It is important that the lease expire* between the
transition of going from never been provisioned to being provisioned because the IP
address must change during this transition (one could also delete the lease – this
will be explained later). The only way to change IP pools belonging to the same relay
agent is to force an expire (or delete) on the current lease and then when the new request
comes in a new lease will be created in the desired pool and the old lease will be freed
up for use. The other requirement is that the CPE operator reboot their CPE. Rebooting the
CPE forces the DHCP client to request an update on the lease. If that lease has changed or
is now expired the DHCP server will disseminate new information based on however the DHCP
registry entry is configured.
*Note
that the CPE is typically given a private IP address when it is first connected on the
network. This private IP address is retained until such time as it becomes provisioned (or
registered with the DHCP server) after which it may obtain a public IP address. The CM can
also be treated this way – in terms of given a private IP address. However, in order
to differentiate this IP address from one it would receive later (since it would continue
to have a private IP address) one would need to break the range of IP addresses given to
DHCP clients into several pools (one for public IP addresses -- registered, one for
private IP addresses -- registered, and one for private IP addresses -- unregistered) on
each RF LAN. One may also just maintain two pools (private and public) but this would mix
registered and unregistered MAC addresses.
In an open access situation, the number of IP
address ranges above will depend on the number of ISPs. To support open access using
multiple secondary addresses one would need to set up each and every RF LAN
as follows: For a three ISP open access
offering, the RF LAN would need to be set up something like the following
(meant as an example only):
24.0.0.1/24
ISP #1 – public IP
address pool
209.0.0.1/24 ISP #2 – public IP address pool
109.0.0.1/24 ISP #3 – public IP address
pool
10.0.0.1/24
Registered -- private IP
address pool
10.1.0.1/24
Unregistered ? private IP address pool
In this example, All 5
networks would be set up on the RF LAN interface. One of them would be
selected as the primary and all the rest would be secondary networks.
Selecting a service belonging to one of the
ISP would require that the CPE be provisioned into that ISPs subnet group and possibly
their service group all depending on the service options selected. Since in true open
access one can mix and match services this may complicate how services are provisioned and
how policy groups are joined in the DHCP server. Regardless, one thing is for sure and
that is when a CPE operator selects an ISP they will join that ISP?s subnet
group. Joining that group, forces that MAC address to only obtain leases
from that ISP?s subnets* (again once their current lease expires or is
deleted).
*Using
multiple ISPs requires that each and every RF LAN contain address space for each ISP. This
address space must support a roaming feature that enables a customer off of one RF LAN to
move or roam to another RF LAN and obtain a new IP address but one from their ISPs subnet
on that RF LAN.Managing IP address space in an open access
environment will be extremely complex. This is because there is a constant component (the
CM) and a varying component (the CPE). The constant component can be managed via the
registered private pool of addresses. Basically, this pool determines the maximum number
of active CMs that can be supported on the RF LAN. The unregistered private space as well
as the public space(s) are where things get ugly. The private unregistered space can
support a maximum number of CMs and CPEs and since these leases are short in duration IP
address management is automatic (note one of the uses of DHCP is to manage IP addresses
– for example by shortening leases one can constantly provide IP addresses to new
clients where by deactivating/reusing old/expired ones on the fly). The public space(s)
will be largely unused however and must minimally accommodate some fraction of the maximum
number of active CPEs possible on the RF LAN. Determining what this fraction is will
stress some threshold of wasted IP address space (IP addresses dedicated to the RF LAN
that may never get used) in exchange for not denying any new customers for that ISP on
that particular RF LAN. Thus, during the provisioning process, some assurance needs to
take place so as to not permit new customers to be provisioned to an ISP that is out of
usable public IP addresses for a particular RF LAN. Furthermore, some mechanism may be
needed to alert operations of situations where IP addresses are running low (reached some
percentage available or number left).
Once the base components have been
provisioned, the CPE operator is then guided through additional provisioning steps
depending on the services s/he selected. These steps may include provisioning additional
CPEs either manually (by typing in the MAC address or explaining the steps they would need
to complete to provisioning them automatically). The steps may also include provisioning
email addresses, phone options, video channels, etc. Once all these options have been
provisioned, the CPE operator is provided with a confirmation number. This number
corresponds to the change ticket that was entered into the MSO’s customer care
system. If any problems were encountered during/after this process the CPE
operator can simply call customer care and ask them to help them complete
what was attempted via the self service site. It may also be desirable to
flash the transaction number earlier in the process so in case anything goes
wrong the customer can call in the problem using the number (which may not
show up unless the transaction is completed). On-line support or help may
also be used during this process to reduce some of the need for phone
support. On-line support should decipher the transaction number and attempt
to determine what operation did not complete or what piece of information
was missing that caused the transaction to fail or hang. Note that any
unexplained failure or hanging should be sent to a bug reporting feature
that is built into the software. As a result, the self service site should
handle any and all exit cases.
Periodic quality control may spot check
various self service change tickets to make sure that what was attempted by the CPE
operator actually was changed in the provisioning and billing systems. An attractive
feature for MSOs would be the ability synchronize with billing or perform
internal audits to ensure that all customers are set up correctly. Today,
these audits are performed manually and are very difficult to perform as
several organizations within the company and outside the company must
provide information to account for all customers. If these audits were
performed at regular intervals, discrepancies could be addressed
immediately. Follow on efforts could then study these accounts for the cause
of the account discrepancy ? the results of which could be sent to a bug
report.Changing ISPs in open access requires the CPE
to change its IP address. Similar to the process of registering, the existing CPE IP
address must be released from the CPE and expired or removed from the DHCP server. The
first step in this process should be to register the CPE MAC address with the new
ISP’s subnet group. Once this is complete, the CPE MAC address will obtain a new IP
address from this subnet group once its current IP address expires. However, the current
IP address lease may be good for quite a while – unlike the unregistered lease that
is very short. So, even though the CPE is provisioned into a new subnet
group it cannot obtain a new lease until its existing lease expires.
One way to force a lease to renumber from the
self service site is to delete the existing lease. Deleting the existing lease forces the
DHCP server to respond to a registered CPE by giving it a new lease appropriate to the
subnet group it belongs (i.e. the new ISP). Since this will then be a new IP address from
the subnet belonging to the new ISP selected, the CPE is forced into a renumber* the next
time it requests info on its lease. However, to force the CPE to request new
info on the lease, a reboot may be the only sure way to initiate this.
*Note
the ping timeout would prevent DHCP server(s) from reusing the DHCP client’s current
IP address – when in actuality it should be free only the DHCP client has not given
it up yet (because it is in the process of obtaining a new IP address). The DHCP server(s)
will set this IP address aside and attempt to offer it to a future DHCP client after some
designated timeout.
Providing email to customers in open access
may be quite a challenge. For example, say one ISP reduces the price of its email services
to a fraction of what the others charge. This would create a demand for these email
services and attract customers to select or change over to the cheaper email services.
However, changing email would cause problems for the CPE operator in that their email
address would change (e.g. from johndoe@isp1.com to johndoe22@isp2.com ).
This would cause all kinds of problems for the CPE operator perhaps even to the point
where they would not be inclined to change ISPs or email. To avoid problems such as this,
open access should provide domain independent services (DIS). Domain independent services
are ISP dependent for the service (hardware and software) but are ISP independent from the
Internet. As an example of domain independent service, the CPE operator would access the
ISP’s email server to get and send their email using their MSO account name and
password. However, their Internet email address would be affiliated with the MSO (e.g. johndoe@att.net). Their actual ISP specific email
address would be used only to get and send their email and not be accessible from the
Internet (i.e. all email would need to flow through att.net for it to be received). In
this case, att.net becomes a director of email sending it to the current ISP selected by
the CPE operator. The benefit of domain independent services is that the CPE operator is
free to change ISPs without forcing the need to inform all his/her contacts of a change in
their email address. Likewise, other services (e.g. personal web services) should be made
domain independent as well to eliminate the need for the customer to redirect others to
currently used provider while providing the customer with the maximum flexibility to
select who every they want to provide their services with the least amount of pain.
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.
|