Responding to network access requests using a transparent media access and uniform delivery of service

[0002] 1. Field of the Invention

[0003] The present invention relates to providing network access. More particularly, the present invention relates to providing network access which is compatible with different network protocols.

[0004] 2. The Background

[0005] The Internet as a communication medium that is easily and economically available to the masses on a worldwide scale is a vision that arguably has been fulfilled in recent years. The proliferation of computers, computer-related devices (such as hand-held organizers), set-top boxes, or any tool that sends and/or receives digitized data has fed the demand for this vision. This is in accord with the premise that the sum of devices on a network are greater than the individual parts of the network. Concomitant with this proliferation of networked and data hungry devices is the increasing reliance on the Internet as the communication medium for which these devices may communicate.

[0006] However, because of bandwidth needs, cost, intended use, and/or applicability, these devices may not only employ disparate network access methods when seeking, network access to the Internet but typically also may use different network layers. Apart from the challenges of supporting network access across disparate physical layers (wireless, cable, twisted pair) and data-link layers, there is also the challenge of supporting different access methods used by the devices seeking Internet network access.

[0007] These challenges include supporting network access methods such as dial-up, cable modem, and ADSL (Asymmetric Digital Subscriber Line), while also maintaining a seamless level of service to a subscriber regardless of the type of network access method used. Solutions exist such as the system shown in FIG. 1, but do not tightly integrate the components used. This results in an approach that is not easily scaled so as to render difficult the ability to support new or additional access methods, may contain more than one user record database and may not consistently provide fault tolerance to the components in a unified way.

[0008] For example, an access point 10, which is connected to Internet 12 and that supports multiple network access methods, is shown in FIG. 1. One network access method shown includes using a dial-up method to obtain the services of Internet 12. Traditionally, a dial-up access method encompasses establishing a connection between a host 14 and a client supported by access point 10, such as a network access server (commonly referred to as “NAS”) 16. This enables the physical and data link layer protocols used by host 14 (and a modem 18 used by the host) to be supported. For example, the physical medium used for a dial-up connection using a pair of modems 18 and 20 connected to a public switched telephone network (PSTN) 22 is a telephone line. Once the physical and data link protocols are established between modems 18 and 20, network access between 14 host and network access service 16 is attempted.

[0009] In a communication system such as the Internet, this usually requires host 14 to send an access request packet 24 to network access server 16. Upon receipt of packet 24, which contains the subscriber's user ID and password, network access service 16 attempts to authenticate the access request by sending the user ID and password to an authentication, authorization, and accounting (AAA) server 26. Those of ordinary skill in the art will readily recognize that a AAA server operates through the RADIUS (Remote Authentication Dial In User Service) application protocol. This enables network access server 16 to receive, process, and send the user ID and password to AAA server 26 as a RADIUS protocol compliant packet, hereinafter “RADIUS access request packet” 28.

[0010] Upon receipt of packet 28, AAA server 26 uses the user ID and password, which are encapsulated in packet 28, to provide authentication and authorization services. For example, AAA server 26 may extract the user ID and password attributes from packet 28 and obtain a user record 30 that corresponds to the subscriber 32 by using the extracted user ID as an index to find user record 30 in a user record database 34. Once user record 30 is obtained, the password is compared with the password contained in the record.

[0011] After performing the above authentication step AAA server 26 performs an authorization step by responding with either a RADIUS access accept packet 36 or access reject packet 38. If an access accept packet 36 is returned, network access service 16 will also need to provide an IP address by seeking the services of a DHCP server 40 (dynamic host configuration protocol). This requires network access service 16 to generate a DHCP discover packet 42 having the user ID, among other things.

[0012] Upon receipt of DHCP discover packet 42, DHCP server 40 obtains the user ID contained within packet 42 to obtain a user record 44 from a user record database 46. User record 44 is then used to determine whether a predetermined IP address should be returned to network access service 16 or whether an IP address should be obtained from a pool of IP addresses. The IP address obtained by DHCP server 40 is then sent to network access service 16 using a DHCP offer packet 48.

[0013] Upon receipt of DHCP offer packet 48, network access service 16 obtains the IP address from packet 48 and encapsulates it as a RADIUS packet 50 and sends it to host 14 via modems 20 and 18, respectively. Upon receipt of RADIUS packet 50, host 14 returns an accounting start packet 52 to network access service 16, triggering an accounting process to begin.

[0014] Access point 10 is also shown supporting an ADSL access method. An ADSL compliant client 60 must not only obtain AAA and DHCP services from servers 62 and 64, respectively, as in the dial-up access method discussed above, but it must also first translate a private address used by an ADSL modem 66. This requires providing and maintaining separate databases 68 and 70. Moreover, the user records stored in database 68, must also include attributes specific to information required by the ADSL modem such as a service type attribute 68. The service type attribute includes a list of services in which the user is subscribed, such as the VPDN (Virtual Private Dial-up Network) service.

[0015] Access point 10 is also shown supporting a cable modem access method via a client 80. Supporting a cable modem network access method does not require a host, such as host 14, to obtain AAA and DHCP services. Instead, an IP address and authentication services are obtained when host 14 sends a request for registration services packet 82 using the MCNS (Multimedia Cable Network System) protocol.

[0016] Under the cable modem network access method, a cable modem number (corresponding to cable modem 81) rather than a subscriber name is included with packet 82. Client 80 receives and then forwards packet 82 to a registration and configuration service 84. Service 84 receives packet 82 and returns registration information 86 by obtaining it from a database 88 using the cable modem number sent within packet 82. Client 80 receives registration information 86, converts it into the Trivial File Transfer Protocol (TFTP), and sends a configuration request packet 90 to configuration service 92. Configuration 92 receives packet 90 and returns an IP address and other configuration information which correspond to the information received in that packet. The IP address and other configuration information is received by client 80 which in turn, forwards them to host 14, enabling host 14 to proceed with the log-on process.

[0017] As can be seen above, supporting different access methods requires clients and services that can provide the states (services and tasks) which are required to establish a particular network service required by a given access method. This requires access to user information that may differ in content and format according to the type of network access method used. Meeting these requirements has resulted in an implementation in which the clients and the services used are loosely integrated. For example, each client is tightly coupled to each service that the client uses and each service has its own database of information. Such an approach renders difficult the ability to provide an access point that can be easily expanded to include new access methods (scalable) and that provides the same subscriber service for all types of access methods used and/or access point location (unified).

[0018] Accordingly, there is a need for supporting different access methods to the Internet, or an equivalent network, which is both scalable and unified.

[0019] Network access requests, which may be based on different access methods, are processed by using a protocol gateway that insulates the processing of the access requests from the specialized protocols required to obtain the necessary services required for the different access methods supported. In a first aspect of the present invention, a protocol handler responsive to the protocol used by the access request is utilized. The protocol handler performs a set of steps necessary for responding to the access request. If the steps include procuring a service, a state object is used to obtain the service, insulating the protocol handler from having to communicate with a provider of the service, such as a service component. Upon completion of the steps defined within the set of steps, the protocol handler denies or grants network access.

[0020] In a second aspect of the present invention, a task engine is used to treat each incoming access request as a task, optimizing the processing of each access request.

[0021] FIG. 1 is a block diagram of an example of a network access point which supports more than one access method for obtain network access to the Internet or a large scale computer network.

[0022] FIG. 2 is a block diagram of a set of element layers for supporting different access methods in a communications system having a set of access services and at least one host in accordance with a presently preferred embodiment of the present invention.

[0023] FIG. 3 is an expanded view of a set of element layers comprising a protocol gateway in accordance with a presently preferred embodiment of the present invention.

[0024] FIG. 4 is a flow diagram illustrating a process for supporting different network access methods in accordance with a presently preferred embodiment of the present invention.

[0025] In the following description, a preferred embodiment of the invention is described with regard to preferred process steps and data structures. However, those skilled in the art would recognize, after perusal of this application, that embodiments of the invention may be implemented using at least one general purpose computer operating under program control, and that modification of the general purpose computer to implement the components, process steps, and/or data structures described herein would not require undue invention.

[0026] In accordance with a presently preferred embodiment of the present invention, the components, process steps, and/or data structures are implemented using C++ programs running on an Enterprise 2000 server™ running SunSolaris™ as its operating system. The Enterprise 2000 server™ and SunSolaris™ operating system are available from Sun MicroSystems, Inc. of Mountain View, Calif. This implementation is not intended to be limiting in any way. Different implementations may be used and may include other types of operating systems, computing platforms, and/or computer programs. In addition, those of ordinary skill in the art will readily recognize that devices of a less general purpose nature, such as hardwired devices, devices relying on FPGA or ASIC technology, or the like, may also be used without departing from the scope and spirit of the inventive concepts disclosed herewith.

[0027] FIG. 2 is a block diagram of a set of element layers for supporting different access methods in a communications system having a set of access services and at least one host in accordance with a presently preferred embodiment of the present invention.

[0028] The set of element layers include a protocol layer 110, a gateway layer 112, and a state transition layer 114, herein collectively referred to as a protocol gateway 116. Protocol gateway 116 enables clients to properly process network access requests based on an access method which may differ depending on the type of hosts supported. For example, protocol gateway 116 may be used to provide a point of presence from which a dial-up host 118 and a host using a cable modem 119 may obtain network access to a communication system 120 using the Internet 122 as the network backbone.

[0029] Protocol layer 110 communicates with clients that receive access requests from supported hosts. Gateway layer 112 queues, load balances, and assigns protocol handlers to process each access request, which was sent by a client to protocol layer 110, according to the protocol used by the client to communicate with protocol layer 110. State transition layer 114 normalizes the steps that obtain a service from a service component and that are relevant to one of the access methods supported. This enables protocol gateway 116 to support multiple access methods.

[0030] Normalization of a step includes obtaining the services required for a given access method from service component layer 124. This enables the protocol handlers (which will be discussed further below) to use a common interface when seeking component services, avoiding the need to configure each protocol handler to be compatible with the different protocols and data formats required to obtain a service from a particular service component.

[0031] In accordance with a preferred embodiment of the present invention, service component layer 124 includes an authentication, authorization, and accounting (AAA) service component 126, an address procurement service component 128, a registration service component 130, a configuration service component 132, and a user record service component 134. AAA service component 126 may be provided using any authentication, authorization, and accounting (AAA) server, such as Cisco ACS or Cisco Secure, available from Cisco Systems, Inc. of San Jose, Calif.

[0032] Address procurement service component 128 may be provided using a DHCP (dynamic host configuration protocol) server, such as when communication system 120 is implemented using the Internet as the primary network backbone. DHCP servers are available from Software.com of Los Angeles, Calif. AAA and DHCP servers traditionally rely on the RADIUS and DHCP application protocols, respectively, for communication.

[0033] Registration service component 130 is responsive to registration request packets that request cable modem registration information. When based on the MCNS protocol, the packets each include a cable modem number attribute. The MCNS protocol is known by those of ordinary skill in the art. Upon receipt and after processing (which will be further described below), registration service component 130 returns a file name which will be used to obtain configuration information.

[0034] Configuration service component 132 is responsive to configuration request packets, each having a file name. Upon receipt of the packet, configuration service retrieves configuration information which corresponds to the file name, and returns this information to state transition layer 114. Registration service component 130 and configuration service component 132 may be provided using the Cisco Network Register product from Cisco Systems, Inc. of San Jose, Calif.

[0035] User record service component 134 is any program object that maintains a set of user records that correspond to the subscribers supported by the protocol gateway. For example, the user records may be stored in a user database having a front end that provides the necessary interface that allows for user record management, such as an in-memory database. The database may be implemented using BerkeleyDB available from Sleepy Cat Software, Inc., of Carlisle, Mass. In accordance with a preferred embodiment of the present invention, each user record contains all of the attributes that may be needed to support the access method selected by its corresponding subscriber. For example, a subscriber capable of obtaining network access through a cable modem and a dial-up modem would have a user record that would contain all of the attributes that are required by both types of access methods.

[0036] The number and type of services provided in service component layer 124 is not intended to be in any way limiting. Any combination or number of services may be supported which are required to support a particular access methodology. Those of ordinary skill in the art will readily recognize that service component layer 124 may be coupled to state transition layer 114 as devices on a network or as program objects and as such, are not intended to be limited in this manner.

[0037] Protocol gateway 116 is also coupled to a client layer 138 which provides the necessary interfaces for supporting physical and data-link protocols. For example, client layer may include a network access service (NAS) client 140 for supporting dial-up modems which use a public switched telephone network (PSTN), a digital subscriber line-based (hereinafter referred to as xDSL) client 142 for supporting a host which uses a DSL access method, a cable client 144 for supporting a host which uses a cable modem, and/or any other type of client that supports any of the access methods currently available. Network access service client 140 may be implemented using Cisco 5200, available from Cisco Systems, Inc. of San Jose, Calif. A xDSL client 142 may be implemented using Cisco 6100, while cable client 144 may be implemented using Cisco 901 and Cisco UBR 7200. These products are also available from Cisco Systems, Inc., of San Jose, Calif.

[0038] FIG. 3 is an expanded view of a set of element layers comprising a protocol gateway in accordance with a presently preferred embodiment of the present invention.

[0039] Protocol layer 110 of protocol gateway 116 (see FIG. 2) is shown having a task processor 150, a task source 152, a task sink 154, and a protocol gateway interface 156. Task source 152 includes at least one port, such as port 158, for receiving packets from a client. Each port is configured to support the application protocol used by a respective client supported by protocol gateway 116. For example, task source 152 may include ports 158, 160, and 162 which support the RADIUS, MCNS, and TFTP protocols, respectively. This enables task source 152 to receive packets from a client that uses the RADIUS protocol, such as network access server 140 or xDSL client 142, or from a client that uses both the MCNS and TFTP protocols, such as cable client 144 as shown in FIG. 2.

[0040] Similarly, task sink 154 includes at least one port for transmitting packets to a client. Each port is configured to support the application protocol used by a respective client supported by protocol gateway 116. For example, task sink may include ports 164, 166, and 168 which support the RADIUS, MCNS, and TFTP protocols, respectively. This enables task sink 154 to receive packets from a client that uses the RADIUS protocol, such as network access server 140 or xDSL client 142, or from a client that uses both the MCNS and TFTP protocols, such as cable client 144 as shown in FIG. 2.

[0041] The number of task processors, task sources, and task sinks shown are not intended to be limiting in any way. Additional task processors, task sources, and task sinks may be used but are not shown to avoid overcomplicating the present invention.

[0042] Protocol gateway interface 156 enables task processor 150 to receive packets form at least one task source, such as task source 152, and to send packets to at least one task sink, such as task sink 154. When a packet is received via protocol gateway interface 156, task processor 150 determines whether such a packet is supported. If so, protocol gateway 150 encapsulates the packet as a task, queues it for processing, and selects from gateway later 112 an available protocol handler, such as RADIUS protocol handler 178, which is configured to process the task according to a set of steps defined by state manager 170.

[0043] The set of steps defined by state manager 170 includes directing RADIUS protocol handler 178 to provide each state required for a particular access method. This enables protocol gateway 116 to normalize the services (“states”) which are relevant to the supported access methods by having at least one state object within state transition layer 114 to obtain the services required for a given access method from at least one state provider, such as the state providers shown in service component layer 124 (see FIG. 2).

[0044] In accordance with a preferred embodiment of the present invention, there is a protocol handler for each application protocol that is required to provide a supported access method. For example, if a dial-up access method using the RADIUS protocol is supported, then a protocol handler is provided that communicates with a dial-up client using RADIUS, such as RADIUS protocol handler 178, and is configured to follow a set of steps defined by state manager 170. The set of steps directs RADIUS protocol handler 178 to provide the necessary states required to process an access request packet received from a dial-up client, such as NAS 140.

[0045] Similarly, if an xDSL access method is supported, then another protocol handler is provided, such as xDSL protocol handler 172, that is capable of communicating with a xDSL client and is configured to follow a set of steps defined by state manager 170. The set of steps defined directs xDSL protocol handler 172 to provide the necessary states required to process a task corresponding to an access request packet received from an xDSL client, such as xDSL client 142.

[0046] If a cable modem access method i s supported, a protocol handler is provided that communicates with a cable modem client, such as MCNS protocol handler 174, and is configured to follow a set of steps defined by state manager 170. The steps direct MCNS protocol handler 174 to provide the necessary states required to process a task encapsulating an access request packet received from a cable modem client, such as cable modem client 144. Thus, for each protocol used by a particular access method, the present invention provides a protocol handler compatible with the protocol and a set of steps which have been configured to direct a respective protocol handler to provide the necessary states required to respond to an access request based on a supported access method. Protocols other than those described are also supported, such as TACAS+, Diameter, DHCP, or equivalent protocol but are not further described to avoid overcomplicating the herein disclosure.

[0047] To provide the necessary states required by a protocol handler, each protocol handler has access to at least one state object which is configured to obtain services from a service component. Each state object is configured to use the protocol required to communicate with a state provider. This frees each protocol handler from dealing with the different protocols required to obtain the services which may differ depending on the service or service component selected. This enables protocol gateway 116 to normalize the steps required to support a particular network access method.

[0048] In accordance with a preferred embodiment of the present invention, task processor 150, task source 152, task sink 154, state manager 170, and protocol handlers 178, 172, and 174 are implemented using a multi-threaded task engine, which is known by those of ordinary skill in the art. Each packet received or sent may be buffered either through a queue or has table. Task source 152 and task sink 154 are implemented as software objects that transfer packets between clients and task processor 150. Task processor 150 is also a software object that determines whether a particular access request is supported and if so, queues the task and assigns a protocol handler to process the task. Each protocol handler is a thread managed by task processor 150. Each thread relies on a state table that defines the steps that the tread must perform to process a particular task. The present invention is not intended to be limited to using a multi-thread task engine. Other methods that implement the functional features described herein may also be used without departing from the scope and spirit of the disclosure.

[0049] In accordance with a preferred embodiment of the present invention, there is a state object for each service required within a given supported access method. For example, a dial-up network access method requires authentication and address procurement services. Consequently, protocol gateway 116 is configured to include an authentication state object 200, an address procurement state object 202, and a user record state object 204.

[0050] Authentication state object 200 is configured to communicate with authentication service component 126 (see FIG. 2). This includes sending a RADIUS access request packet to authentication service component 126 upon request for authentication by a protocol handler. Authentication state object 126 also receives response packets from authentication service component 126 which are then sent to the protocol handler which requested the authentication service. Those of ordinary skill in the art will readily recognize that information sent and received between a protocol handler and a state object may be queued, optimizing the performance of protocol gateway 116. This approach is not in any way intended to limit the present invention disclosed herein.

[0051] User record state object 204 is configured to respond to user record requests. For example, upon receipt of a RADIUS access request packet, authentication service 126 extracts the user ID and password attributes from the packet and uses them to obtain user record services through user record state object 204. Upon receiving the user record, authentication service component 126 would then be able to properly authenticate the request packet.

[0052] In accordance with a preferred embodiment of the present invention, address procurement state object 202 is configured to communicate with an address procurement service component 128 (see FIG. 2), such as a DHCP server, using a DHCP protocol. This includes sending a DHCP request packet to address procurement service when requested to obtain a network address, such as an IP address, by a protocol handler or a service component such as a AAA server. Address procurement state object 202 also receives response packets from address procurement service component 128 which are then sent to the protocol handler which requested the service.

[0053] The authentication and address procurement objects are not limited to a particular protocol handler and may be used by a protocol handler that supports another type of access method which requires similar services. For instance, the xDSL access method requires both authentication and address procurement services. Consequently, a protocol handler, such as xDSL protocol handler 172, following a set of steps that correspond to the xDSL access method would request authentication and address procurement services from state objects 200 and 202, respectively. As discussed above, the set of steps are managed by state manager 170 and are determined according to the access method being supported, which in this example, is the xDSL access method.

[0054] This approach of using state objects to communicate with service components may be extended to support network access requests forwarded by cable modem clients. As discussed above, cable modem network access requires a registration service and a configuration service. Consequently the present invention includes a registration service object 206 and a configuration service object 208. This enables a protocol handler, such as MCNS protocol handler 174 to obtain the necessary registration and configuration services when processing a task corresponding to a cable modem access request. MCSN protocol handler 174 obtains these services by following a set of steps imposed by state manager 170. State manager 170 is configured to define the steps and states required to properly respond to a particular network access request, such as a cable modem network access request.

[0055] Registration state object 206 is configured to communication with registration service component 130 using the MCSN protocol, while configuration state object 208 is configured to communication with a configuration service component 132 using the TFTP protocol. This enables MCNS protocol handler 174 to process a task corresponding to an access request packet received from a cable modem client such as cable modem client 144 (see FIG. 2). Upon assignment of the task to MCNS protocol handler 174, state manager 170 directs MCNS protocol handler 174 to perform the necessary steps required to process the task.

[0056] As is evident by the herein disclosure, the present invention can easily be modified to support additional network access methods simply by including another set of steps which define the necessary states that must be provided for each additional access method to be supported, another protocol handler, state objects which correspond the services needs, and access to state providers.

[0057] FIG. 4 is a process flow diagram illustrating the steps performed for supporting different network access methods in accordance with a presently preferred embodiment of the present invention.

[0058] At step 300, a protocol gateway receives an access request from a client through a task source port.

[0059] At step 302, a task engine within the protocol gateway processes the access request as a task. This may include queuing the task within a queue or using a hash table. Step 302 may further include additional steps that would be apparent to those of ordinary skill in the art, such as checking whether the access request is supported by the protocol gateway. Because such additional steps are within the scope and teach of the herein disclosure they will not be further discussed to avoid over-complicating the discussion regarding the present invention.

[0060] At step 304, the task engine assigns a protocol handler which is configured to perform the necessary steps required to respond to the task. The steps performed by the protocol handler correspond to the type of access requested and are provided to the protocol handler by a state manager.

[0061] At step 306, the protocol handler performs a step within a set of steps defined by the state manager.

[0062] At step 308, if the step performed requires a service, then step 310 is performed.

[0063] At step 310, the protocol handler prompts a state object to send a request for services to a service component. The state object prompted is a state object that has been configured to communicate using a protocol that is compatible with the service component that will provide the state service. For example, if the protocol handler seeks authorization and authentication services, it will prompt a state object that has been configured to properly communicate with a service component that provides authorization and authentication services. Thus, if the service component is a AAA server using RADIUS as an application level protocol, a state object that has been configured to communicate using the RADIUS protocol is selected by the protocol handler to obtain authentication and authorization services.

[0064] At step 312, the state object contacts the state service contacted in step 310 by configuring a packet which corresponds to the protocol used by the service component. For example, if the service component is a AAA server using the RADIUS protocol, the packet sent is a RADIUS access request packet having the user ID and password of the user which is attempting to obtain network access.

[0065] At step 314, upon receipt of a state service reply packet, the state object forwards the reply packet to the protocol handler which requested the state service.

[0066] At step 316, upon receipt of the reply packet, the protocol handler determines whether the process is complete or whether additional steps are required. If not, then step 318 is performed, otherwise the process flow returns to step 306.

[0067] At step 318, the protocol handler determines whether to grant or deny the access request by returning a packet which corresponds to the decision to the port (via an appropriate task sink) coupled to the client which originally forwarded the access request packet in step 300.

[0068] If at step 308, state service is not required, the process flow branches to step 316.

[0069] While embodiments and applications of this invention have been shown and described, it would be apparent to those skilled in the art that many more modifications than mentioned above are possible without departing from the inventive concepts herein. The invention, therefore, is not to be restricted except in the spirit of the appended claims.