Proxy session count limitation

Details Proxy session count limitation Proxy session count limitation

1999-05-06

2003-03-04

Chin, Wellington (Department: 2664)

Electrical computers and digital processing systems: multicomput

Computer network managing

Computer network access regulating

C709S226000, C709S229000, C709S224000, C709S223000, C709S217000

Reexamination Certificate

active

06529955

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of data communications networks. More particularly, this invention relates to a method and apparatus for limiting the number of proxied sessions provided to a group of users locally and network-wide in a data communications network.
2. The Background
ISPs (Internet Service Providers) and Telcos (telephone companies) (collectively referred to as “Wholesale Providers” or “Wholesalers”) typically offer wholesale Internet access and retail Internet access to their subscribers. Wholesale access is typically offered to subsidiary and specialized service providers, CLECs (Competitive Local Exchange Carriers), corporations, and Community of Interest (COI) providers. Naturally, the processing afforded customers of the wholesale variety differs from the processing afforded customers of the retail variety. Subscriber information for individual wholesale users is usually stored by those who lease data communications network access from the Wholesaler. Hence, corporations, CLECs and COI providers do not normally share their user information with the wholesale providers. The Wholesaler, however, typically also has its own retail subscribers whose user information is stored in its databases. In some cases, a particular user might have accounts with both a retail and wholesale provider. Hence, the Wholesaler must distinguish between the user's wholesale and retail accounts and initiate different actions based upon their status or Service Level Agreements (SLAs).
See, for example,
FIG. 1
where a pure retail environment has a number of network access servers (NAS
1
, NAS
2
and NAS
3
) which provide data communications portals to the Wholesaler's point of presence (PoP) on the data communications network. Each NAS is in communication with a conventional AAA (authentication, authorization and accounting) service maintained by the Wholesaler. Incoming users connect to the NASes by dialing in over the telephone network or in another conventional manner such as via DSL (digital subscriber line) access, cable, ISDN (integrated services digital network), etc.
Traditional wholesale ISPs and Roaming Service Providers offer network access through a technique called “authentication proxying.” Proxying involves the transfer of the authentication responsibility to the “owner” of the subscriber. Thus, if a corporation was to outsource its corporate intranet to a Wholesaler, it would give up the maintenance of its dial-up servers (i.e., the NASes). It would not, however, normally want to give up the control of or information regarding its employees. Hence, when a corporate user connects to such a Wholesaler's network access servers, the user essentially perceives that the user is dialing into a corporate facility when the user is actually dialing into the Wholesaler's domain and then somehow gaining admittance to the corporation's intranet.
What really happens in that scenario is that the Wholesaler determines that the user belongs to Corporation A (Corp
A
) by parsing either the fully qualified domain name (“FQDN”) (e.g., Joe@corpa.com) supplied by the user, reading the DNIS ID associated with the call, reading the CLID associated with the call, or by using some other known mechanism. Using a DNIS ID, the Wholesaler looks at the telephone number (or a specific NAS in access networks other than dial-up) through which the user is connecting to the network. So if a user calls in to 123-456-7890 from his number of 123-444-5555, then the Wholesaler can know which number was called, i.e., the completing station. Having determined that the user trying to gain access belongs to Corp
A
, the Wholesaler cannot authenticate the user by itself. As noted earlier, the user's record is still located on Corp
A
's equipment. Hence, the Wholesaler will “proxy” out the authentication transaction from its AAA proxy service to Corp
A
. An AAA service within the corporation domain then identifies the user, verifies the password, and provisions the user with appropriate authorizations. It may also receive accounting information, if desired. Then the AAA service at Corp
A
notifies the Wholesaler's proxy service that the user is acceptable and passes along provisioning details associated with the user (such as an IP (Internet protocol) address to use or a pool identification of an IP address pool from which an IP address needs to be allocated and any other information that may be needed). The Wholesaler then grants the user access to the network based upon the reply it gets back from Corp
A
. This technique is called “proxying.” This is shown diagrammatically in FIG.
2
.
To be able to perform basic proxying, the Wholesaler maintains minimal information on its proxy service
14
at its PoP. Information such as supported domain names, the IP address to which the transaction is to be sent, the port number (typically an OSI Layer
4
port number) to which the transaction is to be addressed, a shared secret between the proxy service and the remote AAA service, etc., are typically stored.
For example, turning now to
FIG. 2
, user Joe@corpa.com dials in to NAS
1
. A PPP (point to point protocol) session
10
is typically raised between Joe's terminal and NAS
1
. A LCP (Link Control Protocol) session is raised between NAS
1
and Joe's terminal. At this time the NAS
1
generates an authentication request using a protocol such as RADIUS (Remote Authentication Dial-In User Service) to the Wholesaler's proxy service
14
. Proxy service
14
then consults its local configuration database
16
. Proxy service
14
then makes a determination about where to send the authentication request (Access-Request in RADIUS). At this time the proxy service decides to forward the authentication request to the AAA service
18
maintained in the Corp
A
domain
20
. The Corp
A
AAA
18
then consults its local database
22
and authenticates Joe@corpa.com. Corp
A
AAA
18
then returns an access-accept packet to proxy service
14
which, in turn, sends an access-accept packet to NAS
1
. Then an IPCP (Internet Protocol Control Protocol) session is raised between NAS
1
and Joe's terminal during which an IP address is returned to configure Joe's terminal's PPP stack completing the log-in of Joe@corpa.com.
Frequently a large corporation or similar entity will have a need to provide PoPs at a number of locations to service its clients, customers and/or employees in a number of different cities. For example, a corporation “Corp
A
” located in Los Angeles, Calif. might have some employees using dial-up lines from San Francisco, Calif. and New York City, N.Y. It could let them dial directly to a server in Los Angeles, but the telephone network charges might be relatively high for the long distance connection. Alternatively, Corp
A
could establish PoPs in these cities—but the cost is also usually relatively high. Instead, it would be ideal to contract with Wholesaler's having a local presence in San Francisco and New York. These providers, in turn, can provide proxied access to the Corp
A
employees without a large capital outlay.
While it might appear ideal to do this, this mechanism raises some problems. For example, if Corp
A
has a great number of employees in San Francisco, they could overwhelm the PoP and prevent regular retail or other wholesale customers of the Wholesaler from enjoying the service that they paid for. Similarly, a large number of employees spread over many regions could potentially overwhelm the network maintained by the Wholesaler. Accordingly, the Wholesaler would like to enter into an arrangement with Corp
A
whereby Corp
A
pays a fee for a more or less specific number of proxied sessions to occur at any one time. When Corp
A
exceeds this contracted number it is either cut off or charged an extra fee. In this way, the Wholesaler is able to plan for its expansion and receive realistic information on the number of these sessions that it mu

Affiliated with

Also associated with

Rating

Proxy session count limitation does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Proxy session count limitation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Proxy session count limitation will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3044631