WO2003081875A1 - Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung - Google Patents

Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung Download PDF

Info

Publication number
WO2003081875A1
WO2003081875A1 PCT/DE2003/000895 DE0300895W WO03081875A1 WO 2003081875 A1 WO2003081875 A1 WO 2003081875A1 DE 0300895 W DE0300895 W DE 0300895W WO 03081875 A1 WO03081875 A1 WO 03081875A1
Authority
WO
WIPO (PCT)
Prior art keywords
rad3
rad2
aaa server
radi
aaa
Prior art date
Application number
PCT/DE2003/000895
Other languages
English (en)
French (fr)
Inventor
Wolfgang Keil
Original Assignee
Siemens Aktiengesellschaft
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 Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to DE50301105T priority Critical patent/DE50301105D1/de
Priority to US10/509,286 priority patent/US20050235000A1/en
Priority to EP03744761A priority patent/EP1488611B1/de
Priority to CN038071665A priority patent/CN1643879B/zh
Publication of WO2003081875A1 publication Critical patent/WO2003081875A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5061—Pools of addresses

Definitions

  • AAA server system for efficient access control and address assignment
  • the invention relates to an AAA (Authentication Authorization Accounting) server system and a method for managing a pool of logical addresses.
  • AAA Authentication Authorization Accounting
  • the logical addressing of participants or hosts and the management of the available address space for network connections and on the Internet is an important area of responsibility for network technology.
  • the hardware required for the management of logical addresses and for the provision of the corresponding functionality when assigning addresses is often in
  • AAA Authentication Authorization Accounting
  • Transfer rate can be exchanged between the individual servers.
  • AAA servers control access to the Internet, which use the RADIUS (Remote Authentication Dial-In User Service) protocol and are therefore called RADIUS servers.
  • RADIUS Remote Authentication Dial-In User Service
  • the transition from the telephone network to the Internet or IP network takes place on an access server that is referred to as the Network Access Server (NAS) for the Internet.
  • NAS Network Access Server
  • messages are exchanged between the NAS and the RADIUS server using the RADIUS protocol in order to have the participant's identity and access rights checked in the RADIUS server. If the response of the RADIUS server is positive, ie the Subscriber is authorized, the NAS establishes a connection between the IP network and the subscriber or his Internet terminal.
  • the subscriber's Internet terminal requires a unique, routable IP address. Since the supply of available IP addresses is limited, most Internet service providers - hereinafter referred to as Internet Service Providers (ISP) - only assign IP addresses to their customers, ie the subscriber, for the duration of an Internet connection. For different internet sessions, the subscriber or his internet terminal is usually assigned different internet addresses.
  • the Internet service provider usually has an IP address range - hereinafter referred to as an address pool - from which the addresses for the temporary assignment to subscribers are taken.
  • An Internet service provider can also have several address pools, for example in order to be able to form several service groups for different services.
  • the dynamic assignment of IP addresses usually takes place either in the access server or NAS or in the AAA server or RADIUS server.
  • the assignment of IP addresses in the access servers or NAS has the disadvantage of considerable administration and maintenance work for Internet service providers who operate a large number of access servers. Address pools must be set up in each individual access server. With large Internet service providers, the number of access servers to be served is considerable, and consequently the effort involved in setting up and changing address pools is considerable. In addition, there is no central control of the current Internet connections and the IP addresses used. For example, for operators of access networks who sublet access to smaller Internet service providers, central administration and allocation of the available address pools is of great importance.
  • high-performance * means the ability to process a large number of access controls per second.
  • a common implementation for a high-performance central control is by means of a multi-server system.
  • This usually consists of a number of individual computers or servers that are connected to each other by means of the IP network.
  • This solution is inexpensive because expensive fail-safe hardware or cluster software is not required.
  • the system is easily scalable upwards by adding additional computers. For reasons of redundancy for security against failure, the individual computers should be able to take over the tasks of other computers in the multiserver system.
  • The, load distribution to the various individual computer of the multi-server system for example, by the RADIUS client to access servers.
  • DHCP Dynamic Host Configuration ration protocol
  • a server that uses manufacturer-specific protocols can be supplied with IP addresses.
  • This solution has the following disadvantages: • The protection of the central server against failures, for example due to duplication, is usually associated with considerable effort. • Exchanged messages should be acknowledged for reliable communication between the central server and the other computers in the multiserver system. As a result, the amount of information to be processed increases rapidly with the number of computers. The scalability, ie the integration of additional computers in the multi-server system, is thereby impaired. • An increased number of connection requests leads to an increase in data traffic between the central server and the individual computers. This can lead to load peaks (bursts) which can cause delays in processing. • The central server often leads to additional maintenance.
  • the entire information about address pools can be stored on all individual computers of the multiserver system and messages for coordinating the address reservations can be exchanged between the individual computers. This procedure leads to a considerable volume of messages to be exchanged if duplicate addresses should be avoided.
  • the object of the invention is to specify the efficient administration of one or more address areas in an AAA server system which avoids the disadvantages of conventional methods.
  • the object is achieved by an AAA server system according to claim 1 and a method according to claim 10.
  • the AAA server system comprises a plurality of AAA servers for managing at least one pool of logical addresses.
  • Several disjoint subsets or subpools of at least one address pool are each assigned to exactly one AAA server.
  • the logical addresses of the subsets of the address pool can only be assigned to a terminal or subscriber by the associated AAA server and are managed by the associated AAA server (claim 1).
  • Several subsets of an address pool can also be assigned to one AAA server.
  • the address pools can be, for example, IP address ranges (claim 2). Addresses can be assigned to end devices by the AAA servers of the AAA server system, for example using the RADIUS (Remote Authentication Dial-In User Service) protocol or the DIAMETER protocol (claim 3).
  • RADIUS Remote Authentication Dial-In User Service
  • DIAMETER DIAMETER
  • the AAA servers of the AAA server system can communicate with one another, for example, using the Internet protocol or TCP / IP (Transmission Control Protocol / Internet Protocol) (claims 4 and 8).
  • TCP / IP Transmission Control Protocol / Internet Protocol
  • the subdivision of the available address space into subsets and the assignment of these subsets to AAA servers enables the effort involved in communication between the individual servers or computers to be reduced.
  • an update message is regularly sent from a first AAA server of the server system to all other servers of the AAA server system.
  • This update message includes
  • Information about status changes in the subsets of the address pool or the address pools assigned to the first AAA server since the existing update By regularly sending update messages from the AAA servers to all other AAA servers of the AAA server system, for example at fixed time intervals, the assignment of logical addresses can be coordinated by the individual AAA servers of the AAA server system. The subsets of the address pool or the address pools that are in use can thus be signaled to all AAA servers. In addition, information regarding the resources required at the logical addresses during the next time interval can be exchanged between the servers AAA. Before sending the update message, an AAA server estimates the number of logical addresses to be assigned in the period between the update message to be sent and the subsequent update message.
  • the estimate obtained in this way provides an upper limit for the number of required Addresses. From the subsets of the address pool assigned to the server, which are determined for the extraction of the logical addresses required according to the estimate in the period.
  • the update message can then contain information about which subsets of the address pools assigned to the AAA server were determined for the removal of the logical addresses required according to the assessment in the period (claim 11). In this way, subsets of logical addresses can be marked as "unsafe", ie logical addresses can be assigned from these subsets within the next time interval.
  • This flag plays a role when individual AAA servers need additional subsets of the address pool to satisfy the connection requests.
  • the responsibility or assignment of subsets of the address pool that are not marked as "unsafe” can be changed and assigned to the AAA server with a lack of logical addresses (claim 13).
  • the individual AAA servers communicate a mixture of redundant data and blocking information (marked subsets of the address pool, the assignment of which is not subject to disposition). This limits the volume of data that is exchanged between the servers.
  • the individual AAA servers do not know which individual addresses are assigned by other AAA servers. Instead, the subsets from which addresses are assigned are communicated.
  • the status of (possibly indexed) subsets is recorded instead of the individual addresses - and the data rate for the exchange of information between the individual servers is reduced.
  • the subsets of the address pool assigned to this AAA server can be assigned to another AAA server, for example in accordance with a priority list (claims 14 and 15). Possibly. the subsets of the failed server are also distributed between several other AAA servers. It then makes sense not to use subsets of logical addresses which were marked as "unsafe" in the last received update message from the failed server for a period of time for the reassignment of logical addresses (claim 16)
  • the maximum permitted connection duration corresponds to claim 17.
  • Update messages can also be used when rebooting AAA servers of the AAA server system, for example a newly rebooted AAA server transmits a multicast message to the other AAA servers with which it sends the update messages and the Assignment of subsets of the address pool requests (claim 18).
  • the TCP / IP protocol, the RADIUS protocol or DIAMETER protocol can be used as the transport protocol for the transmission of update messages.
  • the reduced volume of messages exchanged makes it possible for the individual servers of the Server system at different locations ie decentralized (claim 9).
  • Fig. 1 A scenario for the dynamic assignment of addresses for Internet sessions.
  • Fig. 2 The division of an address area or address pool into subsets or subpools.
  • Fig. 3 The assignment of subsets of logical addresses to RADIUS servers.
  • Fig. 4 The exchange of update messages between three RADIUS servers.
  • Fig. 5 The different steps in requesting an additional subset of logical addresses.
  • IP address ranges are controlled by a RADIUS server system, i.e. a multi-server system that works using the RADIUS protocol can be managed.
  • the RADIUS server system consists of several RADIUS servers that are connected by a network. Special software, e.g. Clustersoft- would not be needed.
  • an address pool corresponds to an IP address range and subsets of the address pool correspond to sub-ranges of IP addresses.
  • a global address range or address pool can be assigned to an Internet service provider or reserved for a certain class of service.
  • IP Internet Protocol
  • PPP Point-to-Point Protocol
  • the RADIUS server system RADSS has a pool IP pool of its own IP addresses @ IP1, ..., @Ipn, which are dynamically assigned to the Internet terminals Hostl, ..., Hosts for the duration of the connection.
  • the access server NAS After receiving the authorization message from the RADIUS server system and assigning an IP address for the duration of the connection, the access server NAS establishes an Internet connection for the requesting Internet terminal Host1, ..., Host5.
  • an address pool A is shown, which consists of the address range IP 1 to IP N.
  • This address pool A is divided into three subsets AI, .., A3, which correspond to the partial address ranges IP 1 to IP I, IP J to IP K, and IP L to IP N.
  • Each of the RADIUS servers has the entire address pool A, ie the entire address range is stored on all servers.
  • Each of the RADIUS servers can release IP addresses of any subsets AI, ..., A3 of IP addresses.
  • there is an exclusive right to assign IP addresses for connections ie each RADIUS server has assigned one or more subsets AI, .., A3 of addresses from which it can assign IP addresses. These rights to assign IP addresses can be moved dynamically between the RADIUS servers.
  • FIG. 3 shows three RADIUS servers RADI, .., RAD3. Each is assigned a sub-range of addresses AI, ..., A3 (indicated by solid arrows) from which it can assign addresses. All three RADIUS servers can release used addresses, which is indicated by broken arrows.
  • FIG. 4 shows how the individual RADIUS servers are updated with information about the status of the other RADIUS servers. At regular intervals, each RADIUS server RADI, ..., RAD3 sends an update message to all other RADIUS servers RADI, ..., RAD3 to inform about changes in the assigned subsets of addresses. This update message is sent with the help of an IP multicast mechanism and only affects subsets that have changed since the last update message. Update messages are not acknowledged.
  • RADIUS server RADI sends update messages UpdtRAD1 (for: update from RADI) to the RADIUS servers RAD2 and RAD3 at the times Sl.l and S1.2.
  • the RADIUS server RAD2 or RADIUS server RAD3 sends update messages UpdtRAD2 or UpdtRAD3 to the two other RADIUS servers RADI and RAD 3 or RADI and RAD2 ,
  • the following information relating to the entire or global address pool A is stored on each of the RADIUS servers RADI, ..., RAD3: An identifier for the global address pool A in the event that several global address pools, for example for different service classes, are used.
  • This list contains the IP address of each RADIUS server RADI, ..., RAD3, an identifier for each RADIUS server RADI, .., RAD3, the time of the last update for each RADIUS server RADI, .., RAD3 and the total number of the current free, ie not assigned IP addresses.
  • a flag can also be defined that indicates a lack of free IP addresses. This flag is set, for example, when the total number of free IP addresses becomes less than a threshold, for example the time between updates multiplied by the maximum rate for requests for IP addresses. The setting of the flag is reversed when the number of free addresses again exceeds the threshold.
  • a threshold for example the time between updates multiplied by the maximum rate for requests for IP addresses. The setting of the flag is reversed when the number of free addresses again exceeds the threshold.
  • the identifier of the RADIUS server that is responsible for the subset of addresses i.e. the AAA server that can assign IP addresses from this subset.
  • the information held on the AAA RADIUS servers and related to the subsets of addresses is updated at regular intervals.
  • the update is triggered by the expiration of a timer that measures the time interval between two update messages.
  • the RADIUS server which sends update messages with regard to the status of its subsets of addresses, determines the free, ie not assigned addresses, the assigned subsets of addresses and identifies the subsets which can be used within the next time interval.
  • the update message then comprises the identifier of the radio server from which the message is sent, the total number of free IP addresses of this RADIUS server, the identifiers or identifiers of the subsets of addresses which are suitable for use within the next time interval, ie which are marked as "unsafe *", change in the use of subsets since the last update message and possibly further status information.
  • the timer is restarted.
  • a RADIUS server that receives an update message sets a watchdog timer that measures how much time has passed since the last update message.
  • the RADIUS server uses the received update message to update the status information about the sending radio server.
  • FIG. 5 shows the exchange of messages for and during the connection of a subscriber or terminal.
  • An authentication request rAUTH is sent from a NAS (Network Access Server) to a RADIUS server RADI using the RADIUS radius protocol for the connection of an Internet terminal.
  • This authentication request rAUTH contains the identifier of the NAS, the identifier of the port and the identifier of the subscriber or terminal.
  • the RADIUS server RADI makes an rLDAP request to an LDAP (Lightweight Directory Access Protocol) database LDAP, in the course of which the identifier or identity of the subscriber is determined.
  • LDAP Lightweight Directory Access Protocol
  • the identifier of the subset of addresses from which the IP address can be found is provided by the LDAP database LDAP.
  • An IP address is then determined from this subset of IP addresses. Then the
  • RADIUS server the specific IP address to the NAS in aAUTH response to the authentication request.
  • the fact of this new connection is communicated to the other radio servers RAD2 in the course of an update message UpdtRADl e.g. in the form of an updated total number of IP addresses used and possibly by re-marking the corresponding subset of addresses as "unsafe".
  • the radio server RADI receives update messages UpdtRAD2 from other radio servers RAD2 during the connection. If the connection is to be interrupted, the NAS sends one
  • Such a request or request is triggered when the total number of free IP addresses of the RADIUS server falls below a threshold which is given, for example, by the product of the time interval between update messages and the maximum editable rate of connection requests.
  • the RADIUS server sets a flag that indicates the lack of IP addresses.
  • the RADIUS server uses the status information of the other RADIUS servers to check which server has the largest number of free IP addresses or the largest number of unmarked or unused subsets of addresses. If a RADIUS server can be identified that has considerably more free addresses than the threshold for lack of IP addresses, the RADIUS server with address deficiency sends a request for assignment of a further subset of addresses. A monitoring timer is set when this message is sent.
  • the RADIUS server sends a corresponding request to other RADIUS servers in accordance with the addresses available there if the address is insufficient. If no RADIUS server can be infected with free IP addresses or if no responses are received from the RADIUS servers, the RADIUS server with an insufficient address waits at least one update time interval before repeating its requests. If all free IP addresses are assigned during this period, additional authentication requests from NAS will be rejected. If, on the other hand, a positive response to the request for a new subset of addresses is received, this positive response is acknowledged with an acknowledgment message to all other RADIUS servers using multicast and all relevant data is updated internally.
  • This mechanism can also be used after a reboot of one of the RADIUS servers to automatically reconfigure the RADIUS server. If one of the RADIUS servers fails, a list of the identifiers of the RADIUS servers specifies a hierarchy of responsibility. After the failed RADIUS server no longer receives any update messages, the RADIUS server at the top of the hierarchy or the subsequent RADIUS server takes over the control or management of the corresponding IP address ranges. The following steps take place in the RADIUS server, which takes over the administration of the subsets of addresses: The transfer of addresses is triggered by the expiry of the monitoring timer. A request for an update message is then sent to the failed RADIUS server.
  • a multicast message is used to inform all other RADIUS servers that the RADIUS server that is sending the multicast message is responsible for managing and assigning the subsets of addresses of the failed RADIUS server.
  • the subsets of addresses of the receiving RADIUS server are expanded to include the subsets of addresses. In this case, subsets marked as "unsafe *" are blocked and a timer for blocking is started. This timer measures the maximum time for the assignment of an IP address for a connection. After the timer has expired, the blocking of the subsets of addresses is canceled. Now all resources at IP addresses are available again and the failure of the RADIUS server is fully compensated.

Abstract

Die Erfindung betrifft ein AAA (Authentication, Authorization, Accounting) Serversystem (RADSS) zur Verwaltung eines Pools (A) von logischen Adressen (IP1, ..., IPN) und ein Verfahren zur Aktualisierung von Statusinformationen innerhalb des AAA Serversystems (RADSS). Das erfindungsgemäße AAA Serversystem (RADSS) umfasst eine Mehrzahl von AAA Servern (RAD1, RAD2, RAD3). Jedem der AAA Server (RAD1, RAD2, RAD3) sind eine oder mehrere disjunkte Teilmengen (A1, A2, A3) des Adresspools (A) zugeordnet. Ausgetauschte Statusinformationen bezüglich Adressvergabe betreffen die disjunkten Teilmengen (A1, A2, A3) von Adressen. Die Erfindung hat den Vorteil eines aufwandsarmen und effizienten Nachrichtenaustausches zwischen den AAA Servern (RAD1, RAD2, RAD3). Eine effiziente Allokation der Ressourcen an logischen Adressen wird durch bedarfsabhängige Änderungen der Zuweisung von Teilmengen (A1, A2, A3) von logischen Adressen (IP1, ..., IPN) an AAA Server (RAD1, RAD2, RAD3) gewährleistet.

Description

Beschreibung
AAA Serversystem zur effizienten Zugangskontrolle und Adresszuordnung
Die Erfindung betrifft ein AAA (Authentification Authorizati- on Accounting) Serversystem und ein Verfahren zur Verwaltung eines Pools von logischen Adressen.
Die logische Adressierung von Teilnehmern bzw. Hosts und die Verwaltung des zur Verfügung stehenden Adressraums bei Netzverbunden und im Internet ist ein wichtiges Aufgabenfeld der Netzwerktechnik. Die notwendige Hardware für die Verwaltung von logischen Adressen und zur Bereitstellung der entspre- chenden Funktionalität bei der Adressvergabe ist häufig in
Form von AAA (Authentification Authorization Accounting) Servern bzw. AAA Serversystemen gegeben. Für die Adressverwaltung durch Multiserversysteme müssen Informationen über die Adressvergäbe, über zur Verfügung stehende Ressourcen sowie Statusinformationen auf zuverlässige Weise mit einer hohen
Übertragungsrate zwischen den einzelnen Servern ausgetauscht werden.
Bei der Einwahl von Teilnehmern in das Internet, z.B. mittels herkömmlicher sch albandiger Telefonverbindungen oder xDSL-
Technologie (DSL: Digital Subscriber Line), kontrollieren üblicherweise AAA Server den Zugang zum Internet, die das RADIUS (Remote Authentification Dial-In User Service) Protokoll verwenden und deshalb RADIUS Server genannt werden. Hierbei findet der Übergang vom Telefonnetz zum Internet bzw. IP-Netz an einem Zugangsserver statt, der für das Internet als Network Access Server (NAS) bezeichnet wird. Bevor für einen Teilnehmer eine Verbindung aufgebaut wird, werden zwischen dem NAS und dem RADIUS Server mittels des RADIUS Proto- kolls Nachrichten ausgetauscht, um die Identität des Teilnehmers und seine Zugangsrechte im RADIUS Server überprüfen zu lassen. Ist die Antwort des RADIUS Servers positiv, d.h. der Teilnehmer ist autorisiert, baut der NAS eine Verbindung zwischen IP-Netz und dem Teilnehmer bzw. seinem Internet- Endgerät auf. Dabei benötigt das Internet-Endgerät des Teilnehmers eine eindeutige routbare IP-Adresse. Da der Vorrat der zur Verfügung stehenden IP-Adressen beschränkt ist, vergeben die meisten Internetdienste-Anbieter - im Folgenden als Internet Service Provider (ISP) bezeichnet - IP-Adressen nur für die Dauer einer Internetverbindung an ihren Kunden, d.h. den Teilnehmer. Bei verschiedenen Internet-Sitzungen bekommt daher der Teilnehmer bzw. sein Internet-Endgerät in der Regel verschiedene Internet-Adressen zugewiesen. Dem Internet Service Provider steht üblicherweise ein IP-Adressbereich - im folgenden als Adresspool bezeichnet - zur Verfügung, aus dem die Adressen für die temporäre Zuweisung an Teilnehmern ent- nommen werden. Ein Internet Service Provider kann auch über mehrere Adresspools verfügen, beispielsweise um mehrere Servicegruppen für verschiedene Dienste bilden zu können.
Die dynamische Zuordnung von IP-Adressen erfolgt üblicherwei- se entweder im Zugangsserver bzw. NAS oder im AAA Server bzw. RADIUS Server. Die Zuordnung von IP-Adressen in den Zugangsservern bzw. NAS hat den Nachteil eines beträchtlichen Ver- waltungs- und Wartungsaufwandes bei Internet Service Providern, die eine große Zahl von Zugangsservern betreiben. Ad- resspools müssen in jedem einzelnen Zugangsserver eingerichtet werden. Bei großen Internet Service Providern ist die Anzahl der zu versorgenden Zugangsservern beträchtlich und folglich der Aufwand bei Einrichtung und Änderung von Adresspools erheblich. Zudem fehlt eine zentrale Kontrolle der lau- fenden Internetverbindungen und der dabei benutzten IP- Adressen. Beispielsweise für Betreiber von Zugangsnetzwerken (Access Networks) , die den Zugang an kleinere Internet Service Provider weitervermieten, ist eine zentrale Verwaltung und Vergabe der zur Verfügung stehenden Adresspools von großer Wichtigkeit. Bei großen Internet Service Providern ist deshalb üblich, dass die Ressourcenverwaltung und damit auch die Verwaltung der IP-Adressen zentral durch einen oder mehrere hochleistungsfähige und hochverfügbare AAA Server erfolgt. Unter „hochleistungsfähig* ist in diesem Zusammenhang die Fähigkeit gemeint, eine große Zahl an Zugangskontrollen pro Sekunde bearbeiten zu können.
Eine übliche Realisierung für eine hochleistungsfähige zent- rale Steuerung ist mittels eines Multiserversystems. Dieses besteht in der Regel aus einer Anzahl von Einzelrechnern bzw. Servern, die mittels des IP-Netzwerkes miteinander verbunden sind. Diese Lösung ist aufwandsarm, weil teure ausfallssichere Hardware oder Clustersoftware nicht erforderlich sind. Zu- dem ist das System durch die Hinzunahme weiterer Rechner leicht nach oben skalierbar. Aus Redundanzgründen zur Ausfallssicherheit sollten die Einzelrechner in der Lage sein, Aufgaben anderer Rechner des Multiserversystems zu übernehmen. Die, Lastverteilung auf die verschiedenen Einzelrechner des Multiserversystems erfolgt beispielsweise durch die RADIUS Clients auf den Zugangsservern.
Für eine Verwaltung der IP-Adressen durch ein Multiserversystem müssen Informationen über die Vergabe von Adressen den Bedarf an Adressen und Zustandsinformationen über laufende und abgeschlossene Internetsitzungen gesammelt und den Einzelrechnern verfügbar gemacht werden. Wegen der Redundanzanforderungen sollten die einem Einzelrechner zur Verfügung stehenden Informationen auch wenigstens einem anderen Einzel- rechner zugängig sein. Weiter ist dafür zu sorgen, dass Adressen durch verschiedene Einzelrechner nicht mehrfach vergeben werden.
Diese Anforderungen bei der Verwaltung von IP-Adressen durch eine Multiserversystem können beispielsweise dadurch erfüllt werden, dass die Einzelrechner des Multiserversystems durch einen zentralen Server, z.B. ein DHCP (Dynamic Host Configu- ration Protocol) Server oder einen unter Verwendung von herstellerspezifischen Protokollen arbeitenden Server, mit IP- Adressen versorgt werden. Diese Lösung hat folgende Nachteile: • Der Schutz des zentralen Servers gegen Ausfälle, z.B. durch Doppelung, ist in der Regel mit beträchtlichen Aufwand verbunden. • Für eine zuverlässige Kommuni ation zwischen dem zentralen Server und den anderen Rechnern des Multiserversystems sollten ausgetauschte Nachrichten quittiert werden. Dadurch wächst die zu bearbeitende Informationsmenge mit der Anzahl der Rechner stark an. Die Skalierbarkeit, d.h. die Integration weitere Rechner in das Multiserversystem wird dadurch beeinträchtigt. • Eine erhöhte Anzahl von Verbindungswünschen führt zu einer Zunahme des Datenverkehrs zwischen dem zentralen Server und den Einzelrechnern. Daher kann es zu Belastungsspitzen (Bursts) kommen, die Verzögerungen bei der Bearbeitung verursachen könne. • Der zentrale Server führt häufig zu zusätzlichen Wartungsaufwand.
Zur Erhöhung der Ausfallsicherheit gibt es die Möglichkeit mittels eines erweiterten RADIUS Protokolls Zustandsinforma- tionen direkt in den Zugangsservern bzw. NAS zu speichern.
Diese Lösung ist in dem RFC (Request for Comments) 2882 dokumentiert, funktioniert aber nur für Zugangsserver die die entsprechende Protokollerweiterung unterstützen.
Alternativ können die gesamten Informationen über Adresspools auf allen Einzelrechnern des Multiserversystems gespeichert und Nachrichten zur Koordinierung der Adressreservierungen zwischen den Einzelrechnern ausgetauscht werden. Diese Vorgehensweise führt zu einer erheblichen Volumen an auszutau- sehenden Nachrichten, wenn Doppelvergaben von Adressen vermieden werden sollten. Die Erfindung hat zur Aufgabe, die effiziente Verwaltung von einem oder mehreren Adressbereichen in einem AAA-Serversystem anzugeben, die die Nachteile herkömmlicher Methoden vermeidet.
Die Aufgabe wird durch eine AAA Serversystem nach Anspruch 1 und ein Verfahren nach Anspruch 10 gelöst.
Das Erfindungsgemäße AAA Serversystem umfasst eine Mehrzahl von AAA Servern zu Verwaltung wenigstens eines Pools von logischen Adressen. Dabei sind mehrere disjunkte Teilmengen bzw. Subpools wenigstens eines Adresspools jeweils genau einem AAA Server zugeordnet. Die logischen Adressen der Teilmengen des Adresspools sind jeweils nur durch den zugehörigen AAA Server einem Endgerät bzw. Teilnehmer zuweisbar und werden von dem zugehörigen AAA Server verwaltet (Anspruch 1) . Es können auch mehrere Teilmengen eines Adresspools einem AAA Server zugeordnet sein. Bei den Adresspools kann es sich beispielsweise um IP Adressbereiche handeln (Anspruch 2) . Die Zuweisung von Adressen zu Endgeräten durch die AAA Server des AAA Serversystems kann beispielsweise mit Hilfe des RADIUS (Remote Authentication Dial-In User Service) Protokolls oder des DIÄMETER Protokolls erfolgen (Anspruch 3) . Diese Protokolle werden häufig zur Kommunikation zwischen einem AAA Ser- versystem und einem Zugangsserver oder NAS verwendet, mit dessen Hilfe Endgeräte mit dem Netz (z.B. Internet) verbindbar sind. Die AAA Server des AAA Serversystems können beispielsweise mittels des Internetprotokolls bzw. TCP/IP (Transmission Control Protocol/Internet Protocol) miteinander kommunizieren (Anspruch 4 und 8) . Für Änderungen der Zuordnung von Teilmengen von logischen Adressen bzw. Subpools von logischen Adressen zu AAA Servern ist sinnvoll, wenn alle AAA Server des Serversystems über den gesamten Pool bzw. die gesamten Pools von logischen Adressen verfügen (Anspruch 5) . Die Unterteilung von dem zur Verfügung stehenden Adressraum in Teilmengen und die Zuordnung dieser Teilmengen zu AAA Server erlaubt den Aufwand bei der Kommunikation zwischen den einzelnen Servern bzw. Rechnern zu reduzieren.
Bei dem erfindungsgemäßen Verfahren zu Aktualisierung von Informationen in einem erfindungsgemäßen AAA Serversystem wird von einem ersten AAA Server des Serversystem regelmäßig eine Aktualisierungsnachricht an alle anderen Server des AAA Ser- versystems gesendet. Diese Aktualisierungsnachricht umfasst
Informationen über Statusänderungen bei dem ersten AAA Server zugeordneten Teilmengen des Adresspools bzw. der Adresspools seit der vorhanden gegangenen Aktualisierung. Durch das regelmäßige, beispielsweise in festen Zeitintervallen vorgenom- mene Senden von Aktualisierungsnachrichten der AAA Server an alle anderen AAA Server des AAA Serversystems kann die Vergabe von logischen Adressen durch die einzelnen AAA Server des AAA Serversystems koordiniert werden. Die sich in Gebrauch befindlichen Teilmengen des Adresspools bzw. der Adresspools können so an alle AAA Server signalisiert werden. Zudem kann eine Information bezüglich der während des nächsten Zeitintervalls benötigten Ressourcen an logischen Adressen zwischen den Servern AAA ausgetauscht werden. Dabei schätzt ein AAA Server vor dem Senden der Aktualisierungsnachricht die Anzahl der in Zeitraum zwischen der zusendenden Aktualisierungsnachricht und der darauffolgenden Aktualisierungsnachricht zu vergebenden logischen Adressen ab. Dies kann geschehen, indem das Produkt der maximal durch den AAA Server bearbeitbaren Rate an Anforderungen für die Vergabe einer logischen Adresse und der dem Zeitraum zwischen der zu sendenden Aktualisierungsnachricht und der darauffolgenden Aktualisierungsnachricht gebildet wird (Anspruch 12) . Die so erhaltene Abschätzung liefert eine obere Grenze für die Anzahl der benötigten Adressen. Aus den dem Server zugeordneten Teilmengen des Adresspools werden welche für die Entnahme der nach der Abschätzung in der Zeitraum benötigten logischen Adressen bestimmt. Die Aktualisierungsnachricht kann dann Informationen darüber enthalten, welche dem AAA Server zugeordneten Teilmengen der Adresspools für die Entnahme der nach der Abschätzung in dem Zeitraum benötigten logischen Adressen bestimmt wurden (Anspruch 11) . Auf diese Weise können Teilmengen von logischen Adressen als "unsicher" markiert werden, d.h. dass eine Vergabe von logischen Adressen aus diesen Teilmengen innerhalb des nächsten Zeitintervalls möglich ist. Diese Markierung spielt eine Rolle, wenn einzelne AAA Server zusätzliche Teilmengen des Adresspools benötigen, um die Verbindungsanfragen zu befriedigen. In ein solchen Fall kann die Zustän- digkeit bzw. Zuordnung von nicht als "unsicher" markierten Teilmengen des Adresspools geändert und dem AAA Server mit Mangel an logischen Adressen zugeordnet werden (Anspruch 13) . Bei diesem Verfahren kommunizieren die einzelnen AAA Server eine Mischung aus redundanten Daten und Sperrinformationen (markierte Teilmengen des Adresspools, deren Zuordnung nicht zur Disposition steht) . Dadurch wird das Volumen der Daten, die zwischen den Servern ausgetauscht werden, beschränkt. Den einzelnen AAA Servern bleibt in Regelfall verborgen, welche Einzeladressen von anderen AAA Servern vergeben werden. Stattdessen werden die Teilmengen kommuniziert, aus denen Adressen vergeben werden. Die auf den einzelnen Rechnern zu speichernden Statusinformationen ist dadurch reduziert - bezüglich anderer AAA Server wird der Status von (evtl. indizierten) Teilmengen statt der einzelner Adressen festgehalten - und die Datenrate des Informationsaustausches zwischen den einzelnen Servern wird reduziert. Bei Ausfall eines AAA Servers können die diesem AAA Server zugeordneten Teilmengen des Adresspools einem anderen AAA Server, z.B. nach Maßgabe einer Prioritätsliste, zugeordnet werden (Anspruch 14 und 15). Evtl. werden die Teilmengen des ausgefallenen Servers auch zwischen mehreren anderen AAA Servern verteilt. Es ist dann sinnvoll, Teilmengen von logischen Adressen, die bei der letzten erhaltenen Aktualisierungsnachricht des ausgefallenen Server als „unsicher" markiert wurden, für eine Zeitspanne nicht für die Neuvergabe von logi- sehen Adressen zu nutzen (Anspruch 16) . Diese Zeitspanne kann beispielsweise der maximale erlaubten Verbindungsdauer entsprechen (Anspruch 17) . Aktualisierungsnachrichten können auch beim Neubooten von AAA Servern des AAA Serversystems verwendet werden. Beispielsweise übermittelt ein neugeboote- ter AAA Server an die anderen AAA Server eine Multicastnach- richt, mit der er die Übersendung von Aktualisierungsnachrichten und die Zuordnung von Teilmengen des Adresspools anfordert (Anspruch 18) . Als Transportprotokoll zu Vermittlung von Aktualisierungsnachrichten können das TCP/IP Protokoll, das RADIUS Protokoll oder DIAMETER Protokoll verwendet werden. Durch das reduzierte Volumen an ausgetauschten Nachrichten ist es möglich, dass die einzelnen Server des Serversystems an verschiedenen Orten d.h. dezentral aufgestellt werden (Anspruch 9) .
Weitere vorteilhafte Weiterbindungen des Erfindungsgegenstandes sind in den weiteren Unteransprüchen angegeben.
Im folgenden wird die Erfindung im Rahmen eines Ausführungs- beispiels anhand von fünf Figuren näher erläutert. Es zeigen:
Fig. 1: Ein Szenarium für die dynamische Zuordnung von Adressen für Internetsitzungen. Fig. 2: Die Aufteilung eines Adressbereiches bzw. Adresspools in Teilmengen bzw. Subpools.
Fig. 3: Die Zuordnung von Teilmengen an logischen Adressen zu RADIUS Servern.
Fig. 4: Den Austausch von Aktualisierungsnachrichten zwischen drei RADIUS Servern.
Fig. 5: Die verschiedenen Schritte bei der Anforderung einer zusätzlichen Teilmengen an logischen Adressen.
Im Rahmen des Ausführungsbeispiels wird angenommen, dass ein oder mehrere IP Adressbereiche durch ein RADIUS Serversystem, d.h. eine Multiserversystem, das mittels des RADIUS Protokolls arbeitet, verwaltet werden. Das RADIUS Serversystem besteht aus mehreren RADIUS Servern, die mit Hilfe eines Netzwerkes verbunden sind. Spezielle Software, z.B. Clustersoft- wäre, wird nicht benötigt. Der Einfachheit halber wird angenommen, dass im Rahmen des Ausführungsbeispiels ein Adresspool einem IP Adressbereich und Teilmengen des Adresspools Teilbereichen von IP Adressen entsprechen. Ein globaler Adressbereich bzw. Adresspool kann einem Internet Service Pro- vider zugeordnet sein oder für bestimmte Dienstklasse reserviert werden.
Im Figur 1 sind Internetendgeräte Hostl, ..., Host5 dargestellt, über die Teilnehmer eine Verbindung zum Internet INT aufbauen können. Mit Hilfe des IP (Internet Protokolls) Protokolls IP, das über dem PPP (Point-to-Point Protocol) Protokoll PPP läuft, kann eine Verbindung zwischen dem Endgerät Hostl ... Host5 und einem Zugangsserver NAS hergestellt wer- den. Bevor von dem Zugangsserver eine Verbindung mit dem Internet INT hergestellt wird, wird eine Anfrage bei dem RADIUS Serversystem RADSS durchgeführt. Der Austausch von Nachrichten zwischen dem Zugangsserver NAS und dem RADIUS Serversys- te RADSS erfolgt mit Hilfe des Radiusprotokolls RADIUS . Das RADIUS Serversystems RADSS verfügt über einen Pool IPPool von eigenen IP Adressen @IP1, ... , @Ipn , die dynamisch für den Zeitraum der Verbindung den Internetendgeräten Hostl, ..., Hostn zugeordnet werden. Nach Erhalt der Autorisierungsnach- rieht durch das RADIUS Serversystem und der Zuteilung einer IP Adresse für den Zeitraum der Verbindung baut der Zugangsserver NAS eine Internetverbindung für das anfragende Internetendgerät Hostl, ..., Host5 auf.
In Figur 2 ist ein Adresspool A dargestellt, der aus dem Adressbereich IP 1 bis IP N besteht. Dieser Adresspool A wird in drei Teilmengen AI, .., A3 unterteilt, die den Teiladressbereichen IP 1 bis IP I, IP J bis IP K, und IP L bis IP N entsprechen. Jeder der RADIUS Server verfügt über den gesam- ten Adresspool A, d.h. auf allen Servern ist der gesamte Adressbereich gespeichert. Jeder der RADIUS Server kann IP Adressen jeder beliebigen Teilmengen AI, ..., A3 von IP Adressen freigeben. Dagegen besteht ein exklusives Recht der Zuordnung von IP Adressen für Verbindungen, d.h. jeder RADIUS Server hat eine oder mehrere Teilmengen AI, .. , A3 von Adressen zugeordnet, aus der er IP Adressen vergeben kann. Diese Vergaberechte von IP Adressen können dynamisch zwischen den RADIUS Servern verschoben werden. In Figur 3 sind drei RADIUS Server RADI, .., RAD3 dargestellt. Jedem ist ein Teilbereich von Adressen AI, ..., A3 zugewiesen (durch durchgezogene Pfeile gekennzeichnet) , aus den er Adressen zuordnen kann. Alle drei RADIUS Server können benützte Adressen freigeben, was durch durchbrochene Pfeile gekennzeichnet ist. In Figur 4 ist gezeigt, wie bei den einzelnen RADIUS Servern die Aktualisierung von Informationen über den Status der andere RADIUS Server vorgenommen wird. In regelmäßigen Zeitab- ständen sendet jeder RADIUS Server RADI, ..., RAD3 eine Aktualisierungsnachricht an alle andern RADIUS Server RADI, ..., RAD3, um über Änderungen bezüglich der zugeordneten Teilmengen an Adressen zu Informieren. Diese Aktualisierungsnachricht wird mit Hilfe von einem IP Multicastmechanismus ver- sendet und betrifft nur Teilmengen, hinsichtlich der sich seit der letzten Aktualisierungsnachricht eine Änderung ergeben hat. Aktualisierungsnachrichten werden nicht quittiert. Die Doppeltvergabe von IP Adressen ist ausgeschlossen, weil schlimmstenfalls eine Freigabeinformation verloren geht, d.h. eine Information, die eine bereits benutzte IP Adresse betrifft. Die Freigabe erfolgt dann später, nachdem der Timer für die maximale Vergabezeit ausgelaufen ist. Zusätzlich enthält die Aktualisierungsnachricht Informationen über die Teilmengen von Adressen, aus welchen voraussichtlichen im folgende Zeitintervall IP Adressen vergeben werden. In Frage kommen dabei Teilmengen, die noch nicht vergebene IP Adressen zu Verfügung haben. Entsprechend Figur 4 sendet RADIUS Server RADI zu den Zeitpunkten Sl.l und S1.2 Aktualisierungsnachrichten UpdtRADl (für: Update von RADI) an die RADIUS Server RAD2 und RAD3. Zu verschobenen Zeitpunkten S2.1 und S2.2 bzw. S3.1 und S3.2 senden der RADIUS Server RAD2 bzw. RADIUS Server RAD3 Aktualisierungsnachrichten UpdtRAD2 bzw. UpdtRAD3 jeweils an die beiden anderen RADIUS Server RADI und RAD 3 bzw. RADI und RAD2.
Auf jedem der RADIUS Server RADI, ..., RAD3 werden folgende Informationen gespeichert, die den gesamten bzw. globalen Adresspool A betreffen: • ein Bezeichner für den globalen Adresspool A für den Fall, dass mehrere globale Adresspools, beispielsweise für verschiedene Dienstklassen, verwendet werden.
• Eine Liste von den RADIUS Servern RADI, .., RAD3, die Zugriff auf Adressen des globalen Adresspools A haben.
Diese Liste beinhaltet die IP Adresse jedes RADIUS Servers RADI, ..., RAD3, einen Bezeichner für jeden RADIUS Server RADI, .., RAD3, den Zeitpunkt der letzten Aktualisierung für jeden RADIUS Server RADI, .., RAD3 und die Gesamtzahl der aktuell freien, d.h. nicht vergebenen IP Adressen.
• Die erste IP Adresse des globalen Adressbereichs A.
• Die Anzahl von IP Adressen, die zu diesem Adressbereich A gehören.
• Die Zeitspanne zwischen zwei Aktualisierungen. • Die maximale Zeitdauer, die für die Verbindung eines Internetendgeräts vorgesehen ist.
• Die Liste der Teilmengen von IP Adressen, beispielsweise in Form von Pointers, die jeweils auf die erste IP Adressen des Teilbereichs zeigen. • Optional eine Liste von Zugangsservern bzw. Portkennungen. Diese Liste enthält alle verbundenen NAS in Form Ihrer IP Adressen oder Ihrer NAS Kennungen und ihrer Portzahlen.
• Für einen globalen Adresspool A kann zusätzlich ein Flag definiert werden, dass einen Mangel an freien IP Adressen anzeigt. Dieses Flag wird beispielsweise gesetzt, wenn die Gesamtzahl der freien IP Adressen kleiner wird als ein Schwellenwert, beispielsweise die Zeitspanne zwischen Aktualisierungen multipliziert mit der maximalen Rate an Anfragen nach IP Adressen. Das Setzen des Flags wird rück- gängig gemacht, wenn die Anzahl der freien Adressen wieder den Schwellenwert übersteigt. Folgende Informationen bezüglich der Teilmengen von Adressen werden auf allen RADIUS Servern gespeichert:
• Der Bezeichner des RADIUS Servers, der für die Teilmenge an Adressen verantwortlich ist, d.h. der AAA Server, der aus dieser Teilmenge IP Adressen vergeben kann.
• Die erste IP Adresse der Teilmenge bzw. des Teilbereiches an IP Adressen.
• Die Anzahl der von der Teilmenge umfassten IP Adressen.
Die auf den AAA RADIUS Servern vorgehaltenen, auf die Teilmengen an Adressen bezogenen Informationen werden in regelmäßigen Zeitabständen aktualisiert. Die Aktualisierung wird ausgelöst durch das Ablaufen eines Timers, der das Zeitintervall zwischen zwei Aktualisierungsnachrichten misst. Von dem RADIUS Server, der Aktualisierungsnachrichten hinsichtlich des Status seiner Teilmengen an Adressen sendet, werden die freien, d.h. nicht vergebenen Adressen, der zugeordneten Teilmengen an Adressen bestimmt und die Teilmengen, welche innerhalb des nächsten Zeitintervalls zur Benutzung in Frage kommen, identifiziert. Die Aktualisierungsnachricht umfasst dann die Kennung des Radiusservers, von dem die Nachricht gesendet wird, die Gesamtzahl der freien IP-Adressen dieses RADIUS Servers, die Kennungen bzw. Bezeichner der Teilmengen an Adressen, die für eine Benutzung innerhalb des nächsten Zeitintervalls in Frage kommen, d.h. die als „unsicher* markiert sind, Änderung hinsichtlich der Benutzung von Teilmengen seit der letzten Aktualisierungsnachricht und gegebenenfalls weitere Statusinformationen. Nach dem Senden der Aktualisierungsnachricht wird der Timer neu gestartet. Ein RADIUS Server, der eine Aktualisierungsnachricht erhält, setzt einen Überwachungstimer neu, der misst, wie viel Zeit seit der letzten Aktualisierungsnachricht verstrichen ist. Anhand der empfangenen Aktualisierungsnachricht bringt der RADIUS Server die Statusinformationen über den sendenden Radiusserver auf den neusten Stand. In Figur 5 ist der Austausch von Nachrichten zur und während der Verbindung eines Teilnehmers bzw. Endgeräts dargestellt. Von einem NAS (Network Access Server) wird für die Verbindung eines Internetendgerätes eine Authentifizierungsanfrage rAUTH mit Hilfe des Radiusprotokolls RADIUS an einen RADIUS Server RADI gerichtet. Diese Authentifizierungsanfrage rAUTH enthält die Kennung des NAS, den Bezeichner des Ports und die Kennung des Teilnehmers bzw. Endgerätes. Von dem RADIUS Server RADI wird eine Anfrage rLDAP an eine LDAP (Lightweight Directory Access Protocol) -Datenbank LDAP gestellt, im Zuge derer die Kennung bzw. Identität des Teilnehmers ermittelt wird. Von der LDAP-Datenbank LDAP wird in der Antwort aLDAP die Kennung der Teilmenge von Adressen mitgeteilt, aus der die IP-Adresse zu entnehmen ist. Daraufhin wird eine IP-Adresse aus dieser Teilmenge von IP-Adressen bestimmt. Anschließend teilt der
RADIUS Server die bestimmte IP-Adresse dem NAS in einer Antwort aAUTH auf die Authentifizierungsanfrage mit. Die Tatsache dieser neuen Verbindung wird den anderen Radiusservern RAD2 im Zuge einer Aktualisierungsnachricht UpdtRADl z.B. in Form einer aktualisierten Gesamtzahl an benützten IP-Adressen und evtl. durch die Neumarkierung der entsprechenden Teilmenge an Adressen als „unsicher* mitgeteilt. Analog erhält der Radiusserver RADI während der Verbindung Aktualisierungsnachrichten UpdtRAD2 von anderen Radiusservern RAD2. Wenn die Verbindung unterbrochen werden soll, sendet der NAS eine
Nachricht astop an den RADIUS Server, mit der die Abrechnung bzw. das Accounting für die entsprechende Verbindung unterbrochen werden soll. Diese Nachricht enthält die Kennung des Teilnehmers und die zugewiesene IP-Adresse. Der RADIUS Server RADI quittiert diese Nachricht dem NAS, wobei die Quittie- rungsnachricht ACKastop wieder die Kennung des Teilnehmers und die verwendete IP-Adresse enthält. Nach Beendigung der Verbindung werden in der darauffolgenden Aktualisierungsnachricht UpdtRADl die anderen Radiusserver RAD2 mit den entspre- chend aktualisierten Statusinformationen versorgt. Wenn der RADIUS Server nicht über genug Teilmengen an Adressen für die Anfragen durch Zugangsserver bzw. NAS verfügt, kann er die Zuordnung weiterer Teilmengen an IP-Adressen an¬ fordern. Eine derartige Anfrage bzw. Anforderung wird ausge- löst, wenn die Gesamtzahl freier IP-Adressen des RADIUS Servers eine Schwelle unterschreitet, die beispielsweise durch das Produkt des Zeitintervalls zwischen Aktualisierungsnachrichten und der maximal bearbeitbaren Rate an Verbindungswünschen gegeben ist. In diesem Fall setzt der RADIUS Server ein Flag, das den Mangel an IP-Adressen anzeigt. Der RADIUS Server überprüft anhand der Statusinformationen der anderen RADIUS Server, welcher Server die größte Anzahl an freien IP- Adressen bzw. die größte Anzahl an nicht markierten bzw. nicht benutzten Teilmengen an Adressen aufweist. Falls ein RADIUS Server identifiziert werden kann, der über beträchtlich mehr freie Adressen als den Schwellenwert für Mangel an IP-Adressen verfügt, wird von dem RADIUS Server mit Adressmangel eine Anforderung für Zuweisung einer weiteren Teilmenge an Adressen gesendet. Mit Senden dieser Nachricht wird ein Überwachungstimer gesetzt. Bei einer negativen Antwort sendet der RADIUS Server mit Adressenmangel eine entsprechende Anfrage an andere RADIUS Server nach Maßgabe der dort freien Adressen. Falls kein RADIUS Server mit freien IP-Adressen infiziert werden kann oder wenn keine Antworten von den RADIUS Servern erhalten werden, wartet der RADIUS Server mit Adressmangel wenigstens ein Aktualisierungszeitintervall, bevor er seine Anfragen wiederholt. Falls in diesem Zeitraum alle freien IP-Adressen vergeben werden, werden zusätzliche Au- thentifizierungsanfragen von NAS zurückgewiesen. Wird dagegen eine positive Antwort auf die Anforderung einer neuen Teilmenge an Adressen erhalten, so wird diese positive Antwort mit einer Quittierungsnachricht an alle anderen RADIUS Server mittels Multicast quittiert und intern werden alle relevanten Daten aktualisiert. Dieser Mechanismus kann auch nach einen Reboot eines der RADIUS Server zur automatischen Rekonfigura- tion des RADIUS Servers verwendet werden. Beim Ausfall eines der RADIUS Server wird durch eine Liste der Kennungen der RADIUS Server eine Hierarchie der Zuständigkeit vorgegeben. Nachdem von dem ausgefallenen RADIUS Server keine Aktualisierungsnachrichten mehr erhalten werden, übernimmt der RADIUS Server an der Spitze der Hierarchie oder der darauf folgende RADIUS Server die Kontrolle bzw. Verwaltung der entsprechenden IP-Adressbereiche. Dabei laufen im RADIUS Server, der die Verwaltung der Teilmengen von Adressen übernimmt, folgende Schritte ab: Die Übernahme von Adressen wird durch den Ablauf des Überwachungstimers angestoßen. Danach wird eine Anforderung für eine Aktualisierungsnachricht an den ausgefallenen RADIUS Server gesendet. Wenn daraufhin keine Antwort enthalten wird, werden mittels einer Multicast-Nachricht alle anderen RADIUS Server darüber informiert, dass der RADIUS Server, der die Multicast-Nachricht sendet, die Verwaltung und Zuordnung der Teilmengen von Adressen des ausgefallenen RADIUS Servers ü- bernimmt. Die Teilmengen von Adressen des übernehmenden RADIUS Servers werden um die übernommenen Teilmengen von Ad- ressen erweitert. Dabei werden als „unsicher* markierte Teilmengen blockiert und ein Timer für die Blockierung gestartet. Dieser Timer misst die maximale Zeit für die Zuordnung einer IP-Adresse für eine Verbindung. Nach Ablauf des Timers wird die Blockierung der Teilmengen von Adressen zurückgenommen. Nun sind alle Ressourcen an IP-Adressen wieder verfügbar und der Ausfall des RADIUS Servers ist vollständig kompensiert.

Claims

Patentansprüche
1. AAA Serversystem (RADSS), umfassend eine Mehrzahl von AAA Servern (RADI, RAD2, RAD3) , zur Verwaltung eines Pools (A) von logischen Adressen (IP1, ... IPN) , dadurch gekennzeichnet, -
- dass mehrere disjunkte Teilmengen (AI, A2, A3) des Adresspools (A) gegeben sind,
- dass jede der disjunkten Teilmengen (AI, A2, A3) des Ad- resspools (A) genau einem AAA Server (RADI, RAD2, RAD3) zugeordnet ist, und
- dass die logischen Adressen der Teilmengen (AI, A2, A3) des Adresspools (A) nur jeweils durch den zugehörigen AAA Server
(RADI, RAD2, RAD3) einem Endgerät zuweisbar sind.
2. AAA ServerSystem nach Anspruch 1, dadurch gekennzeichnet,
- dass die logischen Adressen (IP1,...IPN) durch IP (Internet
Protocol) Adressen gegeben sind.
3. AAA Serversystem nach Anspruch 1 oder 2, dadurch gekennzeichnet,
- dass von den AAA Servern (RADI, RAD2, RAD3) des AAA Serversystems (RADSS) mittels des RADIUS Protokolls oder des DIAMETER Protokolls logische Adressen für Endgeräte zuweisbar sind.
4. AAA Serversystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, - dass zwischen den AAA Servern (RADI, RAD2, RAD3) des AAA
Serversystems (RADSS) Nachrichten mittels des Internet Protokolls austauschbar sind.
5. AAA Serversystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, - dass der gesamte Pool (A) von logischen Adressen
(IP1....IPN) auf allen AAA Servern (RADI, RAD2, RAD3) des AAA Serversystems (RADSS) gespeichert ist.
6. AAA Serversystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet,
- dass die Zuordnung von Teilmengen (AI, A2, A3) des Adresspools (A) zu AAA Servern (RADI, RAD2, RAD3) dynamisch änderbar ist.
7. AAA Serversystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet,
- dass mehrere Adresspools (A) von logischen Adressen gegeben sind, von denen disjunkte Teilmengen (AI, A2, A3) AAA Servern (RADI, RAD2, RAD3) des AAA Serversystems (RADSS) zugeordnet sind,
- dass verschiedene Dienstklassen gegeben sind, und
- dass für die Vergabe von logischen Adressen im Rahmen eines Dienstes einer der Dienstklassen eine Zuordnung von verschie- denen Adresspools (A) zu genau einer Dienstklasse gegeben ist.
8. AAA Serversystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, - dass Nachrichten zwischen den AAA Servern (RADI, RAD2,
RAD3) des AAA Serversystems (RADSS) mittels des TCP/IP Protokolls austauschbar sind.
9. AAA Serversystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet,
- dass wenigstens zwei der AAA Server (RADI, RAD2, RAD3) des AAA Serversystems (RADSS) an unterschiedlichen Orten positioniert sind.
10. Verfahren zur Aktualisierung von Informationen in einem AAA Serversystem nach Anspruch 1, bei dem - von einem ersten AAA Server (RADI, RAD2, RAD3) des AAA Serversystems (RADSS) regelmäßig eine Aktualisierungsnachricht
(UpdtRADl, UpdtRAD2, UpdtRAD3) an alle anderen AAA Server (RADI, RAD2, RAD3) des AAA Serversystems (RADSS) gesendet wird,
- diese Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) Informationen über Statusänderungen von dem ersten AAA Server (RADI, RAD2, RAD3) zugeordneten Teilmengen (AI, A2, A3) des Adresspools (A) seit der vorangegangenen Aktuali- sierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) umfasst.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet,
- dass vor dem Senden der Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) im ersten AAA Server (RADI,
RAD2, RAD3) eine Abschätzung der im Zeitraum zwischen der zu sendenden Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) und der darauffolgenden Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) zu vergebenden logischen Ad- ressen durchgeführt wird,
- dass dem ersten AAA Server (RADI, RAD2, RAD3) zugeordnete Teilmengen (AI, A2, A3) des Adresspools (A) für die Entnahme der nach der Abschätzung in dem Zeitraum benötigten logischen Adressen bestimmt werden, und - dass die Aktualisierungsnachricht (UpdtRADl, UpdtRAD2,
UpdtRAD3) zusätzlich Informationen darüber enthält, welche dem ersten AAA Server (RADI, RAD2, RAD3) zugeordnete Teilmengen (AI, A2, A3) des Adresspools (A) für die Entnahme der nach der Abschätzung in dem Zeitraum benötigten logischen Ad- ressen bestimmt wurden.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet,
- dass für die Abschätzung das Produkt der maximal durch den AAA Server (RADI, RAD2, RAD3) bearbeitbare Rate an Anforderungen für die Vergabe einer logischen Adresse und der dem Zeitraum zwischen der zu sendenden Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) und der darauffolgenden Aktualisierungsnachricht (UpdtRADl, UpdtRAD2, UpdtRAD3) gebildet wird.
13. Verfahren nach einem der Ansprüche 10 bis 12, dadurch gekennzeichnet,
- dass der erste AAA Server (RADI, RAD2, RAD3) überprüft, ob die entsprechend der Abschätzung benötigten Teilmengen (AI, A2, A3) des Adresspools (A) zur Verfügung stehen, und - dass bei negativen Ergebnis der Überprüfung durch den ersten AAA Server (RADI, RAD2, RAD3) bewirkt wird, dass eine Teilmenge eines anderen AAA Servers (RADI, RAD2, RAD3) dem ersten AAA Server (RADI, RAD2, RAD3) zugeordnet wird.
14. Verfahren nach einem der Ansprüche 10 bis 12, dadurch gekennzeichnet, dass bei Ausfall des ersten AAA Servers (RADI, RAD2, RAD3) die dem ersten AAA Server (RADI, RAD2, RAD3) zugeordneten Teilmengen (AI, A2, A3) des Adresspools (A) einem zweiten AAA Server (RADI, RAD2, RAD3) zugeordnet werden.
15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, dass der zweite AAA Server (RADI, RAD2, RAD3) nach Maßgabe einer Prioritätsliste von AAA Servern (RADI, RAD2, RAD3) bestimmt wird.
16. Verfahren nach Anspruch 11 und einem der Ansprüche 14 o- der 15, dadurch gekennzeichnet, dass die entsprechend der letzten von dem zweiten AAA Server (RADI, RAD2, RAD3) erhaltenen Aktualisierungsnachricht des ersten AAA Servers (RADI, RAD2, RAD3) für die Entnahme der nach der Abschätzung in dem Zeitraum benötigten logischen Ad- ressen bestimmten Teilmengen (AI, A2, A3) des Adresspools (A) bei Ausfall des ersten AAA Servers (RADI, RAD2, RAD3) für ei- ne Zeitspanne nicht für die Neuvergabe von logischen Adressen (IP1, ..., IPN) genutzt wird.
17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass die Zeitspanne nach Maßgabe der maximal erlaubten Verbindungsdauer bestimmt wird.
18. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet,
- dass ein zweiter AAA Server (RADI, RAD2, RAD3) neu gebootet wird, und
- dass von dem zweiten AAA Server (RADI, RAD2, RAD3) eine Multicast-Nachricht an alle anderen AAA Server (RADI, RAD2, RAD3) des AAA Serversystems (RADSS) übermittelt wird, wodurch die Übersendung von Aktualisierungsnachrichten (UpdtRADl, UpdtRAD2, UpdtRAD3) und die Zuordnung von Teilmengen (AI, A2, A3) des Adresspools (A) an den ersten AAA Server (RADI, RAD2, RAD3) angefordert wird.
19. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet,
- dass als Transportprotokoll zur Übermittlung von Aktuali- sierungsnachrichten (UpdtRADl, UpdtRAD2, UpdtRAD3) das TCP/IP Protokoll, das RADIUS Protokoll oder das DIAMETER Protokoll verwendet wird.
PCT/DE2003/000895 2002-03-27 2003-03-18 Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung WO2003081875A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE50301105T DE50301105D1 (de) 2002-03-27 2003-03-18 Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung
US10/509,286 US20050235000A1 (en) 2002-03-27 2003-03-18 Aaa server system for efficient control and address assignment
EP03744761A EP1488611B1 (de) 2002-03-27 2003-03-18 Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung
CN038071665A CN1643879B (zh) 2002-03-27 2003-03-18 用于在aaa服务器系统中更新信息的方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10213862 2002-03-27
DE10213862.1 2002-03-27

Publications (1)

Publication Number Publication Date
WO2003081875A1 true WO2003081875A1 (de) 2003-10-02

Family

ID=28050932

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2003/000895 WO2003081875A1 (de) 2002-03-27 2003-03-18 Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung

Country Status (6)

Country Link
US (1) US20050235000A1 (de)
EP (1) EP1488611B1 (de)
CN (1) CN1643879B (de)
DE (1) DE50301105D1 (de)
PL (1) PL372459A1 (de)
WO (1) WO2003081875A1 (de)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1659762A1 (de) * 2004-11-23 2006-05-24 Microsoft Corporation System und Methode für einen als verteiltes System implementierten Server zur Adressvergabe für ein Peer-to-Peer Netz
EP2369815A1 (de) * 2010-03-23 2011-09-28 Juniper Networks, Inc. Verwaltung verteilter Adressenpools in Netzwerkvorrichtungen
US8260902B1 (en) 2010-01-26 2012-09-04 Juniper Networks, Inc. Tunneling DHCP options in authentication messages
US8631100B2 (en) 2010-07-20 2014-01-14 Juniper Networks, Inc. Automatic assignment of hardware addresses within computer networks
US8782211B1 (en) 2010-12-21 2014-07-15 Juniper Networks, Inc. Dynamically scheduling tasks to manage system load
CN101141492B (zh) * 2005-04-29 2014-11-05 华为技术有限公司 实现dhcp地址安全分配的方法及系统
CN104144123A (zh) * 2013-05-10 2014-11-12 中国电信股份有限公司 访问互联网的方法、系统与路由型网关装置
US10931628B2 (en) 2018-12-27 2021-02-23 Juniper Networks, Inc. Duplicate address detection for global IP address or range of link local IP addresses
US10965637B1 (en) 2019-04-03 2021-03-30 Juniper Networks, Inc. Duplicate address detection for ranges of global IP addresses
US10992637B2 (en) 2018-07-31 2021-04-27 Juniper Networks, Inc. Detecting hardware address conflicts in computer networks
US11165744B2 (en) 2018-12-27 2021-11-02 Juniper Networks, Inc. Faster duplicate address detection for ranges of link local addresses

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ES2315579T3 (es) * 2004-01-23 2009-04-01 Siemens Aktiengesellschaft Procedimiento para la asignacion de una direccion ip a un equipo.
ATE545997T1 (de) 2004-12-17 2012-03-15 Tekelec Us Verfahren, systeme und computerprogrammprodukte zur unterstützung des datenbankzugriffs in einer netzwerkumgebung des internet-protokoll- multimedia-subsystems (ims)
US8756298B2 (en) * 2005-12-21 2014-06-17 Cisco Technology, Inc. System for automatic configuration of computers in a server farm
CN1929482B (zh) * 2006-09-20 2010-08-04 华为技术有限公司 一种网络业务认证方法及装置
US8072990B1 (en) * 2007-04-20 2011-12-06 Juniper Networks, Inc. High-availability remote-authentication dial-in user service
US8850067B2 (en) * 2009-10-22 2014-09-30 Verizon Patent And Licensing Inc. Internet protocol (IP) address pool management and allocation
US8615237B2 (en) * 2010-01-04 2013-12-24 Tekelec, Inc. Methods, systems, and computer readable media for policy and charging rules function (PCRF) node selection
US8626157B2 (en) 2010-02-11 2014-01-07 Tekelec, Inc. Methods, systems, and computer readable media for dynamic subscriber profile adaptation
WO2011156274A2 (en) * 2010-06-06 2011-12-15 Tekelec Methods, systems, and computer readable media for obscuring diameter node information in a communication network
US8862613B2 (en) * 2010-07-30 2014-10-14 Sap Ag Extensibility of business process and application logic
US9697042B2 (en) 2010-07-30 2017-07-04 Sap Se Extensibility of business process and application logic
CN101917483B (zh) * 2010-08-18 2015-11-25 中国电信股份有限公司 物联网终端通信管控的实现方法、系统和设备
WO2012106710A1 (en) 2011-02-04 2012-08-09 Tekelec, Inc. Methods, systems, and computer readable media for provisioning a diameter binding repository
US8737304B2 (en) 2011-03-01 2014-05-27 Tekelec, Inc. Methods, systems, and computer readable media for hybrid session based diameter routing
WO2012118963A1 (en) 2011-03-01 2012-09-07 Tekelec, Inc. Methods, systems and computer readable media for dynamically learning diameter binding information
US8918469B2 (en) 2011-03-01 2014-12-23 Tekelec, Inc. Methods, systems, and computer readable media for sharing diameter binding data
CN103493522B (zh) 2011-03-03 2016-12-07 泰科来股份有限公司 用于丰富Diameter信令消息的方法、系统和计算机可读介质
WO2012154674A2 (en) 2011-05-06 2012-11-15 Tekelec, Inc. Methods, systems, and computer readable media for steering a subscriber between access networks
US9253163B2 (en) 2011-12-12 2016-02-02 Tekelec, Inc. Methods, systems, and computer readable media for encrypting diameter identification information in a communication network
CN102932501B (zh) * 2012-11-08 2015-06-10 杭州迪普科技有限公司 一种地址池资源保护的方法及装置
CN103856469A (zh) * 2012-12-06 2014-06-11 中国电信股份有限公司 支持dhcp认证溯源的方法、系统与dhcp服务器
US9277014B2 (en) * 2013-06-19 2016-03-01 Alcatel Lucent Handling of auxiliary NAS
US9723075B2 (en) * 2013-09-13 2017-08-01 Incontact, Inc. Systems and methods for data synchronization management between call centers and CRM systems
US10951519B2 (en) 2015-06-17 2021-03-16 Oracle International Corporation Methods, systems, and computer readable media for multi-protocol stateful routing
US9967148B2 (en) 2015-07-09 2018-05-08 Oracle International Corporation Methods, systems, and computer readable media for selective diameter topology hiding
US9668135B2 (en) 2015-08-14 2017-05-30 Oracle International Corporation Methods, systems, and computer readable media for providing access network signaling protocol interworking for user authentication
US10084755B2 (en) 2015-08-14 2018-09-25 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) proxy and diameter agent address resolution
US9923984B2 (en) 2015-10-30 2018-03-20 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial in user service (RADIUS) message loop detection and mitigation
US9668134B2 (en) 2015-08-14 2017-05-30 Oracle International Corporation Methods, systems, and computer readable media for providing access network protocol interworking and authentication proxying
US10033736B2 (en) 2016-01-21 2018-07-24 Oracle International Corporation Methods, systems, and computer readable media for remote authentication dial-in user service (radius) topology hiding
US10374885B2 (en) * 2016-12-13 2019-08-06 Amazon Technologies, Inc. Reconfigurable server including a reconfigurable adapter device
US10691803B2 (en) 2016-12-13 2020-06-23 Amazon Technologies, Inc. Secure execution environment on a server
US11283883B1 (en) 2020-11-09 2022-03-22 Oracle International Corporation Methods, systems, and computer readable media for providing optimized binding support function (BSF) packet data unit (PDU) session binding discovery responses
US11558737B2 (en) 2021-01-08 2023-01-17 Oracle International Corporation Methods, systems, and computer readable media for preventing subscriber identifier leakage
US11888894B2 (en) 2021-04-21 2024-01-30 Oracle International Corporation Methods, systems, and computer readable media for mitigating network function (NF) update and deregister attacks
US11627467B2 (en) 2021-05-05 2023-04-11 Oracle International Corporation Methods, systems, and computer readable media for generating and using single-use OAuth 2.0 access tokens for securing specific service-based architecture (SBA) interfaces
US11570689B2 (en) 2021-05-07 2023-01-31 Oracle International Corporation Methods, systems, and computer readable media for hiding network function instance identifiers
US11638155B2 (en) 2021-05-07 2023-04-25 Oracle International Corporation Methods, systems, and computer readable media for protecting against mass network function (NF) deregistration attacks
US11695563B2 (en) 2021-05-07 2023-07-04 Oracle International Corporation Methods, systems, and computer readable media for single-use authentication messages

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1089524A2 (de) * 1999-10-01 2001-04-04 Web TV Networks Inc. System zur Unterstützung von mehreren Internet- Dienstanbietern in einem einzelnen Netz

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6614788B1 (en) * 1998-03-03 2003-09-02 Sun Microsystems, Inc. Network address management
US6374295B2 (en) * 1998-10-29 2002-04-16 Nortel Networks Limited Active server management
US6564216B2 (en) * 1998-10-29 2003-05-13 Nortel Networks Limited Server manager
US6427170B1 (en) * 1998-12-08 2002-07-30 Cisco Technology, Inc. Integrated IP address management
US6298383B1 (en) * 1999-01-04 2001-10-02 Cisco Technology, Inc. Integration of authentication authorization and accounting service and proxy service
ATE393513T1 (de) * 2000-03-20 2008-05-15 At & T Corp Verfahren und vorrichtung zur koordinierung der umschaltung des dienstanbieters zwischen einem client und einem server mit identitätsbasierter dienstzugangsverwaltung
JP2002033764A (ja) * 2000-07-14 2002-01-31 Fujitsu Ltd 通信サービス提供システム、並びに通信サービス提供システムにおいて使用される移動端末装置、アドレスサーバ装置、およびルータ装置
KR100350316B1 (ko) * 2000-08-28 2002-08-28 엘지전자 주식회사 에이에이에이 서버에 과부하 방지를 위한 접근요청 메시지처리 방법
US7197549B1 (en) * 2001-06-04 2007-03-27 Cisco Technology, Inc. On-demand address pools

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1089524A2 (de) * 1999-10-01 2001-04-04 Web TV Networks Inc. System zur Unterstützung von mehreren Internet- Dienstanbietern in einem einzelnen Netz

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
DROMS R ET AL: "- DHCP Failover Protocol", DHCP FAILOVER PROTOCOL, March 2000 (2000-03-01), XP002188657, Retrieved from the Internet <URL:http://www.globecom.net/ietf/draft/draft-ietf-dhc-failover-06.html> [retrieved on 20020130] *
MCAULEY A J ET AL: "Self-configuring networks", CONFERENCE PROCEEDINGS ARTICLE, vol. 1, 22 October 2000 (2000-10-22), pages 315 - 319, XP010532606 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7639681B2 (en) 2004-11-23 2009-12-29 Microsoft Corporation System and method for a distributed server for peer-to-peer networks
EP1659762A1 (de) * 2004-11-23 2006-05-24 Microsoft Corporation System und Methode für einen als verteiltes System implementierten Server zur Adressvergabe für ein Peer-to-Peer Netz
CN101141492B (zh) * 2005-04-29 2014-11-05 华为技术有限公司 实现dhcp地址安全分配的方法及系统
US9021100B1 (en) 2010-01-26 2015-04-28 Juniper Networks, Inc. Tunneling DHCP options in authentication messages
US8260902B1 (en) 2010-01-26 2012-09-04 Juniper Networks, Inc. Tunneling DHCP options in authentication messages
EP2369815A1 (de) * 2010-03-23 2011-09-28 Juniper Networks, Inc. Verwaltung verteilter Adressenpools in Netzwerkvorrichtungen
US8560658B2 (en) 2010-03-23 2013-10-15 Juniper Networks, Inc. Managing distributed address pools within network devices
US8631100B2 (en) 2010-07-20 2014-01-14 Juniper Networks, Inc. Automatic assignment of hardware addresses within computer networks
US8782211B1 (en) 2010-12-21 2014-07-15 Juniper Networks, Inc. Dynamically scheduling tasks to manage system load
CN104144123A (zh) * 2013-05-10 2014-11-12 中国电信股份有限公司 访问互联网的方法、系统与路由型网关装置
CN104144123B (zh) * 2013-05-10 2017-06-16 中国电信股份有限公司 访问互联网的方法、系统与路由型网关装置
US10992637B2 (en) 2018-07-31 2021-04-27 Juniper Networks, Inc. Detecting hardware address conflicts in computer networks
US10931628B2 (en) 2018-12-27 2021-02-23 Juniper Networks, Inc. Duplicate address detection for global IP address or range of link local IP addresses
US11165744B2 (en) 2018-12-27 2021-11-02 Juniper Networks, Inc. Faster duplicate address detection for ranges of link local addresses
US10965637B1 (en) 2019-04-03 2021-03-30 Juniper Networks, Inc. Duplicate address detection for ranges of global IP addresses
US11606332B1 (en) 2019-04-03 2023-03-14 Juniper Networks, Inc. Duplicate address detection for ranges of global IP addresses
US11909717B1 (en) 2019-04-03 2024-02-20 Juniper Networks, Inc. Duplicate address detection for ranges of global IP addresses

Also Published As

Publication number Publication date
CN1643879B (zh) 2010-09-29
CN1643879A (zh) 2005-07-20
PL372459A1 (en) 2005-07-25
EP1488611B1 (de) 2005-08-31
US20050235000A1 (en) 2005-10-20
DE50301105D1 (de) 2005-10-06
EP1488611A1 (de) 2004-12-22

Similar Documents

Publication Publication Date Title
EP1488611B1 (de) Aaa serversystem zur effizienten zugangskontrolle und adresszuordnung
DE69935138T2 (de) System und Verfahren zur Optimierung der Leistung und der Verfügbarkeit eines DHCP Dienstes
EP2826224B1 (de) Zugriff von clients auf einen serverdienst mittels einer opc-ua
DE60310676T2 (de) System und verfahren zum identifizieren eines drahtlosen versorgungsknotens für eine mobileinheit
EP1558002A1 (de) Verfahren zur Zuordnung einer IP-Adresse zu einem Gerät
DE10296969B4 (de) Verfahren und System zur automatischen Erkennung von IP-basierenden Netzwerkelementen
EP2037659A2 (de) Verfahren zur DHCP Server-Konfiguration unter Verwendung von DHCP Option 82
EP3059930A1 (de) Verfahren zur Konfiguration eines Kommunikationsgeräts eines industriellen Automatisierungssystems und Kommunikationsgerät
DE69916024T2 (de) Verfahren zur zuordnung von ip addressen an hostendgeräte im internet auf anfrage eines ursprungsendgeräts
DE102008036453A1 (de) Verfahren zum Versenden von Daten und Kommunikationseinrichtung
DE102005006889A1 (de) Verfahren zum Einrichten einer Kommunikationsbeziehung in zumindest einem Kommunikationsnetz
EP1155549A2 (de) Verfahren zum übertragen von ethernet-frames
EP1151591B1 (de) Datenzugriffs- und -verwaltungssystem sowie verfahren zum datenzugriff und zur datenverwaltung für ein rechnersystem
DE10393016B4 (de) Verfahren zur automatischen Netzwerkintegration
EP1081921B1 (de) Verfahren zur Vergabe von IP-Adressen in Kommunikationsnetzen
EP1195945B1 (de) Client, System und Verfahren zum Netzmanagement in einem Multiserver-Kommunikationsnetz
EP3622668B1 (de) Verfahren zum betreiben eines netzwerkes, bei dem eine anfrage per broadcast mittels des protokolls snmp ausgesendet wird
EP2800342A1 (de) Verfahren und System für ein zustandsabhängiges IP-Adressmanagement
EP1815665B1 (de) Verfahren zur bereitstellung einer adresse in einem daten-netzwerk
DE10046311B4 (de) Verfahren für eine Zuweisung von Knotennummern zu Netzknoten eines Netzwerks
EP1511272B1 (de) Verfahren zum Zuordnen von über mehrere Netzwerke verteilten Clients zu einem Server und Client zur Durchführung des Verfahrens
DE102020100870A1 (de) Redundante Speicherung der Konfiguration von Netzwerkgeräten unter Einbeziehung von Nachbarschaftsbeziehungen
EP1052802B1 (de) Verfahren zur Kopplung von NetBIOS Netzwerken und Rechnern
EP1098496A2 (de) Umgekehrte Maskierung fuer die Zugreifbarkeit auf Datenendstationen in privaten IPv4-Netzen
EP1415452B1 (de) Kopplungsmittel für eine datenverarbeitungsvorrichtung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN PL US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2003744761

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10509286

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 372459

Country of ref document: PL

WWE Wipo information: entry into national phase

Ref document number: 20038071665

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2003744761

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 2003744761

Country of ref document: EP