DOCSIS Firmware/Flashware Version Management
Managing firmware by exploiting DHCP

By: Bruce Bahlmann - Contributing Author (your feedback is important to us!)

Created: November 9, 2000

Problem:

One of the many problems that plague MSO’s high speed Internet over cable service is that of maintaining up to date revisions of cable modem flashware. Flashware is the specific software that runs on each cable modem. This software controls the cable modem operation and can be downloaded remotely to the cable modem via a network. Using flashware is important as it allows the cable modem vendor to correct, enhance cable modem operation without the need to recall the devices. The responsibility for performing these upgrades falls into either the hands of the MSO or the ISP depending on the contractual arrangements.

Unfortunately, this software is different for each cable modem model. For example, take two certified DOCSIS cable modem vendors such as 3Com and GI. Each vendor developed its flashware independently thus each vendor’s flashware is different and not compatible with each other. There are also differences between flashware among each vendor’s products. In the case of 3Com, they currently offer several different DOCSIS cable modem models and each of these different models require their own flashware (each model’s flashware is not compatible with another model’s flashware). When a vendor makes improvements to their flashware these software images are made available to the MSO or ISP for testing/confirmation/distribution.  

While some flashware improvements may not be necessary, others may be the direct result of a bug reported by and MSO/ISP and thus be desperately needed. As a result, the distribution of the flashware to the cable modems can range from casual to service critical. Dealing with the distribution of cable modem flashware currently requires manual intervention. This is because each MSO/ISP supports several different cable modems and they are all mixed together across numerous networks. Some vendors provide a tool that requires the MSO/ISP to connect a PC with this tool to each and every network to allow it to discover its cable modems and then proceed with upgrading its model’s flashware. However, because each vendor is not as kind to the MSO/ISP these tools are rare, do not often work across vendors cable modems, and are considered extras (i.e. the MSO/ISP must purchase the tool separately – or commit to purchasing large quantities of cable modems). Flashware may also vary with each cable modem model over time as the version shipped from the factory changes. This may be problematic as newer versions have not been certified/tested by the MSO/ISP and may yield unpredictable results when connected along side other cable modems. As a result, MSO/ISP may be required to change the flashware version prior to installing the cable modem in the customer’s home. 

Essentially, maintaining cable modem flashware is manual process and cannot be addressed by each vendor independently. What is needed is a system that can manage cable modem flashware such that the MSO/ISP can dictate which cable modem flashware versions it supports. The system must also allow the MSO/ISP to easily change the flashware version for any cable modem model easily with out the need to manually create scripts, discover cable modems in the field or some database, and then reach out and touch each one to force an upgrade. 

Requirements:
 

• Set an accepted flashware version for each vendor’s modem
• Set an accepted flashware version for each vendor modem model
• Settings for flashware version are network independent – only need to set accepted flashware versions in one place for the entire system.
• Each modem’s flashware version must be verified upon completion of up/down grade.
•  A database will maintain association between modem and currently held flashware version as well as verification state.
• Upon entry to the system modem flashware version will adhere to the version set for the system (bypassing the need for operator to upgrade flashware before installation).
• Changes to the system flashware version settings will not create a broadcast storm – instead will upgrade all modems over a reasonable period of time.
• Flashware management system must be compatible with other modems (such as DSL).

 Proposed Solution:

The DHCP server provides an idea place to initiate version management. While some feel a DHCP server should do just DHCP, this forces much more customization in other parts of the system that will outweigh the simplicity (single point of control) of using DHCP as the basis for flashware version management. Furthermore, building this functionality into a DHCP server allows one to further differentiate its DHCP server from the competition*. 

*Note that building a basic (generic) DHCP server serves no purpose. There are many of these on the market today that do exactly that (basic DHCP). However, providing DHCP alongside value added services enable one to provide one of a kind DHCP services – preventing other DHCP servers from directly competing. 

The DHCP DISCOVER and DHCP REQUEST represent unique opportunities to manage flashware versions that are explained in more detail in the pseudo code below. 

Pseudo code for proposed additional DHCP server logic:

1.     Modem performs a DHCP DISCOVER on the network

2.     If the DHCP server receives a DHCP DISCOVER it checks its registry to see if modem exists.

a.     If the DHCP server’s flashware management function is activated, it proceeds with maintaining modem flashware.

i.             Proceed with flashware management logic below.

b.     If the DHCP server’s flashware management function is NOT activated, flashware management function is skipped (proceed with normal DHCP behavior).

3.     If the DHCP server receives a DHCP REQUEST it checks its registry to see if modem exists

a.     If the DHCP REQUEST does NOT contain a DHCP server IP address proceed as a potential flashware management opportunity. (NOTE: The Request message will contain a DHCP server identifier option when selecting an Offer, and will not contain a server identifier when verifying/extending a lease.)

i.    If the DHCP server’s flashware management function is activated, it proceeds with maintaining modem flashware.

1.     Proceed with flashware management logic below.

ii.             If the DHCP server’s flashware management function is NOT activated, flashware management function is skipped (proceed with normal DHCP behavior).

b.     If the DHCP REQUEST does contain a DHCP server IP address this is not a valid opportunity to perform flashware management so proceed with normal DHCP behavior.

 Pseudo code for proposed flashware management function: 

1.     If the modem exists in the registry AND has a service group selected (i.e. its an active device rather than a NEW modem), its entry is checked for a verification flag

a.     If a verification flag exists, its registry flashware version is compared with that of its profile.

                 i.      If the modem’s MAC address does NOT match those listed in the profile the modem proceeds with normal DHCP logic (is currently not handled via flashware management system).

                ii.      If the modem’s MAC address registry matches those listed in the profile and its flashware version matches the profile flashware version the DHCP DISCOVER is sent on its way through normal DHCP logic (that which defines its lease and DHCP options -- bootfile and TFTP server IP address).

               iii.      If the modem’s MAC address matches those listed in the profile and its flashware version does NOT match the profile flashware version the modem is sent a temporary (short) lease and the profile’s flashware version along with the TFTP server defined in the profile.

1.     If the profile entry for the modem does not contain a TFTP server and/or file/path name the default values are used in leu of the entry’s values.

b.     If verification flag does NOT exist (the flashware version has not been verified), the DHCP server attempts to check the version via an SNMP MIB defined in the profile for that modem (during this time, the modem receives a short lease from the DHCP server which gives SNMP enough time to complete the query).

                  i.      If the profile entry for the modem does not contain a MIB the default MIB is used.

2.     If the modem does exist in the registry but does NOT have a service group selected (i.e. it does not yet represent an active customer), its entry is checked for a verification flag.

a.     If a verification flag exists, its registry flashware version is compared with that of its profile.

                 i.      If the modem’s registry flashware version matches the profile flashware version the DHCP DISCOVER is sent on its way through normal DHCP logic (that which defines its lease and DHCP options -- bootfile and TFTP server IP address).

                ii.      If the modem’s registry flashware version does NOT match the profile flashware version the modem is sent a short lease and the profile’s flashware version and TFTP server.

1.     If the profile entry for the modem does not contain a TFTP server and/or file/path name the default values are used in leu of the entry’s values.

b.     If verification flag does NOT exist (the flashware version has not been verified), the DHCP server attempts check the version via an SNMP MIB defined in the profile for that modem (during this time, the modem receives a short lease from the DHCP server which gives SNMP enough time to complete the query).

3.     If the modem does NOT exist in the registry, the DHCP server forces the creation of an unregistered entry, assigns the entry a unverified flashware version, and attempts to upgrade the modem’s flashware by sending the modem a short lease along with its profile’s flashware path/file and TFTP server address. 

Successful management of modem flashware is dependent on a single configuration file called a flashware profile (see Figure 1.0). The flashware profile contains information that allows the DHCP operator to manage flashware images for numerous modems. The basic assumption that the flashware profile is based on is that the modem MAC address will differentiate various modem vendors as well as different modem models. The first 6 characters of a MAC address are referred to as the vendor ID. The vendor ID differentiates one vendor from another – this ensures that the flashware management system will work across vendors. To address various modem models that any one vendor produces, a range of modem MAC addresses are supported by the flashware management system. Each range defined allows the flashware management system to accommodate modem models that typically span a range of sequential MAC addresses. The fields of flashware management system’s profile are described below. 

Figure 1.0 Flashware Profile Format 

Specific functionality of profile: 

• Default settings will not replace those for modems that do not match any of the entries in the profile. If a modem MAC does not match entries in the profile the DHCP server does not manage its flashware.
• If a profile entry’s begin/end of MAC address range are the same it will only match a single modem.

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.

(C) Copyright Birds-Eye.Net, All rights reserved.
It is against the law to reproduce this content or any portion of it in any form without the explicit written permission of Birds-Eye Network Services, LLC. Federal copyright law (17 USC 504) makes it illegal, punishable with fines up to $100,000 per violation plus attorney's fees.