Fault tolerance for authentication, authorization, and accounting (AAA) functionality

An example network access device (NAD) includes a network interface to send and receive packets with an authentication, authorization, and accounting (AAA) server, and a subscriber management service unit (SMSU). The SMSU is configured to, responsive to determining that the AAA server is not reachable by the NAD, send a message from the NAD to the AAA server using the network interface, wherein the message directs the AAA server to send a discovery request message to the NAD, receive the discovery request message from the AAA server using the network interface, wherein the discovery request message includes a request for information about a plurality of subscriber sessions, and generate a discovery response message that includes information about at least a portion of the plurality of subscriber sessions, and send the discovery response message to the network access device using the network interface.

TECHNICAL FIELD

This disclosure relates to computer networks and, more particularly, to subscriber authentication, authorization, and accounting within computer networks.

BACKGROUND

Network service providers typically deploy one or more servers to manage authentication, authorization, and accounting (AAA) functionality for networks that offer services to one or more subscribers. The protocol most commonly used by the servers to communicate with clients is the Remote Authentication Dial In User Service (RADIUS) protocol. The RADIUS protocol is described in Carl Rigney et al., “Remote Authentication Dial In User Server (RADIUS),” Network Working Group of the Internet Engineering Task Force (IETF), Request for Comments 2865, June 2000, which is incorporated by reference herein in its entirety (referred to hereinafter as “RFC 2865”).

To request access to a service, a subscriber connects to a network access server (NAS) that acts as a gateway to the service as provided by a service provider network (or the Internet). Often the NAS is a RADIUS client configured to communicate with a RADIUS server for the service provider network using the RADIUS protocol. As such, the NAS confirms that the subscriber is authentic and is authorized to access the service by requesting the RADIUS server to validate the access request from the subscriber. Upon validating an access request, the RADIUS server responds to the NAS with a RADIUS protocol message directing the NAS to accept the access request and establish a session enabling connectivity between the subscriber and the service provider network for the requested service.

The NAS may thereafter monitor and record statistics describing service usage by the subscriber. If configured to use RADIUS accounting, the NAS periodically outputs messages to communicate the statistics to a RADIUS accounting server using the RADIUS protocol. RADIUS accounting is described in Carl Rigney, “RADIUS Accounting,” Network Working Group of the IETF, Request for Comments 2866, June 2000, which is incorporated by reference herein in its entirety (referred to hereinafter as “RFC 2866”).

SUMMARY

In general, techniques are described for providing a fault tolerance mechanism that enables recovery from a loss of session data by a authentication, authorization, and accounting (AAA) server or other server-side device that provides AAA functionality for clients, e.g., a group of network access servers (NASes). In the server-side recovery process, the AAA server may recover session information from the group of NASes (i.e., the clients) using a bulk client state discovery mechanism. The AAA server may execute a bulk client state discover process that queries each NAS to recover client state information (i.e., session information) for clients connected to the respective NAS. The bulk client state discover mechanism may be initiated by the AAA server in response to a failure on the AAA server or may be initiated by any one of the group of NASes when a NAS detects that the AAA server has failed.

In one example, a method includes providing, with a network access device, network access to a plurality of subscribers upon authenticating the subscribers with an authentication, authorization, and accounting (AAA) server, and storing, within the network access device, information for subscriber sessions associated with the subscribers. The method also includes determining, with the network access device, that the AAA server is no longer reachable by the network access device, and, responsive to determining that the AAA server is not reachable by the network access device, sending a message from the network access device to the AAA server to direct the AAA server to send a discovery request message to the network access device. The method also includes receiving, with the network access device, the discovery request message from the AAA server, wherein the discovery request message includes a request for the information about one or more of the subscriber sessions, generating, with the network access device, a discovery response message that includes information about at least a portion of the plurality of subscriber sessions, and sending, with the network access device, the discovery response message to the AAA server.

In another example, a network access device includes one or more network interfaces to send and receive packets associated with a plurality of subscriber session, and a subscriber management service unit having a database of subscriber records to store subscriber information for the subscribers sessions upon authenticating the subscribers with an authentication, authorization, and accounting (AAA) server. The subscriber management service unit is configured to, responsive to determining that the AAA server is not reachable by the network access device, send a message from the network access device to the AAA server, wherein the message directs the AAA server to send a discovery request message to the network access device, receive the discovery request message from the AAA server using the network interface, wherein the discovery request message includes a request for information about a plurality of subscriber sessions, and generate a discovery response message that includes information about at least a portion of the plurality of subscriber sessions, and send the discovery response message to the AAA server using the network interface.

In another example, a computer-readable storage medium is encoded with instructions that cause one or more programmable processors to determine whether an authentication, authorization, and accounting (AAA) server is reachable by the network access device, and, responsive to determining that the AAA server is not reachable by the network access device, send a message to the AAA server, wherein the message directs the AAA server to send a discovery request message to the network access device. The instructions further cause the one or more programmable processors to receive the discovery request message from the AAA server, wherein the discovery request message includes a request for information about a plurality of subscriber sessions, generate a discovery response message that includes information about at least a portion of the plurality of subscriber sessions, and send the discovery response message to the AAA server.

In another example, a method includes receiving, with an authentication, authorization, and accounting (AAA) server, a request to initiate a subscriber session information discovery process, and generating, with the AAA server, a discovery request message that includes a search criterion and a discovery type, wherein the search criterion includes a value of a session identifier, and wherein the discovery type indicates a bulk-type discovery request message. The method further includes sending, with the AAA server and to a network access device, the discovery request message using the AAA protocol, wherein the network access device operates in accordance with an AAA protocol, receiving, with the AAA server, a discovery response message from the network access device using the AAA protocol, wherein the discovery response message includes session information about at least one session identified by the network access device based on the search criterion, and storing the session information in a database of the AAA server.

In another example, a authentication, authorization, and accounting (AAA) server includes one or more network interfaces that send and receive packets with a network access device, a database configured to store subscriber session information, and a control unit. The control unit is configured to receive a request to initiate a subscriber session information discovery process, generate a discovery request message that includes a search criterion and a discovery type, wherein the search criterion includes a value of a session identifier, wherein the discovery type indicates a bulk-type discovery request message, and wherein the discovery request message is configured in accordance with an AAA protocol, send the discovery request message to the network access device using the AAA protocol, and receive a discovery response message from the network access device using the AAA protocol, wherein the discovery response message includes session information about at least one session that matches the search criterion, and store, in the database, the session information included in the received discovery response message.

In another example, a computer-readable storage medium is encoded with instructions that cause one or more programmable processors of an authentication, authorization, and accounting (AAA) server to receive a request to initiate a subscriber session information discovery process, and generate a discovery request message that includes a search criterion and a discovery type, wherein the search criterion includes a value of a session identifier, and wherein the discovery type indicates a bulk-type discovery request message. The instructions further cause the one or more programmable processors to send the discovery request message to a network access device using the AAA protocol, wherein the network access device operates in accordance with the AAA protocol, receive a discovery response message from the network access device using the AAA protocol, wherein the discovery response message includes session information about at least one session identified by the network access device based on the search criterion, store the session information in a database of the AAA server.

The techniques may provide one or more advantages. For example, the techniques may provide a lightweight mechanism by which a AAA server may recover from a crash or loss of data at the AAA server. Rather than querying the NAS for all session information one session at a time, techniques of this disclosure may enable the AAA server to request a group of session information at once and may enable the NAS to send a group of session information in a single response, thereby reducing the number of requests and replies exchanged between the AAA server and each NAS. Further, by providing a lightweight mechanism for recovering session information when an AAA server crashes, service providers may provide less robust AAA services without losing data, thereby reducing financial costs and reducing administrative overhead.

Like reference characters denote like elements throughout the figures and text.

DETAILED DESCRIPTION

FIG. 1is a block diagram illustrating a network system2having a Remote Access Dial in User Service (RADIUS) server14that supports a bulk client state discovery mechanism in accordance with techniques described in this disclosure. In this example, network system2includes service provider network12coupled to access network4via network access servers (NASes)8A-8C (collectively, “NASes8”).

Service provider network12supports one or more packet-based services that are available for request and use by subscriber devices6A-6N (collectively, “subscriber devices6”). As examples, service provider network12may provide Internet access, content delivery, voice over Internet protocol (VoIP), Internet Protocol television (IPTV), Short Messaging Service (SMS), Wireless Application Protocol (WAP) service, Telnet, or customer-specific application services. Service provider network12may include, for instance, a local area network (LAN), a wide area network (WAN), the Internet, a virtual LAN (VLAN), an enterprise LAN, a layer3virtual private network (VPN), an Internet Protocol (IP) intranet operated by a network service provider that also operates access network4, an enterprise IP network, or some combination thereof. In various embodiments, service provider network12may be connected to a public WAN, the Internet, or to other networks. Service provider network12executes one or more packet data protocols (PDPs), such as IP (IPv4 and/or IPv6), X.25 or Point-to-Point Protocol (PPP), to enable packet-based transport of service provider network12services.

An administrator of service provider network12(a network service provider) deploys one or more of NASes8to function as one or more gateways to the service as provided by a service provider network. Accordingly, each of NASes8is a device or component (e.g., board or service card) within a device that provides access to service provider network12. For example, each of NASes8may represent and/or incorporate a network access server that provides dial-up or virtual private network (VPN) services to an enterprise LAN, a remote access server (e.g., broadband remote access server) or broadband services router that aggregates outputs from one or more Digital Subscriber Line Access Multiplexers (DSLAMs) into a higher-speed uplink to service provider network12, a wireless access point (WAP) providing wireless physical layer access to service provider network12, or switches that use other LAN-based (e.g., Ethernet) technologies to provide wired physical layer access to service provider network12. One or more of NASes8may include a plurality of service cards that implement a decentralized control plane for subscriber management. Example network gateways having a decentralized control plane are described in U.S. patent application Ser. No. 13/248,825, entitled HIGH-AVAILABILITY MOBILE GATEWAYS HAVING INTERCHASSIS NON-UNIFORM SERVICE UNIT REDUNDANCY, filed Sep. 29, 2011, the entire contents of which being incorporated herein.

Subscriber devices6connect to NASes8via access network4to receive connectivity to service provider network12services for applications hosted by subscriber devices6. Each of subscriber devices6may represent, for example, a workstation, desktop computer, laptop computer, cellular or other mobile device, Personal Digital Assistant (PDA), gaming console, television set-top box, smart phone, tablet computer, or any other device capable of accessing a computer network via a wireless and/or wired connection. Each of subscriber devices6may be associated with a subscriber (e.g., a human). Applications that access services provided by service provider network12may alternatively be referred to as “user agents.” In this example, any of subscriber devices6may connect to any of NASes8in order to access service provider network12.

A network service provider (or other entity that administers service provider network12) operates or in some cases leases elements of access network4to provide packet transport between subscriber devices6and NASes8. Access network4may include a broadband access network, cellular access network, a wireless LAN, a public switched telephone network (PSTN), or other type of access network. In examples of network system2that include a cellular access network as access network4, any of NASes8may represent a mobile gateway, for example, a Gateway General Packet Radio Service (GPRS) Serving Node (GGSN), an Access Gateway (aGW), or a Packet Gateway (P-GW). Access network4may include a plurality of service virtual LANs (SVLANs) that partition elements of access network (e.g., DSLAMs) into logically different networks. Different subscriber devices6may therefore connect to NASes8using different SVLANs.

The elements of access network4may support any one or more of a variety of protocols, such as Internet Protocol (IP), Frame Relay, Asynchronous Transfer Mode (ATM), Ethernet, Point-to-Point Protocol (PPP), Point-to-Point Protocol over Ethernet (PPPoE), GPRS tunneling protocol (GTP), and virtual local area network (VLAN)-related protocols, among others. Using any one or more of these protocols, any of subscriber devices10may present authentication credentials to one or more of NASes8to request access to a service provider network12service. For example, subscriber device6A may broadcast credentials, such as a username and password, to each of NASes8to request access to a service provided by service provider network12. Subscriber devices6may broadcast credentials using, for instance, a PPPoE Active Discovery Initiation (PADI) packet to each of NASes8. In some instances, each of subscriber devices6is logically associated with one of NASes8and unicasts credentials directly to the associated NAS8to request a service. In some examples, subscriber device6A may be assigned a specific interface on one of NASes8(e.g., NAS8A) such that the subscriber is authenticated based on the interface on which network traffic is sent and received rather than on a username and password.

Each service provided by the active NAS8to a subscriber may constitute a communication session, with the beginning of the session defined as the moment when service is first established and the end of the session defined as the moment when service is terminated. A subscriber may have multiple sessions, such as TCP communication sessions, concurrently. The active NAS8for a partition (e.g., VLAN) stores session context information for corresponding subscriber sessions to a corresponding one of active session contexts10A-10C (collectively, “active session contexts10”) for the NAS. For example, NAS8A stores subscriber session contexts to active session contexts10A.

Each of active session contexts10includes one or more subscriber session contexts for subscriber sessions actively managed by the active NAS8. A subscriber session context in any of active session contexts10for a subscriber session stores session context information, such as the IP address allocated to the subscriber, the Access Point Name (APN) for the service, a Network Service Access Point Identifier (NSAPI) for the service session, forwarding information, charging information for accounting records, one or more quality of service (QoS) profiles for the subscriber, and/or a subscriber IMSI or other mobile subscriber identity.

NASes8are configured by the network service provider (or other administrative entity) as RADIUS clients that outsource authentication, authorization, and accounting (AAA) functions to a specified RADIUS server14, a device that receives and processes connection requests or accounting messages sent by any of NASes8. While described herein as using the RADIUS protocol, NASes8and RADIUS server14may be configured to use other network protocols, including the Diameter protocol and extensions thereof, to exchange authentication, authorization, accounting, and other information. The Diameter protocol is described in P. Calhoun et al., “Diameter Base Protocol,” Request for Comments 3588, September 2003, which is incorporated by reference herein in its entirety (referred to hereinafter as “RFC 3588”). Authentication is the process of verifying a subscriber identity. Authorization is the process of determining whether and the form in which an authenticated subscriber has access to service provider network12. Accounting is the process of generating records of session statistics for subscribers for billing and monitoring, for example.

When an active NAS8for a subscriber receives authentication credentials from the subscriber in an request to access service provider network12services, the active NAS8sends a RADIUS protocol Access-Request to RADIUS server14containing attributes such as the subscriber user name and password, an identifier for the active NAS8(e.g., the “NAS-ID”), the active NAS8network address, and the Port ID the subscriber is accessing. If RADIUS server14contains a configuration record for the subscriber that confirms the authorization credentials, RADIUS server14returns a RADIUS protocol Access-Accept message to the active NAS8. If a match is not found or a problem is found with the authentication credentials, the server returns an Access-Reject message. The active NAS8then establishes or terminates the user's connection. The active NAS8may then forward accounting information to RADIUS server14to document the transaction. RADIUS server14may store or forward this information to support billing for the services provided.

In some examples, RADIUS server14may outsource some AAA functionality to one or more backend servers, such as authentication server18, external database20, and remote RADIUS server22. These backend servers are illustrated inFIG. 1with dashed lines to indicate RADIUS server14may or may not, in various examples, use AAA services provided by the backend servers. Authentication server18is a backend authentication server, such as an RSA SecurID system, a Structured Query Language or Lightweight Directory Access Protocol (LDAP) database server, or Home Location Register, that stores is a list of subscriber accounts and subscriber account properties that can be checked by RADIUS server14to verify authentication credentials and queried by RADIUS server14to obtain subscriber account properties containing authorization and connection parameter information for subscribers. In some cases, authentication server18verifies authentication credentials on behalf of RADIUS server14. External database20is a backend database that RADIUS server14may use to store accounting information. In some cases, RADIUS server14is a proxy server for remote RADIUS server22.

RADIUS server14stores (internally or using external database20, for example) session information in session records for respective subscriber sessions established by NASes8. Session records include information received from NASes8in RADIUS request messages, such as RADIUS Accounting-Request and/or Access-Request messages. For example, a session record for a session established by NAS8A may include a subscriber user name, a NAS-IDentifier value for that uniquely identifies NAS8A to RADIUS server14, a NAS8A network address (e.g., an IPv4 or IPv6 address), an accounting session identifier that uniquely identifies the session on NAS18A (e.g., “Acct-Session-Id” described in RFC 2866), and accounting information (e.g., input or output octets/packets for the session, timing information).

From time to time, one of NASes8and/or RADIUS server14may be unavailable for processing subscriber logins and logouts, enforcing various policies, or performing other subscriber and network management tasks. In examples where one of NASes8crashes (e.g., NAS8A), NAS8A queries RADIUS server14to recover the subscriber session information. However, the success of recovering the session information depends upon RADIUS server14not crashing. In examples where RADIUS server14crashes, RADIUS server14may poll each of NASes8for all sessions known to RADIUS server14one session at a time to determine which sessions are missing (i.e., which sessions terminated while RADIUS server14was unavailable). Polling each of NASes8for the session information one session at a time very time intensive and computationally expensive. Further, using this technique, RADIUS server14may only poll NASes8for sessions having information stored at RADIUS server14and may not be able to recover session information for session that do not have information stored at RADIUS server14.

In accordance with techniques of this disclosure, RADIUS server14includes recovery module16that provides a bulk client state discovery mechanism. Recover module16enables RADIUS server14to issue a bulk request for session information to one or more of NASes8to recover session information for one or more subscriber sessions. Should RADIUS server14crash, be replaced, or otherwise lose connectively with one or more of NASes8, recovery module16, upon connectivity to NASes8being restored, issues a client state discovery command to one or more of NASes8. The client state discovery command may request all session information stored at each respective NAS8or a subset of the session information, whether or not RADIUS server14currently stores information about each session. That is, techniques of this disclosure enable RADIUS server14to request session information in bulk and retrieve session information for sessions not already “known” to RADIUS server14.

In one embodiment, RADIUS server14is configured as a policy and charging rules function (PCRF) device and each of NASes8is configured as a policy and charging enforcement function (PCEF) device, as defined by the 3rdGeneration Partnership Project (3GGP) standard. RADIUS server14and each of NASes8may exchange packets formatted or otherwise configured in accordance with the Diameter protocol. In particular, when implementing techniques of this disclosure, the packets exchanged between RADIUS server14and one or more of NASes8may configured in accordance with the Gx interface for the Diameter protocol.

In examples where the bulk client state discovery techniques are implemented using RADIUS, two previously unassigned RADIUS Packet Type Code values may be assigned such that the values identify packets that request client state information and packets that are sent in response to the request. The Packet Type Code values are included in a Packet Type Code parameter of each RADIUS packet. Each of the newly assigned RADIUS Packet Type Code values may be one of the currently unassigned Packet Type Code values (e.g., one of 52-249). For example, when requesting session information from a NAS8in accordance with techniques of this disclosure, RADIUS server14sends a request message to the respective NAS8(e.g., NAS8A) that includes a new RADIUS Packet Type Code value that identifies the message as a discovery request message that requests the client state information from the respective NAD8. The discovery request message, in one example, includes at least a session identification parameter and a discovery type parameter. The session identification parameter identifies a unique session that is created for the recovery of client state (i.e., session) information from NAS8A. In one example, the discovery type parameter may be set to a value that corresponds to one of three different discovery options. First, the discovery type parameter may be set to a value that corresponds to an “exact” discovery type, which causes NAS8A to return information about a client state or session that is specified in the discovery request message. Second, the discovery type parameter may be set to a value that corresponds to a “done” discovery type, which indicates that RADIUS server14completed all discovery operations. Third, the discovery type parameter may be set to a value that corresponds to a “bulk” discovery type, which causes NAS8A to return information about one or more client states or sessions based on search criteria. For example, NAS8A may return information for all client states or session having session identifiers that are lexicographically greater than a search string included in the discovery request.

The one or more of NASes8that receives the discovery request from RADIUS server14(e.g., NAS8A), generates a discovery response message based on the received discovery request message. The discovery response message includes a RADIUS Packet Type Code value that identifies the response message as a discovery response message that may include session information. The discovery response message specifies a session identifier that corresponds to the session identifier included in the discovery request message, a search criterion, and a result code. As one example, the search criterion may specify a session identifier for a session that is maintained by NAS8A. When the discovery request message includes a discovery type of “exact,” NAS8A returns information for the session that has a session identifier that matches the search criterion.

When the discovery request message specifies a discovery type of “bulk,” the discovery response message may include session information for as many sessions that fit in a single discovery response message and that meet the search criteria (e.g., that are lexicographically greater than the search string included in the discovery request message). In some instances, all of the session information that meets the search criterion will fit in a single discovery response message and NAS8A includes all of the matching session information in the discovery response message, sets the result code to a value that indicates “success” (i.e., that the discovery request completed successfully by being able to response with complete session information) and sends the response message to RADIUS server14. In other instances, more session information meets the search criteria than will fit in a single discovery response message. When more session information meets the search criteria than will fit in a single discovery response message, NAS8A includes as much session information as will fit in a single discovery response message, sets the result code to a value that indicates “limited success” (i.e., that the discovery request was partially successful, but that there is more session information available that matches the query) and sends the response message to RADIUS server14. In some instances, NAS8A may encounter a communication problem or some other issue that prevents NAS8A from retrieving the requested session information. In these instances, NAS8A sets the result code to a value that indicates “failed” (i.e., that the discovery request did not complete successfully) and sends a discovery response message to RADIUS server14.

RADIUS server14receives the discovery response message from NAS8A and processes the included session information. When the result code included in the discovery response message indicates “success,” RADIUS server14may send, to NAS8A, a discovery request message having the discovery type field set to “done” in order to notify NAS8A that the client state discovery process is complete. When the result code included in the discovery response message indicates “failed,” RADIUS server14may generate and send a discovery request message that includes the same search criterion as was sent in the previous discovery request message. That is, RADIUS server14may attempt to recover the same session information as was specified in the previous discovery request that resulted in a discovery response having a “failed” result code.

When the result code included in the discovery response message indicates “partial success,” RADIUS server14processes the session information included in the discovery response message and generates a new discovery request message. The new discovery request message is based on the previous discovery request message, but includes a different search criterion. In the new discovery request message, the search criterion is set to the session identifier for the last session having information included in the received discovery response message. For example, if information about sessions having session identifiers of one through four is included in the received discovery response message, RADIUS server14generates a new discovery request messaging having a discovery type of “bulk” and a search criterion of “four.” Because, in this example, NAS8A is configured to return information about sessions having session identifiers lexicographically greater than the search criterion (i.e., greater than four), NAS8A will return session information for any sessions that have a session identifier greater than four, up to the maximum number of sessions that may have session information included in a single discovery response message. While one example is provided, one of ordinary skill in the art may readily apply other identifier and search criterion matching techniques known in the art to achieve similar results.

In some embodiments, each NAS8may exchange keep-alive messages to RADIUS server14in order to enable RADIUS server14to determine if one or more of NASes8becomes unavailable and to enable each of NASes8to determine if RADIUS server14becomes unavailable. If one of NASes8(e.g., NAS8A) determines that RADIUS server14is unavailable, NAS8A may trigger RADIUS server14to initiate the client state discovery mechanism described above. In one example, each keep-alive message sent from NAS8A to RADIUS server14includes an origin state identifier field. When the keep-alive messages are being actively exchanged (i.e., NAS8A is receiving a response to each keep-alive message sent to RADIUS server14), the origin state identifier field maintains the same value. However, if NAS8A does not receive a response to a keep-alive message and determines that RADIUS server14is unavailable (e.g., crashed), NAS8A changes the value of the origin state identifier field included in the next keep-alive message. Once connectivity is restored to RADIUS server14, RADIUS server14detects the changed origin state identifier value and begins the bulk client state discovery process. In this manner, each of NASes8may initiate the bulk client state discovery mechanism in response to determining that RADIUS server14is unavailable.

FIG. 2is a block diagram illustrating an example instance of a network access server ofFIG. 1that supports a bulk client state discovery mechanism according to techniques described herein. In this example, NAS8A is divided into two logical or physical “planes” to include a first control plane24and a second “data” or “forwarding” plane28. That is, NAS8implements two separate functionalities, e.g., the routing/control and forwarding/data functionalities, either logically, e.g., as separate software instances executing on the same set of hardware components, or physically, e.g., as separate physical dedicated hardware components that either statically implement the functionality in hardware or dynamically execute software or a computer program to implement the functionality.

Control plane24is a decentralized control plane in that control plane functionality is distributed among routing unit26and one or more subscriber management service units32. Similarly, data plane28in this example is a decentralized data plane in that data plane functionality and packet forwarding functionality is distributed among a plurality of forwarding units40A-40N (“forwarding units40”). Each of routing unit30, subscriber management service units32, and forwarding units40may comprise one or more processors (not shown inFIG. 2) that execute software instructions, such as those used to define a software or computer program, stored to a computer-readable storage medium (again, not shown inFIG. 2), such as non-transitory computer-readable mediums including a storage device (e.g., a disk drive, or an optical drive) or a memory (such as Flash memory, random access memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions to cause the one or more processors to perform the techniques described herein. Alternatively or additionally, each of routing unit30, subscriber management service units32, and forwarding units40may comprise dedicated hardware, such as one or more integrated circuits, one or more Application Specific Integrated Circuits (ASICs), one or more Application Specific Special Processors (ASSPs), one or more Field Programmable Gate Arrays (FPGAs), or any combination of one or more of the foregoing examples of dedicated hardware, for performing the techniques described herein.

Switch26couples routing unit30, subscriber management service unit32, and forwarding units40to deliver data units and control messages among the units. Switch26may represent an internal switch fabric or cross-bar, bus, or link. Examples of high-speed multi-stage switch fabrics used as a forwarding plane to relay packets between units within a router are described in U.S. Patent Application 2008/0044181, entitled MULTI-CHASSIS ROUTER WITH MULTIPLEXED OPTICAL INTERCONNECTS. The entire contents of U.S. Patent Application 2008/0044181 are incorporated herein by reference.

Routing unit30executes the routing functionality of NAS8A. In this respect, routing unit30represents hardware or a combination of hardware and software of control that implements routing protocols (not shown inFIG. 2) by which routing information stored in a routing information base31(“RIB31”) may be determined. RIB31may include information defining a topology of a network, such as service provider network12ofFIG. 1. Routing unit30may resolve the topology defined by routing information in RIB31to select or determine one or more routes through the network. Routing unit30may then update data plane28with these routes, where forwarding units40of data plane28store these routes as respective forwarding information bases42A-42N (“FIBs42”). Further details of one example embodiment of a router can be found in U.S. patent application Ser. No. 12/182,619, filed Jul. 30, 2008 entitled “STREAMLINED PACKET FORWARDING USING DYNAMIC FILTERS FOR ROUTING AND SECURITY IN A SHARED FORWARDING PLANE,” which is incorporated herein by reference.

Data plane (alternatively, “forwarding plane”)28represents hardware or a combination of hardware and software that forward network traffic in accordance with forwarding information. In the example of NAS8A ofFIG. 2, data plane28includes forwarding units40that provide high-speed forwarding of network traffic received by interface cards44A-44N (“IFCs44”) via inbound links46A-46N to outbound links48A-48N. Forwarding units40may each comprise one or more packet forwarding engine (“PFE”) coupled to respective interface cards44and may represent, for example, a dense port concentrator (DPC), modular port concentrator (MPC), flexible physical interface card (PIC) concentrator (FPC), or another line card, for example, that is insertable within a NAS8A chassis or combination of chassis.

Each of forwarding units40may include substantially similar components to perform substantially similar functionality, said components and functionality being described hereinafter with respect to forwarding unit40A. Forwarding unit40A includes a request delegation module42A that receives session requests via IFC card44A and delegates the session requests to subscriber management service unit32.

As control plane anchors for subscriber sessions, service unit32handles configuration of forwarding units40for constructing subscriber-specific forwarding paths for processing and forwarding data traffic from the mobile devices. For example, service unit32may program session contexts37to forwarding units40for storage in respective session contexts37A′-37N′ (“session contexts37′”). Forwarding unit40A, for instance, receives user packets, maps the user packets to a session context in session contexts37′, and apply forwarding constructs to forward the user packets according to the session context data. For example, forwarding of downstream user packets by forwarding unit40A for a particular session may include encapsulating the user packets using the GPRS Tunneling Protocol (GTP) and setting the specified downstream TEID for the session within a GTP header. Example details on subscriber management units constructing subscriber-specific forwarding paths within forwarding units40can be found in U.S. patent application Ser. No. 13/172,505, entitled “VARIABLE-BASED FORWARDING PATH CONSTRUCTION FOR PACKET PROCESSING WITHIN A NETWORK DEVICE,” filed Jun. 29, 2011, the entire contents being incorporated herein by reference.

Subscriber management service unit32of control plane25presents a uniform interface to subscriber devices and provides decentralized service session setup and management for NAS8A. Subscriber management service unit32may represent, for example, a packet forwarding engine (PFE) or a component of physical interface card insertable within a chassis of NAS8A. The physical interface card may be, for instance, a multi-services dense port concentrator (MS-DPC). Subscriber management service unit32may also represent a co-processor executing on a routing node, such as routing unit30. Subscriber management service unit32may be alternatively referred to as a “service PIC” or “service card.”

Session control module35establishes subscriber sessions requested by an access network serviced by NAS8A and manages the sessions once established. Session control module35stores session data, received in control plane protocol messages received by session control module35or allocated by session control module35, for one or more sessions managed by service unit32in session contexts37. Service unit32may be referred to as the anchoring service unit for sessions stored in session contexts37in that service unit32stores control and forwarding information needed to manage the sessions. A session context stored in session contexts39for a session in which a device participates may include, for example, the PDP address allocated for the wireless device for use in sending and receiving user packets, routing information used by service unit32in forwarding user packets such as tunnel endpoint identifiers (TEIDs) and identifiers/addresses for downstream nodes, the APN for the session, and quality of service (QoS) profiles.

Session control module35executes an authentication, authorization, and accounting (AAA) module39A, a dynamic host configuration protocol (DHCP) module39B, and a charging protocol module39C for communication, for example, with a policy charging rules function (PCRF) entity (e.g., RADIUS server14). Subscriber management service unit32may independently execute control plane protocols required to establish a requested session for a subscriber, including the RADIUS protocol or Diameter protocol executed by AAA module39A. In this sense, subscriber management service unit32provides a form of a decentralized control plane for managing subscriber communication sessions for particular subscribers that are anchored to service unit. NAS8A may include a plurality of subscriber management service units32, each providing control plane functions to different subscriber communication sessions. As a result, NAS8A may achieve increased scalability to handle thousands or millions of concurrent communication sessions for subscriber devices.

AAA module39A of NAS8A and RADIUS server14operate in a client-server relationship. NAS8A may periodically send requests to RADIUS server14to perform application-to-application keep-alive and event notification. Each keep-alive request includes an origin state identifier parameter that, in accordance with techniques of this disclosure, is used to trigger the server (e.g., RADIUS server14) to perform the bulk client state discovery mechanism described herein. In some examples, fault tolerance module33generates the keep-alive requests and processes the responses to the sent keep-alive request. RADIUS server14receives the keep-alive requests, examines the value of the origin state identifier parameter, and sends a response to NAS8A. RADIUS server14may compare the value of the origin state identifier parameter of the received keep-alive request to a stored value that corresponds to the value of the origin state identifier parameter of a previously received request (i.e., a request received prior to when RADIUS server14received the most recent request).

If fault tolerance module33does not receive a proper response to keep-alive requests from RADIUS server14(e.g., within a configurable amount of time), fault tolerance module33determines that RADIUS server14is unreachable (e.g., because it crashed, lost network connectivity, etc.). When generating the next keep-alive request following the determination that RADIUS server14is unreachable, fault tolerance module33changes the value of the origin state identifier parameter. Fault tolerance module33sends the newly generated keep-alive requested having the changed value of the origin state identifier parameter to RADIUS server14. When RADIUS server14is reachable by NAS8A and receives the newly generated keep-alive request, RADIUS server14compares the value of the origin state identifier parameter to the stored value that corresponds to the value of the origin state identifier parameter of a previously received request. In this instance, the value of the origin state identifier parameter included in the currently received keep-alive request is different than the stored value, which acts as an implicit discovery request to trigger RADIUS server14to initiate the bulk client state discovery procedures. In this manner, NAS8A may trigger RADIUS server14to preform the client state discovery mechanism using link management protocol extension requests (e.g., keep-alive requests).

During the bulk client state discovery process, NAS8A receives a discovery request from RADIUS server14. Session control module35of subscriber management service unit32processes the discovery request and determines which sessions match the criteria specified in the discovery request. As described above, the discovery request includes a session identifier. Session control module35, in one example, identifies a set of sessions that have a session identifier that is lexicographically greater than the session identifier included in the discovery request. In one example, session control module35walks through active session contexts37to identify the matching sessions and retrieve information for each of the matching sessions. Session control module35generates a discovery response message that includes the retrieved information about the identified sessions. In some embodiments, each discovery response message may have a maximum size (e.g., a maximum number of bytes) and not all of the session information requested by RADIUS server14may fit in a single discovery response message.

If the number of sessions included in the identified set of sessions is greater than the number of sessions that fit in a single discovery response message, session control module35includes a first portion of the identified set of sessions in the discovery response message. The first portion, in one example, includes the portion of sessions that have session identifiers lexicographically closest to and greater than the session identifier included in the discovery request message. In one example, if the session identifier included in the discovery request message is the value “ ” (i.e., an empty string) and information about three sessions fit in a single discovery response message, session control module35includes information about the sessions that have session identifiers of “1”, “2”, and “3” as all session identifiers stored by NAS8A are lexicographically greater than an empty string.

As described above, each discovery response message includes a result-code parameter. When RADIUS server14requests more session information than fits in a single discovery response message, session control module35sets the result-code parameter to a value that indicates “limited success.” In other words, session control module35, using the result-code parameter, notifies RADIUS server14that addition session information met the criteria of the discovery request message, but could not be included in the current discovery response because it did not fit.

When RADIUS server14receives a discovery response message that includes a result-code parameter that indicates “limited success,” RADIUS server14generates a new discovery request message and set the search criterion to the session identifier of the last session for which information was included in the received discovery response message. Continuing the example above, the discovery response message includes information about sessions having session identifiers of “1”, “2”, and “3” and the result-code parameter indicates “limited success.” Thus, RADIUS server14generates a new discovery request and sets the search criterion value to “3.”

NAS8A receives the new discovery request and session control module35generates a new discovery response that includes information about sessions having a session identifier greater than “4”. The process continues until all of the requested session information is sent to RADIUS server14. Session control module35notifies RADIUS server14that the last discovery response message is, in deed, the last discovery response message by setting the result-code parameter to a value that indicates “success.”

FIG. 3is a block diagram illustrating an example RADIUS server that supports a bulk client state discovery mechanism in accordance with techniques described in this disclosure. RADIUS server14includes control unit50and network interface card52. Operation of RADIUS server14is described in the context of network system2ofFIG. 1.

Control unit50of RADIUS server14provides an operating environment for executing modules, which in the illustrated example include network interface54, authorization module58, accounting module60, and management interface64. Control unit30may include one or more processors (not shown), including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components, to execute modules that implement the functionality described herein. In this example, control unit30also includes computer-readable storage media to store configuration data55, user profile database57(illustrated as “user profile DB40”), and accounting database59(illustrated as “accounting DB42”) data structures, which may include flat files, databases, tables, trees, and/or lists, for example.

Administrator50represents a network service provider entity (e.g., a human or software agent) that invokes management interface48to configure RADIUS server14with configuration data of configuration data55and user profiles of user profile database57. Management interface48may present a front-end interface, such as a web-based or other graphical user interface or a command-line interface, to allow administrator50to enter configuration data. Management interface48may present an LDAP configuration interface for configuring and retrieving user profiles from user profile database57. Management interface48may also execute Simple Network Management Protocol to enable monitoring and configuration by administrator50.

Administrator50invokes management interface48to add RADIUS client information to configuration data55for each client of RADIUS server14, such as each of NASes8ofFIG. 1. RADIUS client information for any of NASes8may include the NAS network address and a RADIUS shared secret used to validate communications between RADIUS server14and the NAS.

User profile database57stores user profiles for subscribers. A user profile may include a corresponding subscriber user name and password and/or other authentication credentials, as well as the subscriber's authorization and/or connection parameters. In some examples, user profile database57is a remote database to which RADIUS server14issues authentication and authorization requests to receive an authentication indication (e.g., accept or reject) as well as authorization and/or connection parameters.

Accounting database59stores subscriber accounting information for RADIUS server14operating as a RADIUS accounting server. Accounting database59may include a structured query language (SQL) database. In some examples, accounting database59is a remote database to which RADIUS server14issues queries to add or modify subscriber accounting information.

Network interface card32exchanges network packets that carry RADIUS protocol messages with one or more NASes8connected to network interface card32by network links. Network interface card32exchanges network packets with network interface34of control unit30. User Datagram Protocol (UDP) datagrams carry RADIUS protocol messages. Network interface34implements a network stack to receive UDP messages sent to a port assigned to RADIUS and provides application data in the form of RADIUS protocol request packets to authorization module58and accounting module60for processing after threshold validation of the RADIUS protocol messages by validation module56. Similarly, network interface34uses the network stack to encapsulate RADIUS reply packets in UDP datagrams for output by network interface card32to NASes8.

Example RADIUS protocol request packets include Access-Request messages sent by a RADIUS client to request authentication and authorization for a service connection and Accounting-Request messages sent by a RADIUS client to specify accounting information for a service connection that has been established by the RADIUS client. Network interface34provides each RADIUS protocol request packet to validation module56, which performs RADIUS client validation of the packet by confirming that the request authenticator included therein specifies the shared secret configured in alias38for the source network address of the RADIUS protocol request message. If RADIUS client validation fails, the packet is silently ignored/dropped. Upon successful RADIUS client validation, validation module56passes the RADIUS protocol request message to authorization module58(in the case of an Access-Request message) or to accounting module60(in the case of an Accounting-Request message).

Authorization module58processes an Access-Request message from NAS8A by querying user profile database57to obtain credentials for the subscriber requesting access and attempting to validate the subscriber against the credentials. If authorization fails, authorization module58returns an Access-Reject message to NAS8A. If authorization is successful, authorization module58returns an Access-Accept message to the NAS8A.

In addition to a subscriber user name and credentials, the Access-Request message includes one or more attributes. Specifically, the Access-Request message includes at least one network access server (NAS) identifier (e.g., a NAS-IDentifier value and/or a NAS-IP-Address value) for NAS8A and may in some cases include an Acct-Session-Id, as well as other attributes. When the Access-Request message includes an Acct-Session-Id and authorization is successful, authorization module58may in some cases access a session record by creating the session record in accounting database59for the authorized session to be established by NAS8A. In this way, authorization module58creates the session record such that the session may be identified based on the Acct-Session-Id and the NAS identifier for NAS8A.

Like an Access-Request message, an Accounting-Request message issued by NAS8A, for instance, and received by RADIUS server14must include at least one NAS identifier and must also include an Acct-Session-Id that uniquely identifies one of active sessions contexts10A (and the corresponding session) of NAS8A, as well as other attributes that carry accounting information for storage to accounting database59. If the Accounting-Request message is a valid request, accounting module60accesses a session record to retrieve the session record in accounting database59for the session using a combination of the Acct-Session-Id and the NAS identifier. Accounting module60may then modify the session record using the accounting information carried by the Accounting-Request message. Modifying a session record using the accounting information may include adding a log entry to accounting database59that references the session record. RADIUS server14may create, retrieve, modify, and delete a session record in accounting database59upon receiving Accounting-Request messages from NAS8A that include the Acct-Session-Id for the session.

Should RADIUS server14crash, reboot, or otherwise become unavailable, control unit30determines that RADIUS server became unavailable and client state discovery module62automatically initiates the bulk client state discovery techniques described herein. Client state discovery module62sends accounting module60a message that causes accounting module60to retrieve a session identifier and a corresponding NAS identifier from accounting DB42for each unique NAS identifier stored in accounting DB42(e.g., for each one of NASes8). In some instances, accounting module60then deletes the session information stored in accounting DB42. The session identifier retrieved from accounting DB42may, in some examples, be the lowest value (e.g., lexicographically lowest value) stored in accounting DB42. For each NAS, client state discovery module62generates a discovery request message having the value of the search criterion parameter set to an empty string and the value of the discovery-type parameter set to a value that indicates a bulk-type discovery request.

RADIUS server14sends a generated discovery request message to each of NASes8based on the NAS identifier associated with each respective session identifier retrieved from accounting DB42. Each respective NAS8generates a discovery response message based on the discovery request message, as described above, and sends the discovery response message to RADIUS server14. Client state discovery module62process the received discovery response message and determines whether to generate additional discovery request messages based on the value of the result-code parameter included in each discovery response message. When the result-code parameter is set to a value that indicates that the sending one of NASes8encountered an error, client state discovery module62generates a new discovery request message that includes the same search criterion as the previously sent discovery request message (i.e., the discovery request message that caused the respective NAS8to send the discovery response message that included the error indication in the result-code parameter). When the result-code parameter is set to a value that indicates that “success” or “limited success,” client state discovery module62extracts the session information from the discovery response message and passes it to accounting module60. Accounting module60stores the session information in accounting DB42. If the result-code parameter is set to a value that indicates “limited success,” client state discovery module62generates a new discovery request message having a discovery type of “bulk” and a search criterion set to the value of the greatest session identifier included in the received discovery response message. If the result-code parameter is set to a value that indicates “success,” client state discovery module62determines that all session information has been received from the respective one of NASes8and determines that no additional discovery request messages currently need to be generated and sent to the respective one of NASes8. In some embodiments, client state discovery module62may be configured to sent a discovery request message that includes a discovery type of “done” to notify the respective one of NASes8that the current instance of the bulk client state discovery process is complete.

FIG. 4is a flowchart illustrating an example mode of operation for a network access server that supports a bulk client state discovery mechanism in accordance with techniques described in this disclosure. For purposes of illustration only, the example mode of operation shown inFIG. 4will be described with respect to network system2ofFIG. 1and NAS8A ofFIG. 2. One or more example operations in the illustrated mode of operation may be optional and may not be required to perform the bulk client state discovery mechanism described in this disclosure.

In the example operation shown inFIG. 4, NAS8A and RADIUS server14are configured to be communicatively coupled and exchange subscriber session information as described above. NAS8A sends periodic keep-alive messages to RADIUS server14, in part, to verify that RADIUS server14is reachable by NAS8A over a network (70). The keep-alive messages include an origin state identifier field that maintains a static value unless or until RADIUS server14is not reachable by NAS8A. NAS8A monitors responses to the keep-alive message to determine whether RADIUS server14is reachable by NAS8A (72). As long as a response message corresponding to a keep-alive message is received within a configurable amount of time (“YES” branch of72), NAS8A determines that RADIUS server14is reachable from NAS8A and continues normal operation, including sending keep-alive message. If a response to a keep-alive message is not received within a configurable amount of time (“NO” branch of72), NAS8A determines that RADIUS server14is unreachable by NAS8A (e.g., that RADIUS server14failed) (74).

Responsive to sending the keep-alive message with the updated origin state identifier parameter, NAS8A receives a discovery request message from RADIUS server14(78). The discovery request message includes a search criterion parameter that NAS8A uses to identify a plurality of sessions maintained by NAS8A for which RADIUS server14is requesting information and a discovery type parameter that indicates that the message is a discovery request message. In one embodiment, a first discovery request message sent from RADIUS server14includes an empty string as the search criterion. In this embodiment, an empty string indicates that RADIUS server14is requesting information about all of the sessions currently maintained by NAS8A. NAS8A identifies the matching sessions and generates a discovery response message that includes the information for the identified sessions (80).

In one example, the discovery response message has a maximum size (e.g., a maximum number of kilobytes) such that only a portion of the requested session information fits within a single discovery response message (82). When the amount information about the requested sessions is greater than the amount of information that will fit in a single discovery response message (“YES” branch of82), NAS8A generates a first discovery response message that includes a portion of the requested session information, sets a result-code parameter of the discovery response message to a value that indicates “partial success” (84), and sets the discovery type parameter to a value that indicates that the message is a discovery response message. NAS8A sends the discovery response message to RADIUS server14.

RADIUS server14receives the discovery response message and, based at least in part on the value of the result-code parameter of the received discovery response message, determines that addition session information is available. RADIUS server14generates another discovery request message that includes a search criterion parameter set to the value of the lexicographically greatest session identifier included in the received discovery response message. NAS8A receives the additional discovery request message (78) and generates a discovery response message based at least in part on the discovery request message (80). While there remains more session information that matches the search criterion included in the discovery request message than will fit in a single discovery response message (“YES” branch of82), NAS8A continues to generate discovery response messages that have the result-code parameter set to a value that indicates “limited success” (84) and send the discovery response messages to RADIUS server14(86).

When the session information for the sessions that match the search criterion fit in a single discovery response message (“NO” branch of82), NAS8A sets the value of the result-code parameter to a value that indicates “success” (88) and sends the discovery response message to RADIUS server14(90). RADIUS server14, upon receiving the discovery response message that includes the “success” result code, may generate a discovery request message having a discovery type of “done” to notify NAS8A that the current bulk client state discovery operation is complete.

FIG. 5is a flowchart illustrating an example mode of operation for a RADIUS server that supports a bulk client state discovery mechanism according to techniques described herein. For purposes of illustration only, the example mode of operation shown inFIG. 5will be described with respect to network system2ofFIG. 1and RADIUS server14ofFIG. 3. One or more example operations in the illustrated mode of operation may be optional and may not be required to perform the bulk client state discovery mechanism described in this disclosure.

In general, RADIUS server14performs the bulk client state discovery operation in response to detecting that RADIUS server14lost network connectivity, crashed, or otherwise failed (100). However, in some instances, the bulk client state discovery operation may be initiated manually by an administrator (e.g., administrator66ofFIG. 3). RADIUS server14may determine that RADIUS server14failed based on server state information, operational logs, configuration parameters, etc. In some examples, RADIUS server14may determines that RADIUS server14failed in response to receiving a keep-alive request from a NAS communicatively coupled to RADIUS server14(e.g., NAS8A ofFIG. 1) when the keep-alive request includes an origin state identifier parameter that is set to a different value than the last received keep-alive message.

In some examples, responsive to determining that RADIUS server14failed, RADIUS server14may delete all stored subscriber session information (e.g., all information stored in accounting DB59) (102). Deleting all stored subscriber session information may enable RADIUS server14to refresh all subscriber session information and not maintain any expired or inaccurate subscriber session information. RADIUS server14generates a discovery request message that requests subscriber session information and sends a respective discovery request message to each NAS8(104). The discovery request message includes a search criterion parameter and a discovery type parameter. In examples where RADIUS server14deletes all stored session information, the search criterion parameter may be set to the value of an empty string, which may trigger the receiving one of NASes8to send all subscriber session information stored by the receiving one of NAS8esto RADIUS server14. The discovery type parameter may be set to one of three values that indicate a bulk-type discovery request, an exact-type discovery request, and a done-type discovery request. The bulk-type discovery request causes the receiving one of NASes8to send as much information about sessions that match the search criterion as will fit in a single discovery response message. That is, the discovery response message generated in response to a bulk-type discovery request message may include information about a plurality of sessions. The exact-type discovery request message causes the receiving one of NASes8to send information about the one session that matches the search criterion. The done-type discovery request message is an option discovery request message that is used to notify the receiving one of NASes8that the current bulk client state discovery operation is complete.

RADIUS server14receives a discovery response message from each of NASes8and determines whether the discovery response was a success (108). The discovery response messages include a result-code parameter that is set by the respective sending NAS8and indicates whether the respective NAS8was able to retrieve information for sessions matching the search criterion and whether there is additional information available for sessions that match the search criterion but is not included in the current discovery response. When the discovery response indicates that there was an error (“NO” branch of108), RADIUS server14sends a discovery request message to the corresponding NAS8where the discovery request message includes the same search criterion as the discovery request message that was previously sent to the corresponding NAS8. When the discovery response message indicates that it was a limited success (“LIMITED” branch of108), RADIUS server14determines that additional subscriber information matches the previously sent search criterion and sends another discovery request message (110). The additional discovery request message includes the search criterion field set to the value of the lexicographically greatest session identifier included in the received discovery response message.

RADIUS server14receives the next discovery response message (i.e., generated and sent by the NAS8to which RADIUS server14send the additional discovery request message) and processes the next discovery response message as described above. RADIUS server14continues to send discovery request messages and received discovery response messages until the discovery response message includes the result-code parameter set to a value that indicates “success” (“YES” branch of108). The “success” result code signals to RADIUS server14that no additional subscriber session information that matches the last search criterion is available. That is, the “success” result code indicates to RADIUS server14that all subscriber session information matching the search criterion included in the corresponding discovery request message is included in the current discovery response message. RADIUS server14stores all of the received session information (e.g., in accounting DB59) (112). While illustrated inFIG. 5as occurring after all discovery response messages are received by RADIUS server14, RADIUS server14may store the session information included in each received discovery response message at any time, including prior to sending any additional discovery request messages.