AU6861100A - Apparatus and method for routing aaa messages between domains of a network - Google Patents

Apparatus and method for routing aaa messages between domains of a network Download PDF

Info

Publication number
AU6861100A
AU6861100A AU68611/00A AU6861100A AU6861100A AU 6861100 A AU6861100 A AU 6861100A AU 68611/00 A AU68611/00 A AU 68611/00A AU 6861100 A AU6861100 A AU 6861100A AU 6861100 A AU6861100 A AU 6861100A
Authority
AU
Australia
Prior art keywords
nai
aaa
message
domain
local
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
AU68611/00A
Inventor
Haseeb Akhtar
Basavaraj Patil
Emad Qaddoura
Rambabu Tummala
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nortel Networks Ltd
Original Assignee
Nortel Networks Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nortel Networks Ltd filed Critical Nortel Networks Ltd
Publication of AU6861100A publication Critical patent/AU6861100A/en
Abandoned legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/14Charging, metering or billing arrangements for data wireline or wireless communications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/14Charging, metering or billing arrangements for data wireline or wireless communications
    • H04L12/1403Architecture for metering, charging or billing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • H04L61/5014Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5046Resolving address allocation conflicts; Testing of addresses
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5076Update or notification mechanisms, e.g. DynDNS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5084Providing for device mobility
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/2866Architectures; Arrangements
    • H04L67/30Profiles
    • H04L67/306User profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/51Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/52Network services specially adapted for the location of the user terminal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/53Network services using third party service providers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00Indexing scheme associated with group H04L61/00
    • H04L2101/60Types of network addresses
    • H04L2101/604Address structures or formats
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Description

WO 01/24476 PCT/IBOO/01304 APPARATUS AND METHOD FOR ROUTING AAA MESSAGES BETWEEN DOMAINS OF A NETWORK TECHNICAL FIELD OF THE INVENTION This invention relates generally to routing messages between domains of a network and, more particularly, to routing messages between domains of a network using 5 Authentication, Authorization, and Accounting ("AAA") protocols. BACKGROUND Internet Protocol (IP) networks, such as the Internet, are generally apportioned into "domains," and each user of a D network is typically assigned to one "home" domain within the network. Unfortunately, when a user is assigned to one home domain, it is often difficult and cumbersome for that user to then access the network through a "non-home" domain. This is because, when a user attempts to access the network through a non-home domain, the non-home domain is not configured to readily authenticate who the user is, and to determine what the user's home domain is, and what account the user is authorized to use with the home domain. The difficulty users experience accessing the network through non-home domains is becoming more acute as users are becoming more mobile, traveling between domains, and desiring access to networks from any number of different locations, often not within the range of their home domain. Therefore, there is a growing need for technology, namely protocols, which will permit users to readily access a network from "non-home" domains. To this end, various protocols, referred to as Authentication, Authorization and Accounting ("AAA") protocols have been developed by Internet Service Providers (ISP's) which permit domains to WO 01/24476 PCT/IBOO/01304 authenticate users of other domains, to identify the home domain and accounts held by users at their home domains, and to obtain authorization from the user's home domain for the user to use the identified account, as the user travels between domains of the Internet. There are, however, a number of drawbacks associated with using conventional AAA protocols, many of which drawbacks are related to their failure to provide an adequate mechanism to route AAA messages among various AAA entities. Some of the drawbacks of conventional AAA protocols are that: 1) they provide routing based only on user network access identifiers ("NAIs"); 2) they support messaging only between a user's home domain and serving domain; 3) they do not allow communication between two or 5 more non-home serving domains, such as during handoffs; 4) they do not allow specifically directed communication between two AAA entities; 5) they require that AAA entities have publicly routable, as opposed to private, IP addresses; and 6) they create potential security problems by virtue of D modification of AAA messages by AAA servers by addition of a proxy state. With respect to item 5), conventional AAA protocols do not permit communication with a AAA entity behind a firewall or proxy server wherein the entity does not have a publicly routable IP address, but has only a 5 private IP address. Two embodiments of AAA protocols proposed by the Internet Engineering Task Force are referred to as RADIUS and DIAMETER. DIAMETER, for example, specifies that DIAMETER servers be stateless, meaning that DIAMETER servers 0 should act strictly as routers for DIAMETER clients' messages without storing state information, such as the source or destination of the messages. Servers that do not store such state information are referred to as being "lightweight." According to recent drafts of the DIAMETER 2 WO 01/24476 PCT/IBOO/01304 protocol, AAA messages are routed according to a User NAI, which may be provided in a format such as "user@domainX.com". A User NAI is, in common terminology, a user's e-mail address. DIAMETER currently uses the domain 5 of the user NAI (e.g., domainX) to route messages, the domain also being referred to as the realm portion of the user NAI. Conventional AAA servers, such as those employing DIAMETER and RADIUS, include the following fields in AAA 0 messages for routing messages to their proper destinations: 1. User NAI; 2. Proxy State(only used when messages go through proxy servers); and 3. Command Code (i.e., message type). 5 The User NAI identifies the user that the message is carried on behalf of. The Proxy State is a field used when a proxy server is used to forward AAA messages. The Command Code identifies the type of message. FIGURE 1 depicts a communication network 100 commonly 0 used in the prior art in connection with transmission and receipt of AAA messages. The network 100 includes a data network (such as the Internet) 102 that is coupled to a Domain A, a Domain B, and a Domain C. Domain A includes an AAA Entity 1 of Domain A, an AAA Entity 2 of Domain A, and 5 an AAA Server of Domain A, which are operably interconnected to one another and also to the data network 102. In addition, Domain B includes an AAA Entity 1 of Domain B, an AAA Entity 2 of Domain B, and an AAA Server of Domain B, each of which is operably interconnected to one another and 0 also to the data network 102. Similarly, Domain C includes an AAA Entity 1 of Domain C, an AAA Entity 2 of Domain C, and an AAA Server of Domain C, each of which is operably interconnected to one another and also to the data network 102. 3 WO 01/24476 PCT/IBOO/01304 The AAA servers of Domain A, Domain B, and Domain C are each responsible for delivering or routing AAA messages to appropriate entities, which perform task(s) specified by the messages. It is the responsibility of the AAA. servers of 5 Domain A, Domain B, and Domain C to resolve the appropriate server or entity to which to send the AAA messages. The AAA Entities 1 and 2 of Domain A, Domain B, and Domain C each serve users in their respective domains and are also used to forward messages between users and the AAA Entities' LO respective AAA servers. The AAA Servers and AAA Entities illustrated in FIGURE 1 may comprise any conventional computer generally capable of receiving, storing, processing, and outputting data. While not shown in detail, the AAA Servers and AAA Entities L5 each include components, such as input and output devices, volatile and non-volatile memory, and the like, but, because such computer components are well known in the art, they are not shown or described in further detail herein. The drawbacks associated with conventional AAA .0 protocols outlined above are discussed in more detail hereinbelow. For example, as an illustration of the first drawback mentioned above, suppose an AAA registration request of a user with a User NAI of name@DomainB.com is sent from the AAA Entity 1 of Domain A to the AAA Server of 5 Domain A. In accordance with conventional protocols, the AAA Server of Domain A reads the realm portion of the User NAI of the message, determines that the message should be forwarded to the Domain B, and forwards the message to the AAA Server of Domain B. Upon receiving the message, the AAA 0 Server of Domain B determines that the message is intended for an entity in its domain and then forwards the message to the appropriate AAA Entity, such as, for example, the AAA Entity 1 of Domain B. The AAA Entity 1 of Domain B then processes the message. 4 WO 01/24476 PCT/IBOO/01304 After the AAA Entity 1 of Domain B has processed the message, it will attempt to send a registration response message back to the AAA Entity 1 of Domain A. In so attempting, the AAA Entity 1 of Domain B forwards the 5 registration response message to its AAA server, which is the AAA Server of Domain B. The AAA Server of Domain B will then attempt to forward the message to its proper destination, AAA Entity 1 of Domain A. However, the AAA server of Domain B cannot use the user NAI (i.e., 0 name@domainB.com) to route the message to the AAA Entity 1 of Domain A, because to do so would direct the message to the AAA Entity 1 of Domain B as a result of the AAA Server of Domain B determining where to route the message based on the domainB realm of the User NAI. The User NAI does not 5 include any information to tell the AAA server of Domain B that the user (i.e., name@domainB.com) has sought to register at a non-home domain (i.e., Domain A). Under conventional AAA protocols, Domain B would use a Proxy State to send a message back to Domain A. Under such 0 protocols, the AAA server of Domain B does not have the necessary information to forward the registration response message to the Domain A or, more particularly, to the AAA Entity 1 of Domain A. To properly route the registration response message, the AAA server of Domain B would need to 5 maintain state information regarding the source of the original registration request message (i.e., AAA Entity 1 of Domain A) or use a Proxy State. However, the AAA server of Domain B cannot maintain this state information without running afoul of DIAMETER's requirement that all AAA servers 0 be stateless. The second and third drawbacks of conventional AAA protocols mentioned above can be exemplified by a user having a user NAI of user@domainB.com who connects via a wireless mobile link to the data network 102 through the 5 WO 01/24476 PCT/IBOO/01304 Domain A, for example, using a notebook computer or personal digital assistant. As the user moves from the Domain A to the Domain C, the Domain A and the Domain C will need to communicate with one another in order to facilitate a 5 handoff of the user. However, conventional AAA protocols do not permit such communication because a message sent on behalf of the user to the Domain C in an effort to initiate the handoff would result in a response to the message based on User NAI by the Domain C being sent to the Domain B, 0 because Domain B is the user's home domain, as indicated by the realm portion of the user' s user NAI (i.e., "domainB") . Thus, communication between the two non-home serving domains (e.g., Domain A and Domain C) is not possible using conventional protocols. 5 The second and third drawbacks are also exemplified when a user with user NAI of user@domainC.com connected to the data network 102 via a wireless link travels from the Domain B to the Domain A and thus needs to be handed off to the Domain A. Conventional protocols do not permit a 0 particular AAA entity newly assigned to serve the user (e.g., AAA Entity 2 of Domain 7.) to communicate with an AAA entity of Domain B that had been serving the user prior to the handoff request (e.g., ;AA Entity 2 of Domain B) . Rather, a message from the AAA Entity 2 of Domain A would be 5 sent to the Domain C, because The Domain C is indicated as the user's home domain by virtue of the realm portion of the user's User NAI (i.e., "domainC"). The fourth and fifth drawbacks of conventional AAA protocols mentioned above are exemplified when the AAA 0 Entity 2 of Domain A needs to communicate specifically with the AAA Entity 1 of Domain B, for example, because a roaming wireless Internet user moving between Domain A and Domain B needs to be handed off from the Domain A to the Domain B. Conventional AAA protocols do not permit such communication. 6 WO 01/24476 PCT/IBOO/01304 While conventional protocols do permit an entity in a non home serving domain to specifically communicate with another entity in the user's home domain, they do not permit specific entities in two different non-home serving domains to communicate with one another. This problem is exacerbated when one or both of the entities is behind a proxy server or firewall, since conventional protocols require publicly-routable IP addresses. As is well known, an entity behind a proxy server or firewall does not have a publicly routable IP address, but, rather, only has a private IP address. This drawback of conventional protocols is due in part to their use of user NAIs for AAA message routing. In addition, if a host IP address has only a private address, the same drawback of conventional AAA protocols is present. The sixth drawback is illustrated by the use of a proxy state by AAA servers to modify or mark AAA messages so that they can be routed. Under conventional protocols, a computer participating in the routing of a message is required to mark or modify the message in order to keep track of from where it received the message. For example, if computer 1 routes a message to computer 2, computer 2 will mark or modify the message to indicate that it came from computer 1. When computer 2 sends the message to 5 computer 3, computer 3 will, on receipt of the message, mark or modify it as having been received from computer 2. This process of marking or modifying the message will continue until the message reaches its destination. Such marking or modification of messages creates a security risk because it prevents the use of certain security mechanisms, such as IPSEC, which attempt to maintain message security by verifying whether a message has been modified. Thus, if routing computers modify or mark the message using a proxy state, the security mechanisms are 7 WO 01/24476 PCT/IBOO/01304 unable to verify that that the message has not been modified. Thus, there is a need for an apparatus and method for routing AAA messages among various AAA entities in systems 5 based on domains in which routing of AAA messages of roaming users is achievable, messaging between a AAA entity to another AAA entity in any domain can be performed, and communication between two or more non-home serving domains can be accomplished. There is a further need for an 0 apparatus and method that permits communications between two specific entities in different domains as well as communications between entities in which one or more of the entities is behind a firewall or a proxy server and thus does not have a publicly-routable IP address. There is a 5 further need for an apparatus and method that overcome the potential security problems associated with the use of a proxy state message modification to route AAA messages as in the prior art. There is also a need for AAA servers capable of meeting the above-described needs to be stateless and 0 lightweight, since the RADIUS and DIAMETER protocols mandate that message state information not be stored in the servers. SUMMARY OF THE INVENTION 5 In response to these and other limitations, provided herein are a unique method and apparatus for routing Authentication, Authorization, and Accounting ("AAA") messages in a communication system. The communication system comprises a data network coupled to a plurality of ) domains, wherein each domain includes at least one AAA server and at least one AAA Entity. In one embodiment, routing an AAA message includes receiving the AAA message having a User NAI, determining whether the AAA message includes a Destination NAI, in 8 WO 01/24476 PCT/IBOO/01304 response to a determination that the AAA message includes a Destination NAI determining whether an NAI domain of the Destination NAI is or is not local. In response to a determination that the Destination NAI is local, the AAA 5 message is dispatched to a local AAA entity identified by the Destination NAI. In response to a determination that the Destination NAI is not local, the AAA message is dispatched to an AAA server in a non-local domain identified by the Destination NAI. In other embodiments, in response D to a determination that the NAI domain of the User NAI is non-local, the AAA message is dispatched to a non-local AAA entity identified by the User NAI. In still other embodiments, an apparatus for routing AAA messages between AAA entities is provided. The 5 apparatus comprises a first domain operably connected to the Internet that has at least one AAA server that is adapted to route a plurality of AAA messages having at least a Source NAI and a User NAI. The apparatus also includes a first AAA entity operably connected to the first domain that is D adapted to send and receive a plurality of AAA messages having at least a Source NAI and a User NAI. In other embodiments, a second domain operably connected to the Internet and having at least one AAJA server that is adapted to route a plurality of AAA messages having 5 at least a Source NAI and a User NAI is provided. The apparatus further includes an AAA entity operably connected to the second domain that is adapted to send and receive a plurality of AAA messages having at least a Source NAI and a User NAI. BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the present invention and the advantages thereof, reference is now made 9 WO 01/24476 PCT/IBOO/01304 to the following description taken in conjunction with the accompanying drawings, in which like reference numbers indicate like features and wherein: FIGURE 1 is a diagram illustrating a prior art 5 communications system used in connection with current AAA protocols and in connection with the present invention; FIGURE 2 is a diagram illustrating an exemplary Registration Request message according to the present invention; and 0 FIGURE 3 is a flow diagram illustrating an algorithm for routing of AAA messages according to the present invention. DETAILED DESCRIPTION 5 In the following discussion, numerous specific details are set forth to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art that the present invention can be o practiced without such specific details. In other instances, well-known elements have been illustrated in block diagram or schematic form in order not to obscure the present invention in unnecessary detail. Additionally, for the most part, details concerning routing of AAA messages 5 and the like have been omitted inasmuch as such details are not necessary to obtain a complete understanding of the present invention and are within the skills of persons of ordinary skill in the relevant art. Referring to FIGURE 1 of the drawings, the reference 0 numeral 100 generally designates a communication network embodying features of the prior art. The network 100 includes a data network (such as the Internet) 102 that is coupled to a Domain A, a Domain B, and a Domain C. Domain A includes an AAA Entity 1 of Domain A, an AAA Entity 2 of 10 WO 01/24476 PCT/IBOO/01304 Domain A, and an AAA Server of Domain A, which are operably interconnected to one another and also to the data network 102. In addition, Domain B includes an AAA Entity 1 of Domain B, an AAA Entity 2 of Domain B, and an AAA Server of 5 Domain B, each of which is operably interconnected to one another and also to the data network 102. Similarly, Domain C includes an AAA Entity 1 of Domain C, an AAA Entity 2 of Domain C, and an AAA Server of Domain C, each of which is operably interconnected to one another and also to the data 0 network 102. The AAA servers of Domain A, Domain B, and Domain C are each responsible for delivering or routing AAA messages to appropriate entities, which perform task(s) specified by the messages. It is the responsibility of the AAA servers of 5 Domain A, Domain B, and Domain C to resolve the appropriate server or entity to which to send the AAA messages. The AAA Entities 1 and 2 of Domain A, Domain B, and Domain C each serve users in their respective domains and are also used to forward messages between users and the AAA Entities' 0 respective AAA servers. The AAA Servers and AAA Entities illustrated in FIGURE 1 may comprise any conventional computer generally capable of receiving, storing, processing, and outputting data. While not shown in detail, the AAA Servers and AAA Entities 5 each include components, such as input and output devices, volatile and non-volatile memory, and the like; however, because such computer components are well known in the art, they will not be shown or described in further detail herein. 0 In FIGURE 2, an exemplary AAA Registration message 200 of the present invention is shown which facilitates the routing of AAA messages based on domains, using such AAA protocols as DIAMETER and RADIUS, and can be deployed in any type of network setup as either a Registration Request 11 WO 01/24476 PCT/IBOO/01304 message or as a Registration Response message (discussed below) . The AAA Registration message 200 comprises a plurality of Attribute Value Pairs ("AVPs") , including: (1) a Source Network Access Identifier (NAI) field 202, (2) an 5 optional Destination NAI field 204, (3) User NAI field 206, and (4) a Command Code field 208. The Source NAI field 202 is a required field used to identify the source from which a Registration message originates. The Destination NAI field 204 is an optional field used to identify the destination 0 NAI a Registration message. The Registration message 200, when used to Request Registration, generally does not require the Destination NAI, but when used to Respond to a Registration Request, generally does require a Destination NAI, since the Destination NAI of a Registration Response 5 message is most often the Source NAI of a Registration Request message. The User NAI field 206 field identifies the user and the user's home domain, and the Command Code field 208 identifies the type of message, for example, as a Registration Request, or as a Response to a Registration 0 Request. For example, in a preferred embodiment, if a mobile user who is roaming outside his home domain submits a Registration Message 200 to the AAA Server of a non-home domain to Request Registration at the non-home server, the 5 Registration Message would include the Source NAI field 202, the User NAI field 206, and the Command Code field 208. The Source NAI field 202 identifies the source of the message as being an AAA entity of the non-home domain at which the user is requesting Registration. The User NAI field 206 0 identifies the user that originated the request, including the home domain of the user, even though the user is now requesting to be registered at the non-home domain. The Command Code field 208 identifies the type of message as a Registration Request. 12 WO 01/24476 PCT/IBOO/01304 Referring now to both FIGURES 1 and 2, if an AAA Entity 1 of Domain A submits a Registration Request message 200 to the AAA Server of Domain A on behalf of a user with a User NAI of userl@domainB, in a preferred embodiment, the message 5 would include the following: a. Source NAI field 202 (aaaentityl@DomainA); b. Destination NAI field 204 (--empty--) c. User NAI field 206 (userl@Domain B); and d. Command Code field 208 (Registration Request). 0 The Destination NAI field 202 is empty, and the Source NAI field 202 identifies the source of the message 200 as being the AAA Entity 1 of Domain A, since the user is requesting Registration with the Domain A through the AAA Entity 1 of Domain A. The User NAI field 206 identifies the 5 user that originated the request, which in this example is userl, who has a home domain of Domain B, but who is now requesting to be registered at Domain A. The Command Code field 208 identifies the type of message as a Registration Request. 0 FIGURE 3 is a flow diagram, designated by the reference numeral 300, depicting control logic implemented by an AAA server for routing AAA messages 200 in accordance with a preferred embodiment of the present invention. The control logic will be exemplified first with respect to the routing 5 of a message 200, wherein a user (designated herein as "userl") having a home domain in Domain B is requesting Registration in Domain A. Accordingly, in step 302, the AAA Server of Domain A receives a message 200 from the AAA Entity 1 of Domain A. 0 Execution then proceeds to step 304, wherein the AAA Server of Domain A determines whether the message includes a Destination NAI in the field 204 of the Registration Message 200. If the AAA Server of Domain A determines that a Destination NAI is not present in the Destination NAI field 13 WO 01/24476 PCT/IBOO/01304 204, execution proceeds to step 308; otherwise, execution proceeds to step 306, discussed below with respect to a response to a request for registration. In step 308, the AAA Server of Domain A retrieves the User NAI field 206 from 5 the message. Execution then proceeds to step 318, wherein a determination is made whether the User NAI's domain is local (i.e., whether the userl has the Domain B as its home domain). If it is determined that the User NAI's domain is not local, execution proceeds to step 324; otherwise, 0 execution proceeds to step 320, discussed below. In step 324, the Internet Protocol ("IP") address of the NAI domain is resolved using the well-known Domain Name System ("DNS") . Execution then proceeds to step 326. In step 326, the message is dispatched to the proper domain (e.g., Domain B) 5 Execution then returns to step 302. In step 302, the AAA Server of Domain B receives the message sent to Domain B from the AAA Server of Domain A in step 326 above. Execution then proceeds to step 304, wherein the AAA Server of Domain B determines 0 whether a Destination NAI is present in the field 204. If it is determined that a Destination NAI is not present in the field 204, execution proceeds to step 308; otherwise, execution proceeds to step 306, discussed below with respect to a response to a request for 5 registration. In step 308, the AAA Server of Domain B retrieves the User NAI 206 from the message 200. Execution then proceeds to step 318, wherein the AAA Server of Domain B determines whether the domain of the User NAI 206 is local (i.e., whether the userl has the ) Domain B as its home domain). If it is determined that the User NAI's domain is local, execution proceeds to step 320; otherwise, execution proceeds to step 324, 14 WO 01/24476 PCT/IBOO/01304 discussed above. In step 320, the AAA Server of Domain B determines from the Command Code field 208 that the message 200 is a Request for Registration. Execution then proceeds to step 322, wherein the message 200 requesting registration 5 is sent to the appropriate entity of Domain B, which is, for example, the AAA Entity 1 of Domain B. Execution then terminates at step 330. Referring now to FIGURES 1 and 2, if the AAA Entity 1 of Domain B submits to the AAA Entity 1 of Domain A a 0 message 200 responding to a request for registration, the message 200 would, in a preferred embodiment, include the following fields: a. Source NAI field 202 (aaaentityl@DomainB) b. Destination NAI field 204 (aaaentityl@DomainA) 5 c. User NAI field 206 (userl@DomainB) d. Command Code field 208 (Registration Response) The Source NAI field 202 identifies the source of the message as the AAA Entity 1 of Domain B. The Destination NAI field 204 identifies the destination of the message as 0 the AAA Entity 1 of Domain A, since the AAA Entity 1 of Domain A sent the Registration Request message 200. The User NAI field 206 identifies the user that originated the request, which in this example is userl, who has a home domain of the Domain B. The Command Code field 208 5 identifies the type of message as a message 200 responding to a request for registration. Referring again to FIGURE 3, routing of a message 200 responding to a request for registration is illustrated. In step 302, the AAA Server of Domain B receives the D Registration message 200 requesting registration from the AAA Entity 1 of Domain B. Execution then proceeds to step 304, wherein a determination is made whether a Destination NAI is present in the field 204. If it is determined that a Destination NAI (e.g., aaaentityl@DomainA) is present in the 15 WO 01/24476 PCT/IBOO/01304 field 204, then execution proceeds to step 306; otherwise, execution proceeds to step 308, discussed above with respect to transmission of a message requesting registration. In step 306, a determination is made whether the Destination 5 NAI field 204 identifies a local domain. If it is determined that the Destination NAI field 204 does not identify a local domain, execution proceeds to step 314; otherwise, execution proceeds to step 310, discussed below. In step 314, the IP address of the Destination NAI field 204 0 is determined using the well-known DNS. Execution then proceeds to step 316, wherein the AAA Server of Domain B dispatches the message 200 responding to a request for registration to the proper AAA domain, which, in the present example, is the AAA Server of Domain A because the domain 5 portion of the Destination NAI field 204 identifies the Domain A. Execution then returns to step 302. In step 302, the AAA Server of Domain A receives the Registration Response message 200 that was dispatched in step 316 from the AAA Server of Domain B. Execution then 0 proceeds to step 304, wherein a determination is made whether a Destination NAI (e.g., aaaentityl@DomainA) is present in the field 204. If it is determined that a Destination NAI is present in the field 204, then execution proceeds to step 306; otherwise, execution proceeds to step 5 308, discussed above with respect to transmission of a message requesting registration. In step 306, the AAA Server of Domain A determines whether the Destination NAI field 204 identifies a local domain. If it is determined that the Destination NAI field 204 identifies a local domain 0 (e.g., DomainA), then execution proceeds to step 310; otherwise, execution proceeds to step 314, discussed above. In step 310, a determination is made to which AAA entity (e.g., AAA Entity 1 of Domain A) the Registration Response message 200 should be dispatched. It will be apparent to 16 WO 01/24476 PCT/IBOO/01304 those skilled in the art that, unlike prior art approaches, even if the AAA entity to which the Registration message 200 response is directed has only a private IP address, the message 200 can be routed to the proper entity, so long as 5 the AAA Server serving the entity has a publicly routable address. From step 310, execution proceeds to step 312. In step 312, the AAA Server of the Domain A dispatches the message 200 to the proper AAA entity of the local domain (e.g., AAA 0 Entity 1 of Domain A). Execution then terminates at step 328. By use of the present invention, routing of AAA messages of roaming users is achievable, messaging between a AAA entity to another AAA entity in any domain can be 5 performed, and communication between two or more non-home serving domains can be accomplished in a system using any AAA protocol. In addition, the present invention provides an apparatus and method that permits communications between two specific entities in different domains as well as 0 communications between entities in which one or more of the entities is behind a firewall or a proxy server and thus does not have a publicly-routable IP address. The present invention also allows servers to be stateless and lightweight (since message routing state information need 5 not be stored in the servers). It is understood that the present invention can take many forms and embodiments. Accordingly, several variations may be made in the foregoing without departing from the spirit or the scope of the invention. For example, various 0 algorithms in addition to the that disclosed herein could be devised using the destination NAI to route AAA messages among different domains of a network. Although the invention has been described with specific AAA protocol embodiments, these descriptions are not meant 17 WO 01/24476 PCT/IBOO/01304 to be construed in a limiting sense. Various modifications of the disclosed embodiments, as well as alternative embodiments of the invention, will become apparent to persons skilled in the art upon reference to the description 5 of the invention. It is, therefore, contemplated that the claims will cover any such modifications or embodiments that fall within the true scope and spirit of the invention. 18

Claims (27)

1. A method for facilitating authentica:ion, authorization, and accounting (AAA) message routing by an AAA server comprising the steps of: receiving an AAA message having at least a user network address identifier (NAI); determining whether the AAA message includes a destination NAI; in response to a determination that the AAA message includes a destination NAI, determining whether an NAI domain of the destination NAI is local; in response to a determination that the destination NAI is local, determining from the destination NAI a local AAA entity to which the AAA message should be dispatched and dispatching the AAA message to the determined local AAA entity; and in response to a determination that the destination NAI is not local, resolving an internet protocol (IP) address of the destination NAI and dispatching the AAA message to an AAA server in a non-local domain identified by the destination NAI.
2. The method of claim 1 wherein the AAA server is stateless.
3. The method of claim 1 further comprising the step of retrieving the user NAI in response to a determination :hat the AAA message does not include a destination NAI. 19 WO 01/24476 PCT/IBOO/01304
4. The method of claim 3 further comprising the step of determining whether a NAI domain of the user NAI of the AAA message is local.
5. The method of claim 4 further comprising the step of determining a local AAA entity to which the AAA message should be dispatched from a message type of the AAA message in response to a determination that the NAI domain of the user NAI of the AAA message is local.
6. The method of claim 4 further comprising the step of resolving an IP address of the user NAI in response to a determination that the NAI domain of the user NAI of the AAA message is not local.
7. The method of claim 5 further comprising the step of dispatching the AAA message to a proper local AAA entity.
8. The method of claim 6 further comprising the step of dispatching the AAA message to a proper non-local domain.
9. The method of claim 8 wherein at least one of the AAA entities does not have a publicly routable IP address.
10. A method of facilitating routing of an AAA registration request message comprising the steps of: receiving an AAA registration request message having at least a user NAI; determining whether a NAI domain of the user NAI is local; in response to a determination that the NAI domain is 20 WO 01/24476 PCT/IBOO/01304 local, dispatching the message to a local entity identified by the user NAI; and in response to a determination that the NAI domain is non-local, dispatching the message to a non-local domain identified by the user NAI.
11. A method of facilitating routing of an AAA registration response message comprising the steps of: receiving an AAA registration response message having at least a destination NAI; determining whether the NAI domain of the destination NAI is local; in response to a determination that the NAI domain of the destination NAI is local, dispatching the message to a local AAA entity identified by the destination NAI; and in response to a determination that the NAI domain of the destination NAI is not local, dispatching the message to an AAA domain identified by the destination NAI.
12. The method of claim 10 wherein the local AAA entity has a private IP address.
13. The method of claim 11 wherein the local AAA entity has a private IP address.
14. An apparatus for routing of Authentication, Authorization, and Accounting (AAA) messages between AAA entities comprising: a first domain operably connected to a data network, the first domain having at least one first AAA server, the first AAA server being adapted to route a plurality of AAA messages having a source NAI and a user NAI; and 21 WO 01/24476 PCT/IBOO/01304 a first AAA entity operably connected to the first domain, the first AAA entity being adapted to send and receive a plurality of AAA messages, each message having at least a source NAI and a user NAI. 5
15. The apparatus of claim 14 further comprising: a second domain operably connected to a data network, the second domain having at least one second AAA server, the second AAA server being adapted to route a plurality of AAA messages having a source NAI and a user NAI; a second AAA entity operably connected to the second domain, the second AAA entity being adapted to send and receive a plurality of AAA messages, each message having at least a source NAI and a user NAI.
16. The apparatus of claim 14 further comprising a 5 computer program product having a medium with a computer program embodied thereon, the computer program comprising computer program code executable, in response to receipt of an AAA message, for routing the AAA message, the computer program further comprising: D computer program code for determining whether a destination network access identifier (NAI) is present in the AAA message; computer code for determining, in response to a determination that a destination NAI is present in the AAA 5 message, whether an NAI domain of the destination NAI is local; computer code for determining, in response to a determination that the NAI domain of the destination NAI is local, a local AAA entity to which the message should be 22 WO 01/24476 PCT/IBOO/01304 dispatched; and computer code for dispatching the AAA message to the local AAA entity in response to the determination of the local AAA entity to which the message should be dispatched.
17. The apparatus of claim 14 further comprising a computer program product having a medium with a computer program embodied thereon, the computer program comprising computer program code executable, in response to receipt of an AAA message, for routing the AAA message, the computer program further comprising: computer program code for determining whether a destination network access identifier (NAI) is present in the AAA message; computer code for determining, in response to a determination that a destination NAI is present in the AAA message, whether an NAI domain of the destination NAI is local; computer code for determining, in response to a determination that the NAI domain of the destination NAI is local, a local AAA entity to which the message should be dispatched; computer code for dispatching the AAA message to the local AAA entity in response to determination of the local AAA entity to which the message should be dispatched; computer code for resolving an internet protocol (IP) address of the NAI domain of the destination NAI in response to a determination that the destination NAI is not local; and computer code for dispatching the AAA message to the NAI domain of the destination NAI in response to resolution of the IP address of the NAI domain. 23 WO 01/24476 PCT/IBOO/01304
18. The acoaratus of claim 14 further comprising a computer program product having a medium with a computer program embodied thereon, the computer program comprising computer program code executable, in response to receipt of an AAA message, for routing the AAA message, the computer program further comprising: computer program code for determining whether a destination network access identifier (NAI) is present in the AAA message; computer code for determining, in response to a determination that a destination NAI is present in the AAA message, whether an NAI domain of the destination NAI is local; computer code for determining, in response to a determination that the NAI domain of the destination NAI is local, a local AAA entity to which the message should be dispatched; computer code for dispatching the AAA message to the local AAA entity in response to identification of the local AAA entity to which the message should be dispatched; computer code for resolving an internet protocol (IP) address of the NAI domain of the destination NAI in response to a determination that the destination NAI is not local; computer code for dispatching the AAA message to the NAI domain of the destination NAI in response to resolution of the IP address of the NAI domain of the destination NAI; computer code for retrieving a user NAI from the AAA message in response to a determination that a destination NAI is not present in the AAA message; computer code for determining, in response to retrieval of the user NAI from the AAA message, whether the NAI domain 24 WO 01/24476 PCT/IBOO/01304 of the user NAI is local; computer code for determining, in response to a determination that the NAI domain of the user NAI of the AAA message is local, a local AAA entity to which the AAA message should be dispatched; and computer code for dispatching the AAA message to the local AAA entity in response to the determination of the local AAA entity to which the AAA message should be dispatched. The apparatus of claim 14 further comprising a computer program product having a medium with a computer program embodied thereon, the computer program comprising computer program code executable, in response to receipt of an AAA message, for routing the AAA message, the computer program further comprising: computer program code for determining whether a destination network access identifier (NAI) is present in the AAA message; computer code for determining, in response to a determination that a destination NAI is present in the AAA message, whether an NAI domain of the destination NAI is local; computer code for determining, in response to a determination that the NAI domain of the destination NAI is local, a local AAA entity to which the message should be dispatched; computer code for dispatching the AAA message to the local AAA entity in response to identification of the local AAA entity to which the message should be dispatched; computer code for resolving an internet protocol (IP) address of the NAI domain of the destination NAI in response to a determination that the destination NAI is not local; 25 WO 01/24476 PCT/IBOO/01304 computer code for dispatching the AAA message to the NAI domain of the destination NAI in response to resolution of the IP address of the NAI domain of the destination NAI; computer code for retrieving a user NAI from the AAA 5 message in response to a determination that a destination NAI is not present in the AAA message; computer code for determining, in response to retrieval of the user NAI from the AAA message, whether the NAI domain of the user NAI is local; computer code for determining, in response to a determination that the NAI domain of the user NAI of the AAA message is local, a local AAA entity to which the AAA message should be dispatched; computer code for dispatching the AAA message to the 5 local AAA entity in response to the determination of the local AAA entity to which the AAA message should be dispatched; computer code for resolving an IP address of the NAI domain of the user NAI in response to a determination that the NAI domain of the user NAI is not local; and computer code for dispatching the AAA message to the NAI domain of the user NAI in response to resolution of the IP address of the NAI domain of the user NAI.
19. The apparatus of claim 14 wherein the first domain is a non-home serving domain.
20. The apparatus of claim 14 wherein a portion of the AAA messages are registration request messages. The apparatus of claim 14 wherein a portion of the AAA messages are registration response messages that include a destination NAI. The apparatus of claim 14 wherein at least one of the AAA 26 WO 01/24476 PCT/IBOO/01304 entities has a private IP address. The apparatus of claim 15 wherein at least one of the AAA servers is stateless. The apparatus of claim 15 wherein the second domain is a non-home serving domain.
21. The apparatus of claim 15 wherein a portion of the AAA messages are registration request messages.
22. The apparatus of claim 15 wherein a portion of the AAA messages are response messages that include a destination NAI. The apparatus of claim 15 wherein at least one of the AAA entities has a private IP address.
23. The apparatus of claim 15 further comprising a computer program product having a medium with a computer program embodied thereon, the computer program comprising computer program code executable, in response to receipt of an AAA message, for routing the AAA message, the computer program further comprising: computer program code for determining whether a destination network access identifier (NAI) is present in the AAA message; computer code for determining, in response to a determination that a destination NAI is present in the AAA message, whether an NAI domain of the destination NAI is local; computer code for determining, in response to a determination that the NAI domain of the destination NAI is local, a local AAA entity to which the message should be dispatched; and computer code for dispatching the AAA message to the local AAA entity in response to the determination of the local 27 WO 01/24476 PCT/IBOO/01304 AAA entity to which the message should be dispatched.
24. The apparatus of claim 15 further comprising a computer program product having a medium with a computer program embodied thereon, the computer program comprising computer program code executable, in response to receipt of an AAA message, for routing the AAA message, the computer program further comprising: computer program code for determining whether a destination network access identifier (NAI) is present in the AAA message; computer code for determining, in response to a determination that a destination NAI is present in the AAA message, whether an NAI domain of the destination NAI is local; computer code for determining, in response to a determination that the NAI domain of the destination NAI is local, a local AAA entity to which the message should be dispatched; computer code for dispatching the AAA message to the local AAA entity in response to determination of the local AAA entity to which the message should be dispatched; computer code for resolving an internet protocol (IP) address of the NAI domain of the destination NAI in response to a determination that the destination NAI is not local; and computer code for dispatching the AAA message to the NAI domain of the destination NAI in response to resolution of the IP address of the NAI domain.
25. The apparatus of claim 15 further comprising a computer program product having a medium with a computer 28 WO 01/24476 PCT/IBOO/01304 program embodied thereon, the computer program comprising computer program code executable, in response to receipt of an AAA message, for routing the AAA message, the computer program further comprising: computer program code for determining whether a destination network access identifier (NAI) is present in the AAA message; computer code for determining, in response to a determination that a destination NAI is present in the AAA message, whether an NAI domain of the destination NAI is local; computer code for determining, in response to a determination that the NAI domain of the destination NAI is local, a local AAA entity to which the message should be dispatched; computer code for dispatching the AAA message to the local AAA entity in response to identification of the local AAA entity to which the message should be dispatched; computer code for resolving an internet protocol (IP) address of the NAI domain of the destination NAI in response to a determination that the destination NAI is not local; computer code for dispatching the AAA message to the NAI domain of the destination NAI in response to resolution of the IP address of the NAI domain of the destination NAI; computer code for retrieving a user NAI from the AAA message in response to a determination that a destination NAI is not present in the AAA message; computer code for determining, in response to retrieval of the user NAI from the AAA message, whether the NAI domain of the user NAI is local; computer code for determining, in response to a 29 WO 01/24476 PCT/IBOO/01304 determination that the NAI domain of the user NAI of the AAA message is local, a local AAA entity to which the AAA message should be dispatched; and computer code for dispatching the AAA message to the local AAA entity in response to the determination of the local AAA entity to which the AAA message should be dispatched. The apparatus of claim 15 further comprising a computer program product having a medium with a computer program embodied thereon, the computer program comprising computer program code executable, in response to receipt of an AAA message, for routing the AAA message, the computer program further comprising: computer program code for determining whether a destination network access identifier (NAI) is present in the AAA message; computer code for determining, in response to a determination that a destination NAI is present in the AAA message, whether an NAI domain of the destination NAI is local; computer code for determining, in response to a determination that the NAI domain of the destination NAI is local, a local AAA entity to which the message should be dispatched; computer code for dispatching the AAA message to the local AAA entity in response to identification of the local AAA entity to which the message should be dispatched; computer code for resolving an internet protocol (IP) address of the NAI domain of the destination NAI in response to a determination that the destination NAI is not local; computer code for dispatching the AAA message to the NAI domain of the destination NAI in response to resolution of the 30 WO 01/24476 PCT/IBOO/01304 IP address of the NAI domain of the destination NAI; computer code for retrieving a user NAI from the AAA message in response to a determination that a destination NAI is not present in the AAA message; computer code for determining, in response to retrieval of the user NAI from the AAA message, whether the NAI domain of the user NAI is local; computer code for determining, in response to a determination that the NAI domain of the user NAI of the AAA message is local, a local AAA entity to which the AAA message should be dispatched; computer code for dispatching the AAA message to the local AAA entity in response to the determination of the local AAA entity to which the AAA message should be dispatched; computer code for resolving an IP address of the NAI domain of the user NAI in response to a determination that the NAI domain of the user NAI is not local; and computer code for dispatching the AAA message to the NAI domain of the user NAI in response to resolution of the IP address of the NAI domain of the user NAI. An AAA message comprising a source network access identifier that indicates a source AAA entity from which the AAA message has been sent. The AAA message of claim 33 further comprising a destination network access identifier that indicates a destination to which the message is to be sent.
26. The AAA message of claim 34 further comprising a user network access identifier that indicates a user's name and the user's home domain.
27. The AAA message of claim 35 further comprising a 31 WO 01/24476 PCT/IBOO/01304 command code that indicates what type of action should be taken in response to the message. 32
AU68611/00A 1999-09-29 2000-09-12 Apparatus and method for routing aaa messages between domains of a network Abandoned AU6861100A (en)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US15666999P 1999-09-29 1999-09-29
US60156669 1999-09-29
US55181100A 2000-04-18 2000-04-18
US09551811 2000-04-18
PCT/IB2000/001304 WO2001024476A1 (en) 1999-09-29 2000-09-12 Apparatus and method for routing aaa messages between domains of a network

Publications (1)

Publication Number Publication Date
AU6861100A true AU6861100A (en) 2001-04-30

Family

ID=26853405

Family Applications (1)

Application Number Title Priority Date Filing Date
AU68611/00A Abandoned AU6861100A (en) 1999-09-29 2000-09-12 Apparatus and method for routing aaa messages between domains of a network

Country Status (3)

Country Link
EP (1) EP1219089A1 (en)
AU (1) AU6861100A (en)
WO (1) WO2001024476A1 (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60233255D1 (en) * 2001-12-03 2009-09-17 Nokia Corp GUIDELINES-BASED MECHANISMS FOR SELECTION OF ACCESS ROUTERS AND MOBILE CONTEXT
CN100463479C (en) * 2001-12-25 2009-02-18 中兴通讯股份有限公司 Wide-band network authentication, authorization and accounting method
US6954793B2 (en) * 2002-05-13 2005-10-11 Thomson Licensing S.A. Pre-paid data card authentication in a public wireless LAN access system
ES2289114T3 (en) 2002-06-20 2008-02-01 Nokia Corporation METHOD, SYSTEM AND DEVICES TO TRANSFER ACCOUNTING INFORMATION.
US7565688B2 (en) 2002-12-23 2009-07-21 Hewlett-Packard Development Company, L.P. Network demonstration techniques
CN1874217B (en) * 2005-09-27 2010-12-08 华为技术有限公司 Method for determining route
US8831016B2 (en) * 2011-03-18 2014-09-09 Tekelec, Inc. Methods, systems, and computer readable media for configurable diameter address resolution

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6675208B1 (en) * 1997-10-14 2004-01-06 Lucent Technologies Inc. Registration scheme for network
US6119171A (en) * 1998-01-29 2000-09-12 Ip Dynamics, Inc. Domain name routing

Also Published As

Publication number Publication date
EP1219089A1 (en) 2002-07-03
WO2001024476A1 (en) 2001-04-05

Similar Documents

Publication Publication Date Title
Perkins Mobile ip
JP3557056B2 (en) Packet inspection device, mobile computer device, and packet transfer method
US8429400B2 (en) VPN processing via service insertion architecture
US7707310B2 (en) Mobile IP registration supporting port identification
KR101086349B1 (en) Method And System For Controlling Operation Of A Communication Network, Related Network And Computer Program Product Therefor
JP4226553B2 (en) Routing in data communication networks
US7489667B2 (en) Dynamic re-routing of mobile node support in home servers
CA2321396C (en) Mobile communications service system, mobile communications service method, authentication apparatus, and home agent apparatus
JP3964257B2 (en) System and method for allowing a simple IP mobile node to operate seamlessly by performing true roaming in a mobile IP network
US7152238B1 (en) Enabling mobility for point to point protocol (PPP) users using a node that does not support mobility
US20060059264A1 (en) Enabling push technologies for mobile IP
US20030208602A1 (en) System and method for pushing data in an internet protocol network environment
US20070171886A1 (en) System and method for managing foreign agent selections in a mobile internet protocol network
US20070214352A1 (en) Role aware network security enforcement
CN101305543B (en) Method and device for allowing network access for proxy mobile IP cases for nodes that do not support CHAP authentication
JP2001527331A (en) Ways to support mobility on the Internet
JP2006505154A (en) Method and apparatus for mobile IP dynamic home agent assignment
JPH09149036A (en) Address settlement method
US8755354B2 (en) Methods and apparatus for broadcast optimization in mobile IP
TWI270278B (en) System and method of providing computer networking
US20040156374A1 (en) Router and routing method for providing linkage with mobile nodes
AU6861100A (en) Apparatus and method for routing aaa messages between domains of a network
US7215668B2 (en) Method and apparatus for processing information, storage medium, and software program
US7237025B1 (en) System, device, and method for communicating user identification information over a communications network
Cisco Configuring Mobile IP