WO2007007007A2 - Systeme et procede d ' allocation de donnees de configuration au moyen du protocole dhcp - Google Patents

Systeme et procede d ' allocation de donnees de configuration au moyen du protocole dhcp Download PDF

Info

Publication number
WO2007007007A2
WO2007007007A2 PCT/FR2006/050704 FR2006050704W WO2007007007A2 WO 2007007007 A2 WO2007007007 A2 WO 2007007007A2 FR 2006050704 W FR2006050704 W FR 2006050704W WO 2007007007 A2 WO2007007007 A2 WO 2007007007A2
Authority
WO
WIPO (PCT)
Prior art keywords
dhcp
configuration data
request
servers
server
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.)
Ceased
Application number
PCT/FR2006/050704
Other languages
English (en)
Other versions
WO2007007007A3 (fr
Inventor
François BOURDAIS
Frédéric THERON
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.)
Orange SA
Original Assignee
France Telecom SA
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 France Telecom SA filed Critical France Telecom SA
Publication of WO2007007007A2 publication Critical patent/WO2007007007A2/fr
Publication of WO2007007007A3 publication Critical patent/WO2007007007A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • 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/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • 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/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4523—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using lightweight directory access protocol [LDAP]
    • 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/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Definitions

  • DHCP Dynamic Host Configuration Protocol
  • a DHCP server must meet a number of specifications and constraints to achieve efficient and flexible processing of different DHCP requests for obtaining configuration data that reaches it, such configuration data including at least one IP address (Internet Protocol ).
  • IP address Internet Protocol
  • a DHCP server must respond to these requests regardless of the address allocation mechanism among the three mechanisms provided by the DHCP protocol: permanent address allocation, static address allocation, or dynamic address allocation.
  • the role of a DHCP server is critical, especially in large networks, in which the DHCP server must be able to respond to requests from very different types of terminals: personal computer, IP phone (Internet Protocol), videophone, routers, home gateways, etc., which may have configuration requirements that vary from one type of terminal to another.
  • the DHCP server must therefore be able to quickly process DHCP requests from these different types of terminals.
  • DHCP client module Most of these terminals use their DHCP client module to obtain configuration data by the simplest mechanism to manage which is the dynamic allocation mechanism, and not by the static allocation mechanism. This implies for the DHCP server to implement a dynamic IP address generation process, this IP address being chosen from a set of possible addresses.
  • Recommendation RFC 2131 provides for the simultaneous use of multiple servers DHCP, as well as, the detection of possible inconsistencies between the configuration data allocated by two competing servers, particularly in the case of the dynamic IP address generation process.
  • each DHCP server locally stores all the configuration data that this server manages, including the address ranges corresponding to the addresses that this server can allocate. , as well as those that can be allocated by the other DHCP servers in the network. All of this configuration data is therefore stored redundantly on each of the DHCP servers in the network.
  • this protocol is named "Failover” (failover ) in the document entitled “DHCP Failover Protocol, Network Working Group, INTERNET DRAFT”, by Droms et al., dated January 2002.
  • a certain redundancy is provided between the DHCP servers: to a DHCP server, called primary server, are associated one or more DHCP servers, called secondary servers.
  • Each secondary server maintains a dialogue with the primary server during its operation.
  • a terminal issues a request
  • both the primary and secondary servers receive the request. If the secondary server finds by querying the primary server that it is able to respond, he lets it answer. If it does not receive a response from the primary server, it takes over and processes the request. When one of the two servers has processed the request, it informs the other server of the address allocation made.
  • the integrity of the allocated configuration data may be deficient in the event of a synchronization problem between the DHCP servers, for example in the event of a temporary failure of one of these servers or simply in case of a time out of one of the servers. two. It is therefore essential that the DHCP servers are constantly synchronized with each other to inform the other servers of the configuration data allocations made. Any problem of synchronization between the servers becomes critical because the same IP address may then be assigned to two different terminals.
  • each DHCP server that is configured as a secondary server must keep a specific IP address range in case the primary server associated with this secondary server stops responding and a new terminal appears to have to be processed by the primary. This involves provisioning at the secondary server a range of addresses constituting a pool of addresses for private use, used only in case of failure of the primary server by the secondary server. The result is often unnecessary use of addresses.
  • Another disadvantage of using the "Failover" protocol is that, when used in combination with the DHCP load sharing mechanism, described in RFC 3074, the mechanism by which each server determines whether to handle a request received by application of a hash function on a decoded parameter of the request to be processed, the servers do not cooperate effectively in the processing of the requests and the distribution of load between servers that results is not necessarily fair .
  • DHCP server In large networks, the availability of a DHCP server can be critical. Indeed the provision of configuration data to a large number of terminals in a limited time can be difficult to achieve.
  • the object of the invention is to provide a configuration data allocation solution, compatible with DHCP, applicable to networks comprising a large number of terminals and which makes it possible to solve the problems mentioned related to the use of the protocol. failover ".
  • the object of the invention is a system for the allocation, by means of the DHCP protocol, of configuration data to terminals interconnected to one another.
  • communication network comprising at least one database, capable of storing configuration data allocation lease management data, accessible by at least one DHCP server from among a plurality of DHCP servers interconnected to said communication network and configured to process DHCP requests issued by one of said terminals for obtaining configuration data, said database being in shared access by at least two DHCP servers of said plurality of DHCP servers, said database being capable of receiving from any of said at least two DHCP servers a query request for obtaining configuration data of a terminal, able to supply configuration data responding to said interrogation request and able to store configuration data allocation lease management data relating to the provided configuration data.
  • the system according to the invention makes it possible, by implementing a database shared by several DHCP servers and adapted to store configuration data allocation lease management data relating to the configuration data provided on demand. of these DHCP servers, to centrally manage the configuration data allocated by lease, according to the DHCP protocol. This eliminates the need to set up a "Failover" protocol between the DHCP servers accessing this centralized database to ensure consistency between the configuration data allocations processed at each of the servers. This results in a significant simplification of the process of data allocation and the process of communication between servers.
  • such a database is unique in a network or sub-network and is in shared access by all the DHCP servers of this network or this sub-network.
  • the management of this network or this sub-network is fully centralized and therefore managed independently of the number of DHCP servers required for this network or this subnet.
  • said database is designed to analyze the stored configuration data allocation lease management data to provide in response to said query request only configuration data that is consistent with the configuration data already allocated.
  • said database is designed to analyze the stored configuration data allocation lease management data to provide in response to said query request only configuration data that is consistent with the configuration data already allocated.
  • said interrogation request comprises at least part of the data of a DHCP request sent by a terminal for which said configuration data are to be generated.
  • said database is capable of supplying each of said at least two DHCP servers with communication parameters relating to the communication between this DHCP server and the database.
  • the database makes it possible to centrally manage the communication parameters between each of the DHCP servers and the database. This results in a simplification of the management of access to the database.
  • the addition of a new server is transparent for other servers.
  • said database is capable of supplying each of said at least two DHCP servers with parameters and processing rules defining processing to be performed on the DHCP requests received by this DHCP server.
  • the database can centrally and uniformly manage how DHCP servers handle requests. The changes made to the way DHCP servers handle queries are thus simple to manage.
  • the system according to the invention very simply allows the implementation of a load sharing mechanism.
  • said database is able to supply each of said at least two DHCP servers with at least one parameter (in particular hash key) determining the load allocated to this server.
  • the parameterization of the load sharing mechanism is handled in this embodiment centrally at the database level, the addition of a new server being completely transparent to the DHCP servers.
  • the system according to the invention comprises a distributing switch interconnected to said at least two DHCP servers, said switch receiving the DHCP requests intended for said at least two DHCP servers and being able, following receipt of a DHCP request, to select by means of a load sharing algorithm a DHCP server among said at least two DHCP servers and to transfer said DHCP request to said selected DHCP server.
  • the implementation of a load sharing mechanism is centrally managed at the switch level, the addition of a new server being completely transparent to the DHCP servers.
  • the subject of the invention is also a DHCP server interconnected to a communication network and able to process a DHCP request sent by a terminal to obtain configuration data, this server being able to access a first database whose access is shared with at least one other DHCP server interconnected to said communication network, able to send a query request to said database to obtain configuration data, and able to develop a response to said DHCP request according to the configuration data received from said database.
  • the DHCP server uses this database as a shared repository with other DHCP servers accessing it.
  • the DHCP server therefore no longer needs to deal locally with the consistency problem with other allocations made by these other servers, or to implement a protocol of "Failover" type.
  • it is able to interrogate a second database accessible locally by said DHCP server and adapted to answer a query request for the allocation of a static or permanent address , said DHCP server being designed to interrogate firstly said second database following the receipt of a DHCP request for the allocation of a static or permanent address. In this way, it is possible to optimize the query times of the database when the allocation process does not require immediate consistency checking by the centralized database.
  • the invention also relates to a method for allocating, by means of the DHCP protocol, configuration data to terminals interconnected to a communication network, this method being executed by a database whose access is shared by the at least two DHCP servers among a plurality of DHCP servers interconnected to said communication network and adapted to process DHCP requests transmitted by one of said terminals for obtaining configuration data, the method comprising the steps of receiving from any one of the at least two DHCP servers a query request for obtaining configuration data,
  • FIG. 1 schematically represents a communication network in which a system according to the invention is implemented
  • FIG. 2 diagrammatically represents a first example of a dialogue between different entities of the communication network of FIG. 1,
  • FIG. 3 diagrammatically represents a second example of dialogue between different entities of the communication network of FIG. 1.
  • IP terminal designates a terminal embedding a DHCP client.
  • IP terminal designates a terminal embedding a DHCP client.
  • FIG. 1 an embodiment of a system according to the invention will be described.
  • the system according to the invention applies to different versions of the DHCP protocol, especially to versions 4 and 6.
  • such a system is interconnected to a communication network 20.
  • this communication network 20 To this communication network 20 are also connected the following elements:
  • IP terminals for example an adapter box (Set Top Box) 10, a modem 11, a personal computer 12, a personal assistant 13, an IP telephone 14;
  • an adapter box Set Top Box 10
  • modem 11 for example, a modem 11, a personal computer 12, a personal assistant 13, an IP telephone 14;
  • DHCP servers 40, 41, 42, 43 forming a cluster 45 of servers,
  • the DHCP server is defined as the entity that hosts the DHCP request processing process as described in RFC 2131 except for the point of using a local database.
  • the DHCP server is attached to an independent entity, called a repository, dedicated to the management and storage of data related to the DHCP service.
  • the repository 50 is made in the form of a relational database, shared between several DHCP servers, and adapted for storing data related to the DHCP service, including configuration data allocation lease management data.
  • a repository is preferably redundant, for example using data replication mechanisms that are customary in the field of database management. In the invention, such mechanisms are completely transparent to DHCP servers.
  • the repository 50 is made in the form of a Lightweight Directory Access Protocol (LDAP).
  • LDAP Lightweight Directory Access Protocol
  • the repository is physically installed on a computer machine that hosts one of the DHCP servers, or on a dedicated machine.
  • the repository 50 is a permanent data storage system whose access is shared by several DHCP servers. It allows centralized management for these DHCP servers of data related to the DHCP service.
  • the repository is preferably unique for the DHCP servers of a given network or of several interconnected networks. The DHCP servers associated with the repository share access to this repository.
  • this repository is unique for a cluster of servers
  • each of the repositories of the network is preferably interconnected to a central repository that globally manages the configurations within an information system.
  • the system according to the invention thus counteracts the recommendation RFC 2131 which recommends using a local storage system. It eliminates the need for a consistency check protocol, type "Failover" and therefore eliminates the disadvantages associated with the use of such a protocol.
  • the principle underlying the invention is the decoupling between the process of processing DHCP requests and generating responses to these requests, implemented by each of the DHCP servers 40, 41, 42, 43 and the generation process, storage and management of configuration data related to the DHCP service, implemented implemented by the repository 50.
  • the repository 50 centrally implements the management of the consistency of the allocated configuration data, the DHCP servers being unloaded from this function.
  • the system according to the invention allows the implementation of a simple and efficient mechanism of load sharing between the DHCP servers associated with the same repository.
  • the DHCP service related data that is stored and managed by the repository is as follows:
  • configuration data allocated to the terminal these data representing as a whole a state at a given time of the allocation of the configuration data for the various IP terminals of the network, or of a portion of the managed network by this reference;
  • configuration data allocation lease management data for each IP terminal, configuration data allocation lease management data; the set of allocatable configuration data managed by the repository, notably comprising the address ranges corresponding to the addresses that this repository can allocate.
  • the repository 50 furthermore comprises data relating to the DHCP relays of the network, describing for each type of relay present in the network, the format and mode of encoding of the data that it inserts into the queries of the client terminals qu it conveys.
  • each relay encodes information with proprietary formatting in the sub-options of a query.
  • the same information (for example the customer line identifier or CLID) may, depending on the relay, be encoded in different sub-options (DHCP option 82 "remote id" or "circuit id” sub-options). ) or be encoded in the same sub-option but in a different format.
  • the repository 50 must therefore contain the information on the type of relay and the way it encodes information such as the CLID which is useful for the allocation of configuration data, so as to be able to decode this information and use a neutral format. storage of this information.
  • Configuration data allocation lease management data including in particular an identifier of the terminal concerned by the lease, the status (for example "expired” or “released” or “reserved” or other) of the lease, its start time and its estimated duration, also the end time if the lease has expired or has been released by a terminal. This data also includes all or part of the configuration data associated with the lease.
  • the configuration data associated with the lease can be accessed in a separate table indexed for example by the identifier of the terminal ("client identifier" option of the DHCP protocol) or by the allocated IP address or by another parameter.
  • client identifier option of the DHCP protocol
  • Other storage modes based on a relational schema of the data stored in the repository 50, are also conceivable.
  • the configuration data of the IP terminals comprises the configuration data allocated to a terminal, in particular its IP address. These data are stored for each terminal corresponding to an identifier of the terminal, this identifier being for example the MAC address of the terminal. Preferably, any other information relating to a terminal, which is likely to be present in one of the options of a DHCP request and necessary for the process of allocating configuration data for this terminal, is also stored correlatively to a Terminal ID.
  • the communication parameters are stored appropriately to be loaded by each of the DHCP servers at startup. They include the communication port identifiers used in the repository dialog, the IP address of the repository or machine that hosts the repository, the associated server user account, and the associated password for accessing the repository.
  • the parameters and processing rules are stored appropriately to be loaded by each of the DHCP servers at startup. They include rules for identifying DHCP requests to be applied to each request by the DHCP server, as well as the parameters associated with these rules.
  • a DHCP request identification rule is a regular expression composed of mathematical operators (including logical operators and / or arithmetic operators) applying to data contained in the fields and options of the DHCP request, in particular to the MAC address.
  • the first step of the process of processing by a DHCP server 40, 41, 42, 43 is to compare the result of the identification rule to the DHCP frame with the list of expected results. If the result is Negative, the server ignores the request and does not respond.
  • the request processing process proceeds to the next step of generating a query query of the repository 50 to obtain an IP address and other configuration parameters compatible with the rule of return. identification corresponding to the IP terminal issuing the request.
  • the query request formulated by the server to the repository 50 preferably includes all or part of the data (option fields and / or frame) of the DHCP request to which it relates and which is being processed by the server.
  • Other parameters specific to the communication between the server and the repository may optionally be provided as an option for processing the request, so as to ask the repository for additional actions or information.
  • the repository 50 does not respond to the query request in a given time, it is advantageously expected that the server sends the same query to a queries repository (the slave repository associated with the master repository).
  • the repository 50 If the repository 50 does not find configuration data responding to the query request, it sends a predefined response to the server. In this case, the server ignores the DHCP request and does not respond.
  • the repository 50 analyzes the stored configuration data allocation lease management data to provide in response to the query only configuration data that is consistent with the already allocated configuration data. This analysis consists in checking the state of the lease relating to the terminal issuing the DHCP request if this lease exists, to check if there is unallocated configuration data that responds to the interrogation request if this lease does not exist. not exist, to check if no other current lease conflicts with the request issued by the terminal, etc. If the repository can not provide such configuration data, it sends a predefined response, for example, signaling a refusal to reply to the server or notifying the server of a consistency problem, or asking it to re-issue a request or asking it to restart the server. terminal (for example by sending a "DHCP NACK" message by the DHCP server to the IP terminal), etc.
  • the repository 50 finds configuration data responsive to the query request, it sends a response to the DHCP server including this data of configuration, and records configuration data allocation lease management data relating to the allocation made on these configuration data, so that another server can not allocate them in turn.
  • This data includes in particular the allocated IP address, the MAC address of the terminal sending the request, the "client identifier" field of this request.
  • the servers are connected to the network by a switch 30 or packet switching equipment.
  • the switch 30 sends the data packets comprising the DHCP requests to each of the DHCP servers that are interconnected to it. This broadcast is done in "broadcast” mode (broadcast, a message to several recipients) or in "unicast” mode (individual broadcast, one message per recipient).
  • the equipment used is an Ethernet switch (usually called “L2 switch”).
  • the switch 30 distributes the packets equitably between the servers, according to a load distribution mechanism implemented by the switch.
  • the equipment used is a load balancing switch (commonly called "L4 switch").
  • variant C no switch is necessary, the terminals and the DHCP relays emitting their DHCP request in "anycast" mode, that is to say to an IP address anycast, the router d access that sends the request to the DHCP server closest to the access router.
  • each server implements a load distribution mechanism. All servers receive requests broadcast in broadcast mode, but each of the servers in the server cluster associated with the switch processes only the portion of the load assigned to it.
  • the load balancing algorithm is for example the mechanism provided in the RFC 3074. It is based on a terminal identifier, this identifier generally comprising the MAC address, Media Access Control, which is unique for each terminal and is transmitted. with each DHCP request, via the DHCP option named "Client Identifier".
  • a load sharing identifier is further assigned to each DHCP server as a hash key.
  • This mechanism is as follows: When multiple DHCP servers receive a request, each server uses a hash function applied to the MAC address of the terminal to determine, based on the result of the hash function and a predefined distribution rule. load, whether it is up to him or not to process the request. This predefined load balancing rule is to compare the result of the hash function with the load share identifier assigned to that server. In this way, each time a given terminal sends a request, it is always the same server that processes this request.
  • the repository which includes a program for determining the hash function used and / or the load sharing identifier of the servers.
  • the load distribution is centrally controlled at the repository level.
  • the load sharing identifier of a server is stored by the repository with the processing parameters associated with this server. This parameter, determining the load allocated to this server, is transmitted by the repository 50 to this server or loaded by this server when it starts.
  • Figure 2 is an illustration of a data exchange implemented in the variant embodiment. In this data exchange the following steps are performed:
  • a terminal for example the terminal 10, sends a DHCP DISCOVER request to one of the DHCP relays, for example the DHCP relay 25; - the DHCP relay 25 transfer 202 the DHCP DISCOVER request to the switch
  • each of the servers determines, according to the identifier of the terminal transmitted in the DHCP DISCOVER request, whether or not to process this request; suppose for example that it is the server 40 which is responsible for processing this request;
  • the server 40 performs, in particular by applying the identification rules, a check of the integrity of the request then sends 204 an interrogation request to the repository to obtain configuration data making it possible to respond to the request.
  • DHCP DISCOVER request this request preferably comprising the data of the DHCP DISCOVER request;
  • the repository returns 205 a response to the server 40;
  • the server 40 elaborates the response to the DHCP DISCOVER request in the form of a DHCP OFFER request and sends this request to the DHCP relay 25;
  • the DHCP relay transfer 207 then the DHCP OFFER request to the terminal 10;
  • the terminal 10 sends 21 1 a DHCP REQUEST request which is intercepted by the DHCP relay 25;
  • the DHCP relay 25 transfers the DHCP request REQUEST to the switch 30;
  • each of the servers determines, according to the identifier of the terminal transmitted in the DHCP request, whether or not to process the request; as for the previous request sent by the terminal 10, the server 40 is responsible for processing this request;
  • the server 40 performs, in particular by applying the identification rules, a check of the integrity of the request then sends 214 a query request to the repository, to obtain configuration data for responding to the DHCP request REQUEST ;
  • the repository 50 returns 215 a response to the server 40;
  • the server 40 elaborates the response to the DHCP request REQUEST in the form of a DHCP ACK request and sends this request to the DHCP relay 25;
  • the transfer DHCP relay 217 then the ACK DHCP request to the terminal 10; the terminal 10 issues a DHCP REQUEST RENEW request to the server 40 having responded to its previous REQUEST DHCP request;
  • the server 40 sends 222 then an interrogation request to the repository to obtain configuration data making it possible to respond to the DHCP request REQUEST RENEW; the repository 50 returns 223 a response to the server 40;
  • the server 40 elaborates the response to the DHCP request REQUEST RENEW in the form of a DHCP ACK request and sends this request to the terminal 10;
  • the terminal 10 sends 231 a DHCP RELEASE request to the server 40 having responded to its previous DHCP REQUEST RENEW request; the server 40 sends 232 an instruction to the repository to signal to it the end the configuration data allocation procedure for this terminal;
  • the repository 50 then records information indicating this end of the allocation procedure.
  • the load balancer distributes the requests between the DHCP servers according to the load.
  • the servers therefore do not need to implement a DHCP load sharing algorithm, because, seen from the client, they form globally a single DHCP server, each server responding by setting the same IP address in the field of "server identifier" option, thus posing as a single DHCP server.
  • different servers can handle queries issued by the same client for the same transaction, through the combined use of the dispatcher and the database serving as a common configuration repository. From the network, the presence of several physical DHCP servers is masked by the presence of the dispatcher, the set of physical DHCP servers forming a single logical server.
  • the DHCP mechanism is adapted so that the IP terminals see the DHCP servers as a single server, by sending, in response to a DHCP request, a virtual IP address to the terminal by using the DHCP protocol option. named "server identifier", so that the terminal uses this virtual IP address for subsequent requests.
  • server identifier so that the terminal uses this virtual IP address for subsequent requests.
  • DHCP is inserted in the server cluster, it is not necessary to change the configuration of the servers: the change is in this case completely transparent.
  • the dispatcher determines a new distribution of the load according to the number of operational servers.
  • the common virtual IP address for the servers associated with a repository is preferably stored in the repository and provided to the servers by the repository. It is, for example, part of the parameters loaded by each of the servers at startup.
  • the variant B is therefore particularly interesting from the point of view of load distribution and fault tolerance of the servers, while being fully compatible with the services and communication mechanisms of the DHCP protocol.
  • FIG. 3 is an illustration of a data exchange implemented in variant B embodiment.
  • a terminal for example the terminal 10, sends a DHCP DISCOVER request to one of the DHCP relays, for example the DHCP relay 25;
  • the DHCP relay 25 transfers the DHCP DISCOVER request to the switch 30; the transfer switch 303 this same DHCP DISCOVER request to one of the servers, for example to the server 40, this server being selected according to a load distribution algorithm implemented by the switch;
  • the server 40 performs, in particular by applying the identification rules, a check of the integrity of the request then sends 304 an interrogation request to the repository to obtain configuration data making it possible to respond to the DHCP DISCOVER request;
  • the repository 305 returns a response to the server 40;
  • the server 40 elaborates the response to the DHCP DISCOVER request in the form of a DHCP OFFER request and sends this request to the DHCP relay 25; the DHCP relay transfer 307 then the DHCP OFFER request to the terminal 10;
  • the terminal 10 sends 31 1 a DHCP REQUEST request which is intercepted by the DHCP relay 25;
  • the DHCP relay transfers the DHCP REQUEST request to the switch 30; the transfer switch 313 this same DHCP DISCOVER request to one of the servers, for example to the server 41, this server being selected according to a load distribution algorithm implemented by the switch;
  • the server 41 processes the request: it performs, in particular by applying the identification rules, a check of the integrity of the request then sends 314 an interrogation request to the repository to obtain configuration data making it possible to respond to the request.
  • DHCP DISCOVER request ;
  • the repository returns 315 a response to the server 40;
  • the server 41 elaborates the response to the DHCP request REQUEST in the form of a DHCP ACK request and sends this request to the DHCP relay 25; the transfer DHCP relay 317 then the ACK DHCP request to the terminal 10;
  • the terminal 10 sends 321 a DHCP REQUEST RENEW request to the server 41 having responded to its previous REQUEST DHCP request;
  • the server 41 then sends 322, if necessary, an interrogation request to the repository for obtaining configuration data making it possible to respond to the DHCP request REQUEST RENEW; the repository 50 returns 323 a response to the server 40;
  • the server 40 elaborates the response to the DHCP request REQUEST RENEW in the form of a DHCP ACK request and sends this request to the terminal 10;
  • the terminal 10 sends 331 a DHCP RELEASE request to the server 40 having responded to its previous DHCP REQUEST RENEW request;
  • the server 40 sends 332 an instruction to the repository to signal to it the end of the configuration data allocation procedure for this terminal;
  • the repository 50 then records information indicating this end of the allocation procedure.
  • the repository 50 is partially redundant at each of the DHCP servers associated with it: the part of the database relating to the configuration data of the IP terminals of the network for which a static or permanent address is allocated is duplicated at each DHCP server.
  • a second database is thus constituted which is a replica of a subset of the repository.
  • a server can firstly interrogate this second database to respond directly, without querying the repository 50, to a static or permanent address request.
  • This address allocation mode does not generate coherence problems because the response to a request is unique.
  • This embodiment reduces the response time to this type of request.
  • a mechanism is provided to warn the repository of such allocation, which mechanism preferably runs at a time when the server load permits.
  • the availability of the configuration data generation service is maximum: a change, made at the level of the repository, of the processing parameters associated with the servers (in particular load identifiers), is transparent for the servers and therefore for the process of processing DHCP requests by the servers. Adding or stopping a server in the server cluster does not affect the availability of the service.
  • the system according to the invention is perfectly robust, does not require the establishment of synchronization mechanism between servers and does not present the malfunctions related to the current "Failover" protocol. It is no longer necessary to implement a process of consistency between the servers. This results in simplification and high performance of the configuration data generation service.
  • the invention thus proposes a new solution for configuration data management that is compatible with DHCP and better suited to availability, robustness and performance constraints that are critical in network deployment including a high number of IP terminals.
  • a repository such as a database or an LDAP directory facilitates the integration of the DHCP solution in an information system that provides network configuration and supervision operations.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Système pour l'allocation, au moyen du protocole DHCP, de données de configuration à des terminaux interconnectés à un réseau de communication, comprenant au moins une base de données, apte à stocker au moins une partie des données de configuration allouées, accessible par au moins un serveur DHCP parmi une pluralité de serveurs DHCP interconnectés audit réseau de communication et conçus pour traiter les requêtes DHCP émises par l'un desdits terminaux en vue de l'obtention de données de configuration, la base de données étant en accès partagé par au moins deux serveurs DHCP de ladite pluralité de serveurs DHCP, apte à recevoir de l'un quelconque des deux serveurs DHCP une requête d'interrogation pour l'obtention de données de configuration d'un terminal, apte à fournir des données de configuration en réponse à la requête d'interrogation et apte à stocker des données de gestion de bail d'allocation relatives aux données de configuration générées.

Description

Système et procédé d'allocation de données de configuration au moyen du protocole DHCP
L'invention concerne un système et procédé d'allocation de données de configuration au moyen du protocole DHCP.
Dans le protocole DHCP (Dynamic Host Configuration Protocole), notamment dans la recommandation RFC 2131 (Request For Comment 2131 , http://www.ietf.org/rfc/rfc2131.txt?number=2131 ) disponible auprès de l'organisme IETF (Internet Engineering Task Force), sont décrits différents mécanismes de traitement par des serveurs DHCP de requêtes DHCP pour l'obtention de données de configuration.
Un serveur DHCP doit répondre à un certain nombre de spécifications et contraintes pour parvenir à un traitement efficace et flexible des différentes requêtes DHCP pour l'obtention de données de configuration qui lui parviennent, ces données de configuration comprenant au moins une adresse IP (Internet Protocol).
Un serveur DHCP doit répondre à ces requêtes quel que soit le mécanisme d'allocation d'adresse parmi les trois mécanismes prévus par le protocole DHCP: allocation d'adresse permanente, allocation d'adresse statique, ou allocation d'adresse dynamique. De plus, le rôle d'un serveur DHCP est critique, particulièrement dans les réseaux de grande taille, dans lesquels le serveur DHCP doit être capable de répondre à des requêtes en provenance de terminaux de types très différents: ordinateur personnel, téléphone IP (Internet Protocol), visiophone, routeurs, passerelles domestiques, etc, susceptibles d'avoir des besoins en configuration variables d'un type de terminal à l'autre. Le serveur DHCP doit donc être capable de traiter rapidement des requêtes DHCP issues de ces différents types de terminaux.
La plupart de ces terminaux utilisent leur module client DHCP pour obtenir des données de configuration par le mécanisme le plus simple à gérer qui est le mécanisme d'allocation dynamique, et non par le mécanisme d'allocation statique. Ceci implique pour le serveur DHCP de mettre en œuvre un processus de génération d'adresse IP dynamique, cette adresse IP étant choisie parmi un ensemble d'adresses possibles.
Pour des raisons de redondance et de disponibilité du service de configuration
DHCP, il n'est pas réaliste de faire reposer ce service sur un seul serveur DHCP. La recommandation RFC 2131 prévoit donc l'utilisation simultanée de plusieurs serveurs DHCP, ainsi que, la détection d'incohérences possibles entre les données de configuration allouées par deux serveurs concurrents, notamment dans le cas du processus de génération d'adresse IP dynamique.
Dans ce but, il est prévu, notamment dans la recommandation RFC 2131 , un mode de réalisation dans lequel chaque serveur DHCP stocke localement toutes les données de configuration que ce serveur gère, notamment les plages d'adresses correspondant aux adresses que ce serveur peut allouer, ainsi que celles pouvant être allouées par les autres serveurs DHCP du réseau. Toutes ces données de configuration sont donc stockées de manière redondante sur chacun des serveurs DHCP du réseau.
Pour garantir la cohérence entre les allocations - notamment les allocations dynamiques - effectuées par les différents serveurs DHCP, il est nécessaire de mettre en oeuvre un protocole de communication entre les serveurs DHCP d'un même réseau : ce protocole est nommé "Failover" (basculement) dans le document intitulé "DHCP Failover Protocol, Network Working Group, INTERNET DRAFT", par Droms et al., daté de janvier 2002.
Selon ce protocole, il est prévu une certaine redondance entre les serveurs DHCP: à un serveur DHCP, dit serveur primaire, sont associés un ou plusieurs serveurs DHCP, dit serveurs secondaires. Chaque serveur secondaire maintient un dialogue avec le serveur primaire au cours de son fonctionnement. Lorsqu'un terminal émet une requête, les deux serveurs primaire et secondaire reçoivent la requête. Si le serveur secondaire constate en interrogeant le serveur primaire que celui-ci est en état de répondre, il le laisse répondre. S'il ne reçoit pas de réponse de la part du serveur primaire, il prend sa relève et traite la requête. Lorsque l'un des deux serveurs a traité la requête, il informe l'autre serveur de l'allocation d'adresse effectuée.
L'intégrité des données de configuration allouées peut être déficiente dans le cas où un problème de synchronisation entre les serveurs DHCP apparaît, par exemple en cas de panne temporaire de l'un de ces serveurs ou simplement en cas de désynchronisation horaire de l'un d'eux. Il est donc indispensable que les serveurs DHCP soient en permanence synchronisés entre eux pour informer les autres serveurs des allocations de données de configuration effectuées. Tout problème de synchronisation entre les serveurs devient critique car une même adresse IP risque alors d'être attribuée à deux terminaux différents. De plus, chaque serveur DHCP qui est configuré en serveur secondaire doit conserver une plage d'adresses IP spécifique pour le cas où le serveur primaire associé à ce serveur secondaire ne répond plus et qu'un nouveau terminal apparaît devrant être traité par le primaire. Ceci suppose de provisionner au niveau du serveur secondaire une plage d'adresses constituant une réserve d'adresses à usage privé, utilisée uniquement en cas de panne du serveur primaire par le serveur secondaire. Il en résulte une consommation souvent inutile d'adresses.
Un autre inconvénient lié à l'utilisation du protocole "Failover" est que, lorsqu'il est utilisé en combinaison avec le mécanisme de partage de charge DHCP, décrit dans la recommandation RFC 3074, mécanisme selon lequel chaque serveur détermine s'il doit traiter une requête reçue par application d'une fonction de hachage sur un paramètre décodé de la requête à traiter, les serveurs ne coopèrent pas de manière efficace dans le traitement des requêtes et la répartition de charge entre serveurs qui en résulte n'est pas forcément équitable.
Par conséquent, bien qu'il traite le problème de disponibilité du service, l'utilisation du protocole "Failover" présente des inconvénients patents. De plus l'augmentation du nombre de serveurs DHCP entraîne une augmentation du trafic de synchronisation entre serveurs, ce qui pénalise les performances globales du service de traitement des requêtes DHCP au lieu de l'améliorer.
Dans les réseaux de grande taille, la disponibilité d'un serveur DHCP peut s'avérer critique. En effet la fourniture de données de configuration à un nombre important de terminaux en un temps limité peut être difficile à réaliser.
Il est donc nécessaire de mettre en place des solutions pour que le ou les serveurs DHCP s'adaptent de manière transparente au nombre de terminaux à gérer. Cette adaptation au nombre de terminaux peut se faire soit par un déploiement d'un nombre important de serveurs DHCP, soit par une mise à jour matérielle des serveurs existant de manière à augmenter leur capacité de traitement, par exemple par augmentation du nombre de processeurs ou ajout de mémoire vive. Toutefois ces solutions ne permettent pas de résoudre les problèmes d'incohérence d'allocation d'adresses dynamiques liés à un défaut de synchronisation entre serveurs. L'invention a pour but de fournir une solution d'allocation de données de configuration, compatible avec le protocole DHCP, applicable à des réseaux comportant un nombre important de terminaux et qui permette de résoudre les problèmes cités liés à l'utilisation du protocole "Failover".
Dans ce but, l'invention a pour objet un système pour l'allocation, au moyen du protocole DHCP, de données de configuration à des terminaux interconnectés à un réseau de communication, le système comprenant au moins une base de données, apte à stocker des données de gestion de bail d'allocation de données de configuration, accessible par au moins un serveur DHCP parmi une pluralité de serveurs DHCP interconnectés audit réseau de communication et conçus pour traiter les requêtes DHCP émises par l'un desdits terminaux en vue de l'obtention de données de configuration, ladite base de données étant en accès partagé par au moins deux serveurs DHCP de ladite pluralité de serveurs DHCP, ladite base de données étant apte à recevoir de l'un quelconque desdits au moins deux serveurs DHCP une requête d'interrogation pour l'obtention de données de configuration d'un terminal, apte à fournir des données de configuration répondant à ladite requête d'interrogation et apte à stocker des données de gestion de bail d'allocation de données de configuration relatives aux données de configuration fournies.
Le système selon l'invention permet, par la mise en œuvre d'une base de données partagée par plusieurs serveurs DHCP et adaptée pour stocker des données de gestion de bail d'allocation de données de configuration relatives aux données de configuration fournies à la demande de ces serveurs DHCP, de gérer de manière centralisée les données de configuration allouées par bail, conformément au protocole DHCP. Ceci supprime la nécessité de mettre en place un protocole de type "Failover" entre les serveurs DHCP accédant à cette base de données centralisée pour garantir la cohérence entre les allocations de données de configuration traitées au niveau de chacun des serveurs. Il en résulte une simplification importante du processus d'allocation de données et du processus de communication entre serveurs.
Avantageusement, une telle base de données est unique dans un réseau ou sous-réseau et est en accès partagé par tous les serveurs DHCP de ce réseau ou de ce sous-réseau. De cette manière, la gestion de ce réseau ou de ce sous-réseau est entièrement centralisée et donc gérée indépendamment du nombre de serveurs DHCP nécessaires pour ce réseau ou de ce sous-réseau.
Dans une variante du système selon l'invention, ladite base de donnée est conçue pour analyser les données de gestion de bail d'allocation de données de configuration stockées pour ne fournir en réponse à ladite requête d'interrogation que des données de configuration qui soient cohérentes avec les données de configuration déjà allouées. De cette manière, la gestion de cohérence entre les demandes d'allocation de données de configuration traitées au niveau de chacun des serveurs est simplifiée car centralisée. Il n'y a plus de risque d'incohérence en cas de panne d'un serveur DHCP ou de désynchronisation horaire de l'un par rapport à l'autre.
Dans une variante du système selon l'invention, ladite requête d'interrogation comprend au moins une partie des données d'une requête DHCP émise par un terminal pour lequel lesdites données de configuration sont à générer. De cette manière, la communication entre la base de données est simple à mettre en œuvre, le serveur ayant la possibilité de constituer simplement le contenu de la requête d'interrogation à partir du contenu de la requête DHCP qu'il traite.
Dans une variante du système selon l'invention, ladite base de données est apte à fournir à chacun desdits au moins deux serveurs DHCP, des paramètres de communication relatifs à la communication entre ce serveur DHCP et la base de données. De cette manière, la base de données permet de gérer de manière centralisée les paramètres de communication entre chacun des serveurs DHCP et la base de données. Il en résulte une simplification de la gestion des accès à la base de données. De plus l'ajout d'un nouveau serveur est transparent pour les autres serveurs.
Dans une variante du système selon l'invention, ladite base de données est apte à fournir à chacun desdits au moins deux serveurs DHCP, des paramètres et règles de traitement définissant des traitements à effectuer sur les requêtes DHCP reçues par ce serveur DHCP. De cette manière, la base de données permet de gérer de manière centralisée et uniforme la manière dont les serveurs DHCP vont traiter les requêtes. Les évolutions apportées à la manière dont les serveurs DHCP traitent les requêtes sont ainsi simples à gérer.
Le système selon l'invention permet très simplement la mise en œuvre d'un mécanisme de partage de charge.
Selon un premier mode de réalisation du système selon l'invention, ladite base de données est apte à fournir à chacun desdits au moins deux serveurs DHCP au moins un paramètre (notamment clef de hachage) déterminant la charge attribuée à ce serveur. La paramétrisation du mécanisme de partage de charge est gérée dans ce mode de réalisation de manière centralisée au niveau de la base de données, l'ajout d'un nouveau serveur étant complètement transparente pour les serveurs DHCP.
Selon un deuxième mode de réalisation, le système selon l'invention comprend un commutateur répartiteur interconnecté auxdits au moins deux serveurs DHCP, ledit commutateur recevant les requêtes DHCP destinées auxdits au moins deux serveurs DHCP et étant apte, suite à la réception d'une requête DHCP, à sélectionner au moyen d'un algorithme de partage de charge un serveur DHCP parmi lesdits au moins deux serveurs DHCP et à transférer ladite requête DHCP audit serveur DHCP sélectionné. Dans ce mode de réalisation, la mise en œuvre d'un mécanisme de partage de charge est gérée de manière centralisée au niveau du commutateur, l'ajout d'un nouveau serveur étant complètement transparente pour les serveurs DHCP.
L'invention a également pour objet un serveur DHCP interconnecté à un réseau de communication et apte à traiter une requête DHCP émise par un terminal pour l'obtention de données de configuration, ce serveur étant apte à accéder à une première base de données dont l'accès est partagé avec au moins un autre serveur DHCP interconnecté audit réseau de communication, apte à envoyer une requête d'interrogation à ladite base de données pour obtenir des données de configuration, et apte à élaborer une réponse à ladite requête DHCP en fonction des données de configuration reçues de ladite base de données.
Le serveur DHCP utilise cette base de données comme un référentiel partagé avec les autres serveurs DHCP y accédant. Le serveur DHCP n'a donc plus besoin de traiter localement de problème de cohérence avec d'autres allocations effectuées par ces autres serveurs, ni de mettre en œuvre un protocole de type "Failover". Dans une variante du serveur DHCP selon l'invention, celui-ci est apte à interroger une deuxième base de données accessible localement par ledit serveur DHCP et adaptée pour répondre à une requête d'interrogation pour l'allocation d'une adresse statique ou permanente, ledit serveur DHCP étant conçu pour interroger prioritairement ladite deuxième base de données suite à la réception d'une requête DHCP pour l'allocation d'une adresse statique ou permanente. De cette manière, il est possible d'optimiser les temps d'interrogation de la base de données lorsque le processus d'allocation ne demande pas de vérification immédiate de cohérence par la base de données centralisée.
L'invention a également pour objet un procédé d'allocation, au moyen du protocole DHCP, de données de configuration à des terminaux interconnectés à un réseau de communication, ce procédé étant exécuté par une base de données dont l'accès est partagé par au moins deux serveurs DHCP parmi une pluralité de serveurs DHCP interconnectés audit réseau de communication et conçus pour traiter les requêtes DHCP émises par l'un desdits terminaux en vue de l'obtention de données de configuration, le procédé comprenant les étapes consistant à, - recevoir de l'un quelconque desdits au moins deux serveurs DHCP une requête d'interrogation pour l'obtention de données de configuration,
- fournir des données de configuration en réponse à ladite requête d'interrogation, - stocker des données de gestion de bail d'allocation de données de configuration relatives aux données de configuration fournies.
Les avantages énoncés pour le système selon l'invention sont transposables à ce procédé.
D'autres buts, caractéristiques et avantages de l'invention apparaîtront à travers la description qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite par référence aux dessins annexés sur lesquels:
- la figure 1 représente schématiquement un réseau de communication dans lequel est mis en oeuvre un système selon l'invention,
- la figure 2 représente schématiquement un premier exemple de dialogue entre différentes entités du réseau de communication de la figure 1 ,
- la figure 3 représente schématiquement un deuxième exemple de dialogue entre différentes entités du réseau de communication de la figure 1 .
Dans la suite de ce document, le terme "terminal IP" désigne un terminal embarquant un client DHCP. En référence avec la figure 1 , on va décrire un mode de réalisation d'un système selon l'invention. Le système selon l'invention s'applique à différentes versions du protocole DHCP, notamment aux versions 4 et 6.
Comme représenté à la figure 1 , un tel système est interconnecté à un réseau de communication 20. A ce réseau de communication 20 sont également connectés les éléments suivants:
- plusieurs terminaux IP, par exemple un boîtier adaptateur (en anglais "Set Top Box") 10, un modem 1 1 , un ordinateur personnel 12, un assistant personnel 13, un téléphone IP 14;
- plusieurs relais DHCP 25, 26, 27, 28, - un commutateur 30,
- plusieurs serveurs DHCP 40, 41 , 42, 43 formant une grappe 45 de serveurs,
- un référentiel 50 de gestion et de stockage de données liées au service DHCP,
- un système d'information 60 dédié par exemple à la gestion du réseau d'entreprise. Le serveur DHCP est définit comme l'entité qui héberge le processus de traitement des requêtes DHCP tel que décrit dans la RFC 2131 excepté sur le point de l'utilisation d'une base de données locale. Dans l'invention, le serveur DHCP est attaché à une entité indépendante, appelée référentiel, dédiée à la gestion et au stockage des données liées au service DHCP.
Le référentiel 50 est réalisé sous la forme d'une base de données relationnelle, mutualisée entre plusieurs serveurs DHCP, et adaptée pour le stockage de données liées au service DHCP, notamment des données de gestion de bail d'allocation de données de configuration. Un tel référentiel est de préférence redondé, par exemple en utilisant des mécanismes de réplication de données qui sont usuels dans le domaine de la gestion de base de données. Dans l'invention, de tels mécanismes sont complètement transparents pour les serveurs DHCP.
Selon une variante, le référentiel 50 est réalisé sous la forme d'un annuaire LDAP (Lightweight Directory Access Protocol). Le référentiel est physiquement installé sur une machine informatique qui héberge un des serveurs DHCP, ou bien sur une machine dédiée.
Le référentiel 50 est un système de stockage permanent de données dont l'accès est partagé par plusieurs serveurs DHCP. Il permet la gestion centralisée pour ces serveurs DHCP des données liées au service DHCP. Le référentiel est de préférence unique pour les serveurs DHCP d'un réseau donné ou de plusieurs réseaux interconnectés entre eux. Les serveurs DHCP associés au référentiel partagent l'accès à ce référentiel.
Selon une variante, ce référentiel est unique pour une grappe de serveurs
DHCP donnée, plusieurs grappes de serveurs étant définies au sein du réseau. Dans cette variante, chacun des référentiels du réseau est de préférence interconnecté à un référentiel central qui gère globalement les configurations au sein d'un système d'information.
Le système selon l'invention prend ainsi à contre-pied la recommandation RFC 2131 qui préconise d'utiliser un système de stockage local. Il supprime la nécessité d'un protocole de contrôle de cohérence, de type "Failover" et donc supprime les inconvénients liés à l'utilisation d'un tel protocole.
Le principe sous-jacent à l'invention est le découplage entre le processus de traitement des requêtes DHCP et de génération des réponses à ces requêtes, mis en œuvre par chacun des serveurs DHCP 40, 41 , 42, 43 et le processus de génération, stockage et gestion des données de configuration liées au service DHCP, mis en œuvre par le référentiel 50. Le référentiel 50 met en oeuvre de manière centralisée la gestion de la cohérence des données de configuration allouées, les serveurs DHCP étant déchargés de cette fonction.
De plus, comme décrit plus en détail plus loin, le système selon l'invention permet la mise en oeuvre d'un mécanisme simple et efficace de partage de charge entre les serveurs DHCP associés à un même référentiel.
Les données liées au service DHCP qui sont stockées et gérées par le référentiel sont les suivantes :
- pour chaque serveur DHCP, des paramètres de communication pour la communication entre ce serveur DHCP et le référentiel;
- pour chaque serveur DHCP, des paramètres et règles de traitement, définissant certains des traitements effectués sur les requêtes DHCP par ce serveur DHCP;
- pour chaque terminal IP, des données de configuration allouées au terminal, ces données représentant dans leur ensemble un état à un instant donné de l'allocation des données de configuration pour les différents terminaux IP du réseau, ou d'une partie de réseau gérée par ce référentiel;
- pour chaque terminal IP, des données de gestion de bail d'allocation de données de configuration; - l'ensemble des données de configuration allouables, gérées par le référentiel, comprenant notamment les plages d'adresses correspondant aux adresses que ce référentiel peut allouer.
Selon une variante, le référentiel 50 comprend en outre des données relatives aux relais DHCP du réseau, décrivant pour chaque type de relais présent dans le réseau, le format et mode d'encodage des données qu'il insère dans les requêtes des terminaux clients qu'il convoie. En effet, chaque relais encode des informations avec un formatage propriétaire dans les sous-options d'une requête. Une même information (par exemple l'identifiant de ligne client ou CLID) peut, selon le relais, être encodée dans des sous-options différentes (sous-options "remote id" ou "circuit id" de l'option 82 du protocole DHCP) ou être encodée dans une même sous-option mais dans un format différent. Le référentiel 50 doit donc contenir l'information sur le type de relais et la façon dont il encode une information telle que le CLID qui est utile pour l'allocation de données de configuration, de manière à pouvoir décoder cette information et utiliser un format neutre de stockage de cette information. Les données de gestion de bail d'allocation de données de configuration, comprenant notamment un identifiant du terminal concerné par le bail, le statut (par exemple "expiré" ou "libéré" ou "réservé" ou autres) du bail, son heure de démarrage et sa durée prévisionnelle, également l'heure de fin si le bail a expiré ou a été libéré par un terminal. Ces données comprennent également tout ou partie des données de configuration associées à bail. En variante, les données de configuration associées à bail sont accessibles dans une table séparée indexée par exemple par l'identifiant du terminal (option "client identifier" du protocole DHCP) ou par l'adresse IP allouée ou par un autre paramètre. D'autres modes de stockage, basés sur un schéma relationnel des données stockées dans le référentiel 50, sont également envisageables.
Les données de configuration des terminaux IP comprennent les données de configuration allouées à un terminal, notamment son adresse IP. Ces données sont stockées pour chaque terminal corrélativement à un identifiant du terminal, cet identifiant étant par exemple l'adresse MAC du terminal. De préférence, toute autre information relative à un terminal, qui est susceptible d'être présente dans l'une des options d'une requête DHCP et nécessaire au processus d'allocation de données de configuration pour ce terminal, est également stockée corrélativement à un identifiant du terminal.
Les paramètres de communication sont stockés de manière adaptée pour être chargés par chacun des serveurs DHCP à son démarrage. Ils comprennent notamment les identifiants de ports de communication utilisés dans le dialogue avec le référentiel, l'adresse IP du référentiel ou de la machine qui héberge le référentiel, le compte utilisateur du serveur et mot de passe associé permettant l'accès au référentiel. Les paramètres et règles de traitement sont stockés de manière adaptée pour être chargés par chacun des serveurs DHCP à son démarrage. Ils comprennent notamment des règles d'identification des requêtes DHCP à appliquer sur chaque requête par le serveur DHCP, ainsi que les paramètres associés à ces règles.
Une règle d'identification de requête DHCP est une expression régulière composée d'opérateurs mathématiques (notamment opérateurs logiques et/ou arithmétiques) s'appliquant à des données contenues dans les champs et options de la requête DHCP, notamment à l'adresse MAC.
Lors de l'arrivée de la requête DHCP, la première étape du processus de traitement par un serveur DHCP 40, 41 , 42, 43 est de comparer le résultat de la règle d'identification à la trame DHCP avec la liste des résultats attendus. Si le résultat est négatif, le serveur ignore la requête et ne répond pas.
Si le résultat est positif, le processus de traitement de la requête passe à l'étape suivante consistant à générer une requête d'interrogation du référentiel 50 pour obtenir en retour une adresse IP ainsi que d'autres paramètres de configuration compatibles avec la règle d'identification correspondant au terminal IP émetteur de la requête.
La requête d'interrogation formulé par le serveur au référentiel 50 comprenant de préférence tout ou partie des données (champs d'options et/ou trame) de la requête DHCP à laquelle est se rapporte et qui est en train d'être traitée par le serveur. D'autres paramètres spécifiques à la communication entre le serveur et le référentiel peuvent optionnellement être prévus, sous forme d'option de traitement de la requête, de manière à demander au référentiel des actions ou informations supplémentaires.
Si le référentiel 50 ne répond pas à la requête d'interrogation dans un temps déterminé, il est avantageusement prévu que le serveur émette cette même requête d'interrogation vers un référentiel de repli (le référentiel esclave associé au référentiel maître).
Si le référentiel 50 ne trouve pas de données de configuration répondant à la requête d'interrogation, il envoie une réponse prédéfinie au serveur. Dans ce cas, le serveur ignore la requête DHCP et ne répond pas.
Le référentiel 50 analyse les données de gestion de bail d'allocation de données de configuration stockées pour ne fournir en réponse à la requête d'interrogation que des données de configuration qui soient cohérentes avec les données de configuration déjà allouées. Cette analyse consiste notamment à vérifier l'état du bail relatif au terminal émetteur de la requête DHCP si ce bail existe, à vérifier s'il y a des données de configuration non allouées qui répondent à la requête d'interrogation si ce bail n'existe pas, à vérifier si aucun autre bail en cours ne vient en conflit avec la requête émise par le terminal, etc. Si le référentiel ne peut fournir de telles données de configuration, il envoie une réponse prédéfinie, signalant par exemple un refus de répondre au serveur ou lui signalant un problème de cohérence ou lui demandant de ré-émettre une requête ou lui demandant de faire redémarrer le terminal (par exemple par l'envoi d'un message "DHCP NACK" par le serveur DHCP vers le terminal IP), etc.
Si le référentiel 50 trouve des données de configuration répondant à la requête d'interrogation, il envoie une réponse au serveur DHCP comprenant ces données de configuration, et enregistre des données de gestion de bail d'allocation de données de configuration relatives à l'allocation effectuée sur ces données de configuration, afin qu'un autre serveur ne puisse pas les allouer à son tour. Ces données comprennent notamment l'adresse IP allouée, l'adresse MAC du terminal émetteur de la requête, le champ "client identifier" de cette requête.
Dans le mode de réalisation de la figure 1 , les serveurs sont reliés au réseau par un commutateur 30 ou équipement de commutation de paquet.
Selon une première variante de réalisation, nommée variante A, le commutateur 30 envoie les paquets de données comprenant les requêtes DHCP à chacun des serveurs DHCP qui lui sont interconnectés. Cette diffusion se fait en en mode "broadcast" (diffusion générale, un message à plusieurs destinataires) ou en mode "unicast" (diffusion individuelle, un message par destinataire). Dans cette variante, l'équipement utilisé est un commutateur Ethernet (dénommé usuellement "switch L2"). Selon une deuxième variante de réalisation, nommée variante B, le commutateur 30 distribue les paquets de manière équitable entre les serveurs, en fonction d'un mécanisme de répartition de charge mis en œuvre par le commutateur. Dans cette variante, l'équipement utilisé est un commutateur répartiteur de charge (dénommé usuellement "switch L4"). Selon une troisième variante de réalisation, nommée variante C, aucun commutateur n'est nécessaire, les terminaux et les relais DHCP émettant leur requête DHCP en mode "anycast", c'est-à-dire vers une adresse IP anycast, le routeur d'accès se chargeant de transmettre la requête au serveur DHCP le plus proche du routeur d'accès. Ces différentes variantes sont décrites plus en détail ci-dessous.
Dans la variante A, chaque serveur met en oeuvre un mécanisme de répartition de charge. Tous les serveurs reçoivent les requêtes émises en mode broadcast, mais chaque serveur parmi les serveurs constituant la grappe de serveurs associée au commutateur ne traite que la portion de charge qui lui est attribuée. L'algorithme de répartition de charge est par exemple le mécanisme prévu dans la recommandation RFC 3074. Il est basé sur un identifiant du terminal, cet identifiant comprenant généralement l'adresse MAC, Media Access Control, qui est unique pour chaque terminal et est transmis avec chaque requête DHCP, via l'option DHCP nommée "Client Identifier". Un identifiant de partage de charge est en outre attribué à chaque serveur DHCP sous forme de clef de hachage. Ce mécanisme est le suivant : lorsque plusieurs serveurs DHCP reçoivent une requête, chaque serveur utilise une fonction de hachage appliquée sur l'adresse MAC du terminal pour déterminer, en fonction du résultat de la fonction de hachage et d'une règle prédéfinie de répartition de charge, si c'est à lui ou non de traiter la requête. Cette règle prédéfinie de répartition de charge consiste à comparer le résultat de la fonction de hachage avec l'identifiant de partage de charge attribué à ce serveur. De cette manière, à chaque fois qu'un terminal donné émet une requête, c'est toujours le même serveur qui traite cette requête.
Dans la variante A, en cas d'ajout d'un serveur supplémentaire, il est nécessaire de modifier la fonction de hachage utilisée et/ou l'identifiant de partage de charge des serveurs pour réaffecter de manière équitable la charge globale entre les serveurs. Cette modification est avantageusement effectuée par le référentiel, qui comprend un programme pour déterminer la fonction de hachage utilisée et/ou l'identifiant de partage de charge des serveurs. De cette manière, la répartition de charge est contrôlée de manière centralisée au niveau du référentiel. De préférence, l'identifiant de partage de charge d'un serveur est stocké par le référentiel avec les paramètres de traitement associé à ce serveur. Ce paramètre, déterminant la charge attribuée à ce serveur, est transmis par le référentiel 50 à ce serveur ou chargé par ce serveur lors de son démarrage. La figure 2 est une illustration d'un échange de données mis en oeuvre dans la variante A de réalisation. Dans cet échange de données les étapes suivantes sont exécutées:
- un terminal, par exemple le terminal 10, émet 201 une requête DHCP DISCOVER à destination d'un des relais DHCP, par exemple le relais DHCP 25; - le relais DHCP 25 transfert 202 la requête DHCP DISCOVER au commutateur
30;
- le commutateur transfert 203 en mode broadcast à chacun des serveurs 40, 41 , 42, 43 cette même requête DHCP DISCOVER;
- chacun des serveurs détermine, en fonction de l'identifiant du terminal transmis dans la requête DHCP DISCOVER, s'il doit ou non traiter cette requête; supposons par exemple que ce soit le serveur 40 qui soit chargé de traiter cette requête;
- le serveur 40 effectue, notamment en appliquant les règles d'identification, un contrôle de l'intégrité de la requête puis envoie 204 une requête d'interrogation au référentiel pour obtenir des données de configuration permettant de répondre à la requête DHCP DISCOVER; cette requête comprenant de préférence les données de la requête DHCP DISCOVER;
- le référentiel retourne 205 une réponse au serveur 40;
- le serveur 40 élabore la réponse à la requête DHCP DISCOVER sous la forme d'une requête DHCP OFFER et envoie 206 cette requête au relais DHCP 25;
- le relais DHCP 25 transfert 207 alors la requête DHCP OFFER au terminal 10;
- le terminal 10 émet 21 1 une requête DHCP REQUEST qui est interceptée par le relais DHCP 25;
- le relais DHCP 25 transfert 212 la requête DHCP REQUEST au commutateur 30;
- le commutateur transfert 213 en mode broadcast à chacun des serveurs 40, 41 , 42, 43 cette même requête DHCP REQUEST;
- chacun des serveurs détermine, en fonction de l'identifiant du terminal transmis dans la requête DHCP REQUEST, s'il doit ou non traiter la requête; comme pour la requête précédente émise par le terminal 10, c'est le serveur 40 qui est chargé de traiter cette requête;
- le serveur 40 effectue, notamment en appliquant les règles d'identification, un contrôle de l'intégrité de la requête puis envoie 214 ensuite une requête d'interrogation au référentiel, pour obtenir des données de configuration permettant de répondre à la requête DHCP REQUEST;
- le référentiel 50 retourne 215 une réponse au serveur 40;
- le serveur 40 élabore la réponse à la requête DHCP REQUEST sous la forme d'une requête DHCP ACK et envoie 216 cette requête au relais DHCP 25;
- le relais DHCP 25 transfert 217 alors la requête DHCP ACK au terminal 10; - le terminal 10 émet 221 une requête DHCP REQUEST RENEW à destination du serveur 40 ayant répondu à sa requête DHCP REQUEST précédente;
- le serveur 40 envoie 222 alors une requête d'interrogation au référentiel pour obtenir des données de configuration permettant de répondre à la requête DHCP REQUEST RENEW; - le référentiel 50 retourne 223 une réponse au serveur 40;
- le serveur 40 élabore la réponse à la requête DHCP REQUEST RENEW sous la forme d'une requête DHCP ACK et envoie 224 cette requête au terminal 10;
- le terminal 10 émet 231 une requête DHCP RELEASE à destination du serveur 40 ayant répondu à sa requête DHCP REQUEST RENEW précédente; - le serveur 40 envoie 232 une instruction au référentiel pour lui signaler la fin de la procédure d'allocation de données de configuration pour ce terminal;
- le référentiel 50 enregistre alors une information signalant cette fin de la procédure d'allocation.
Dans la variante B, le commutateur répartiteur de charge distribue les requêtes entre les serveurs DHCP selon la charge. Les serveurs n'ont donc pas besoin de mettre en oeuvre un algorithme de partage de charge DHCP, car, vu du client, ils forment globalement un seul et unique serveur DHCP, chaque serveur répondant en positionnant la même adresse IP dans le champ d'option "server identifier", se faisant ainsi passer pour un seul et unique serveur DHCP. En conséquence, différents serveurs peuvent traiter les requêtes émises par un même client pour une même transaction, grâce à l'utilisation combinée du répartiteur et de la base de données servant de référentiel commun de configuration. Vu du réseau, la présence de plusieurs serveurs physiques DHCP est masquée par la présence du répartiteur, l'ensemble des serveurs DHCP physiques formant un seul serveur logique. Dans cette variante B, le mécanisme DHCP est adapté de façon à ce que les terminaux IP voient les serveurs DHCP comme un serveur unique, en envoyant, en réponse à une requête DHCP une adresse IP virtuelle au terminal en utilisant l'option du protocole DHCP nommée "server identifier", pour que le terminal utilise cette adresse IP virtuelle pour les requêtes suivantes. Dans la variante B, si le parc de terminaux augmente, et qu'un nouveau serveur
DHCP est inséré dans la grappe de serveur, il n'est pas nécessaire de modifier la configuration des serveurs: le changement est dans ce cas complètement transparent. Inversement, lorsqu'un serveur DHCP ne répond pas à une requête du répartiteur (par exemple en cas de panne de ce serveur), le répartiteur détermine une nouvelle répartition de la charge en fonction du nombre de serveurs opérationnels. L'adresse IP virtuelle commune pour les serveurs associés à un référentiel est de préférence stockée dans le référentiel et fournie aux serveurs par le référentiel. Elle fait partie par exemple des paramètres chargés par chacun des serveurs au démarrage. La variante B est donc particulièrement intéressante du point de vue de la répartition de charge et de la tolérance aux pannes des serveurs, tout en étant complètement compatible avec les services et mécanismes de communication du protocole DHCP.
La figure 3 est une illustration d'un échange de données mis en oeuvre dans la variante B de réalisation. Dans cet échange de données les étapes suivantes sont exécutées: - un terminal, par exemple le terminal 10, émet 301 une requête DHCP DISCOVER à destination d'un des relais DHCP, par exemple le relais DHCP 25;
- le relais DHCP 25 transfert 302 la requête DHCP DISCOVER au commutateur 30; - le commutateur transfert 303 cette même requête DHCP DISCOVER à un des serveurs, par exemple au serveur 40, ce serveur étant sélectionné en fonction d'un algorithme de répartition de charge mis en œuvre par le commutateur;
- le serveur 40 effectue, notamment en appliquant les règles d'identification, un contrôle de l'intégrité de la requête puis envoie 304 une requête d'interrogation au référentiel pour obtenir des données de configuration permettant de répondre à la requête DHCP DISCOVER;
- le référentiel retourne 305 une réponse au serveur 40;
- le serveur 40 élabore la réponse à la requête DHCP DISCOVER sous la forme d'une requête DHCP OFFER et envoie 306 cette requête au relais DHCP 25; - le relais DHCP 25 transfert 307 alors la requête DHCP OFFER au terminal 10;
- le terminal 10 émet 31 1 une requête DHCP REQUEST qui est interceptée par le relais DHCP 25;
- le relais DHCP 25 transfert 312 la requête DHCP REQUEST au commutateur 30; - le commutateur transfert 313 cette même requête DHCP DISCOVER à un des serveurs, par exemple au serveur 41 , ce serveur étant sélectionné en fonction d'un algorithme de répartition de charge mis en œuvre par le commutateur;
- le serveur 41 traite la requête: il effectue, notamment en appliquant les règles d'identification, un contrôle de l'intégrité de la requête puis envoie 314 une requête d'interrogation au référentiel pour obtenir des données de configuration permettant de répondre à la requête DHCP DISCOVER;
- le référentiel retourne 315 une réponse au serveur 40;
- le serveur 41 élabore la réponse à la requête DHCP REQUEST sous la forme d'une requête DHCP ACK et envoie 316 cette requête au relais DHCP 25; - le relais DHCP 25 transfert 317 alors la requête DHCP ACK au terminal 10;
- le terminal 10 émet 321 une requête DHCP REQUEST RENEW à destination du serveur 41 ayant répondu à sa requête DHCP REQUEST précédente;
- le serveur 41 envoie 322 ensuite si besoin une requête d'interrogation au référentiel pour obtenir des données de configuration permettant de répondre à la requête DHCP REQUEST RENEW; - le référentiel 50 retourne 323 une réponse au serveur 40;
- le serveur 40 élabore la réponse à la requête DHCP REQUEST RENEW sous la forme d'une requête DHCP ACK et envoie 324 cette requête au terminal 10;
- le terminal 10 émet 331 une requête DHCP RELEASE à destination du serveur 40 ayant répondu à sa requête DHCP REQUEST RENEW précédente;
- le serveur 40 envoie 332 une instruction au référentiel pour lui signaler la fin de la procédure d'allocation de données de configuration pour ce terminal;
- le référentiel 50 enregistre alors une information signalant cette fin de la procédure d'allocation. Dans un mode de réalisation du système selon l'invention, le référentiel 50 est partiellement redondé au niveau de chacun des serveurs DHCP qui lui sont associés: la partie de la base de données concernant les données de configuration des terminaux IP du réseau pour lesquels une adresse statique ou permanente est allouée est dupliquée au niveau de chaque serveur DHCP. Une deuxième base de données est ainsi constituée qui est une réplique d'un sous-ensemble du référentiel.
De cette manière, un serveur peut interroger prioritairement cette deuxième base de données pour répondre directement, sans interroger le référentiel 50, à une demande d'adresse statique ou permanente. Ce mode d'allocation d'adresses ne génère en effet pas de problèmes de cohérence puisque la réponse à une requête est unique. Ce mode de réalisation réduit le temps de réponse à ce type de requête. Dans ce mode de réalisation, un mécanisme est prévu pour avertir le référentiel d'une telle allocation, ce mécanisme s'exécutant de préférence à un moment où la charge du serveur le permet.
Avec le système selon l'invention la disponibilité du service de génération de données de configuration est maximale : un changement, effectué au niveau du référentiel, des paramètres de traitement associés aux serveurs (notamment identifiants de charge), est transparent pour les serveurs et donc pour le processus de traitement des requêtes DHCP par les serveurs. L'ajout ou l'arrêt d'un serveur dans la grappe de serveurs n'a ainsi pas d'impact sur la disponibilité du service. En outre, le système selon l'invention est parfaitement robuste, ne nécessite pas la mise en place de mécanisme de synchronisation entre serveurs et ne présente pas les disfonctionnements liés au protocole de "Failover" actuel. Il n'est plus nécessaire de mettre en œuvre un processus de mise en cohérence entre les serveurs. Il en résulte une simplification et une performance élevée du service de génération de données de configuration. L'invention propose ainsi une nouvelle solution pour la gestion de données de configuration qui est compatible avec le protocole DHCP et mieux adapté aux contraintes de disponibilité, de robustesse et de performance qui sont critiques dans le déploiement de réseau comprenant un nombre élevé de terminaux IP. Enfin l'utilisation d'un référentiel tel une base de données ou un annuaire LDAP facilite l'intégration de la solution DHCP dans un système d'information qui assure les opérations de configuration et de supervision du réseau.

Claims

REVENDICATIONS
1. Système pour l'allocation, au moyen du protocole DHCP, de données de configuration à des terminaux interconnectés à un réseau de communication, le système comprenant au moins une base de données, apte à stocker des données de gestion de bail d'allocation de données de configuration, accessible par au moins un serveur DHCP parmi une pluralité de serveurs DHCP interconnectés audit réseau de communication et conçus pour traiter les requêtes DHCP émises par l'un desdits terminaux en vue de l'obtention de données de configuration, caractérisé en ce que ladite base de données est en accès partagé par au moins deux serveurs DHCP de ladite pluralité de serveurs DHCP et en ce qu'elle est apte à recevoir de l'un quelconque desdits au moins deux serveurs DHCP une requête d'interrogation pour l'obtention de données de configuration d'un terminal, apte à fournir des données de configuration répondant à ladite requête d'interrogation et apte à stocker des données de gestion de bail d'allocation de données de configuration relatives aux données de configuration fournies.
2. Système selon la revendication 1 , caractérisé en ce que ladite base de donnée est conçue pour analyser les données de gestion de bail d'allocation de données de configuration stockées pour ne fournir en réponse à ladite requête d'interrogation que des données de configuration qui soient cohérentes avec les données de configuration déjà allouées.
3. Système selon la revendication 1 ou 2, caractérisé en ce que ladite requête d'interrogation comprend au moins une partie des données d'une requête DHCP émise par un terminal pour lequel lesdites données de configuration sont à générer.
4. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite base de données est apte à fournir à chacun desdits au moins deux serveurs DHCP, des paramètres de communication relatifs à la communication entre ce serveur DHCP et la base de données.
5. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite base de données est apte à fournir à chacun desdits au moins deux serveurs DHCP, des paramètres et règles de traitement définissant des traitements à effectuer sur les requêtes DHCP reçues par ce serveur DHCP.
6. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite base de données est apte à fournir à chacun desdits au moins deux serveurs DHCP au moins un paramètre déterminant la portion de charge attribuée à ce serveur.
7. Système selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend un commutateur répartiteur interconnecté auxdits au moins deux serveurs DHCP, ledit commutateur recevant les requêtes DHCP destinées auxdits au moins deux serveurs DHCP et étant apte, suite à la réception d'une requête DHCP, à sélectionner au moyen d'un algorithme de partage de charge, un serveur DHCP parmi lesdits au moins deux serveurs
DHCP et à transférer ladite requête DHCP audit serveur DHCP sélectionné.
8. Serveur DHCP interconnecté à un réseau de communication et apte à traiter une requête DHCP émise par un terminal pour l'obtention de données de configuration, caractérisé en ce qu'il est apte à accéder à une première base de données dont l'accès est partagé avec au moins un autre serveur DHCP interconnecté audit réseau de communication, apte à envoyer une requête d'interrogation à ladite base de données pour obtenir des données de configuration, et apte à élaborer une réponse à ladite requête DHCP en fonction des données de configuration reçues de ladite base de données.
9. Serveur DHCP selon la revendication 8 caractérisé en ce qu'il est apte à interroger une deuxième base de données accessible localement par ledit serveur DHCP et adaptée pour répondre à une requête d'interrogation pour l'allocation d'une adresse statique ou permanente, ledit serveur DHCP étant conçu pour interroger prioritairement ladite deuxième base de données suite à la réception d'une requête DHCP pour l'allocation d'une adresse statique ou permanente.
10. Procédé d'allocation, au moyen du protocole DHCP, de données de configuration à des terminaux interconnectés à un réseau de communication, caractérisé en ce qu'il est exécuté par une base de données dont l'accès est partagé par au moins deux serveurs DHCP parmi une pluralité de serveurs
DHCP interconnectés audit réseau de communication et conçus pour traiter les requêtes DHCP émises par l'un desdits terminaux en vue de l'obtention de données de configuration, et en ce qu'il comprend les étapes consistant à, - recevoir de l'un quelconque desdits au moins deux serveurs DHCP une requête d'interrogation pour l'obtention de données de configuration, - fournir des données de configuration en réponse à ladite requête d'interrogation,
- stocker des données de gestion de bail d'allocation de données de configuration relatives aux données de configuration fournies.
PCT/FR2006/050704 2005-07-11 2006-07-11 Systeme et procede d ' allocation de donnees de configuration au moyen du protocole dhcp Ceased WO2007007007A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0552145 2005-07-11
FR0552145 2005-07-11

Publications (2)

Publication Number Publication Date
WO2007007007A2 true WO2007007007A2 (fr) 2007-01-18
WO2007007007A3 WO2007007007A3 (fr) 2007-06-21

Family

ID=36013366

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/050704 Ceased WO2007007007A2 (fr) 2005-07-11 2006-07-11 Systeme et procede d ' allocation de donnees de configuration au moyen du protocole dhcp

Country Status (1)

Country Link
WO (1) WO2007007007A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008128480A1 (fr) * 2007-04-23 2008-10-30 Huawei Technologies Co., Ltd. Dispositif, système et procédé servant à configurer automatiquement des terminaux d'application dans un réseau domestique
FR2938144A1 (fr) * 2008-10-31 2010-05-07 Canon Kk Procede de gestion d'espaces d'adressage a la fermeture d'un tunnel de communication entre une premiere et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et dispositif correspondants.

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6654891B1 (en) * 1998-10-29 2003-11-25 Nortel Networks Limited Trusted network binding using LDAP (lightweight directory access protocol)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008128480A1 (fr) * 2007-04-23 2008-10-30 Huawei Technologies Co., Ltd. Dispositif, système et procédé servant à configurer automatiquement des terminaux d'application dans un réseau domestique
US8787200B2 (en) 2007-04-23 2014-07-22 Huawei Technologies Co., Ltd. Device, system, and method for automatically configuring application terminals in home network
FR2938144A1 (fr) * 2008-10-31 2010-05-07 Canon Kk Procede de gestion d'espaces d'adressage a la fermeture d'un tunnel de communication entre une premiere et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et dispositif correspondants.

Also Published As

Publication number Publication date
WO2007007007A3 (fr) 2007-06-21

Similar Documents

Publication Publication Date Title
CN106657287B (zh) 一种数据访问方法及系统
CN102783094B (zh) 用于基于会话发起协议的通信系统的弹性路由
JP5523012B2 (ja) エンドポイントを生き残ったネットワークのコントローラのリスト内にコントローラのスライディング・ウインドウで登録する方法
US7395328B2 (en) Method and system for detecting a dead server
US20110307541A1 (en) Server load balancing and draining in enhanced communication systems
EP2000929B1 (fr) Utilisation d'un arbre de hachage à préfixes (PHT) pour la localisation des services au sein d'un réseau de communication poste-à-poste
US20060036747A1 (en) System and method for resource handling of SIP messaging
EP2795849B1 (fr) Procédé et appareil de messagerie dans le nuage
JP2005503595A (ja) 向上されたコラボレーション、スケーラビリティ、およびリライアビリティを提供するために接続され得るネットワーク装置のセットのための方法およびシステム
FR3042931A1 (fr) Systeme de continuite de services fournis par une passerelle residentielle
WO2005018254A2 (fr) Fourniture de services par réservation de ressources au sein d'un réseau de communications à gestion de ressources par des règles de politique
EP3085065B1 (fr) Procédé de mise a jour dynamique d'informations obtenues de la part d'un serveur dns
US7203742B1 (en) Method and apparatus for providing scalability and fault tolerance in a distributed network
FR3041842A1 (fr) Systeme de restauration de services fournis par une passerelle residentielle
CN112367221A (zh) 一种工业物联网下分布式注册中心推荐方法
EP0877319B1 (fr) Procédé et dispositif de transmission d'une notification comportant plusieurs services de notification
EP3891935A1 (fr) Procédé de configuration d'un noeud d'un réseau
EP1966978A1 (fr) Procédé d'affectation dynamique d'ensembles d'adresses par dhcp, entité de gestion, relais et programme d'ordinateur correspondants
EP2807815B1 (fr) Système et procédö de controle d'une requête dns
EP2955875A1 (fr) Serveur, client et système de gestion d'un réseau d'interconnexion
EP1501241B1 (fr) Procédé d'approvisionnement de règles de politique dans un réseau géré à base de règles de politique
WO2007007007A2 (fr) Systeme et procede d ' allocation de donnees de configuration au moyen du protocole dhcp
CN110049081A (zh) 用于搭建及使用高可用性Docker私库的方法和系统
EP3053328A1 (fr) Procédés de configuration et de gestion d'un réseau ip, dispositifs et programmes d'ordinateur correspondants
Cirani et al. Implementation of a framework for a DHT-based Distributed Location Service

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06779040

Country of ref document: EP

Kind code of ref document: A2