HK1105259A - Method and apparatus for obtaining server information in a wireless network - Google Patents

Description

Method and apparatus for obtaining server information in a wireless network

Priority as required by 35U.S.C § 119

Priority of the present patent application for U.S. provisional application No. 60/558,796 entitled "Method and apparatus for organizing Server Information in a Wireless Network", filed 3, 31, 2004, which is assigned to the assignee hereof and hereby expressly incorporated by reference herein.

Technical Field

The present invention relates generally to packet data communications, and more particularly to identification of server location during packet data communications.

Background

The global interconnection of networks allows for quick access to information regardless of geographic distance. Fig. 1 shows a simplified schematic diagram of the global connections of a network, generally referred to as the internet, indicated by reference numeral 20. The internet 20 is essentially a number of networks with different hierarchical levels connected together. The internet 20 operates in accordance with TCP/IP (transmission control protocol/internet protocol) promulgated by IETF (internet engineering task force). TCP/IP can be found in RFC (request for comments) 703 and RFC 791 published by IETF.

Connected to the internet 20 are various individual networks, sometimes referred to as LANs (local area networks) or WANs (wide area networks) depending on the network size. Shown in fig. 1 are some of such networks 22, 24, 26, and 28 connected to the internet 20.

Within each network 22, 24, 26, and 28, there may be various equipment connected to and in communication with each other. Examples are computers, printers and servers, to name a few. Each equipment has a unique hardware address, commonly referred to as a MAC (media access control) address. Equipment with a MAC address is sometimes referred to as a node. When a node communicates over its own network via the internet 20, it needs to be assigned an IP address.

The assignment of the IP address may be manual or automatic. The manual assignment of the IP address may be performed by, for example, a network administrator. More generally, the IP address is automatically assigned by a server called a DHCP (dynamic host control protocol) server located inside the network of nodes.

Returning now to fig. 1, as an example, assume a node 30 in network 22 attempts to send a data packet to another node 32 in network 28. Under TCP/IP, each data packet needs to have a source address and a destination address. In this case, the source address is the address of the node 30 in the network 22. The destination address is the address of a node 32 in the network 28.

As another example, when a node 30 in a network 22 attempts to retrieve information from a node 34 in another network 24, such as in a virtual host session where the node 34 is acting as a virtual host, the node 30 must provide the correct IP address of the node 34 in the network 24 for such a session.

The advent of wireless technology allows nodes to leave their originally registered network and reach another network. For example, referring back to FIG. 1, rather than being permanently wired to network 22, node 30 may be a wireless device, such as a PDA (personal device Assistant), a cellular telephone, or a mobile computer. The wireless node 30 may move outside the boundaries of its home network 22. Thus, for example, the node 30 may roam from its home network 22 to the foreign network 26. In this case, the initial IP address assigned to the node 30 will no longer be applicable to the node 30. Likewise, data packets sent to node 30 may not reach node 30.

MIP (mobile internet protocol) proposed by IETF is proposed to solve the node mobility problem. According to the IETF published RFC 2002, a node 30 is assigned a "Care-of Address," abbreviated CoA (Care-of Address). According to RFC 2002, there are two types of coas, namely, FA CoA (foreign agent care-of address) and CCoA (co-configured care-of address). The FACoA is essentially an address of an FA (foreign agent) (not shown) that is a designated server in the foreign network in which the node 30 is located. The CCoA is a separate but temporary address assigned to the node 30 by the foreign network. In any case, whenever the node 30 is in the foreign domain, the node 30 must register a CoA, whether a FA CoA or a CCoA, with its home network 22 so that the home network 22 is always aware of the whereabouts of the node 30. After registration, the CoA is stored in a routing table maintained by a designated server called an HA (home agent) (not shown) of the home network 22.

An example is used for illustration. Assume that the node 30 roams into the foreign network 26. Upon receiving the advertisement from the foreign network 26, the node learns the FA address of the foreign network 26. The node 30 then registers the FA CoA with the home network 22. When a node 30 in the foreign network 26 sends a data packet to a node 34 in the network 24, the data packet may be sent directly knowing the address of the node 34 in the network 24. However, reverse traffic cannot be so straightforward.

In reverse data routing, when a node 34 in the network 24 attempts to send a data packet to a node 30 now in the foreign network 26, both a source address and a destination address must be specified in the data packet according to TCP/IP, as described above. In this case, the source address is the IP address of the node 34 in the network 24. As for the destination address, the node 34 only knows the IP address of the node 30 assigned by its home network 22, called HoA (home assigned address), and does not know the FA CoA of the node 30. Thus, the destination address will be set at the HoA of the node 30. However, since the FA CoA of the node 30 is stored in the routing table HA of the home network 22, when a data packet arrives at the home network 22, the HA of the network 22 encapsulates the received data packet with the stored FA CoA and resends it to the node 30 in the foreign network 26. The encapsulated FA CoA serves as the destination address for the retransmitted data packet. Once the foreign network 26 receives the rerouted data packet, the foreign network 26 simply strips off the encapsulated FA CoA and delivers the initial packet to the mobile node 30.

Operating in this manner, a virtual data tunnel is said to be established between node 34 in network 24 and node 30 roaming in foreign network 26, all intended to be transparent to the user. This is regardless of the actual situation, the virtual tunnel actually involves three-way data communications.

Heretofore, when node 30 was roaming, it was difficult and often impossible for node 30 to locate other nodes in other networks, even if node 30 exactly known the type of data it wanted to access. Returning to the example just mentioned above, the node 30 in the foreign network 26 is able to send data packets to the node 34 in the network 24 because the node 30 has a good knowledge of the IP address of the node 34 in advance. In practice, this is not always the case. It is assumed that the node 30 only knows the type of information to be accessed. The node 30 may even know the address of the network 24 with the server holding the information to access. However, the node 30 does not know the exact IP address of the server node 34 and is therefore blocked in reaching the node 34.

Accordingly, there is a need to provide a roaming node having a method of conveniently accessing server information located in different networks.

Disclosure of Invention

In a communication system in which a mobile node seeks to establish contact with a server node, either within or outside a local network, the mobile node first locates a DHCP (dynamic host configuration protocol) server. The mobile node then provides the generic location and the server type of the sought server node to the DHCP server. The DHCP server then matches the provided information with its record in memory and reaches the IP (internet protocol) address or FQDN (fully qualified domain name) of the sought server node. The DHCP server then sends the IP address or FQDN to the mobile node, allowing the mobile node to contact the server node directly.

In the first embodiment, a mobile node roaming in a foreign network communicates with a DHCP server using an FA CoA (foreign agent care-of address) and reaches the sought server.

In a second embodiment, a mobile node roaming in a foreign network communicates with a DHCP server using a CCoA (co-located care-of address) and, after that, with the sought server node.

According to the present invention, a mobile node roaming between networks is designed to be able to access information from any server in any network. These and other features and advantages of the present invention will become apparent to those skilled in the art from the following detailed description, taken in conjunction with the accompanying drawings, in which like reference numerals refer to like parts throughout.

Drawings

FIG. 1 is a schematic illustration of the global interconnection of networks;

FIG. 2 is a schematic diagram showing a first embodiment of the present invention;

FIG. 3 is a flow chart showing steps according to a first embodiment of the present invention;

FIG. 4 is a schematic diagram showing a second embodiment of the present invention;

fig. 5 is a schematic diagram of circuitry of a mobile node in accordance with the present invention; and

fig. 6 is a schematic diagram of circuitry of a configuration server according to the present invention.

Detailed Description

The following description is presented to enable any person skilled in the art to make and use the invention. The details set forth in the following description are for the purpose of illustration. It will be understood by one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and processes are not shown in detail so that the description of the invention is not obscured by unnecessary detail. Thus, the present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Reference is now made directly to fig. 2, which schematically shows a first embodiment of the invention.

The overall system, generally designated by the reference numeral 40, includes a backbone network 42, such as an intranet or the internet. For example, as shown in fig. 2, connected to the backbone network 42 are a HN (home network) 44 and an FN (foreign network) 46. Other networks are not specifically shown for clarity and brevity of illustration. In the system 40 there is a node 48 that is initially registered with the HN 44, but is able to migrate to other foreign networks such as the FN 46.

In the following, few terms need to be defined. According to the two standard versions of IP, IPv4 and IPv6, a node capable of moving and changing a connected network is called a "mobile node". The network to which the mobile node is initially connected is referred to as the "home network". Nodes that appear in the home network and are responsible for the mobile node during periods when it is not, are referred to as "home agents". The network to which the mobile node is actually connected is referred to as a "foreign network". A node that appears in a foreign network to take care of a mobile node when the mobile node is in the foreign network is referred to as a "foreign agent". The foreign network may sometimes be referred to as a "visited network".

Reference is now returned to fig. 2. In HN 44, in addition to mobile node 48, there are other nodes within HN 44, but are not shown for clarity. These nodes may be computers of various sizes, printers, and any other device that may be mobile or non-mobile. Further, in the HN 44, there is an HA (home agent) 50 which is mainly a node that takes responsibility for managing data traffic within the HN 44 and also controls data traffic for inbound and outbound routing of the HN 44.

In addition to the HA 50, there are other dedicated nodes within the HN 44 that perform different tasks. For example, there are nodes such as: a BCMCS (broadcast multicast service) controller 52, a DHCP (dynamic host control protocol) server 54, a DNS (domain name system) server 56, and a SIP (session initiation protocol) proxy server 58, to name a few.

The BCMCS controller 52 is primarily a server that provides broadcast and multicast configuration information to allow users to peruse available broadcast or multicast sessions upon user request.

The DHCP server 54 is installed to automatically assign IP addresses and other configuration parameters to the nodes in the HN 44 during startup, allowing the nodes in the HN 44 to communicate with other nodes in the system 40. DHCP server 54 may also provide updated configuration information to the nodes during operation.

Sometimes, data packets traveling in system 40 are not specified in the 4-octet IP address commonly used under IPv4 or the 16-octet format used under IPv6, but are instead specified in a domain name expressed in text. DNS 56 primarily translates domain names expressed in text into IP addresses of machine-readable numbers in system 40.

The SIP proxy server 58 is essentially an intermediate router that plays a dual role as a host and a client in rerouting data packets on behalf of other client nodes.

Likewise, for simplicity of explanation, the FN 46 is shown to be substantially the same as the HN 44. It should be understood that the structure of the FN 46 may be completely different depending on the application. Thus, in this case, the FN 46 also includes, among other things, a BCMCS controller 58, a DHCP server 60, a DNS 62, and a SIP proxy server 66. Coordination of data traffic within and outside the FN 46 is handled by the FA (foreign agent) 66.

Assume that MN48 is roaming in FN 46. In this particular example, the MN48 wants a video clip of a news event from a broadcast service in which the user of the MN48 is a subscriber. The broadcast service may be, for example, a publisher or media organization serving the public. To meet this need, a broadcast service has different BCMCS controllers installed in many networks, such as the HN 44 and the FN 46. The MN48 wants to access either the BCMCS controller 52 in the HN 44 or the BCMCS controller 58 in the FN 46, but the latter is preferred because the MN48 is now in the FN 46 and thus has the proximity advantage.

In this embodiment, the MN48 seeks assistance to a DHCP server 54 in the HN 44 or a DHCP server 60 in the FN 46 in order to access the BCMCS controller.

If the MN48 knows the exact address of either of the DHCP servers 54 or 60, the MN48 may send a DHCPINFORM message directly to the DHCP server 54 or 60. On the other hand, if MN48 does not have a direct address of any DHCP server, MN48 may perform the restricted broadcast all the way by sending a DHCPINFORM message to reach the available DHCP servers. It should be noted that under IPv6, the equivalent message is referred to as INFORMATION REQUEST. In this specification, the terminology of IPv4 is used for the purpose of describing the consistency and conciseness of the embodiments. It should be noted that those of ordinary skill in the art can readily implement the present invention using equivalent messages in IPv6 corresponding to IPv4 messages.

Further, according to the DHCP promulgated by the IETF, various types of messages may be used to communicate with the DHCP server. For example, during startup, that is, during the time a node makes a request to own an assigned IP address, message types such as DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, and the like may be used. After startup, a message type such as DHCPRELEASE, DHCPINFORM, DHCPACK is also typically used. Depending on DHCP, there are different "options" available to the user in each message type for flexibility purposes. Details and available options for DHCP are set forth in IETF RFCs 2131, 2132 and 3315.

Under DHCP, DHCPINFORM messages are typically used to change network parameters of configured nodes. In the DHCPINFORM message, there are options VCI (vendor class identifier) and VSI (vendor specific information) that can be used as input. Both the VCI and VSI options contain specific information to help any DHCP server properly configure client nodes that may not be routine-capable nodes.

To date, DHCPINFORM message types have been used mostly for network internal configuration. According to the invention, the DHCPINFORM message type is used for configuration between networks. First, the MN48 needs to inform the DHCP host of the network where the sought server is located. The MN48 can meet this requirement by providing the IP address or FQDN (fully qualified domain name) of the network of the server being sought. In this case, since the sought server is located on the HN 44 or FN 46, the IP address or FQDN of the HN 44 or FN 46 may be provided to satisfy the requirement. In addition, the MN48 also needs to inform the DHCP host of the type of server the MN48 is looking for. In this case, it is a BCMCS controller. It should be noted that even with these two pieces of basic information, the MN48 is not able to contact the sought server directly, because the MN48 does not reach all the necessary information to reach the direct IP address of the sought server. For example, the MN48 does not have the MAC address or domain name of the server sought in order to derive an available IP address.

To meet the above objective, in the DHCPINFORM message, MN48 populates the VCI option with the IP address or FQDN of the network with the server that MN48 wants to access.

The IP address or FQDN of the network where the server is located and has the server that the MN48 is attempting to reach can be extracted from various sources.

For example, if the MN48 wants the BCMCS controller 52 in the HN 44, the MN48 can simply submit to the DHCP server using its home address as the requested IP address. As another option, the MN48 may use a realm part of its NAI (network access identifier) corresponding to the domain name of the home address of the MN 48.

If the MN48 wants the BCMCS controller 58 in the FN 46, when the MN enters the realm of the FN 46, the MN48 can extract the IP address of the FN 46 from its FA CoA available during the announcement of the FN 46 in order to allow the MN48 to register the FA CoA with the HN 44.

For the type of server that MN48 is looking for, MN48 may populate any available options for the DHCPINFORM message. Some exemplary options are a router option, a name server option, a domain name option, to name just a few. As described above, in this example, the type of server that the MN48 wants is a BCMCS controller.

As an alternative, the IP name or FQDN may be populated into the VSI option of the DHCPINFORM message, while the server type information may be populated into other available options as previously described.

As another alternative, all the required information, i.e., IP name or FQDN and the type of server sought, may be fully populated into either the VCI option or the VSI option.

Upon receiving the DHCPINFORM message, the DHCP host maps the two pieces of information together by referring to the DHCP host's own stored record. If the DHCP host has previously processed the sought server, a processing record with the sought information can generally be found. If a match is found, the IP address of the sought server can be reconstructed and then passed into the VSI option in the DHCPACK message to MN 48. On the other hand, if no match is found, the DHCPNACK message is sent to the MN 48.

The processing described above is shown in the flow chart of fig. 3.

Fig. 4 shows another embodiment of the present invention. In this embodiment, the responsibility of a foreign agent in the foreign network (such as the FA 64 in the FN 46 shown in fig. 2) is omitted. But rather by the MN48 acting as its own proxy.

When the MN48 roams away from the HA 44, according to MIP the MN48 can request a CCoA (co-configured care-of address) via a DHCP server in any foreign network (such as the FN 72 shown in fig. 4) in which the MN48 is located, without requesting a FA CoA (foreign agent care-of address). However, the MN48 performs all functions of the foreign agent, except for CCoA assignment performed by the FN 72. Furthermore, the MN48 needs to register the CCoA with the HN 44.

For example, in order to coincide with a CN (correspondent network) 76, the MN48 transmits a data packet with two-layer addresses. At the outer layer, the source address is set to CCoA and the destination address is set to HA 50. At the inner layer, the source address is the HoA (home assigned address) of the MN48, and the destination address is the address of the CN 76. Upon receiving the data packet from the roaming MN48, the HA 50 strips off the outer address layer and resends the data packet to the CN 76 with the inner address layer.

In the reverse data path, that is, when the CN 76 sends a data packet to the MN48, the data packet has only one address layer, the source address is set at the CN 76, and the destination address is set at the HoA of the MN 48. Upon receiving the data packet, the HA 50 encapsulates the data packet with the CCoA as the destination address and resends the data packet to the MN 48. MN48 performs decapsulation on itself without going through FA 74.

In this embodiment, it is assumed that the MN48 needs to access the SIP proxy server 78. The MN48 knows that there is such a SIP proxy server in the CN 76 but does not know its exact IP address. The MN48 first needs to locate the DHCP server by directly contacting, for example, one of the networks 44, 72, and 76. Alternatively, the DHCP server may be located by a limited broadcast as explained above. The MN48 then provides the IP address or domain name of the CN 76 to the selected DHCP server in the manner described above. In addition, the MN48 informs the selected DHCP server that the sought server type is a SIP proxy server. The rest of the operation is substantially the same as described in the previous embodiment. Details of the operation are not repeated for the sake of clarity and conciseness.

Figure 5 schematically shows a hardware implementation of a mobile node device, indicated with reference numeral 80, according to the invention. The device 80 may be embedded or incorporated in a variety of devices, such as a laptop computer, PDA, or cellular telephone. The device 80 includes a central data bus 82 that connects several circuits together. These circuits include a CPU (central processing unit) or controller 84, a receive circuit 86, a transmit circuit 88, and a memory circuit 90.

The receiving and transmitting circuits 86 and 88 may be connected to RF (radio frequency) circuits, but are not shown in the drawing. The receive circuitry 86 processes and buffers the received signal before sending it to the data bus 82. On the other hand, transmit circuitry 88 processes and buffers data from data bus 82 before sending the data from data bus 82 out of device 80. The CPU/controller 84 performs the function of data management of the data bus 82 and further performs the function of general data processing including executing the instruction contents of the memory circuit 90.

The memory circuit 90 includes a set of instructions, generally indicated by reference numeral 92. In this embodiment, the instructions include portions such as the MIP client 94, the SIP client 96, the DHCP client 98, the DNS client 100, and the BCMCS client 102, the node location client 104, to name a few. In this embodiment, the memory circuit 90 is a RAM (random access memory) circuit. The exemplary instruction portions 94, 96, 98, 100, 102 and 104 are software modules. The memory circuit 90 may be tied to another memory circuit (not shown) which may be of a volatile or non-volatile type. Alternatively, the memory circuit 90 may be formed from other circuit types, such as an EEPROM (electrically erasable programmable read Only memory), an EPROM (electrically programmable read Only memory), a ROM (read Only memory), a magnetic disk, an optical disk, and other circuit types known in the art.

Fig. 6 schematically shows a hardware implementation of a DHCP apparatus according to the present invention, indicated with reference numeral 106. The DHCP device 106 includes a central data bus 108 that connects several circuits together. These circuits include a CPU (central processing unit) or controller 120, a receive circuit 112, a transmit circuit 114, a memory circuit 116, and a data storage unit 130.

The receive and transmit circuits 112 and 114 may be connected to a network data bus (not shown) to which the DHCP device 106 is connected. The receive circuitry 112 processes and buffers signals received from a network data bus (not shown) before routing them to the internal data bus 108. The transmit circuit 114 processes and buffers data from the data bus 108 before sending the data from the data bus 108 out of the device 106. The CPU/controller 120 performs the duties of the data management of the data bus 96 and performs the functions of general data processing, including executing the instructional contents of the memory circuit 116.

The memory circuit 116 includes a set of instructions, generally indicated by reference numeral 118. In this embodiment, the instructions include portions of, among other things, a DHCP host 122 and a node location host 124. The data storage unit 130 includes past processing records of the DHCP device 106 that are retrievable by the CPU/controller 120 via the data bus 108. Memory circuit 116 and data storage unit 130 may be constructed of memory circuit types as described above and are not repeated. Further, the memory circuit 116 and the data storage unit 130, although shown separately in fig. 6, may be made as one unit.

Finally, only some networks bound to the backbone network are described in the embodiments. It is obvious that a multiplicity of networks may be involved. Furthermore, the mobile node may access other nodes than the node type. Furthermore, any of the logical blocks, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented by hardware, software, firmware, or combinations thereof. It will be understood by those skilled in the art that these and other changes in form and details may be made therein without departing from the scope and spirit of the invention.

Claims (31)

1. A method of obtaining information of a communication node in a communication system, comprising:

identifying a configuration server;

providing generic location information and a node type of the communication node in a notification message; and

sending the notification message to the configuration server.

2. The method of claim 1, further comprising:

receiving an acknowledgement message from the configuration server, the acknowledgement message comprising specific location information of the communication node; and

accessing the communication node using the specific location information.

3. The method of claim 2, wherein identifying a configuration server comprises identifying a DHCP server, wherein providing a notification message comprises providing a DHCPINFORM message, and wherein receiving an acknowledgement message comprises receiving a DHCPACK message.

4. The method of claim 2, further comprising obtaining a care-of address prior to said identifying a provisioning server.

5. The method of claim 4 wherein said obtaining a care-of address comprises obtaining the care-of address selected from one of a foreign agent care-of address and a co-located care-of address.

6. The method of claim 1, further comprising broadcasting a search for available configuration servers prior to said identifying a configuration server.

7. A method of accessing a target server in a plurality of networks in a communication system supporting TCP/IP, comprising:

identifying a DHCP server;

providing generic location information for one of the plurality of networks and a server type for the target server in a notification message;

sending the notification message to the DHCP server;

receiving an acknowledgement message from the DHCP server, the acknowledgement message including specific location information of the target server; and

accessing the target server using the specific location information.

8. The method of claim 7, wherein the specific location information is selected from one of an IP address of the target server and a domain name of the target server.

9. The method of claim 7, further comprising obtaining a care-of address (CoA) prior to said identifying a provisioning server.

10. The method of claim 9, wherein the obtaining a care-of address comprises obtaining the care-of address selected from one of a foreign agent care-of address (FA CoA) and a co-located care-of address (CCoA).

11. A method of obtaining information of a communication node in a communication system, comprising:

receiving a notification message, the notification message including general location information and a node type of the communication node;

comparing the generic location information and the node type to stored records; and

generating an acknowledgement message including the specific location information of the communication node in the communication system if the stored record is consistent with the generic location information and the node type.

12. The method of claim 11, wherein receiving the notification message comprises receiving a DHCPINFORM message, and wherein generating the acknowledgement message comprises generating a DHCPACK message.

13. The method of claim 11, wherein the specific location information is selected from one of an IP address of the communication node and a domain name of the communication node.

14. An apparatus in a communication system, comprising:

means for identifying a configuration server;

means for providing generic location information and a node type of a communication node in the communication system in a notification message; and

means for sending the notification message to the configuration server.

15. The apparatus of claim 14, further comprising:

means for receiving an acknowledgement message from the configuration server, the acknowledgement message comprising specific location information of the communication node; and

means for accessing the communication node using the specific location information.

16. The method of claim 14, further comprising means for obtaining a care-of address.

17. The method as recited in claim 16, wherein the care-of address is selected from one of a foreign agent care-of address and a co-located care-of address.

18. An apparatus for locating a target server in a plurality of networks in a communication system supporting TCP/IP, comprising:

means for identifying a DHCP server;

means for providing generic location information for one of the plurality of networks and a server type of the target server in a notification message;

means for sending the notification message to the DHCP server;

means for receiving an acknowledgement message from the DHCP server, the acknowledgement message including specific location information of the target server; and

means for accessing the target server using the specific location information.

19. The apparatus of claim 18, wherein the specific location information is selected from one of an IP address of the target server and a domain name of the target server.

20. The method of claim 19, further comprising means for obtaining a care-of address (CoA) for the device.

21. The method of claim 20, wherein the care-of address is selected from one of a foreign agent care-of address (FA CoA) and a co-located care-of address (CCoA).

22. An apparatus in a communication system, comprising:

means for receiving a notification message comprising generic location information and a node type of a communication node;

means for comparing the generic location information and the node type to stored records; and

means for generating an acknowledgement message including the specific location information of the communication node in the communication system if the stored record is consistent with the generic location information and the node type.

23. The apparatus of claim 22, wherein the specific location information is selected from one of an IP address of the communication node and a domain name of the communication node.

24. The apparatus of claim 22 wherein the notification message comprises a DHCPINFORM message and the acknowledgement message comprises a DHCPACK message.

25. An apparatus in a communication system, comprising:

memory circuitry having computer-readable instructions for identifying a configuration server, providing generic location information and a node type of a communication node in a notification message, and sending the notification message to the configuration server; and

a processor circuit, coupled to the memory circuit, for processing the computer-readable instructions.

26. The apparatus of claim 25, wherein the memory circuit further comprises computer-readable instructions for receiving an acknowledgement message from the configuration server that includes specific location information for the communication node, and accessing the communication node using the specific location information.

27. An apparatus for locating a target server in a plurality of networks in a communication system supporting TCP/IP, comprising:

memory circuitry having computer-readable instructions for identifying a DHCP server, providing generic location information for one of the plurality of networks and a server type of the target server in a notification message, sending the notification message to the DHCP server, receiving an acknowledgement message from the DHCP server that includes specific location information for the target server, and accessing the target server using the specific location information; and

a processor circuit, coupled to the memory circuit, for processing the computer-readable instructions.

28. The apparatus of claim 27, wherein the specific location information is selected from one of an IP address of the target server and a domain name of the target server.

29. An apparatus in a communication system, comprising:

memory circuitry having computer-readable instructions for receiving a notification message including generic location information and a node type for a communication node in the communication system, comparing the generic location information and the node type to stored records, and generating an acknowledgement message including specific location information for the communication node in the communication system if the stored records are consistent with the generic location information and the node type; and

a processor circuit, coupled to the memory circuit, for processing the computer-readable instructions.

30. The apparatus of claim 29, wherein the specific location information is selected from one of an IP address of the communication node and a domain name of the communication node.

31. The apparatus of claim 30 wherein the notification message comprises a DHCPINFORM message and the acknowledgement message comprises a DHCPACK message.