Method and system for cable modem initialization using dynamic servers

Abstract

A method and system for initializing cable modems with dynamic protocol servers is provided. The method and system allow a dynamic protocol server such as a dynamic Trivial File Transfer Protocol ("TFTP") server to override a request for a standard configuration file whose name is supplied to a cable modem in a Dynamic Host Configuration Protocol ("DHCP") response message during initialization. Instead, the dynamic TFTP server identifies a cable modem by performing a reverse Domain Name System lookup of an Internet Protocol address used for the cable modem. Based on the determined identity for the cable modem, the dynamic TFTP server constructs a new configuration file specifically for the cable modem and transfers it to the cable modem. The new configuration file is different from the default configuration file originally requested by the cable modem. Creating a new configuration file with a dynamic protocol server allows greater flexibility for configuring cable modems in a data-over-cable system.

Claims

I claim:

1. In a data-over-cable system including a plurality of network devices, a method of initializing a network device, the method comprising the following steps:

receiving a first message on a first protocol server with a first protocol from a network device including a request for a first configuration file to configure the network device, wherein the name for the first configuration file was obtained by the network device from a second protocol server using a second protocol during an initialization sequence;

determining an identity for the network device by performing a reverse Domain Name System lookup on a network address from the first message, wherein the identity includes a device type for the network device;

constructing a second configuration file with a plurality of configuration parameters based on a determined identity for the network device; and

transferring the second configuration file to the network device from the first protocol server using the first protocol in response to the request in the first message for the first configuration file, thereby providing a second configuration file specifically for the network device and different from the requested first configuration file.

2. A computer readable medium having stored therein instructions for causing a central processing unit to execute the steps of the method of claim 1.

3. The method of claim 1 wherein the first protocol server is a Trivial File Transfer Protocol server and the second protocol server is a Dynamic Host Configuration Protocol server.

4. The method of claim 1 wherein the Trivial File Transfer Protocol server is a dynamic Trivial File Transfer Protocol server.

5. The method of claim 1 wherein the first protocol is a Trivial File Transfer Protocol and the second protocol is a Dynamic Host Configuration Protocol.

6. The method of claim 1 wherein the network device is a cable modem.

7. The method of claim 1 wherein the step of determining an identity for the network device includes determining a device type for the network device by performing a reverse Domain Name System lookup using an Internet Protocol address from a header field in the first message from the network device.

8. The method of claim 1 wherein the step of constructing a second configuration file with a plurality of configuration parameters based on a determined identity for the network device includes constructing the second configuration file with required standard configuration parameters, and any of optional standard configuration parameters, or vendor-specific configuration parameters.

9. The method of claim 8 wherein the required standard configuration parameters, optional standard configuration parameters and vendor-specific configuration parameters in the second configuration file are encoded in a type-length-value encoding format including two or more message integrity check values used for authentication.

10. The method of claim 1 wherein the second configuration file includes one or more message integrity check values to verify the integrity of the configuration parameters.

11. The method of claim 1 wherein the second configuration file includes one or more configuration parameters not included in the requested first configuration file.

12. In a data-over-cable system including a plurality of network devices, a method of initializing a network device, the method comprising the following steps:

receiving a first message with a first protocol on a first protocol server from a network device including a request for a first configuration file to configure the network device, wherein the name for the first configuration file was obtained by the network device from a second protocol server using a second protocol during an initialization sequence;

determining an identity for the network device by performing a Reverse Domain Name system lookup on a network address from the first message, wherein the identity includes a device type for the network device; and

transferring configuration information dynamically as a data stream to the network device in a pre-determined format based on a determined identity for the network device using the first protocol, wherein the configuration information is dynamically sent as a data stream in response to the request in the first message for the first configuration file and wherein the configuration information sent dynamically as a data system is different form configuration information in the first configuration file.

13. A computer readable medium having stored therein instructions for causing a central processing unit to execute the steps of the method of claim 12.

14. The method of claim 12 wherein the step of determining an identity for the network device includes determining a device type for the network device by performing a reverse Domain Name System lookup on an Internet Protocol address from a header field in the first message from the network device.

15. The method of claim 12 wherein the step of transferring configuration information dynamically as a data stream to the network device in a pre-determined format based on a determined identity for the network device includes transferring required standard configuration parameters and any of optional standard configuration parameters or vendor-specific configuration parameters encoded in a type-length-value encoding format including two or more message integrity check values used for authentication.

16. The method of claim 12 wherein the first protocol server is a dynamic Trivial File Transfer Protocol server.

17. A dynamic protocol server for transferring configuration information for a network device in a data-over-cable system, the dynamic protocol server comprising in combination:

a plurality of network device type identifiers, for identifying a plurality of network device types, wherein a network device identity is obtained by performing a reverse Domain Name System look-up on a network address in a protocol message sent to the dynamic protocol server by a network device requesting a first configuration file, wherein the plurality of network device type identifiers include device types for a plurality of network devices; and

a plurality of configuration information constructors, for dynamically constructing configuration information for initializing a network device based on a device type determined by a network device type identifier, wherein configuration information is constructed from the plurality of configuration information constructors based on a determined network device identity for a network device, thereby providing a second configuration file specifically for the network device and different from a first configuration file originally requested by the network device.

18. The dynamic protocol server of claim 17 wherein the dynamic protocol server is a dynamic Trivial File Transfer Protocol server and the dynamic Trivial File Transfer Protocol server sends a network device a second configuration file or configuration information as a dynamic data stream that is constructed based on a determined identify for the network device instead of a first configuration file requested by the network device.

19. The dynamic protocol server of claim 17 wherein the plurality of network device identifiers determine a device type for a cable modem by performing a reverse Domain Name System lookup on an Internet Protocol address from a header field in a Trivial File Transfer Protocol message.

20. The dynamic protocol server of claim 17 wherein the plurality of configuration information constructors include required standard configuration parameters, and any of optional standard configuration parameters or vendor-specific configuration parameters for initializing a cable modem.

21. In a data-over-cable system including a plurality of cable modems, a method of initializing a cable modem, the method comprising the following steps:

receiving a first Trivial File Transfer Protocol message on a dynamic Trivial File Transfer Protocol server from a cable modem including a request for a first configuration file to configure the cable modem, wherein the name for the first configuration file was obtained by the cable modem from a Dynamic Host Configuration Protocol server using a Dynamic Host Configuration Protocol during an initialization sequence;

determining an identity for the cable modem by performing a reverse Domain Name System lookup on the Internet Protocol address for the cable modem from the first Trivial File Transfer Protocol message, wherein the identity includes a device type for the cable modem;

constructing a second configuration file with a plurality of configuration parameters based on a determined identity for the cable modem; and

transferring the second configuration file to the cable modem from the dynamic Trivial File Protocol server using the Trivial File Protocol in response to the request in the first Trivial File Protocol message for the first configuration file, thereby providing a second configuration file different from the requested first configuration file and specifically for the determined identity of the cable modem.

22. A computer readable medium having stored therein instructions for causing a central processing unit to execute the method of claim 21.

Description

FIELD OF INVENTION

The present invention relates to communications in computer networks. More specifically, it relates to a method and system for using a dynamic configuration server for cable modem configuration.

BACKGROUND OF THE INVENTION

Cable television networks such as those provided by Comcast Cable Communications, Inc., of Philadelphia, Pa., Cox Communications of Atlanta, Ga., Tele-Communications, Inc., of Englewood, Colo., Time-Warner Cable, of Marietta, Ga., Continental Cablevision, Inc., of Boston, Mass., and others provide cable television services to a large number of subscribers over a large geographical area. The cable television networks typically are interconnected by cables such as coaxial cables or a Hybrid Fiber/Coaxial ("HFC") cable system which have data rates of about 10 Mega-bits-per-second ("Mbps") to 30+ Mbps.

The Internet, a world-wide-network of interconnected computers, provides multi-media content including audio, video, graphics and text that typically requires a large bandwidth for downloading and viewing. Most Internet Service Providers ("ISPs") allow customers to connect to the Internet via a serial telephone line from a Public Switched Telephone Network ("PSTN") at data rates including 14,400 bps, 28,800 bps, 33,600 bps, 56,000 bps and others that are much slower than the about 10 Mbps to 30+ Mbps available on a coxial cable or HFC cable system on a cable television network.

With the explosive growth of the Internet, many customers have desired to use the larger bandwidth of a cable television network to connect to the Internet and other computer networks. Cable modems, such as those provided by 3Com Corporation of Santa Clara, Calif., U.S. Robotics Corporation of Skokie, Ill., and others offer customers higher-speed connectivity to the Internet, an intranet, Local Area Networks ("LANs") and other computer networks via cable television networks. These cable modems currently support a data connection to the Internet and other computer networks via a cable television network with a "downstream" data rate of 30+ Mbps, which is a much larger data rate than can be supported by serial telephone line used over a modem.

However, most cable television networks provide only uni-directional cable systems, supporting only a "downstream" data path. A downstream data path is the flow of data from a cable system "headend" to a customer. A cable system headend is a central location in the cable television network that is responsible for sending cable signals in the downstream direction. A return data path via a telephone network, such as a Public Switched Telephone Network provided by AT&T and others, (i.e., "telephony return") is typically used for an "upstream" data path. An upstream data path is the flow of data from the customer back to the cable system headend. A cable television system with an upstream connection to a telephony network is called a "data-over-cable system with telephony return."

An exemplary data-over-cable system with telephony return includes a cable modem termination system, a cable television network, a public switched telephone network, a telephony remote access concentrator, a cable modem, customer premise equipment (e.g., a customer computer) and a data network (e.g., the Internet). The cable modem termination system and the telephony remote access concentrator together are called a "telephony return termination system."

The cable modem termination system receives data packets from the data network and transmits them downstream via the cable television network to a cable modem attached to the customer premise equipment. The customer premise equipment sends responses data packets to the cable modem, which sends response data packets upstream via the public switched telephone network to the telephony remote access concentrator, which sends the response data packets back to the appropriate host on the data network. The data-over-cable system with telephony return provides transparent Internet Protocol ("IP") data traffic between customer premise equipment, a cable modem and the data network (e.g., the Internet or an intranet). As is known in the art, IP is a routing protocol designed to route traffic within a network or between networks.

When a cable modem used in the data-over-cable system with telephony return is initialized, it will make a connection to both the cable modem termination system via the cable network and to the telephony remote access concentrator via the public switched telephone network. If the cable modem is using telephony return, it will acquire telephony connection parameters on a downstream connection from the cable modem termination system and establish a Point-to-Point Protocol ("PPP") connection to connect an upstream channel to the telephony remote access concentrator. As is known in the art, PPP is used to encapsulate datagrams over a serial communications link. After a PPP connection is established, the cable modem negotiates a telephony IP address with the telephony remote access concentrator. The telephony IP address allows the customer premise equipment to send IP data packets upstream to the telephony remote access concentrator via the public switched telephone network to the data network.

The cable modem also makes an IP connection to the cable modem termination system so that IP data received on the cable modem termination system from the data network can be forwarded downstream to the customer premise equipment via the cable network and the cable modem.

Once an IP address is obtained on the cable modem termination system, the cable modem obtains the name of a configuration file used to complete initialization. The cable modem downloads a configuration file from a central location in the data-over-cable system using a Trivial File Transfer Protocol ("TFTP") server. As is known in the art, TFTP is a very simple protocol used to transfer files, where any error during file transfer typically causes a termination of the file transfer.

There are several problems associated with using a configuration file from a central location to configure a cable modem. In a typical cable modem initialization scenario, a Dynamic Host Configuration Protocol ("DHCP") is used to obtain an IP address and to obtain the name of a configuration file on a DHCP server from which configuration parameters are obtained for cable modem initialization. The configuration file is downloaded to the cable modem with TFTP using a TFTP server. Each DHCP server has an identical copy of the same configuration file. Thus, each cable modem in the data-over-cable system is configured exactly the same way with the same configuration file with TFTP.

Since all cable modems in the data-over-cable are not made by the same manufacturer and may be used for a number of different purposes, a single common configuration file is inappropriate for all cable modems in the data-over-cable system. However, if more than one configuration file name is used in a data-over-cable system, DHCP servers would be required to maintain a listing of configuration files for multiple cable modem types. This would not be practical in a data-over-cable system. In addition, modifying DHCP servers to use more than one configuration file violates the spirit of the DHCP standard and is expensive since a large number of DHCP servers, including third-party DHCP servers in the data-over-cable system would require modifications.

It is desirable to allow an individual cable modem to use configuration information from a configuration file different from the default configuration file without modifying existing DHCP servers or the DHCP initialization process used to obtain an IP address and a configuration file name.

SUMMARY OF THE INVENTION

In accordance with an illustrative embodiment of the present invention, the problems associated initializing a cable modem with configuration parameters from a common configuration file are overcome. A method and system is provided for initializing a cable modem with a configuration file different from a common default configuration file.

The method includes receiving a first message on a first protocol server from a network device including a name for a first configuration file to configure the network device. The name for the first configuration file was obtained by the network device from a second protocol server using a second protocol during an initialization sequence. An identity for the network device is determined using one or more fields from the first message. A second configuration file is constructed with multiple configuration parameters based on a determined identity for the network device. The second configuration file is transferred to the network device from the first protocol server using a first protocol in response to the request in first message for the first configuration file. Thus, the network device receives a second configuration file different from the requested first configuration file.

In an illustrative embodiment of the present invention, a TFTP server connected to a cable modem termination system receives a TFTP Read-ReQuest ("RRQ") message from a cable modem in a data-over-cable system. The TFTP RRQ message includes a message field including a name for a default configuration file sent to the cable modem by a DHCP server in a DHCP response message during an initialization sequence. The TFTP server extracts an IP address (e.g., 124.35.14.58) for the cable modem which is included as part of a message header in the TFTP RRQ message. The TFTP server performs a reverse look-up on the cable modem's IP address through a Domain Name System ("DNS") using a reverse DNS name space, also called the "in-addr.arpa" name space. Reverse DNS mapping maps the IP address 124.35.14.58 back to a domain name for the cable modem (e.g., "cm-type1.data-over-cable.net"). As is known in the art, a domain name is an English translation of a computer network address such as an IP address.

The TFTP server determines what type of configuration parameters the cable modem requires by looking up the domain name determined for the cable modem in a table. The TFTP server constructs a second configuration file with required configuration parameters, and any of optional configuration parameters or vendor specific configuration parameters for the cable modem based on its domain name. The second configuration file constructed specifically for the cable modem is transferred to the cable modem from the TFTP server using the TFTP protocol even though the cable modem requested a first configuration file (i.e., a default configuration file) in the TFTP RRQ message. However, the present invention is not limited to the network devices, protocol servers and configuration files described above, and other network devices, protocol servers and configuration file could also be used.

An illustrative embodiment of the present invention allows a TFTP server, called a "dynamic TFTP server," to provide a configuration file to an individual cable modem different than a common default configuration file requested by the cable modem. The dynamic TFTP server constructs a configuration file specifically for a cable modem based on a domain name for a cable modem and ignores a request for a default configuration file supplied to the cable modem during the DHCP initialization sequence. Cable modems receive a configuration file different from the default configuration file supplied by a DCHP server without modifications to any DCHP servers or the DHCP initialization process. This provides flexibility for initialization of cable modems in a data-over-cable system. An illustrative embodiment of the present invention is described with respect to dynamic TFTP server. However, other dynamic servers may also be used and the present invention is not limited to dynamic TFTP servers.

The foregoing and other features and advantages of an illustrative embodiment of the present invention will be more readily apparent from the following detailed description, which proceeds with references to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a cable modem system with telephony return;

FIG. 2 is a block diagram illustrating a protocol stack for a cable modem;

FIG. 3 is a block diagram illustrating a Telephony Channel Descriptor message structure;

FIG. 4 is a block diagram illustrating a Termination System Information message structure;

FIG. 5 is a flow diagram illustrating a method for addressing hosts in a cable modem system;

FIG. 6 is a block diagram illustrating a Dynamic Host Configuration Protocol message structure;

FIGS. 7A and 7B are a flow diagram illustrating a method for discovering hosts in a cable modem system;

FIG. 8 is a block diagram illustrating a data-over-cable system for the method illustrated in FIGS. 7A and 7B;

FIG. 9 is a block diagram illustrating the message flow of the method illustrated in FIGS. 7A and 7B;

FIGS. 10A and 10B are a flow diagram illustrating a method for resolving host addresses in a data-over-cable system;

FIG. 11 is a flow diagram illustrating a method for resolving discovered host addresses; and

FIG. 12 is a block diagram illustrating the message flow of the method illustrated in FIG. 10;

FIGS. 13A and 13B are a flow diagram illustrating a method for obtaining addresses for customer premise equipment;

FIGS. 14A and 14B are a flow diagram illustrating a method for resolving addresses for customer premise equipment;

FIGS. 15A and 15B are a flow diagram illustrating a method for addressing network host interfaces from customer premise equipment;

FIGS. 16A and 16B are a flow diagram illustrating a method for resolving network host interfaces from customer premise equipment;

FIG. 17 is a block diagram illustrating a message flow for the methods in FIGS. 15A, 15B, and 16A and 16B;

FIG. 18 is a block diagram illustrating a data-over-cable system with dynamic protocol servers;

FIG. 19 is a flow diagram illustrating a method for obtaining a configuration file for a cable modem;

FIG. 20 is a flow diagram illustrating a method for obtaining a configuration file for a cable modem;

FIG. 21 is a block diagram illustrating a configuration file format for a cable modem; and

FIG. 22 is a flow diagram illustrating another method for obtaining a configuration file for a cable modem.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Cable Modem System with Telephony Return

FIG. 1 is a block diagram illustrating a data-over-cable system with telephony return 10, hereinafter data-over-cable system 10. Most cable providers known in the art predominately provide uni-directional cable systems, supporting only a "downstream" data path. A downstream data path is the flow of data from a cable television network "headend" to customer premise equipment (e.g., a customer's personal computer). A cable television network headend is a central location that is responsible for sending cable signals in a downstream direction. A return path via a telephony network ("telephony return") is typically used for an "upstream" data path in uni-directional cable systems. An upstream data path is the flow of data from customer premise equipment back to the cable television network headend.

However, data-over-cable system 10 of the present invention may also provide a bi-directional data path (i.e., both downstream and upstream) without telephony return as is also illustrated in FIG. 1 and the present invention is not limited to a data-over-cable system with telephony return. In a data-over cable system without telephony return, customer premise equipment or cable modem has an upstream connection to the cable modem termination system via a cable television connection, a wireless connection, a satellite connection, or a connection via other technologies to send data upstream to the cable modem termination system.

Data-over-cable system 10 includes a Cable Modem Termination System ("CMTS") 12 connected to a cable television network 14, hereinafter cable network 14. Cable network 14 includes cable television networks such as those provided by Comcast Cable Communications, Inc., of Philadelphia, Pa., Cox Communications, or Atlanta, Ga., Tele-Communications, Inc., of Englewood, Colo., Time-Warner Cable, of Marietta, Ga., Continental Cablevision, Inc., of Boston, Mass., and others. Cable network 14 is connected to a Cable Modem ("CM") 16 with a downstream cable connection.

CM 16 is connected to Customer Premise Equipment ("CPE") 18 such as a personal computer system via a Cable Modem-to-CPE Interface ("CMCI") 20. CM 16 is connected to a Public Switched Telephone Network ("PSTN") 22 with an upstream telephony connection. PSTN 22 includes those public switched telephone networks provided by AT&T, Regional Bell Operating Companies (e.g., Ameritch, U.S. West, Bell Atlantic, Southern Bell Communications, Bell South, NYNEX, and Pacific Telesis Group), GTE, and others. The upstream telephony connection is any of a standard telephone line connection, Integrated Services Digital Network ("ISDN") connection, Asymmetric Digital Subscriber Line ("ADSL") connection, or other telephony connection. PSTN 22 is connected to a Telephony Remote Access Concentrator ("TRAC") 24. In a data-over cable system without telephony return, CM 16 has an upstream connection to CMTS 12 via a cable television connection, a wireless connection, a satellite connection, or a connection via other technologies to send data upstream outside of the telephony return path. An upstream cable television connection via cable network 14 is illustrated in FIG. 1.

FIG. 1 illustrates a telephony modem integral to CM 16. In another embodiment of the present invention, the telephony modem is a separate modem unit external to CM 16 used specifically for connecting with PSTN 22. A separate telephony modem includes a connection to CM 16 for exchanging data. CM 16 includes cable modems provided by the 3Com Corporation of Santa Clara, Calif., U.S. Robotics Corporation of Skokie, Ill., and others. In yet another embodiment of the present invention, CM 16 includes functionality to connect only to cable network 14 and receives downstream signals from cable network 14 and sends upstream signals to cable network 14 without telephony return. The present invention is not limited to cable modems used with telephony return.

CMTS 12 and TRAC 24 may be at a "headend" of cable system 10, or TRAC 24 may be located elsewhere and have routing associations to CMTS 12. CMTS 12 and TRAC 24 together are called a "Telephony Return Termination System" ("TRTS") 26. TRTS 26 is illustrated by a dashed box in FIG. 1. CMTS 12 and TRAC 24 make up TRTS 26 whether or not they are located at the headend of cable network 14, and TRAC 24 may in located in a different geographic location from CMTS 12. Content severs, operations servers, administrative servers and maintenance servers used in data-over-cable system 10 (not shown in FIG. 1) may also be in different locations. Access points to data-over-cable system 10 are connected to one or more CMTS's 12 or cable headend access points. Such configurations may be "one-to-one", "one-to-many," or "many-to-many," and may be interconnected to other Local Area Networks ("LANs") or Wide Area Networks ("WANs").

TRAC 24 is connected to a data network 28 (e.g., the Internet or an intranet) by a TRAC-Network System Interface 30 ("TRAC-NSI"). CMTS 12 is connected to data network 28 by a CMTS-Network System Interface ("CMTS-NSI") 32. The present invention is not limited to data-over-cable system 10 illustrated in FIG. 1, and more or fewer components, connections and interfaces could also be used.

Cable Modem Protocol Stack

FIG. 2 is a block diagram illustrating a protocol stack 36 for CM 16. FIG. 2 illustrates the downstream and upstream protocols used in CM 16. As is known in the art, the Open System Interconnection ("OSI") model is used to describe computer networks. The OSI model consists of seven layers including from lowest-to-highest, a physical, data-link, network, transport, session, presentation and application layer. The physical layer transmits bits over a communication link. The data link layer transmits error free frames of data. The network layer transmits and routes data packets.

For downstream data transmission, CM 16 is connected to cable network 14 in a physical layer 38 via a Radio Frequency ("RF") Interface 40. In an illustrative embodiment of the present invention, RF Interface 40 has an operation frequency range of 50 Mega-Hertz ("MHz") to 1 Giga-Hertz ("GHz") and a channel bandwidth of 6 MHz. However, other operation frequencies may also be used and the invention is not limited to these frequencies. RF interface 40 uses a signal modulation method of Quadrature Amplitude Modulation ("QAM"). As is known in the art, QAM is used as a means of encoding digital information over radio, wire, or fiber optic transmission links. QAM is a combination of amplitude and phase modulation and is an extension of multiphase phase-shift-keying. QAM can have any number of discrete digital levels typically including 4, 16, 64 or 256 levels. In one embodiment of the present invention, QAM-64 is used in RF interface 40. However, other operating frequencies modulation methods could also be used. For more information on RF interface 40 see the Institute of Electrical and Electronic Engineers ("IEEE") standard 802.14 for cable modems incorporated herein by reference. IEEE standards can be found on the World Wide Web at the Universal Resource Locator ("URL") "www.ieee.org." However, other RF interfaces 40 could also be used and the present invention is not limited to IEEE 802.14 (e.g., RF interfaces from Multimedia Cable Network Systems ("MCNS") and other could also be used).

Above RF interface 40 in a data-link layer 42 is a Medium Access Control ("MAC") layer 44. As is known in the art, MAC layer 44 controls access to a transmission medium via physical layer 38. For more information on MAC layer protocol 44 see IEEE 802.14 for cable modems. However, other MAC layer protocols 44 could also be used and the present invention is not limited to IEEE 802.14 MAC layer protocols (e.g., MCNS MAC layer protocols and others could also be used).

Above MAC layer 44 is an optional link security protocol stack 46. Link security protocol stack 46 prevents authorized users from making a data connection from cable network 14. RF interface 40 and MAC layer 44 can also be used for an upstream connection if data-over-cable system 10 is used without telephony return.

For upstream data transmission with telephony return, CM 16 is connected to PSTN 22 in physical layer 38 via modem interface 48. The International Telecommunications Union-Telecommunication Standardization Sector ("ITU-T", formerly known as the CCITT) defines standards for communication devices identified by "V.xx" series where "xx" is an identifying number. ITU-T standards can be found on the World Wide Web at the URL "www.itu.ch. "

In one embodiment of the present invention, ITU-T V.34 is used as modem interface 48. As is known in the art, ITU-T V.34 is commonly used in the data link layer for modem communications and currently allows data rates as high as 33,600 bits-per-second ("bps"). For more information see the ITU-T V.34 standard. However, other modem interfaces or other telephony interfaces could also be used.

Above modem interface 48 in data link layer 42 is Point-to-Point Protocol ("PPP") layer 50, hereinafter PPP 50. As is known in the art, PPP is used to encapsulate network layer datagrams over a serial communications link. For more information on PPP see Internet Engineering Task Force ("IETF") Request for Comments ("RFC"), RFC-1661, RFC-1662 and RFC-1663 incorporated herein by reference. Information for IETF RFCs can be found on the World Wide Web at URLs "ds.internic.net" or "www.ietf.org."

Above both the downstream and upstream protocol layers in a network layer 52 is an Internet Protocol ("IP") layer 54. IP layer 54, hereinafter IP 54, roughly corresponds to OSI layer 3, the network layer, but is typically not defined as part of the OSI model. As is known in the art, IP 54 is a routing protocol designed to route traffic within a network or between networks. For more information on IP 54 see RFC-791 incorporated herein by reference.

Internet Control Message Protocol ("ICMP") layer 56 is used for network management. The main functions of ICMP layer 56, hereinafter ICMP 56, include error reporting, reachability testing (e.g., "pinging") congestion control, route-change notification, performance, subnet addressing and others. Since IP 54 is an unacknowledged protocol, datagrams may be discarded and ICMP 56 is used for error reporting. For more information on ICMP 56 see RFC-792 incorporated herein by reference.

Above IP 54 and ICMP 56 is a transport layer 58 with User Datagram Protocol layer 60 ("UDP"). UDP layer 60, hereinafter UDP 60, roughly corresponds to OSI layer 4, the transport layer, but is typically not defined as part of the OSI model. As is known in the art, UDP 60 provides a connectionless mode of communications with datagrams. For more information on UDP 60 see RFC-768 incorporated herein by reference.

Above the network layer are a Simple Network Management Protocol ("SNMP") layer 62, Trivial File Protocol ("TFTP") layer 64, Dynamic Host Configuration Protocol ("DHCP") layer 66 and a UDP manager 68. SNMP layer 62 is used to support network management functions. For more information on SNMP layer 62 see RFC-1157 incorporated herein by reference. TFTP layer 64 is a file transfer protocol used to download files and configuration information. For more information on TFTP layer 64 see RFC-1350 incorporated herein by reference. DHCP layer 66 is a protocol for passing configuration information to hosts on an IP 54 network. For more information on DHCP layer 66 see RFC-1541 incorporated herein by reference. UDP manager 68 distinguishes and routes packets to an appropriate service (e.g., a virtual tunnel). More or few protocol layers could also be used with data-over-cable system 10.

CM 16 supports transmission and reception of IP 54 datagrams as specified by RFC-791. CMTS 12 and TRAC 24 may perform filtering of IP 54 datagrams. CM 16 is configurable for IP 54 datagram filtering to restrict CM 16 and CPE 18 to the use of only their assigned IP 54 addresses. CM 16 is configurable for IP 54 datagram UDP 60 port filtering (i.e., deep filtering).

CM 16 forwards IP 54 datagrams destined to an IP 54 unicast address across cable network 14 or PSTN 22. Some routers have security features intended to filter out invalid users who alter or masquerade packets as if sent from a valid user. Since routing policy is under the control of network operators, such filtering is a vendor specific implementation. For example, dedicated interfaces (i.e., Frame Relay) may exist between TRAC 24 and CMTS 12 which preclude filtering, or various forms of virtual tunneling and reverse virtual tunneling could be used to virtually source upstream packets from CM 16. For more information on virtual tunneling see Level 2 Tunneling Protocol ("L2TP") or Point-to-Point Tunneling Protocol ("PPTP") in IETF draft documents incorporated herein by reference by Kory Hamzeh, et. al (IETF draft documents are precursors to IETF RFCs and are works in progress).

CM 16 also forwards IP 54 datagrams destined to an IP 54 multicast address across cable network 14 or PSTN 22. CM 16 is configurable to keep IP 54 multicast routing tables and to use group membership protocols. CM 16 is also capable of IP 54 tunneling upstream through the telephony path. A CM 16 that wants to send a multicast packet across a virtual tunnel will prepend another IP 54 header, set the destination address in the new header to be the unicast address of CMTS 12 at the other end of the tunnel, and set the IP 54 protocol field to be four, which means the next protocol is IP 54.

CMTS 12 at the other end of the virtual tunnel receives the packet, strips off the encapsulating IP 54 header, and forwards the packet as appropriate. A broadcast IP 54 capability is dependent upon the configuration of the direct linkage, if any, between TRAC 24 and CMTS 12. CMTS 12, CM 16, and TRAC 24 are capable of routing IP 54 datagrams destined to an IP 54 broadcast address which is across cable network 14 or PSTN 22 if so configured. CM 16 is configurable for IP 54 broadcast datagram filtering.

An operating environment for the present invention includes a processing system with at least one high speed Central Processing Unit ("CPU") and a memory system. In accordance with the practices of persons skilled in the art of computer programming, the present invention is described below with reference to acts and symbolic representations of operations that are performed by the processing system, unless indicated otherwise. Such acts and operations are sometimes referred to as being "computer-executed", or "CPU executed."

It will be appreciated that the acts and symbolically represented operations include the manipulation of electrical signals by the CPU. The electrical system represent data bits which cause a resulting transformation or reduction of the electrical signal representation, and the maintenance of data bits at memory locations in the memory system to thereby reconfigure or otherwise alter the CPU's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the data bits.

The data bits may also be maintained on a computer readable medium including magnetic disks, optical disks, organic disks, and any other volatile or non-volatile mass storage system readable by the CPU. The computer readable medium includes cooperating or interconnected computer readable media, which exist exclusively on the processing system or is distributed among multiple interconnected processing systems that may be local or remote to the processing system.

Initialization of a Cable Modem with Telephony Return

When CM 16 is initially powered on, if telephony return is being used, CM 16 will receive a Telephony Channel Descriptor ("TCD") from CMTS 12 that is used to provide dialing and access instructions on downstream channels via cable network 14. Information in the TCD is used by CM 16 to connect to TRAC 24. The TCD is transmitted as a MAC management message with a management type value of TRI.sub.-- TCD at a periodic interval (e.g., every 2 seconds). To provide for flexibility, the TCD message parameters are encoded in a Type/Length/Value ("TLV") form. However, other encoding techniques could also be used. FIG. 3 is a block diagram illustrating a TCD message structure 70 with MAC 44 management header 72 and Service Provider Descriptor(s) ("SPD") 74 encoded in TLV format. SPDs 74 are compound TLV encodings that define telephony physical-layer characteristics that are used by CM 16 to initiate a telephone call. SPD 74 is a TLV-encoded data structure that contains sets of dialing and access parameters for CM 16 with telephony return. SPD 74 is contained within TCD message 70. There may be multiple SPD 74 encodings within a single TCD message 70. There is at least one SPD 74 in TCD message 70. SPD 74 parameters are encoded as SPD-TLV tuples. SPD 74 contains the parameters shown in Table 1 and may contain optional vendor specific parameters. However, more or fewer parameters could also be used in SPD 74.

                  TABLE 1
    ______________________________________
    SPD 74 Parameter
                  Description
    ______________________________________
    Factory Default Flag
                  Boolean value, if TRUE(1), indicates a
                  SPD which should be used by CM 16.
    Service Provider Name
                  This parameter includes the name of a
                  service provider. Format is standard
                  ASCII string composed of numbers and
                  letters.
    Telephone Numbers
                  These parameters contain telephone
                  numbers that CM 16 uses to initiate a
                  telephony modem link during a login
                  process. Connections are attempted in
                  ascending numeric order (i.e., Phone
                  Number 1, Phone Number 2...). The SPD
                  contains a valid telephony dial string as
                  the primary dial string (Phone Number 1),
                  secondary dial-strings are optional.
                  Format is ASCII string(s) composed of:
                  any sequence of numbers, pound "#" and
                  star "*" keys and comma character ","
                  used to indicate a two second pause in
                  dialing.
    Connection Threshold
                  The number of sequential connection
                  failures before indicating connection
                  failure. A dial attempt that does not result
                  in an answer and connection after no
                  more than ten rings is considered a
                  failure. The default value is one.
    Login User Name
                  This contains a user name CM 16 will use
                  an authentication protocol over the
                  telephone link during the initialization
                  procedure. Format is a monolithic
                  sequence of alphanumeric characters in
                  an ASCII string composed of numbers
                  and letters.
    Login Password
                  This contains a password that CM 16 will
                  use during authentication over a
                  telephone link during the initialization
                  procedure. Format is a monolithic
                  sequence of alphanumeric characters in
                  an ASCII string composed of numbers
                  and letters.
    DHCP Authenticate
                  Boolean value, reserved to indicate that
                  CM 16 uses a specific indicated DHCP 66
                  Server (see next parameter) for a DHCP
                  66 Client and BOOTP Relay Process
                  when TRUE (one). The default is FALSE
                  (zero) which allows any DHCP 66 Server.
    DHCP Server   IP 54 address value of a DHCP 66 Server
                  CM 16 uses for DHCP 66 Client and
                  BOOTP Relay Process. If this attribute is
                  present and DHCP 66 Authenticate
                  attribute is TRUE(1). The default value is
                  integer zero.
    RADIUS Realm  The realm name is a string that defines a
                  RADIUS server domain. Format is a
                  monolithic sequence of alphanumeric
                  characters in an ACSII string composed
                  of numbers and letters.
    PPP Authentication
                  This parameter instructs the telephone
                  modem which authentication procedure to
                  perform over the telephone link.
    Demand Dial Timer
                  This parameter indicates time (in
                  seconds) of inactive networking time that
                  will be allowed to elapse before hanging
                  up a telephone connection at CM 16. If
                  this optional parameter is not present, or
                  set to zero, then the demand dial feature
                  is not activated. The default value is zero.
    Vendor Specific Extensions
                  Optional vendor specific extensions.
    ______________________________________

                  TABLE 2
    ______________________________________
    TSI 76 Parameter
                    Description
    ______________________________________
    Downstream Channel
                    This field contains an IP 54 address of
    IP Address 80   CMTS 12 available on the downstream
                    channel this message arrived on.
    Registration IP Address 82
                    This field contains an IP 54 address
                    CM 16 sends its registration request
                    messages to. This address MAY be
                    the same as the Downstream Channel
                    IP 54 address.
    CMTS Boot Time 84
                    Specifies an absolute-time of a CMTS
                    12 recorded epoch. The clock setting
                    for this epoch uses the current clock
                    time with an unspecified accuracy.
                    Time is represented as a 32 bit binary
                    number.
    Downstream Channel ID 86
                    A downstream channel on which this
                    message has been transmitted. This
                    identifier is arbitrarily chosen by CMTS
                    12 and is unique within the MAC 44
                    layer.
    Epoch 88        An integer value that is incremented
                    each time CMTS 12 is either re-
                    initialized or performs address or
                    routing table flush.
    Vendor Specific Extensions 90
                    Optional vendor extensions may be
                    added as TLV encoded data.
    ______________________________________

                  TABLE 3
    ______________________________________
    1.  An IP 54 datagram from data network 28 destined for CM 16 arrives
        on CMTS-NSI 32 and enters CMTS 12.
    2.  CMTS 12 encodes the IP 54 datagram in a cable data frame, passes it
        to MAC 44 and transmits it "downstream" to RF interface 40 on
        CM 16 via cable network 14.
    3.  CM 16 recognizes the encoded IP 54 datagram in MAC layer 44
        received via RF interface 40.
    4.  CM 16 responds to the cable data frame and encapsulates a response
        IP 54 datagram in a PPP 50 frame and transmits it "upstream" with
        modem interface 48 via PSTN 22 to TRAC 24.
    5.  TRAC 24 decodes the IP 54 datagram and forwards it via TRAC-NSI
        30 to a destination on data network 28.
    ______________________________________

                  TABLE 4
    ______________________________________
    DCHP 66
    Parameter    Description
    ______________________________________
    OP 110       Message op code / message type.
                 1 BOOTREQUEST, 2 = BOOTREPLY.
    HTYPE 112    Hardware address type (e.g., `1` = 10
                 Mps Ethernet).
    HLEN 114     Hardware address length (e.g. `6` for 10
                 Mbps Ethernet).
    HOPS 116     Client sets to zero, optionally used by
                 relay-agents when booting via a relay-
                 agent.
    XID 118      Transaction ID, a random number
                 chosen by the client, used by the client
                 and server to associate messages and
                 responses between a client and a
                 server.
    SECS 120     Fitted in by client, seconds elapsed
                 since client started trying to boot.
    FLAGS 122    Flags including a BROADCAST bit.
    CIADDR 124   Client IP address; filled in by client in
                 DHCPREQUEST if verifying previously
                 allocated configuration parameters.
    YIADDR 126   `Your`(client) IP address.
    SIADDR 128   IP 54 address of next server to use in
                 bootstrap; returned in DHCPOFFER,
                 DHCPACK and DHCPNAK by server.
    GIADDR 130   Gateway relay agent IP 54 address,
                 used in booting via a relay-agent.
    CHADDR       Client hardware address (e.g., MAC
    132          layer 44 address).
    SNAME 134    Optional server host name, null
                 terminated string.
    FILE 136     Boot file name, terminated by a null
                 string.
    OPTIONS      Optional parameters.
    138
    ______________________________________

                  TABLE 5
    ______________________________________
    1.  A network host client broadcasts a DHCP DISCOVER 66 message
        on its local physical subnet. The DHCP DISCOVER 66 message may
        include options that suggest values for a network host interface
        address. BOOTP relay agents may pass the message on to DHCP 66
        servers not on the same physical subnet.
    2.  DHCP servers may respond with a DHCPOFFER message that
        includes an available network address in the `yiaddr` field (and
        other
        configuration parameters in DHCP 66 options) from a network host
        interface. DHCP 66 servers unicasts the DHCPOFFER message to the
        network host client (using the DHCP/BOOTP relay agent if
        necessary) if possible, or may broadcast the message to a broadcast
        address (preferably 255.255.255.255) on the client's subnet.
    3.  The network host client receives one or more DHCPOFFER messages
        from one or more DHCP 66 servers. The network host client may
        choose to wait for multiple responses.
    4.  The network host client chooses one DHCP 66 server with an
        associated network host interface from which to request
        configuration
        parameters, based on the configuration parameters offered in the
        DHCPOFFER messages.
    ______________________________________

                  TABLE 6
    ______________________________________
    DHCP 66
    Parameter   Description
    ______________________________________
    OP 110      Set to BOOTREQUEST.
    HTYPE 112   Set to network type (e.g., one for 10 Mbps
                Ethernet).
    HLEN 114    Set to network length (e.g., six for 10 Mbps
                Ethernet)
    HOPS 116    Set to zero.
    FLAGS 118   Set BROADCAST bit to zero.
    CIADDR 124  If CM 16 has previously been assigned an IP
                54 address, the IP 54 address is placed in this
                field. If CM 16 has previously been assigned
                an IP 54 address by DHCP 66, and also has
                been assigned an address via IPCP, CM 16
                places the DHCP 66 IP 54 address in this
                field.
    GIADDR 130  CM 16 places the Downstream Channel IP 54
                address 80 of CMTS 12 obtained in TSI
                message 76 on a cable downstream channel
                in this field.
    CHADDR 132  CM 16 places its 48-bit MAC 44 LAN address
                in this field.
    ______________________________________

                  TABLE 7
    ______________________________________
    DHCP 66 Parameter
                     Description
    ______________________________________
    FLAGS 122        BROADCAST bit set to zero.
    YIADDR 126       IP 54 address from a network
                     host interface to allow CM 16 to
                     receive data from data network
                     28 via a network host interface
                     available on CMTS 12.
    SIADDR 128       An IP 54 address for a TFTP 64
                     server to download configuration
                     information for an interface host.
    CHADDR 132       MAC 44 address of CM 16.
    SNAME 134        Optional DHCP 66 server
                     identifier with an interface host.
    FILE 136         A TFTP 64 configuration file
                     name for CM 16.
    ______________________________________

                  TABLE 8
    ______________________________________
    DHCP 66
    Parameter   Description
    ______________________________________
    OP 110      Set to BOOTREQUEST.
    HTYPE 112   Set to network type (e.g., one for 10Mbps
                Ethernet).
    HLEN 114    Set to network length (e.g., six for 10Mbps
                Ethernet)
    HOPS 116    Set to zero.
    FLAGS 118   Set BROADCAST bit to zero.
    CIADDR 124  If CM 16 has previously been assigned an IP
                address, the IP address is placed in this field.
                If CM 16 has previously been assigned an IP
                address by DHCP 66, and also has been
                assigned an address via IPCP, CM 16 places
                the DHCP 66 IP 54 address in this field.
    YIADDR 126  IP 54 address sent from the selected network
                interface host in DCHPOFFER message
    GIADDR 130  CM 16 places the Downstream Channel IP 54
                address 80 CMTS 12 obtained in TSI
                message 76 on a cable downstream channel
                in this field.
    CHADDR 132  CM 16 places its 48-bit MAC 44 LAN address
                in this field.
    SNAME 134   DHCP 66 server identifier for the selected
                network interface host
    ______________________________________

                  TABLE 9
    ______________________________________
    DHCP 66 Parameter
                    Description
    ______________________________________
    FLAGS 122       Set a BROADCAST bit to zero.
    YIADDR 126      IP 54 address for the selected
                    network host interface to allow
                    CM 16 to receive data from data
                    network 28.
    SIADDR 128      An IP 54 address for a TFTP 64
                    server to download configuration
                    information for an interface host.
    CHADDR 132      MAC 44 address of CM 16.
    SNAME 134       DHCP 66 server identifier
                    associated with the selected
                    network host interface.
    FILE 136        A configuration file name for an
                    network interface host.
    ______________________________________

                  TABLE 10
    ______________________________________
     ##STR1##
    ______________________________________

                  TABLE 11
    ______________________________________
     ##STR2##
    ______________________________________

                  TABLE 12
    ______________________________________
    ;cable modem hosts entries
    cm-type1   A       124.35.14.58
               A       124.35.14.59
               ...
               HINFO   3Com Cable Modem
    cm-type2   A       124.35.14.60
               A       123.35.14.73
               ...
               HINFO   U.S. Robotics Cable Modem
    ;reverse DNS entries
    58.14.35.124.in-addr.arpa
                   PTR     cm-type1.data-over-cable.net
    59.14.35.124.in-addr.arpa
                   PTR     cm-type1.data-over-cable.net
    60.14.35.124.in-addr.arpa
                   PTR     cm-type2.data-over-cable.net
    73.14.34.124.in-addr.arpa
                   PTR     cm-type2.data-over.cable.net
    ______________________________________

                  TABLE 13
    ______________________________________
    The following configuration parameters are supported by all CMs 16 and
    included in the second configuration file:
    .cndot. Network Access Configuration parameter.
    .cndot. End Configuration parameter.
    The following configuration parameters may be included in the second
    configuration file:
    .cndot. Downstream Frequency Configuration parameters.
    .cndot. Upstream Channel ID Configuration parameters.
    .cndot. Class of Service Configuration parameter.
    .cndot. Vendor ID Configuration parameter.
    .cndot. Baseline Privacy Configuration parameter.
    .cndot. Software Upgrade Filename Configuration parameter.
    .cndot. SNMP 62 Write-Access Control
    .cndot. SNMP 62 MIB Object
    .cndot. Pad Configuration parameter.
    The following configuration parameters may be included in the second
    configuration file:
    .cndot. Vendor Specific Configuration parameters.
    ______________________________________

                  TABLE 14
    ______________________________________
    Type    Length       Description of Value
    ______________________________________
     1      4            Receive frequency
     2      1            Upstream channel identifier
     4x     N            Class of service header
     41     1            Class identifier
     42     4            Maximum downstream data
                         rate in bits/sec
     43     4            Maximum upstream data rate
                         in bits/sec
     44     1            Upstream channel priority
     45     4            Upstream guaranteed
                         minimum data rate in bits/sec
     46     2            Maximum upstream
                         configuration setting in
                         minislots
     47     1            Privacy enable
     8      3            Vendor Identifier configuration
                         setting
     17x    N            Baseline privacy settings
                         header
    171     4            Authorize timeout seconds
    172     4            Reauthorize wait timeout
                         seconds
    173     4            Authorization wait timeout
                         seconds
    174     4            Operational wait timeout
                         seconds
    175     4            Re-key wait timeout seconds
    176     4            TEK grace time seconds
     9      N            Software upgrade filename
     10     1            SNMP 62 access control
     11     N            Arbitrary SNMP 62 object
                         setting
     0      N            Padding to align on 4-byte
                         boundary
     3      1            Network access
     6      16           CM-MIC
     7      16           CMTS-MIC
    255     N/A          End-of-file
    ______________________________________

                  TABLE 15
    ______________________________________
    Create the TLV entries (e.g., 362, 364, ... , 366) for all parameters
    used by
    CM 16.
    Calculate CM-MIC field 368 by performing an MD5 digest over the bytes
    of the TLV entries.
    Add CM-MIC field 368 to the file following the last TLV entry.
    Calculate CMTS-MIC field 370 using the method illustrated in Table 16.
    Add CMTS-MIC field 370 to the file following CM-MIC field 368.
    Add an End-of-File ("EOF") marker to the file.
    ______________________________________

                  TABLE 16
    ______________________________________
    CMTS-MIC field 370 is calculated by performing an MD5 digest over the
    following configuration parameter fields, when present in the
    configuration file, in the order shown:
    .cndot. Downstream Frequency Conflguration parameter.
    .cndot. Upstream Channel ID Configuration parameter
    .cndot. Network Access Configuration parameter.
    .cndot. Class of Service Configuration parameter.
    .cndot. Vendor ID Configuration parameter.
    .cndot. Baseline Privacy Configuration parameter.
    .cndot. Vendor specific Configuration parameters.
    .cndot. CM-MIC 368 value
    .cndot. Authentication string
    The configuration parameter fields are treated as if they were
    contiguous
    data when calculating the MD5 digest.
    ______________________________________