Electrical computers and digital processing systems: multicomput – Computer-to-computer protocol implementing
Reexamination Certificate
1998-11-02
2002-05-07
Lim, Krisna (Department: 2153)
Electrical computers and digital processing systems: multicomput
Computer-to-computer protocol implementing
C709S225000, C709S203000
Reexamination Certificate
active
06385653
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
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.
2. The Background
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.
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.
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.
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.
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
.
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.
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.
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
.
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.
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.
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.
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.
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
Bhasham Sampath Kumar Sthothra
Lou Shuxian
Sitaraman Aravind
Zhang Shujin
LandOfFree
Responding to network access requests using a transparent... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Responding to network access requests using a transparent..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Responding to network access requests using a transparent... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2888599