Pervasive inter-domain dynamic host configuration

Abstract

There is provided pervasive dynamic host configuration in a communication system comprising a plurality of domains being separated from each other by intermediary devices blocking host configuration messages, including encapsulation-based dynamic host configuration messaging and an enhanced host apparatus for dynamic host configuration.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

In the following, the present invention will be described in greater detail with reference to the accompanying drawings, in which

FIG. 1 illustrates a schematic overview of a scenario according to an embodiment of the present invention;

FIG. 2 illustrates message structures of DHCP messages according to an embodiment of the present invention;

FIG. 3 illustrates a schematic flow chart of a client method for sending messages according to an embodiment of the present invention;

FIG. 4 illustrates a schematic flow chart of a client method for receiving messages according to an embodiment of the present invention;

FIG. 5 illustrates a schematic flow chart of a relay agent method for forwarding non-encapsulated messages according to an embodiment of the present invention;

FIG. 6 illustrates a schematic flow chart of a relay agent method for forwarding encapsulated messages according to an embodiment of the present invention;

FIG. 7 illustrates a schematic flow chart of a server method for receiving encapsulated messages according to an embodiment of the present invention;

FIG. 8 illustrates a schematic flow chart of a server method for sending messages according to an embodiment of the present invention;

FIG. 9 illustrates a schematic block diagram of an enhanced DHCP host according to an embodiment of the present invention;

FIG. 10 illustrates a schematic block diagram of an enhanced DHCP host according to an embodiment of the present invention;

FIG. 11 illustrates a logical two-stage decision process according to an embodiment of the present invention;

FIG. 12 illustrates a schematic flow chart of a local relay agent means method for relaying messages received from a local client means according to an embodiment of the present invention;

FIG. 13 illustrates a schematic flow chart of a local relay agent means method for forwarding messages toward a local client means according to an embodiment of the present invention;

FIG. 14 illustrates a schematic block diagram of an enhanced DHCP host according to an embodiment of the present invention; and

FIG. 15 illustrates a schematic block diagram of an enhanced DHCP host according to an embodiment of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE PRESENT INVENTION

The present invention is described herein with reference to particular non-limiting examples. A person skilled in the art will appreciate that the invention is not limited to these examples, and may be more broadly applied.

In particular, the present invention is described in relation to DHCP as a known dynamic host configuration scheme. As such, the description of the embodiments given herein specifically refers to terminology which is directly related to DHCP. Such terminology is however only used in the context of the presented examples, and does not limit the invention in any way. That is, all aspects of the present invention are similarly applicable for a dynamic host configuration being based on another scheme, as long as that has a comparable underlying concept.

First Overall Embodiment

FIG. 1 illustrates a schematic overview of a scenario according to an embodiment of the present invention.

In FIG. 1, there is depicted a communication system comprising a plurality of networks or domains, i.e. a visited network, a public network and a home network. These networks or domains are separated from each other by firewalls, which are depicted as an example for intermediary devices blocking host configuration messages, i.e. DHCP traffic, for example. The terms “visited” and “home” denoting particular domains relate to a mobile terminal acting as DHCP client in the illustrated example.

The mobile terminal of FIG. 1, for some reason as e.g. being switched on in the depicted situation, requires to perform a dynamic host configuration according to DHCP. The visited network represents the local DHCP framework comprising a DHCP relay agent and a DHCP server. However, a DHCP messaging within this local framework (illustrated by dashed line arrows) is not suited to provide the mobile terminal with appropriate address and/or configuration information. For this purpose, the mobile terminal has to communicate with its home DHCP server being located in its remote home network.

According to an embodiment of the present invention, in general terms being referred to as encapsulation-based DHCP, the mobile DHCP client node is enabled to perform an encapsulated DHCP messaging with its home DHCP server through different domains and intermediary devices blocking DHCP traffic (illustrated by solid line arrows).

For inter-domain dynamic host configuration according to the present embodiment, the mobile terminal encapsulates a DHCP message generated and transfers the encapsulated DHCP message through the communication system. The encapsulated messaging is applicable between a client and a relay agent or server, and between a relay agent and another relay agent or server.

An encapsulation procedure used in this embodiment is based on a protocol, whose transmission is supported by the intermediary devices, e.g. firewalls, as well as access and transport networks. Thereby, the encapsulation provides for a transparent DHCP traversal through firewalls, networks address translators (NAT), network access port translators (NAPT) and other kinds of middle-box devices. Stated in other words, the encapsulation-based DHCP enables a (reliable) exchange of host configuration messages between DHCP entities (i.e. client, relay agent, server) in independent (separated) DHCP frameworks.

The encapsulated message is decapsulated at a destination entity or at a relay entity, which uses the same (but inverted) encapsulation procedure.

In principle, an encapsulation of host configuration messages can be performed at a client entity or at a relay agent entity, and a respective decapsulation of encapsulated host messages can be performed at a relay agent entity or at a server entity. Thus, in an example scenario with a client, two relay agents and a server, the following basic use cases of encapsulation-based DHCP messaging according to Table 1 are possible in the present embodiment.

	TABLE 1
	client ->	relay agent ->	relay agent ->
	relay agent	relay agent	server
	encapsulated	non-encapsulated	non-encapsulated
	non-encapsulated	encapsulated	non-encapsulated
	non-encapsulated	non-encapsulated	encapsulated
	encapsulated	encapsulated	non-encapsulated
	non-encapsulated	encapsulated	encapsulated
	encapsulated	non-encapsulated	encapsulated
	encapsulated	encapsulated	encapsulated

That is, any combination of encapsulated and non-encapsulated (i.e. standard) messaging on each individual link is possible. Accordingly, the respective apparatuses and entities involved are configured correspondingly according to an embodiment of the present invention.

Pursuant to alternative implementations, the use of encapsulation can be pre-configured or can be agreed upon dynamically (by negotiation) between respective apparatuses or entities.

According to a present implementation, the encapsulation is performed by an encapsulation procedure being based a protocol of layer 4 or above according to the OSI (Open Systems Interconnection) reference model. One example of such a layer 4+protocol is HTTP (Hypertext Transfer Protocol). The encapsulation procedure used does preferable not utilize any IP address or port number in layers 4 to 7, if transparency to application level gateways (ALG) of NAT or NAPT is desired. In detail, the encapsulation procedure involves a standalone set of protocols of different layers, e.g. IP+TCP (Transport Control Protocol)+HTTP. Moreover, if the encapsulation procedure used is secured, e.g. by using HTTPS, the encapsulated DHCP message is secured as well.

From firewall or middle-box perspective, if HTTP is used as encapsulation protocol, a method according to a firewall enhancement protocol (FEP) as defined in RFC 3093 may be used to get traversal through firewalls. The firewall enhancement protocol defines for example how to encode IP and TCP headers and to what HTTP messages they are to be used.

FIG. 2 illustrates by way of example message structures of DHCP messages according to an embodiment of the present invention.

In FIG. 2a), there is depicted a standard DHCP message using protocols IP (Internet Protocol), UDP (User Datagram Protocol) and DHCP (Dynamic Host Configuration Protocol). An example of an encapsulated message of the present embodiment is depicted in FIG. 2b). The encapsulated message can be divided into the original DHCP message of FIG. 2a) and an encapsulation part comprising an IP section and a section denoted by layers 4+, representing the encapsulation procedure used. FIG. 2c) depicts another example of an encapsulated message of the present embodiment. Namely, the message of FIG. 2c) is encapsulated by means of HTTPS as an example of a secured encapsulation procedure. The part of the encapsulation is visible to an access level gateway (ALG), whereas the part of the original DHCP message is transparent to an ALG, and thus the encapsulated message will not be blocked.

In the context of the present embodiment, it is to be noted that, due to the nature of the used addressing in DHCP, it is possible that source addresses of the inner and outer IP header are not equal (i.e. DHCP message creation point may be different from its encapsulation point) and therefore a relay agent and a server need to be able to do necessary mapping between the different source addresses for a possible response. Correspondingly, the destination addresses may be different, representing the case in which a DHCP message destination point is different from its decapsulation point.

The thus proposed method is compliant to current standards, does not add any new message delivery points, and thus maintains the overall signaling path. If provided optionally, additional message delivery points are used for encapsulation/decapsulation, which are not visible to the DHCP framework.

Stated in general terms, there is provided a method of dynamic host configuration in a communication system comprising a plurality of domains being separated from each other by intermediary devices blocking host configuration messages, wherein a source entity and a destination entity of a host configuration message are located in different domains, the method comprising the steps of obtaining (i.e. receiving or generating) a host configuration message to be transferred to the destination entity, encapsulating the obtained host configuration message based on an encapsulation procedure, and transferring the encapsulated host configuration message toward the destination entity.

Embodiments of the present invention are directed to respective apparatuses which are configured to perform the above methods. Such apparatuses are provided for a client entity, a relay agent entity, and a server entity.

In the following, the apparatuses of the present embodiments (although not shown) are described by way of the functions carried out at them, respectively. However, it is to be understood that the present invention also comprises respectively configured and arranged functional elements, apparatuses, devices and means. In the following, only those functions and/or means are described, which are relevant for the description of the present embodiments, thus omitting generally known functions and/or means of the respective apparatuses or entities.

As the following schematic flow charts are self-explaining for a skilled person, a detailed description thereof will not be given herein.

FIG. 3 illustrates a schematic flow chart of a client method for sending messages according to an embodiment of the present invention. A client or client apparatus for dynamic host configuration, which is configured to perform this method, comprises an obtainer or obtaining means for generating the DHCP message, an encapsulator or encapsulating means for encapsulating the generated DHCP message, if required, e.g. based on a layer 4+protocol, and a sender or transferring means such as a sender for transferring the encapsulated or non-encapsulated DHCP message toward a destination entity, namely to a destination server or an intermediate relay entity. The client or client apparatus further comprises a respective decider and determinator, i.e. respective decision or determination means for making the decisions of steps 2 and 3 of FIG. 3.

FIG. 4 illustrates a schematic flow chart of a client method for receiving messages according to an embodiment of the present invention. A client or client apparatus for dynamic host configuration, which is configured to perform this method, comprises a receiver or receiving means for receiving an encapsulated DHCP message, wherein the message is encapsulated based on a certain encapsulation procedure, and a decapsulator or decapsulating means for decapsulating the received encapsulated DHCP message based on the inverse encapsulation procedure. The client or client apparatus further comprises a respective decider and determinator, i.e. respective decision or determination means for making the decision of step 2 of FIG. 4.

FIG. 5 illustrates a schematic flow chart of a relay agent method for forwarding non-encapsulated messages according to an embodiment of the present invention. A relay agent or relay agent apparatus for dynamic host configuration, which is configured to perform this method, comprises a receiver or receiving means for receiving a standard (i.e. non-encapsulated) DHCP message, an encapsulator or encapsulating means for encapsulating the received DHCP message, if required, and a sender or transferring means such as a sender for transferring the encapsulated or non-encapsulated DHCP message toward a destination entity, namely to a destination server or another intermediate relay entity. To this end, an address mapper or address mapping means are provided. The relay agent or relay agent apparatus further comprises a respective decider and determinator, i.e. respective decision or determination means for making the decisions of steps 2 and 3 of FIG. 5.

FIG. 6 illustrates a schematic flow chart of a relay agent method for forwarding encapsulated messages according to an embodiment of the present invention. In contrast to the embodiment of FIG. 5, a relay agent or relay agent apparatus of FIG. 6 is configured to receive encapsulated DHCP messages. The relay agent or relay agent apparatus for dynamic host configuration, which is configured to perform this method, comprises a receiver or receiving means for receiving an encapsulated DHCP message, e.g. from a client or another relay agent, a decapsulator or decapsulating means for decapsulating the received encapsulated DHCP message, if required, an encapsulator or encapsulating means for encapsulating the previously decapsulated DHCP message again (after being processed), and a sender or transferring means such as a sender for transferring the encapsulated or non-encapsulated DHCP message toward a destination entity, namely to a destination server or another intermediate relay entity. An address mapper or address mapping means are also provided for executing address mapping, when the message is decapsulated and/or when the message is encapsulated again. The relay agent or relay agent apparatus further comprises a respective decider and determinator, i.e. respective decision or determination means for making the decisions of steps 2 and 5 of FIG. 6.

FIG. 7 illustrates a schematic flow chart of a server method for receiving encapsulated messages according to an embodiment of the present invention. This method of the server side basically corresponds to the respective method of the client side, as depicted in FIG. 4, further comprising an address mapping generation step. Thus, the respective server or server apparatus also structurally basically corresponds to the client or client apparatus according to FIG. 4, additionally comprising an address mapper or address mapping means, if required.

FIG. 8 illustrates a schematic flow chart of a server method for sending messages according to an embodiment of the present invention. This method of the server side basically corresponds to the respective method of the client side, as depicted in FIG. 3, further comprising an address mapping generation step. Thus, the respective server or server apparatus also structurally basically corresponds to the client or client apparatus according to FIG. 3, additionally comprising an address mapper or address mapping means, if required.

Second Overall Embodiment

Embodiments of the present invention are also directed to an enhanced host (or client) for dynamic host configuration, e.g. an enhanced DHCP host (or client). An enhanced host according to present embodiments is suited to be applied in a scenario as exemplarily illustrated in FIG. 1, that is in a communication system comprising a plurality of domains being separated from each other by intermediary devices blocking host configuration messages.

According to certain embodiments, the DHCP host enables a pervasive (inter-domain) use of dynamic host configuration, e.g. according to DHCP, in hosts regardless of its current location in the communication system. In this embodiment, the enhanced DHCP host basically acts as a mobile node, not as a mobile router. That is, pervasive DHCP usage refers to additional functions on a mobile node side of a host (or client), which particularly relate to use cases and circumstances where standard DHCP is not successfully applicable. These are for example:

• • exchange of DHCP messages between DHCP entities in independent DHCP frameworks or domains (i.e. non-local DHCP usage), such as a DHCP client node being located in a visited network and requesting configurations from its home network, or
  • DHCP client-server message exchange in a proximity network that does not have its own DHCP framework, such as a mobile network for example.

FIG. 9 illustrates a schematic block diagram of an enhanced DHCP host according to an embodiment of the present invention.

According to FIG. 9, the host apparatus of the present embodiment comprises a DHCP client means containing standard client functionality according to standard DHCP and additional functionalities according to the present invention. The DHCP client means, also referred to as initiator or initiating means, is operable to initiate a dynamic host configuration of the enhanced DHCP host apparatus either by way of standard DHCP or by way of pervasive DHCP of a first alternative. The DHCP host apparatus further comprises a DHCP relay agent means (also referred to as relay or relaying means), connected to the DHCP client means, which is operable for relaying DHCP messages received from the DHCP client means toward the remote server apparatus, e.g. via a remote relay agent or not. The relay agent means is configured to relay the DHCP messages such that the relayed DHCP messages are not blocked by intermediary devices such as firewalls.

According to the first alternative, this is achieved by utilizing the capability of DHCP relay agents to be allowed, unlike DHCP clients, to communicate with other trusted DHCP relay agents and servers with their global unicast addresses. That is, when pervasive DHCP use is needed, instead of a normal sending operation, the local DHCP client means delivers messages to the local relay agent means for relaying (referred to as alternative 1).

Because this relay agent functionality is strictly for the pervasive DHCP usage, it is transparent to a local DHCP framework, i.e. it is not used with a local DHCP framework.

This method as such is however vulnerable to possible middle-box filtering, such as firewalls, on the packet path and therefore is particularly feasible in cases where security and reliability of the packet path has been established in advance, such as over IP-IP tunnels or in local trusted networks.

FIG. 10 illustrates a schematic block diagram of an enhanced DHCP host according to another embodiment of the present invention. In this embodiment, the DHCP host again enables a pervasive (inter-domain) use of dynamic host configuration, e.g. according to DHCP, in hosts regardless of its current location in the communication system. Again, the enhanced DHCP host basically acts as a mobile node, not as a mobile router.

According to FIG. 10, the host apparatus of the present embodiment comprises a DHCP client means and a DHCP relay means, which basically correspond to that of FIG. 9, thus not being described in detail here. The enhanced DHCP host apparatus of the present embodiment further comprises an encapsulator or encapsulating means for encapsulating DHCP messages received from the DHCP client means or the DHCP relay agent means according to a pervasive DHCP usage of a second alternative.

Hence, the second alternative of pervasive DHCP usage is effected by using encapsulation, for example an encapsulation-based DHCP method as described above in connection with the first overall embodiment. That is, when pervasive DHCP usage is needed, instead for normal relaying, the relay agent means delivers DHCP messages to the encapsulator or encapsulation means (referred to as alternative 2).

This alternative requires no existing secure connectivity or existing reliable transport on the packet path, but it can provide those itself. Therefore, it can be applied in any network.

It is evident from FIGS. 9 and 10 that the present embodiments provide for several alternatives for using a pervasive (inter-domain) host configuration. The logical two-stage decision process of the present embodiment is illustrated in FIG. 11, without being described because of being self-explaining in view of the foregoing.

In order to perform the decision process as illustrated in FIG. 11, the enhanced DHCP host apparatus of FIG. 10 comprises a first decider or a first decision means, i.e. a first decision logic, for making the first decision whether or not pervasive DHCP is to be used, namely whether or not the relay agent means is to be used for dynamic host configuration. Further, it comprises a second decider or a second decision means, i.e. a second decision logic, for making the second decision whether alternative 1 or 2 is to be used, namely whether or not the encapsulator or encapsulation means is to be used for dynamic host configuration.

According to the present embodiment, although not illustrated explicitly, the first decider or decision means may be arranged at the local DHCP client means or at the local DHCP relay agent means, in which case all DHCP messages are redirected via the local relay agent means. In the former case, the second decider or decision means may be arranged at the local DHCP client means, at the local DHCP relay agent means or at the local encapsulation means (encapsulator). In the later case, the second decider or decision means may be arranged at the local DHCP relay agent means or at the local encapsulation means (encapsulator).

The decision making in both stages may be based on the will of an application to originate the signaling, and/or policies and/or rules at the host apparatus, and/or an active third party entity in the host apparatus.

It is to be noted that the enhanced DHCP host apparatus of FIG. 9 is only enabled to perform a pervasive DHCP usage of the first alternative, thus comprising a first decider or decision means corresponding to the one above.

As regards additional functionality of the local relay agent means of FIGS. 9 and 10, reference is made to FIGS. 12 and 13. Again, the following schematic flow charts are self-explaining for a skilled person, thus a detailed description thereof will not be given herein. As above, respective apparatuses of the present embodiment (although not shown) are described by way of the functions carried out at them, respectively. However, it is to be understood that the present invention also comprises respectively configured and arranged apparatuses, devices and means.

FIG. 12 illustrates a schematic flow chart of a local relay agent means method for relaying messages received from a local client means according to an embodiment of the present invention. Thus, the relay agent means comprises correspondingly configured relaying means (i.e. a relay) and decision or determination means (i.e. a decider and a determinator) for making the decision of step 3 of FIG. 12.

FIG. 13 illustrates a schematic flow chart of a local relay agent means method for forwarding messages toward a local client means according to an embodiment of the present invention. The relay agent means comprises correspondingly configured forwarding means and decision or determination means for making the decision of step 2 of FIG. 13.

In general, as is obvious from the foregoing, in order to be enabled to receive DHCP response messages from a DHCP server (either directly or via a remote relay agent), the enhanced DHCP host apparatus further comprises a decapsulator or decapsulating means for receiving an encapsulated DHCP message from a remote relay agent apparatus or server apparatus and for decapsulating the received encapsulated host configuration message. Then, the relay agent means is further configured to receive a DHCP message and to determine whether or not the received message is destined for the local client means.

According to further certain embodiments, an enhanced DHCP host enables DHCP service for connected adjacent (proximity) networks such as MANET or PAN, when the enhanced DHCP host acts as a mobile router (MR) instead of or in addition to acting as a mobile node (MN) as described above.

A DHCP service for connected adjacent networks, when the host operates in MR mode, refers to functions both on the MN- and/or the MR-side of the enhanced DHCP host architecture, that can enable use of the same DHCP service for nodes in a network behind the MR as well as on the MN-side.

FIG. 14 illustrates a schematic block diagram of an enhanced DHCP host according to an embodiment of the present invention.

In FIG. 14, the mobile node (MN) side of the host basically corresponds to the hosts of the embodiments of FIGS. 9 and 10. The arrows numbered 1, 2 and 3 indicate the different alternative operations of the above embodiments of the host's mobile node side.

Further to the devices and/or means of the MN side, the enhanced DHCP host of the present embodiment further comprises a mobile router (MR) side. On the MR side, the host comprises server means (i.e. a committer) for committing a dynamic host configuration of network nodes (not shown) connected to the MR-side of the host apparatus. This is indicated by arrow numbered 4 in FIG. 14, which indicates incoming DHCP messages (e.g. DHCPDISCOVER, DHCPREQUEST) from client network nodes and outgoing DHCP messages (e.g. DHCPOFFER) to the client network nodes, after processing at the MR-side of the host apparatus. The MR-side of the host further comprises at least one configuration database (DB), connected to the server means and to the MN-side of the host system, for receiving host configurations from the MN-side, e.g. from the client means, and for storing the thus received configurations (indicated by a solid line arrow denoted with data). For processing dynamic host configuration messages of its client network nodes, the server means accesses the database and uses the configurations stored therein.

An interface between the MR-side and the MN-side can be used to trigger configuration requests in the DHCP client means of the MN-side, i.e. DHCP requests of nodes in a connected adjacent network to the server means of the MR-side can trigger DHCP requests to the MN-side, e.g. to the client means (indicated by a dashed line arrow denoted with control). Moreover, this triggered request can trigger requests also to non-DHCP frameworks via a management interface being indicated in the right upper corner of the host. The management interface serves for importing new parameters to a DHCP service, exporting received parameters to an external framework, and/or requesting parameters from an external framework.

Nodes in the connected adjacent network are required to support standard DHCP and, if they do, the respective DHCP framework must be configured properly. But, if nodes support pervasive use of DHCP as defined and described hereinabove, no other DHCP entities are required to enable DHCP service. However, in the latter case nodes in the network must be aware of the address of a mobile router acting as DHCP server (which however should be a common functionality for mobile networks).

According to further certain embodiments, an enhanced DHCP host enables adaptive multi-access support for dynamic host configuration, e.g. according to DHCP. This functionality refers both to the mobile node (MN) side as well as to the mobile router (MR) side of the enhanced DHCP host, and is independent from the implementation of any one of the above-mentioned functionalities.

FIG. 15 illustrates a schematic block diagram of an enhanced DHCP host according to an embodiment of the present invention, said host having a plurality of interfaces for dynamic host configuration. The illustration of the present embodiment is exemplarily based on the previously described embodiment of FIG. 14. However, the present embodiment is not restricted thereto.

For the purpose of the present embodiment, adaptive multi-access support refers to functions in the host apparatus, that enable a seamless DHCP service in a multi-access host, namely in case of interface handovers. To this end, there is provided a multi-access mapping entity for adapting the host apparatus to the actual interface used for dynamic host configuration, e.g. according to DHCP. In detail, socket layer functions of DHCP client/relay agent/server are adapted to changes in physical and/or virtual interfaces, which includes monitoring changes in interfaces and implementing proper mapping functions for this purpose. Thereby, the enhanced DHCP host of the present embodiment is, in its DHCP transactions, not interface specific any more, and is adjustable to changing conditions, which is particularly beneficial in dynamic network environments.

While the illustrated multi-access mapping entity handles the handover issues in the system, also certain logical changes take place in the DHCP entities, namely in the client. An enhanced DHCP client (or host) of a present embodiment is thus configured to “see” (i.e. recognize) all logical interfaces (i.e. virtual and physical interfaces) of the host as concurrent interfaces (i.e. as one single interface) at all times. This means that transactions are not tied to specific interfaces in the client entity and receiving reply message from a “wrong” interface alone is not a valid reason to discard the received message in the client. In practice, this may be achieved by using a common transaction ID space for all logical interfaces. Stated in other words, the client means (acting as a processor) is further configured to operate in such a way that a dynamic host configuration is associated with any interface, instead of only one interface per transaction.

However, the client means preferably also maintains a functionality to handle interface specific configurations received in DHCP messages, even in a multi-access environment.

In contrast to the above solution for a multi-access architecture, prior DHCP entities usually are interface specific at least on logical level. For example, a DHCP client's transaction ID pools are interface-specific. In multi-access host architecture such an approach easily leads to discarding of DHCP reply messages in the client due to unknown and/or faulty transaction IDs, when interface handover takes place in the middle of a DHCP transaction. In other words, standard DHCP expects to receive reply from the same interface that the originating request was sent to. Also in standard DHCP, interface specific configurations received from a certain interface are configurations of that receiving interface by default and should not be used in other interfaces. Problems and drawbacks related with these prior art solutions are solved by the present embodiment.

In general, it is to be noted that respective functional elements according to above-described embodiments can be implemented by any known devices or means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

Furthermore, method steps likely to be implemented as software code portions and being run using a processor at one of the entities are software code independent and can be specified using any known or future developed programming language such as e.g. C, C++, and Assembler. Method steps and/or devices or means likely to be implemented as hardware components at one of the peer entities are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS, CMOS, BICMOS, ECL, TTL, etc, using for example ASIC components or DSP components, as an example. Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to those skilled in the art.

In accordance with embodiments of the present invention, there is provided pervasive dynamic host configuration in a communication system comprising a plurality of domains being separated from each other by intermediary devices blocking host configuration messages, including encapsulation-based dynamic host configuration messaging and an enhanced host apparatus for dynamic host configuration.

Even though the invention is described above with reference to the examples according to the accompanying drawings, it is clear that the invention is not restricted thereto. Rather, it is apparent to those skilled in the art that the present invention can be modified in many ways without departing from the scope of the inventive idea as disclosed in the appended claims.

Claims

1. A method, comprising: obtaining a host configuration message to be transferred from a source entity to a destination entity, the destination entity of the host configuration message being located in a different domain than the source entity of the host configuration message, the domains being separated from each other by intermediary devices configured to block host configuration messages;encapsulating the obtained host configuration message based on an encapsulation procedure; andtransferring the encapsulated host configuration message toward the destination entity.

2. The method according to claim 1, wherein obtaining, encapsulating and transferring is performed at the source entity.

3. The method according to claim 2, further comprising: receiving the encapsulated host configuration message at a relay entity;decapsulating the received encapsulated host configuration message based on an inverse encapsulation procedure; andtransferring the host configuration message toward the destination entity.

4. The method according to claim 2, further comprising: receiving the encapsulated host configuration message at a relay entity; andforwarding the received encapsulated host configuration message toward the destination entity.

5. The method according to claim 1, wherein obtaining, encapsulating and transferring is performed at a relay entity, wherein the host configuration message is obtained by receiving the host configuration message from the source entity.

6. The method according to claim 1, further comprising: receiving the encapsulated host configuration message at the destination entity; anddecapsulating the received encapsulated host configuration message at the destination entity based on the inverse encapsulation procedure.

7. The method according to claim 1, wherein the encapsulation procedure is based on a protocol, whose transmission is supported by the intermediary devices.

8. The method according to claim 1, wherein the encapsulation procedure is based on a Hypertext Transfer Protocol.

9. The method according to claim 1, wherein the host configuration message is in accordance with a Dynamic Host Configuration Protocol.

10. The method according to claim 9, wherein the source entity comprises a Dynamic Host Configuration Protocol client and the destination entity comprises a Dynamic Host Configuration Protocol server.

11. The method according to claim 9, wherein the source entity comprises a Dynamic Host Configuration Protocol server and the destination entity comprises a Dynamic Host Configuration Protocol client.

12. An apparatus, comprising: a processor configured to operate the apparatus as a dynamic host configuration client or server;an obtainer configured to obtain a host configuration message to be transferred from a source entity to a destination entity, the destination entity being located in a different domain than the source entity of the host configuration message, the domains being separated from each other by intermediary devices configured to block host configuration messages;an encapsulator configured to encapsulate the obtained host configuration message based on an encapsulation procedure; anda sender configured to transfer the encapsulated host configuration message toward the destination entity.

13. The apparatus according to claim 12, further comprising: a receiver configured to receive the encapsulated host configuration message, wherein the message is encapsulated based on an encapsulation procedure; anda decapsulator configured to decapsulate the received encapsulated host configuration message based on an inverse encapsulation procedure.

14. An apparatus, comprising: a processor configured to operate the apparatus as a dynamic host configuration relay agent;a receiver configured to receive a host configuration message;an encapsulator configured to encapsulate the received host configuration message based on an encapsulation procedure; anda sender configured to transfer the encapsulated host configuration message from a source entity toward a destination entity, the destination entity being located in a different domain than the source entity of the host configuration message, the domains being separated from each other by intermediary devices configured to block host configuration messages.

15. An apparatus, comprising: a processor configured to operate the apparatus as a dynamic host configuration relay agent,a receiver configured to receive an encapsulated host configuration message, the message being encapsulated based on an encapsulation procedure;a decapsulator configured to decapsulate the received encapsulated host configuration message based on an inverse encapsulation procedure; anda sender configured to transfer the host configuration message from a source entity toward a destination entity, the destination entity being located in a different domain than the source entity of the host configuration message, the domains being separated from each other by intermediary devices configured to block host configuration messages.

16. The apparatus according to claim 15, further comprising: an encapsulator configured to encapsulate the host configuration message, after being received by the receiver and decapsulated by the decapsulator, based on an encapsulation procedure.

17. A method, comprising: initiating, by client means, a dynamic host configuration of a host apparatus with a remote server apparatus in a communication system by generating a host configuration message destined for the server apparatus; andrelaying, by relay agent means, the generated host configuration message from the client means toward the remote server apparatus such that the relayed host configuration message is not blocked by intermediary devices,wherein the communication system comprises a plurality of domains being separated from each other by the intermediary devices configured to block host configuration messages.

18. The method according to claim 17, said relaying further comprising communicating between the relay agent means and remote relay agent apparatuses and server apparatuses by means of their global unicast addresses.

19. The method according to claim 17, further comprising: encapsulating, by encapsulating means, the host configuration message based on an encapsulation procedure, whereinsaid relaying of the host configuration message is performed via the encapsulating means.

20. The method according to claim 19, wherein the encapsulation procedure is based on a protocol, whose transmission is supported by the intermediary devices.

21. The method according to claim 19, wherein the encapsulation procedure is based on a Hypertext Transfer Protocol.

22. The method according to claim 17, further comprising: first-stage deciding whether or not relaying is to be used for dynamic host configuration.

23. The method according to claim 19, further comprising: second-stage deciding whether or not encapsulating is to be used for dynamic host configuration.

24. The method according to claim 17, further comprising: receiving an encapsulated host configuration message from a remote relay agent apparatus or server apparatus and decapsulating the received encapsulated host configuration message.

25. The method according to claim 17, further comprising receiving a host configuration message and determining whether or not the received message is destined for the client means.

26. The method according to claim 17, further comprising: committing, by a server means, a dynamic host configuration of network nodes connected to the host apparatus, said network nodes acting as client nodes, by processing incoming host configuration messages from the network nodes; andstoring, in a configuration database, host configurations received from the client means, wherein said processing is performed by means of the configurations stored.

27. The method according to claim 26, further comprising triggering configuration requests from the server means in the client means.

28. The method according to claim 17, further comprising: multi-access mapping to adapt the host apparatus to an actual interface used for dynamic host configuration,wherein said apparatus comprises a plurality of interfaces for dynamic host configuration.

29. The method according to claim 28, said multi-access mapping further comprising monitoring changes in at least one of physical or virtual interfaces of the host apparatus.

30. The method according to claim 28, said client means being further configured to operate in such a way that a dynamic host configuration is associated with any interface.

31. The method according to claims 17, wherein the host configuration message is in accordance with a Dynamic Host Configuration Protocol.

32. An apparatus, comprising: an initiator configured to initiate a dynamic host configuration of a host apparatus with a remote server apparatus in a communication system by generating a host configuration message destined for the server apparatus; anda relay configured to relay the generated host configuration message from the initiator toward the remote server apparatus such that the relayed host configuration message is not blocked by intermediary devices,wherein the communication system comprises a plurality of domains being separated from each other by the intermediary devices configured to block host configuration messages.

33. The apparatus according to claim 32, further comprising a transceiver configured to communicate with remote relay agent apparatuses and server apparatuses by means of their global unicast addresses.

34. The apparatus according to claim 32, further comprising: an encapsulator configured to encapsulate the host configuration message based on an encapsulation procedure, andanother relay configured to relay the host configuration message via the encapsulator.

35. The apparatus according to claim 34, wherein the encapsulation procedure is based on a protocol, whose transmission is supported by the intermediary devices.

36. The apparatus according to claim 34, wherein the encapsulation procedure is based on a Hypertext Transfer Protocol.

37. The apparatus according to claim 32, further comprising: a first decider configured to decide on a first stage whether or not the relay is to be used for dynamic host configuration.

38. The apparatus according to claim 34, further comprising: a second decider configured to decide on a second stage whether or not the encapsulator is to be used for dynamic host configuration.

39. The apparatus according to claim 32, further comprising: a receiver configured to receive an encapsulated host configuration message from a remote relay agent apparatus or server apparatus; anda decapsulator configured to decapsulate the received encapsulated host configuration message.

40. The apparatus according to claim 32, said relay comprising: a receiver configured to receive a host configuration message; anda determinator configured to determine whether or not the received message is destined for the initiator.

41. The apparatus according to claim 32, further comprising: a committer configured to commit a dynamic host configuration of network nodes connected to the host apparatus, said network nodes acting as client nodes, by processing incoming host configuration messages from the network nodes; anda storage configured to receive host configurations from the initiator and to store the configurations,said committer further comprising a processor configured to process the incoming messages by way of the configurations stored in the storage.

42. The apparatus according to claim 41, said committer further comprising a trigger configured to trigger configuration requests in the initiator.

43. The apparatus according to claim 32, said apparatus having a plurality of interfaces for dynamic host configuration, further comprising: a multi-access mapper configured to adapt the host apparatus to an actual interface used for dynamic host configuration.

44. The apparatus according to claim 43, said multi-access mapper further comprising a monitor configured to monitor changes in at least one of physical or virtual interfaces of the host apparatus.

45. The apparatus according to claim 43, said initiator further comprising a processor configured to operate in such a way that a dynamic host configuration is associated with any interface.

46. The apparatus according to claim 32, wherein the apparatus comprises a processor configured to operate in accordance with a Dynamic Host Configuration Protocol.

47. A computer program embodied in a computer-readable medium, comprising program code configured to operate a host apparatus for dynamic host configuration in a communication system comprising a plurality of domains being separated from each other by intermediary devices configured to block host configuration messages, the computer program being configured to initiate, by client means, the dynamic host configuration of the host apparatus with a remote server apparatus in the communication system by generating a host configuration message destined for the server apparatus; and relay, by relay agent means, the generated host configuration message from the client means toward the remote server apparatus such that the relayed host configuration message is not blocked by intermediary devices.

48. A computer program embodied in a computer-readable medium, comprising program code configured to operate an apparatus for dynamic host configuration in a communication system comprising a plurality of domains being separated from each other by intermediary devices configured to block host configuration messages, wherein a source entity and a destination entity of a host configuration message are located in different domains, the computer program being configured to obtain a host configuration message to be transferred from the source entity to the destination entity, the destination entity of the host configuration message being located in a different domain than the source entity of the host configuration message, the domains being separated from each other by intermediary devices configured to block host configuration messages;to encapsulate the obtained host configuration message based on an encapsulation procedure; andto transfer the encapsulated host configuration message toward the destination entity.

49. An apparatus, comprising: means for acting as a dynamic host configuration client or server;means for obtaining a host configuration message to be transferred from a source entity to a destination entity, the destination entity being located in a different domain than the source entity of the host configuration message, the domains being separated from each other by intermediary devices configured to block host configuration messages;means for encapsulating the obtained host configuration message based on an encapsulation procedure; andmeans for transferring the encapsulated host configuration message toward the destination entity.

50. An apparatus, comprising: means for acting as a dynamic host configuration relay agent;means for receiving a host configuration message;means for encapsulating the received host configuration message based on an encapsulation procedure; andmeans for transferring the encapsulated host configuration message from a source entity toward a destination entity, the destination entity being located in a different domain than the source entity of the host configuration message, the domains being separated from each other by intermediary devices configured to block host configuration messages.

51. An apparatus, comprising: means for acting as a dynamic host configuration relay agent,means for receiving an encapsulated host configuration message, the message being encapsulated based on an encapsulation procedure;means for decapsulating the received encapsulated host configuration message based on an inverse encapsulation procedure; andmeans for transferring the host configuration message from a source entity toward a destination entity, the destination entity being located in a different domain than the source entity of the host configuration message, the domains being separated from each other by intermediary devices configured to block host configuration messages.

52. An apparatus, comprising: means for initiating a dynamic host configuration of a host apparatus with a remote server apparatus in a communication system by generating a host configuration message destined for the server apparatus; andmeans for relaying the generated host configuration message from the means for initiating a dynamic host configuration toward the remote server apparatus such that the relayed host configuration message is not blocked by intermediary devices,wherein the communication system comprises a plurality of domains being separated from each other by the intermediary devices configured to block host configuration messages.