CA2109787C - Name translation in communications networks - Google Patents
Name translation in communications networks Download PDFInfo
- Publication number
- CA2109787C CA2109787C CA002109787A CA2109787A CA2109787C CA 2109787 C CA2109787 C CA 2109787C CA 002109787 A CA002109787 A CA 002109787A CA 2109787 A CA2109787 A CA 2109787A CA 2109787 C CA2109787 C CA 2109787C
- Authority
- CA
- Canada
- Prior art keywords
- name
- node
- message
- network address
- network
- 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.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/42—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker
- H04Q3/47—Circuit arrangements for indirect selecting controlled by common circuits, e.g. register controller, marker using translators
Abstract
Apparatus and methods used in a network for translating names into network addresses. Source nodes in the network receive names and have name caches for translating the names; destination nodes have have local name tables containing correspondences between names and the network addresses served by the destination node. There is further a name server accessible to the nodes which contains current correspondences between names and network addresses. A name is translated by first presenting it to the name cache in a source node; if there is no entry for the name in the cache, name cache maintenance code in the source node obtains information about the name from the name server; once there is an entry, the name is translated and a call set up message containing the name and the network address is sent to the destination node, which checks whether the name and network address are its local name table. If they are, the destination node returns a call complete message to the source node. Otherwise, it returns an unknown destination message to the source node. The name cache maintenance code responds to the unknown destination message by invalidating the cache entry and obtaining the correct information from the name server.
Description
-t-~10~787 NAME TRANSLATION IN COMMUNICATIONS NETWORKS
Background of the Invention Field of the Invention The invention concerns name translation generally and more particularly name translation in communications networks.
Description of the Prior Art As networks have grown more complex, it has become more and more worthwhile to give users of the networks techniques for reaching other users which are not dependent on the actual addressing mechanisms used in the networks. One example of such a technique is the 800 number, described in detail in U.S. Patent 4,191,860, Roy P. Weber, Data Base Correrrwnication Call Processing Methad, issued March 4, 1980. The 800 number is not itself an actual telephone number, but instead represents an actual telephone number. When a telephone switch receives an 800 number, it sends a message with the 800 number to a network control point which contains a data base relating the 800 number to an actual telephone number.
The network control point returns a message to the switch which contains the actual telephone number corresponding to the 800 number, and the switch then uses the actual number to setup the telephone call. The fact that the 800 number is not an actual telephone number provides a high degree of flexibility: the number may be a mnemonic for the business which is using the 800 number, the business may change its actual telephone number without changing its 800 number, the 800 number may correspond to different actual telephone numbers in different parts of the country or at different times of day, and the 800 number may even correspond to more than one actual telephone number, with calls being divided among the actual telephone numbers according to a load balancing scheme.
Calls made using 800 numbers are already an important part of the business of telephone companies. Moreover, the growing need for portability in the telephone system will make numbers which work like the 800 number even more important. For instance, in the future, each person may be given a single lifetime telephone number which may be used to reach him no matter where he is. As more and more of the numbers used in the telephone system are numbers like 800 numbers, it becomes more and more important that the translation of such numbers _2_ ~109~8~
to the actual numbers be done as quickly and with as little extra network traffic as possible.
The problem of making the user of a network independent of the addressing mechanisms actually employed in the network is of course encountered in any network. The general solution is to establish a correspondence in the network between a name and a network address. In this context, a network address is a value used internally by the network to address a user of the network and a name is another value which is not itself a network address but represents a network address.
In the context of the telephone system, an actual telephone number is a network address l0 and an 800 number is a name. Once the correspondence between the network address and the name is established, a user of the system can provide the network with a name and the network can translate the name into its corresponding network address and then use the network address to establish communications between the user and the desired destination.
The component of the network in which the correspondence between a name and a network address is established is termed a name server. The name server maintains a list of names and their corresponding network addresses. When a node of the network sends the name server a message containing a name, the name server looks the name up in the list and returns a message containing the corresponding network address. In the context of the telephone system, the network control point is a name server for 800 numbers.
As with the telephone network, a critical issue in other networks which employ names is the efficiency of name translation, the translation of a name into the network address which it represents. The simplest way to do name translation is in the manner described above for 800 numbers, i.e., the network address is always obtained from the name server; difficulties with this technique include the time it takes to do a translation and the number of messages required to do it. As regards the time, the switch which has received the name must send the name to the name server and wait until the name server has returned the corresponding network address before it can begin communicating. As regards the number of messages, when a name is used instead of a network address, two extra messages must be sent before the switch can begin communicating.
One technique which has been used in the past to speed up translation is name caches in nodes of the network. In general terms, a name cache contains copies of some of the correspondences between names and network addresses from the name server. When a node receives a name, it looks first in the name cache. If 3 ~10978~
the name cache has a copy of the correspondence between the name and the network address, the node uses the network address from the cache to begin communications;
otherwise, it goes to the name server as described above. When the node obtains the corresponding address from the name server, it not only begins communications, but also adds the name and the corresponding address to the name cache. As may be seen from the foregoing, once a name is in the cache, the node can begin communicating without exchanging messages with the name server.
A difficulty with name caches is keeping the name-network address correspondences contained in a cache consistent with the name-network 1o correspondences presently in use in the network. For example, as mentioned above, in an 800 number system, the actual telephone number corresponding to an 800 number may vary according to a load-balancing scheme; when the relationship between the 800 number and the actual telephone number changes in the name server, it must also change in all of the name caches in the network. A prior-art solution to the problem has been to periodically invalidate part or all of the name cache (see for example U.S. Patent 4,706,801, Hart, et al., Method and Apparatus for Bridging Local Area Networks, issued Nov. 10, 1987). There, bridges connecting LANs have tables containing source and destination addresses for the stations connected to the LANs. If a bridge does not receive a frame containing one of the values in the table for a period of about 15 minutes, the value is deleted from the table. There are two difficulties with this approach: the first is that an invalid entry may remain in the table for up to fifteen minutes, and may be used by the system during that period. The second is that mere non-use of a source or destination address for a relatively short time may cause the address to be removed from the table. When the source or destination address is again used, it must again be incorporated into the table.
What is needed, and what is provided by the present invention, is a name translation technique which employs name caches, but which avoids the opportunities for error and the excess overhead associated with partial or complete name cache invalidation.
Summary of the Invention In one aspect, the invention is a method for determining whether a translation of a name into a network address done in a first node of a network is valid, the method including the steps of:
~10978~
~ sending a first message containing at least the name to a second node specified by the network address;
~ in the second node, determining whether the name corresponds to any network address served by the second node; and ~ when the name does not so correspond, sending a second message indicating that there is no correspondence to the first node.
Other aspects of the invention include the methods employed in the second node for generating the second message and in the first node for responding to the second message, methods for keeping the first and second nodes consistent with the name server, and apparatus for performing name translation in the first node and name verification in the second node. A further aspect of the invention is a generalization of the techniques for use in any situation in which one value is automatically translated into another value.
In accordance with one aspect of the present invention there is provided a method for processing a name in a network that includes a plurality of nodes, comprising the steps of: translating at a first node the name of a network address that specifies a second node; sending from the first node to the second node a first message that includes the name; determining at the second node if the name corresponds to any network address served by the second node; and if the name does not so correspond, then sending from the second node to the first node a second message indicating that there is no correspondence between the name and the network address at the second node.
In accordance with another aspect of the present invention there is provided a communications network of the type wherein network addresses may be represented by names and nodes of the network may exchange messages, the communications network being characterized by: means in a first one of the nodes for translating a name into a network address and sending a first message including the name to a second one of the nodes which is specified by the network address; and means in A
-4a-the second node responsive to the first message for determining whether the name corresponds to any network address served by the second node and when the name does not so correspond, sending a second message indicating that there is no correspondence to the first node.
Brief Description of the Drawings FIG. 1 is an overview of a network in which the invention is employed;
FIG. 2 presents details of name translator 111; and FIG. 3 presents details of name verifier 114.
The reference numbers employed in the Drawings and the Detailed Description have three or more digits. The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, the element with the reference number "305" is first shown in FIG. 3.
Detailed Description The following Detailed Description will first present an overview of a network in which the name translation techniques are implemented and of the use of the techniques in the network. Thereupon, it will present details of a presently-preferred implementation of the techniques.
~10978~-Overview: FIG. 1 FIG. 1 shows a network 101 in which the name translation techniques are implemented. Network 101 is made up of some number of nodes 103, which are connected by a connection path 117. Dashed lines represent messages which move between components of network 101; the messages may move via connection paths 117 or by means of separate communications paths. Each node further has terminals 105 connected to it. Each terminal 105 has a network address 107, by means of which it is addressed in the network. Some or all terminals 105 may also be represented by a name 109. The currently-valid correspondences between names l0 109 and network addresses 107 are maintained in name server 119, which is accessible to all of the nodes 103 in the network. Network 101 may be understood in concrete terms as a telephone network; in such an embodiment, nodes 103 are switches, terminals 105 are devices such as telephones, names are numbers such as 800 numbers, network addresses are actual telephone numbers, and name server is a data base in a network control point. However, as will be apparent to those of ordinary skill in the art, the techniques described herein are by no means limited to telephone networks, but may be employed in any kind of communications network.
For present purposes, only two nodes 103 are interesting: node 103(a), which has just received a name 109(j) from terminal 105(m), and node 103(b), which has terminal 105(n) whose network address A 107(i) currently corresponds to name 107(j). In order to better distinguish the two nodes, node 103(a) will be termed hereinafter the source node and node 103(b) will be termed hereinafter the destination node. In source node 103(a), FIG. 1 shows those components which the techniques require in any node 103 which receives names from terminals 105; in destination node 103(b), FIG. 1 shows those components which the techniques require in any node 103 which serves network addresses represented by names.
In most embodiments, nodes 103 would contain both the components shown in node 103(a) and those shown in node 103(b).
Both nodes have a message interface 113 Message interface 113 has 3o two functions. First, it responds to other components of the nodes by making messages of the types required by the components and including data provided by the components in the nodes. Second, it responds to messages received in node by providing the data in the messages to the proper components of node 103.
The dashed lines of FIG. 1 show the messages which are of interest in the present context. In each case, the name of the message and that part of its contents which is relevant in the present context appear as labels on the dashed lines.
-6_ X109787 ~ Unknown Name Message (UNM) 129 from source node 103(a) to name server 119. The message specifies at least source node 103(x) and a name 109 which is unknown to source node 103(a).
~ Resolved Name Message (RNM) 131, which name server 109 sends in response to an unknown name message 129 from a node. The Resolved Name Message 131 contains at least the network address 107 corresponding to the name 109 in the unknown name message to which name server 119 is responding.
~ Call set-up message (CSM) 123 is a message from a source node 103(a) to a destination node 103(b) which sets up communication between the nodes. In t0 networks using the name translation techniques described herein, call set-up message 123 includes a name 109 and an address 107 corresponding to the name 109.
~ Call completion message (CCM) 125 is a message which destination node 103(b) sends in response to a call set up message 123. If the source node 103(a) can communicate with a terminal accessible to destination node 103(b), destination node 103(b) sends the call completion message 125 to the source node 103(a).
~ Unknown Destination Message (UDM) 127 is a message which destination node 103(b) sends to the source node in response to a call set up message 123 which contains a name 109 for which there is no corresponding network address 107 in the destination node.
~ Bad Destination Message (BDM) 121 is a message which destination node 103(b) sends to name server 119 to indicate that a correspondence between a name 109 and a network address 107 in name server 119 is no longer valid.
~ New Destination Message (NDM) 122 is a message which destination node 103(b) sends to name server 119 to announce a new correspondence between a name 109 and a network address 107 to the name server.
~ Acknowledge Message (ACK) 120 is a message which name server 119 sends to destination node 103(b) in response to a new destination message 122 or a bad destination message 121.
Again, in most embodiments, any node 103 will be capable of sending an unknown name message 129, a bad destination message 121, or a new destination message ~109787~-122, of receiving a resolved name message 131 or ~an acknowledge message 120, and of sending or receiving a call set-up message 123, a call completion message 125, or an unknown destination message 127.
Source node 103(a) further includes name translator 111. Name translator 111's function is to attempt to translate a name 109 received from a terminal 105 into a network address 107. If the attempt succeeds, node 103(a) sends a call set up message 123 containing at least the name to destination node 103(b) specified by the network address 107 resulting from the translation. If the attempt fails, node 103(a) sends an unknown name message 120 to name server 119. When 1o name server 119 responds with a resolved name message 131 containing the network address 107 corresponding to the name, source node 103 sends a call setup message 123 as just described and also updates name translator 111 so that the translation will succeed on the next attempt. The dotted arrows connecting name translator 111 show the flow of information between name translator 111 and message interface 113. Name invalid (NI) 108 results when message interface 113 receives an unknown destination message 127.
Destination node 103(b) further includes name verifier 114. Name verifier 114's function is to check whether a name 109 received in a call set up message 123 corresponds to a network address 107 served by destination node 103(b). If the name does correspond, destination node 103(b) sets up a connection to terminal 105 having the network address 107 and sends a call complete message to source node 103(a); if it does not, destination node 103(b) merely sends an unknown destination message to source node 103(a). Again, the dotted arrows between name verifier 114 and message interface 113(b) indicate the How of data. Name Valid/Invalid (NV} 115 indicates whether a name has been found to correspond to a network address which the node 103(b) serves.
Name translation in network 101 proceeds as follows:
1. When source node 103(a) receives a name 109 from a terminal 105, it employs name translator 111 to translate the name 109 into a network address 107.
Background of the Invention Field of the Invention The invention concerns name translation generally and more particularly name translation in communications networks.
Description of the Prior Art As networks have grown more complex, it has become more and more worthwhile to give users of the networks techniques for reaching other users which are not dependent on the actual addressing mechanisms used in the networks. One example of such a technique is the 800 number, described in detail in U.S. Patent 4,191,860, Roy P. Weber, Data Base Correrrwnication Call Processing Methad, issued March 4, 1980. The 800 number is not itself an actual telephone number, but instead represents an actual telephone number. When a telephone switch receives an 800 number, it sends a message with the 800 number to a network control point which contains a data base relating the 800 number to an actual telephone number.
The network control point returns a message to the switch which contains the actual telephone number corresponding to the 800 number, and the switch then uses the actual number to setup the telephone call. The fact that the 800 number is not an actual telephone number provides a high degree of flexibility: the number may be a mnemonic for the business which is using the 800 number, the business may change its actual telephone number without changing its 800 number, the 800 number may correspond to different actual telephone numbers in different parts of the country or at different times of day, and the 800 number may even correspond to more than one actual telephone number, with calls being divided among the actual telephone numbers according to a load balancing scheme.
Calls made using 800 numbers are already an important part of the business of telephone companies. Moreover, the growing need for portability in the telephone system will make numbers which work like the 800 number even more important. For instance, in the future, each person may be given a single lifetime telephone number which may be used to reach him no matter where he is. As more and more of the numbers used in the telephone system are numbers like 800 numbers, it becomes more and more important that the translation of such numbers _2_ ~109~8~
to the actual numbers be done as quickly and with as little extra network traffic as possible.
The problem of making the user of a network independent of the addressing mechanisms actually employed in the network is of course encountered in any network. The general solution is to establish a correspondence in the network between a name and a network address. In this context, a network address is a value used internally by the network to address a user of the network and a name is another value which is not itself a network address but represents a network address.
In the context of the telephone system, an actual telephone number is a network address l0 and an 800 number is a name. Once the correspondence between the network address and the name is established, a user of the system can provide the network with a name and the network can translate the name into its corresponding network address and then use the network address to establish communications between the user and the desired destination.
The component of the network in which the correspondence between a name and a network address is established is termed a name server. The name server maintains a list of names and their corresponding network addresses. When a node of the network sends the name server a message containing a name, the name server looks the name up in the list and returns a message containing the corresponding network address. In the context of the telephone system, the network control point is a name server for 800 numbers.
As with the telephone network, a critical issue in other networks which employ names is the efficiency of name translation, the translation of a name into the network address which it represents. The simplest way to do name translation is in the manner described above for 800 numbers, i.e., the network address is always obtained from the name server; difficulties with this technique include the time it takes to do a translation and the number of messages required to do it. As regards the time, the switch which has received the name must send the name to the name server and wait until the name server has returned the corresponding network address before it can begin communicating. As regards the number of messages, when a name is used instead of a network address, two extra messages must be sent before the switch can begin communicating.
One technique which has been used in the past to speed up translation is name caches in nodes of the network. In general terms, a name cache contains copies of some of the correspondences between names and network addresses from the name server. When a node receives a name, it looks first in the name cache. If 3 ~10978~
the name cache has a copy of the correspondence between the name and the network address, the node uses the network address from the cache to begin communications;
otherwise, it goes to the name server as described above. When the node obtains the corresponding address from the name server, it not only begins communications, but also adds the name and the corresponding address to the name cache. As may be seen from the foregoing, once a name is in the cache, the node can begin communicating without exchanging messages with the name server.
A difficulty with name caches is keeping the name-network address correspondences contained in a cache consistent with the name-network 1o correspondences presently in use in the network. For example, as mentioned above, in an 800 number system, the actual telephone number corresponding to an 800 number may vary according to a load-balancing scheme; when the relationship between the 800 number and the actual telephone number changes in the name server, it must also change in all of the name caches in the network. A prior-art solution to the problem has been to periodically invalidate part or all of the name cache (see for example U.S. Patent 4,706,801, Hart, et al., Method and Apparatus for Bridging Local Area Networks, issued Nov. 10, 1987). There, bridges connecting LANs have tables containing source and destination addresses for the stations connected to the LANs. If a bridge does not receive a frame containing one of the values in the table for a period of about 15 minutes, the value is deleted from the table. There are two difficulties with this approach: the first is that an invalid entry may remain in the table for up to fifteen minutes, and may be used by the system during that period. The second is that mere non-use of a source or destination address for a relatively short time may cause the address to be removed from the table. When the source or destination address is again used, it must again be incorporated into the table.
What is needed, and what is provided by the present invention, is a name translation technique which employs name caches, but which avoids the opportunities for error and the excess overhead associated with partial or complete name cache invalidation.
Summary of the Invention In one aspect, the invention is a method for determining whether a translation of a name into a network address done in a first node of a network is valid, the method including the steps of:
~10978~
~ sending a first message containing at least the name to a second node specified by the network address;
~ in the second node, determining whether the name corresponds to any network address served by the second node; and ~ when the name does not so correspond, sending a second message indicating that there is no correspondence to the first node.
Other aspects of the invention include the methods employed in the second node for generating the second message and in the first node for responding to the second message, methods for keeping the first and second nodes consistent with the name server, and apparatus for performing name translation in the first node and name verification in the second node. A further aspect of the invention is a generalization of the techniques for use in any situation in which one value is automatically translated into another value.
In accordance with one aspect of the present invention there is provided a method for processing a name in a network that includes a plurality of nodes, comprising the steps of: translating at a first node the name of a network address that specifies a second node; sending from the first node to the second node a first message that includes the name; determining at the second node if the name corresponds to any network address served by the second node; and if the name does not so correspond, then sending from the second node to the first node a second message indicating that there is no correspondence between the name and the network address at the second node.
In accordance with another aspect of the present invention there is provided a communications network of the type wherein network addresses may be represented by names and nodes of the network may exchange messages, the communications network being characterized by: means in a first one of the nodes for translating a name into a network address and sending a first message including the name to a second one of the nodes which is specified by the network address; and means in A
-4a-the second node responsive to the first message for determining whether the name corresponds to any network address served by the second node and when the name does not so correspond, sending a second message indicating that there is no correspondence to the first node.
Brief Description of the Drawings FIG. 1 is an overview of a network in which the invention is employed;
FIG. 2 presents details of name translator 111; and FIG. 3 presents details of name verifier 114.
The reference numbers employed in the Drawings and the Detailed Description have three or more digits. The two least significant digits are a number within a figure; the remaining digits are the figure number. Thus, the element with the reference number "305" is first shown in FIG. 3.
Detailed Description The following Detailed Description will first present an overview of a network in which the name translation techniques are implemented and of the use of the techniques in the network. Thereupon, it will present details of a presently-preferred implementation of the techniques.
~10978~-Overview: FIG. 1 FIG. 1 shows a network 101 in which the name translation techniques are implemented. Network 101 is made up of some number of nodes 103, which are connected by a connection path 117. Dashed lines represent messages which move between components of network 101; the messages may move via connection paths 117 or by means of separate communications paths. Each node further has terminals 105 connected to it. Each terminal 105 has a network address 107, by means of which it is addressed in the network. Some or all terminals 105 may also be represented by a name 109. The currently-valid correspondences between names l0 109 and network addresses 107 are maintained in name server 119, which is accessible to all of the nodes 103 in the network. Network 101 may be understood in concrete terms as a telephone network; in such an embodiment, nodes 103 are switches, terminals 105 are devices such as telephones, names are numbers such as 800 numbers, network addresses are actual telephone numbers, and name server is a data base in a network control point. However, as will be apparent to those of ordinary skill in the art, the techniques described herein are by no means limited to telephone networks, but may be employed in any kind of communications network.
For present purposes, only two nodes 103 are interesting: node 103(a), which has just received a name 109(j) from terminal 105(m), and node 103(b), which has terminal 105(n) whose network address A 107(i) currently corresponds to name 107(j). In order to better distinguish the two nodes, node 103(a) will be termed hereinafter the source node and node 103(b) will be termed hereinafter the destination node. In source node 103(a), FIG. 1 shows those components which the techniques require in any node 103 which receives names from terminals 105; in destination node 103(b), FIG. 1 shows those components which the techniques require in any node 103 which serves network addresses represented by names.
In most embodiments, nodes 103 would contain both the components shown in node 103(a) and those shown in node 103(b).
Both nodes have a message interface 113 Message interface 113 has 3o two functions. First, it responds to other components of the nodes by making messages of the types required by the components and including data provided by the components in the nodes. Second, it responds to messages received in node by providing the data in the messages to the proper components of node 103.
The dashed lines of FIG. 1 show the messages which are of interest in the present context. In each case, the name of the message and that part of its contents which is relevant in the present context appear as labels on the dashed lines.
-6_ X109787 ~ Unknown Name Message (UNM) 129 from source node 103(a) to name server 119. The message specifies at least source node 103(x) and a name 109 which is unknown to source node 103(a).
~ Resolved Name Message (RNM) 131, which name server 109 sends in response to an unknown name message 129 from a node. The Resolved Name Message 131 contains at least the network address 107 corresponding to the name 109 in the unknown name message to which name server 119 is responding.
~ Call set-up message (CSM) 123 is a message from a source node 103(a) to a destination node 103(b) which sets up communication between the nodes. In t0 networks using the name translation techniques described herein, call set-up message 123 includes a name 109 and an address 107 corresponding to the name 109.
~ Call completion message (CCM) 125 is a message which destination node 103(b) sends in response to a call set up message 123. If the source node 103(a) can communicate with a terminal accessible to destination node 103(b), destination node 103(b) sends the call completion message 125 to the source node 103(a).
~ Unknown Destination Message (UDM) 127 is a message which destination node 103(b) sends to the source node in response to a call set up message 123 which contains a name 109 for which there is no corresponding network address 107 in the destination node.
~ Bad Destination Message (BDM) 121 is a message which destination node 103(b) sends to name server 119 to indicate that a correspondence between a name 109 and a network address 107 in name server 119 is no longer valid.
~ New Destination Message (NDM) 122 is a message which destination node 103(b) sends to name server 119 to announce a new correspondence between a name 109 and a network address 107 to the name server.
~ Acknowledge Message (ACK) 120 is a message which name server 119 sends to destination node 103(b) in response to a new destination message 122 or a bad destination message 121.
Again, in most embodiments, any node 103 will be capable of sending an unknown name message 129, a bad destination message 121, or a new destination message ~109787~-122, of receiving a resolved name message 131 or ~an acknowledge message 120, and of sending or receiving a call set-up message 123, a call completion message 125, or an unknown destination message 127.
Source node 103(a) further includes name translator 111. Name translator 111's function is to attempt to translate a name 109 received from a terminal 105 into a network address 107. If the attempt succeeds, node 103(a) sends a call set up message 123 containing at least the name to destination node 103(b) specified by the network address 107 resulting from the translation. If the attempt fails, node 103(a) sends an unknown name message 120 to name server 119. When 1o name server 119 responds with a resolved name message 131 containing the network address 107 corresponding to the name, source node 103 sends a call setup message 123 as just described and also updates name translator 111 so that the translation will succeed on the next attempt. The dotted arrows connecting name translator 111 show the flow of information between name translator 111 and message interface 113. Name invalid (NI) 108 results when message interface 113 receives an unknown destination message 127.
Destination node 103(b) further includes name verifier 114. Name verifier 114's function is to check whether a name 109 received in a call set up message 123 corresponds to a network address 107 served by destination node 103(b). If the name does correspond, destination node 103(b) sets up a connection to terminal 105 having the network address 107 and sends a call complete message to source node 103(a); if it does not, destination node 103(b) merely sends an unknown destination message to source node 103(a). Again, the dotted arrows between name verifier 114 and message interface 113(b) indicate the How of data. Name Valid/Invalid (NV} 115 indicates whether a name has been found to correspond to a network address which the node 103(b) serves.
Name translation in network 101 proceeds as follows:
1. When source node 103(a) receives a name 109 from a terminal 105, it employs name translator 111 to translate the name 109 into a network address 107.
2. If the translation succeeds, source node 103(a) sends a call set up message to the destination node 103(b) specified in the network address 107 into which the name 109 was translated.
3. If the translation fails, source node 103(a) sends an unknown name message 129 with the name 109 to name server 119; when source node 103(a) receives the resolved name message 131, it sends the call set up message using the network address 107 contained in the resolved name message 131 and adds the name to the set of names which can be translated by name translator 111.
4. When destination node 103(b) receives a call set up message 123 from another node 103 which contains a name 109, it employs name verifier 114 to determine whether destination node 103(b) serves a network address 107 corresponding to the name 109; if it does, it sends a call complete message to the other node 103; otherwise, it sends the unknown destination message 127 to the other node 103 which contains the name 109 for which there was no correspondence.
S. When source node 103(a) receives an unknown destination message 127, it proceeds as described for a failed translation above.
While the foregoing method can deal with the situation where a name 109 no longer corresponds to any address 107 served by the destination node, it cannot handle the situation where the name corresponds to a different address 107 served by the destination node. The latter situation can be dealt with by giving not only name 109 from call set up message 123 to name verifier 114, but also address 107, and having name verifier 114 verify that the name-network address correspondence from call set-up message 123 matches a name-network address correspondence known to name verifier 114.
A fundamental assumption in the procedure just described is that an unknown destination message 127 is produced whenever name verifier 114 cannot verify the name in the call set up message 123. This assumption ensures that network 101 will work correctly even when there are changes in correspondences between names 109 and network addresses 107. An advantageous way of dealing with such changes is the following:
1. A change in a correspondence between a name and a network address 107 is first indicated to the destination node 103(b) for the network address, as indicated by the arrow NC (name change) 133 in FIG. 1. There are two ways in which a correspondence may change: it may be deleted from node 103(b) or it may be added to node 103(b);
2. In the case of a deletion, ~'! 09787 a. node 103(b) i. removes the correspondence from name verifier 114; and ii. sends a bad destination message 121 with the name 109 belonging to the deleted correspondence to name server 119;
b. server 119 i. invalidates the correspondence for the name 109 in name server 119 and ceases providing resolved name messages 131 for the name 109 until there is a valid correspondence for the name 109 in name server 119; and ii. sends an acknowledge message 120 with the name 109 and the corresponding address 107 to node 103(b); and 3. in the case of an addition, a. node 103(b) i. adds the correspondence to name verifier 114; and ii. sends a new destination message 122 with the new correspondence to name server 119;
b. server 119 i. adds the new correspondence to name server 119 and again begins providing resolved name messages 131 for the name 109; and ii. sends an acknowledge message 120 with the name 109 and the corresponding address 107 to node 103(b).
To ensure consistency, name server 119 may require that it have both bad destination message 121 and new destination message 122 for a name before it changes the name-network address correspondence for the name and may further even require that it have first received message 121 and then message 122.
During the period in which name server 119 is changing a name-network address correspondence, it does not respond to unknown name messages 129 for the name in the correspondence. If node 103(a) fails to name message 129 to name receive a resolved name message 131 back within a reasonable period after it __ _lo_ ~'~ 09787 has sent an unknown name message 129, it again sends unknown name message 129.
Similarly, if node 103(b) sends a bad destination message 121 or a new destination message 122 and receives no acknowledgement message 120 within a reasonable period, it again sends the bad destination or new destination message.
In many cases, the change in correspondence between a name 109 and a network address 107 will involve a change of nodes 103(b); in that case, the old correspondence will be deleted from a first node 103(b) and a new correspondence will be added to a second node 103(b). The first node will then send the bad destination message 121 and the second the new destination message 122. If the change does not involve a change of node, the old correspondence will be deleted from and the new correspondence will be added to the same node and messages and 122 will both be sent from that node.
The above technique works because the old and new destination nodes 103(b) will provide unknown destination messages 127 to a source node 103 from the time they change the correspondences in node verifier 114 until the time that the contents of name translator 111 in the source node agree with the contents of name server 119. Any other technique which achieves the same result may also be employed to change correspondences between names 109 and network addresses 107.
Details of Name Translator 111: FIG. 2 FIG. 2 shows details of name translator 111 in a preferred embodiment.
The main component of name translator 111 is name cache (NC) 201. Name cache 201 is a set of copies of information from name server 119. In a preferred embodiment, the information includes at a minimum correspondences of names 109 and network addresses 107. Other information which may be associated with a name 109 in name server 119 and in name cache 201 includes billing information and information describing the service associated with the name 109. For example, if different network addresses are valid at different times of the day, the entry may contain a list of the network addresses and the times at which they are valid.
A copy of the information for each name 109 is contained in a name cache entry (NCE) for the name. A name cache entry 203 may further contain information such as a valid bit (not shown) which indicates whether the correspondence between the name and the information in name cache entry 203 is still valid.
Name cache 201 may be contained in memory belonging to a processor in node 203, or it may be implemented in special high-speed cache memory hardware. Implementation of caches is generally well-understood in the art.
For example, if the name cache is implemented in general-purpose memory, it can be implemented as a sorted list of names or as a hash table; if it is implemented in special hardware, content-addressable memories may be employed.
The two other components of name translator 111 are made up of code executing on a processor in node 203. The first component, name translation code 207, actually performs translations using name cache 201; the second component, name cache maintenance code 219, keeps the name-network address corresponences in name cache 201 current. Arrows pointing into or out of components 207 and show the flow of data to and from those components. The division between the to components in FIG. 2 is logical, i.e.> by the function of the component.
Depending on the embodiment, the two components may be parts of a single code module or may be contained in separate code modules. The code may further be executed by a single process or task or by a separate process or task for each component.
Again, depending on the embodiment, communication between the components may be by means of function invocations or inter-process communications.
Operation of name translator 111 is as follows: when a node 103 receives a name 109 from a terminal 105, the name goes to name translation code 207, as shown by arrow 217. Name translation code 207 presents the name 109 to name cache 201, as shown by arrow 209; if there is a valid name cache entry 203 for the name 109, name translation code 207 obtains the corresponding address 205 for the name, as shown by arrow 211. Name translation code 211 then provides the name 109 and the corresponding address 205 to message interface 113(a), which uses the name 109 and address 107 in a call set up message 123 for the node specified by corresponding address 205, as shown by arrows 213 and 215. If there is no valid name cache entry 203 for the name 109, name translation code 207 provides the name to name cache maintenance code 219 (arrow 21$).
When name cache maintenance code 219 receives the name from name translation code 207, it provides the name to message interface 113(a), which sends an unknown name message 129 containing the name 109 to name server 119 (arrow 225). If there is a name-network address correspondence for the name 109 in name server 119, name server 119 sends a resolved name message 131 to message interface 113; on receipt of resolved name message 131, message interface 113 provides at least the corresponding address 205 from the resolved name message to name cach maintenance code 219 (arrow 227). Name cache maintenance code 219 then makes a name cache entry 203 using the name 109 and the corresponding address 205 and places the entry 203 in the proper location in name cache 201 (arrow _~2_ ~~ aa~s~
221). Thereupon, name cache maintenance code 219 again provides name 109 to name translation code 207 (arrow 217), which again presents it to name cache 201 as previously described. This time, there is an entry 203 for the name 109, and consequently, name translation code 207 provides the name and the address 205 to message interface 113, as described above.
The other situation in which name cache maintenance code 219 must maintain name cache 201 is when node 103(a) receives an unknown destination message 127 containing a name 109. In that situation, message interface 113(a) provides the name to name cache maintenance code 219 (arrow 223), which invalidates name cache entry 203 and then proceeds in the same fashion as described above for a name received from name translation code 207. As indicated there, after the new name cache entry 203 has been made and placed in name cache 201, the name 109 is again provided to name translation code 207 for translation.
The approach described above for names 109 and network addresses 107 can be used with any information in name cache entry 203 for the name. For example, billing information in name cache entry 203 might be used in a message sent by node 103(a) to a component of network 101 which handles billing; if that component detected that the billing information was incorrect, it could provide an "incorrect billing information" message to node 103(a) to which name cache maintenance code 219 would respond in a fashion similar to that in which it responds to an unknown destination message 127: as in that case, name translator 111 would obtain the correct information from name server 119 (or some other location in the network which contained the information) and update the information in name cache entry 203 for the name. Indeed, the "incorrect billing information"
message might itself contain the information needed to update name cache entry 203.
Details of Name Verifier 114: FIG. 3 FIG. 3 shows details of name verifier 114. As is apparent from the figure, name verifier 114 has an overall structure similar to that of name translator 111. The main component is local name table 301, which has a local name table entry 303 for each name 109 which corresponds to a network address (LCA 305) served by node 103 containing name verifier 114. In some embodiments, the entry 305 may contain only the name; in others, it may additionally contain local corresponding address 305 and may further contain a valid bit. Local name table 301 may be implemented using the techniques described for name cache 201.
Indeed, since most nodes 103 will contain both a name cache 201 and a local name table 301 and since a node 103 needs to translate names 109 corresponding to local _t3_ X109787 network addresses as well as names 109 corresponding to non-local network addresses, it may be advantageous to implement local name table 301 in whole or in part within name cache 201. In such an implementation, each name cache entry would additionally contain a flag indicating whether it was a local name table entry 303.
The code components of name verifier 114 are name verification code 307, which verifies names 109 received in call set up messages 123, and local name table maintenance code 321, which maintains local name table 301 in response to name changes 133 received in node 103(b). As was the case with name translator 11 l, the components are functionally distinguished, and may be implemented using the same techniques as described for the code components of name translator 111.
Again, arrows show the flow of data.
Operation of name verifier 114 is as follows: when message interface 113 receives a call set up message 123 containing a name 109 and an address 205, it provides at least the name 109 and perhaps also the address 205 to name verification code 307 (arrow 309). Name verification code 307 presents the name 109 to local name table 301 (arrow 311); if there is a local name table entry 303 for the name 109, the name has a corresponding local network address 305. When address 205 is also provided, name verification code 307 not only confirms that there is an entry 303 for the name 109, but also that address 205 matches local corresponding address 305. Both forms of verification are indicated by arrow 313 If the verification of the name 109 is successful, name verification code 307 indicates that fact to message interface 113 (arrow 319), which responds to the indication by sending a call complete message 125 back to the node 103 from which name 109 came. If the verification of the name 109 fails, name verification code 307 provides the name 109 to message interface 113 (arrow 317), which sends an unknown destination message 127 containing the name back to the node 103 from which name 109 came.
In the embodiment presently being described, local name table maintenance code 321 maintains local name table 301 in response to name changes 133 received in node 103(b). Each name change specifies whether the correspondence for the name 109 is to be deleted from local name table 301 or whether a correspondence for the name 109 is to be added to local name table 301.
When a correspondence is to be deleted, only the name need be supplied; when one is to be added, both the name 109 and the network address 107 are necessary.
As shown by arrows 325 and 327, local name table maintenance code 321 responds to a name change 133 specifying that a name be deleted by locating local name table entry 303 for the name and invalidating it and then sending a bad destination message 121 containing at least the name to name server 119. Local name table maintenance code 321 responds to a name change 133 specifying that a name be added by adding a local name table entry 303 for the name and the corresponding network address and then sending a new destination message 122 containing the name and the network address to name server 119. As shown by arrow 323, if the proper acknowledgement message 120 is not received from name server 119, local name table maintenance code 321 again sends the bad destination message 121 or the new destination message 122.
Conclusion The foregoing Detailed Description has disclosed to one of ordinary skill in the art techniques for determining whether a name translation carried out in a network node is valid and the best mode currently known to the inventor for implementing those techniques. The techniques are examples of a general name translation technique in which the name is first translated using a source which is easily available but may be wrong. The result is then used in a fashion in which a wrong result will be detected, and when a wrong result is detected, the name is again translated using a more reliable but less easily available source.
As will be immediately apparent to those of ordinary skill in the art, the general name translation techniques described herein have uses outside the context of networks and the specific examples given herein may be implemented in networks other than the one disclosed herein. Other implementations of the name translation and name verification components disclosed herein are also possible.
For example, in the disclosed embodiment, a name server is the source of currently-correct correspondences between names and network addresses, the source node responds to an unknown destination message by obtaining the correct correspondence from the name server, and changes in correspondences between names and network addresses are made first in the destination node; in other embodiments, the changes in correspondences may be made first in the name server and the manner in which changes in correspondences are propagated may be different from what is described herein; further, in some embodiments, there may not be a name server. In such an embodiment, the source node might respond to an unknown destination message by sending a broadcast message to all other nodes to determine which node currently has a network address corresponding to the name, and the node having the corresponding network address might send a message to the ~10978~' broadcasting node. Since there are many possible embodiments of the basic principles of the techniques disclosed herein, the foregoing Detailed Description is to be regarded as being in all respects illustrative and exemplary, and not restrictive, and the scope of the invention disclosed herein is to be determined solely by the appended claims as interpreted in light of the Specification and according to the doctrine of equivalents.
What is claimed is:
FILE: fraag016us.1
S. When source node 103(a) receives an unknown destination message 127, it proceeds as described for a failed translation above.
While the foregoing method can deal with the situation where a name 109 no longer corresponds to any address 107 served by the destination node, it cannot handle the situation where the name corresponds to a different address 107 served by the destination node. The latter situation can be dealt with by giving not only name 109 from call set up message 123 to name verifier 114, but also address 107, and having name verifier 114 verify that the name-network address correspondence from call set-up message 123 matches a name-network address correspondence known to name verifier 114.
A fundamental assumption in the procedure just described is that an unknown destination message 127 is produced whenever name verifier 114 cannot verify the name in the call set up message 123. This assumption ensures that network 101 will work correctly even when there are changes in correspondences between names 109 and network addresses 107. An advantageous way of dealing with such changes is the following:
1. A change in a correspondence between a name and a network address 107 is first indicated to the destination node 103(b) for the network address, as indicated by the arrow NC (name change) 133 in FIG. 1. There are two ways in which a correspondence may change: it may be deleted from node 103(b) or it may be added to node 103(b);
2. In the case of a deletion, ~'! 09787 a. node 103(b) i. removes the correspondence from name verifier 114; and ii. sends a bad destination message 121 with the name 109 belonging to the deleted correspondence to name server 119;
b. server 119 i. invalidates the correspondence for the name 109 in name server 119 and ceases providing resolved name messages 131 for the name 109 until there is a valid correspondence for the name 109 in name server 119; and ii. sends an acknowledge message 120 with the name 109 and the corresponding address 107 to node 103(b); and 3. in the case of an addition, a. node 103(b) i. adds the correspondence to name verifier 114; and ii. sends a new destination message 122 with the new correspondence to name server 119;
b. server 119 i. adds the new correspondence to name server 119 and again begins providing resolved name messages 131 for the name 109; and ii. sends an acknowledge message 120 with the name 109 and the corresponding address 107 to node 103(b).
To ensure consistency, name server 119 may require that it have both bad destination message 121 and new destination message 122 for a name before it changes the name-network address correspondence for the name and may further even require that it have first received message 121 and then message 122.
During the period in which name server 119 is changing a name-network address correspondence, it does not respond to unknown name messages 129 for the name in the correspondence. If node 103(a) fails to name message 129 to name receive a resolved name message 131 back within a reasonable period after it __ _lo_ ~'~ 09787 has sent an unknown name message 129, it again sends unknown name message 129.
Similarly, if node 103(b) sends a bad destination message 121 or a new destination message 122 and receives no acknowledgement message 120 within a reasonable period, it again sends the bad destination or new destination message.
In many cases, the change in correspondence between a name 109 and a network address 107 will involve a change of nodes 103(b); in that case, the old correspondence will be deleted from a first node 103(b) and a new correspondence will be added to a second node 103(b). The first node will then send the bad destination message 121 and the second the new destination message 122. If the change does not involve a change of node, the old correspondence will be deleted from and the new correspondence will be added to the same node and messages and 122 will both be sent from that node.
The above technique works because the old and new destination nodes 103(b) will provide unknown destination messages 127 to a source node 103 from the time they change the correspondences in node verifier 114 until the time that the contents of name translator 111 in the source node agree with the contents of name server 119. Any other technique which achieves the same result may also be employed to change correspondences between names 109 and network addresses 107.
Details of Name Translator 111: FIG. 2 FIG. 2 shows details of name translator 111 in a preferred embodiment.
The main component of name translator 111 is name cache (NC) 201. Name cache 201 is a set of copies of information from name server 119. In a preferred embodiment, the information includes at a minimum correspondences of names 109 and network addresses 107. Other information which may be associated with a name 109 in name server 119 and in name cache 201 includes billing information and information describing the service associated with the name 109. For example, if different network addresses are valid at different times of the day, the entry may contain a list of the network addresses and the times at which they are valid.
A copy of the information for each name 109 is contained in a name cache entry (NCE) for the name. A name cache entry 203 may further contain information such as a valid bit (not shown) which indicates whether the correspondence between the name and the information in name cache entry 203 is still valid.
Name cache 201 may be contained in memory belonging to a processor in node 203, or it may be implemented in special high-speed cache memory hardware. Implementation of caches is generally well-understood in the art.
For example, if the name cache is implemented in general-purpose memory, it can be implemented as a sorted list of names or as a hash table; if it is implemented in special hardware, content-addressable memories may be employed.
The two other components of name translator 111 are made up of code executing on a processor in node 203. The first component, name translation code 207, actually performs translations using name cache 201; the second component, name cache maintenance code 219, keeps the name-network address corresponences in name cache 201 current. Arrows pointing into or out of components 207 and show the flow of data to and from those components. The division between the to components in FIG. 2 is logical, i.e.> by the function of the component.
Depending on the embodiment, the two components may be parts of a single code module or may be contained in separate code modules. The code may further be executed by a single process or task or by a separate process or task for each component.
Again, depending on the embodiment, communication between the components may be by means of function invocations or inter-process communications.
Operation of name translator 111 is as follows: when a node 103 receives a name 109 from a terminal 105, the name goes to name translation code 207, as shown by arrow 217. Name translation code 207 presents the name 109 to name cache 201, as shown by arrow 209; if there is a valid name cache entry 203 for the name 109, name translation code 207 obtains the corresponding address 205 for the name, as shown by arrow 211. Name translation code 211 then provides the name 109 and the corresponding address 205 to message interface 113(a), which uses the name 109 and address 107 in a call set up message 123 for the node specified by corresponding address 205, as shown by arrows 213 and 215. If there is no valid name cache entry 203 for the name 109, name translation code 207 provides the name to name cache maintenance code 219 (arrow 21$).
When name cache maintenance code 219 receives the name from name translation code 207, it provides the name to message interface 113(a), which sends an unknown name message 129 containing the name 109 to name server 119 (arrow 225). If there is a name-network address correspondence for the name 109 in name server 119, name server 119 sends a resolved name message 131 to message interface 113; on receipt of resolved name message 131, message interface 113 provides at least the corresponding address 205 from the resolved name message to name cach maintenance code 219 (arrow 227). Name cache maintenance code 219 then makes a name cache entry 203 using the name 109 and the corresponding address 205 and places the entry 203 in the proper location in name cache 201 (arrow _~2_ ~~ aa~s~
221). Thereupon, name cache maintenance code 219 again provides name 109 to name translation code 207 (arrow 217), which again presents it to name cache 201 as previously described. This time, there is an entry 203 for the name 109, and consequently, name translation code 207 provides the name and the address 205 to message interface 113, as described above.
The other situation in which name cache maintenance code 219 must maintain name cache 201 is when node 103(a) receives an unknown destination message 127 containing a name 109. In that situation, message interface 113(a) provides the name to name cache maintenance code 219 (arrow 223), which invalidates name cache entry 203 and then proceeds in the same fashion as described above for a name received from name translation code 207. As indicated there, after the new name cache entry 203 has been made and placed in name cache 201, the name 109 is again provided to name translation code 207 for translation.
The approach described above for names 109 and network addresses 107 can be used with any information in name cache entry 203 for the name. For example, billing information in name cache entry 203 might be used in a message sent by node 103(a) to a component of network 101 which handles billing; if that component detected that the billing information was incorrect, it could provide an "incorrect billing information" message to node 103(a) to which name cache maintenance code 219 would respond in a fashion similar to that in which it responds to an unknown destination message 127: as in that case, name translator 111 would obtain the correct information from name server 119 (or some other location in the network which contained the information) and update the information in name cache entry 203 for the name. Indeed, the "incorrect billing information"
message might itself contain the information needed to update name cache entry 203.
Details of Name Verifier 114: FIG. 3 FIG. 3 shows details of name verifier 114. As is apparent from the figure, name verifier 114 has an overall structure similar to that of name translator 111. The main component is local name table 301, which has a local name table entry 303 for each name 109 which corresponds to a network address (LCA 305) served by node 103 containing name verifier 114. In some embodiments, the entry 305 may contain only the name; in others, it may additionally contain local corresponding address 305 and may further contain a valid bit. Local name table 301 may be implemented using the techniques described for name cache 201.
Indeed, since most nodes 103 will contain both a name cache 201 and a local name table 301 and since a node 103 needs to translate names 109 corresponding to local _t3_ X109787 network addresses as well as names 109 corresponding to non-local network addresses, it may be advantageous to implement local name table 301 in whole or in part within name cache 201. In such an implementation, each name cache entry would additionally contain a flag indicating whether it was a local name table entry 303.
The code components of name verifier 114 are name verification code 307, which verifies names 109 received in call set up messages 123, and local name table maintenance code 321, which maintains local name table 301 in response to name changes 133 received in node 103(b). As was the case with name translator 11 l, the components are functionally distinguished, and may be implemented using the same techniques as described for the code components of name translator 111.
Again, arrows show the flow of data.
Operation of name verifier 114 is as follows: when message interface 113 receives a call set up message 123 containing a name 109 and an address 205, it provides at least the name 109 and perhaps also the address 205 to name verification code 307 (arrow 309). Name verification code 307 presents the name 109 to local name table 301 (arrow 311); if there is a local name table entry 303 for the name 109, the name has a corresponding local network address 305. When address 205 is also provided, name verification code 307 not only confirms that there is an entry 303 for the name 109, but also that address 205 matches local corresponding address 305. Both forms of verification are indicated by arrow 313 If the verification of the name 109 is successful, name verification code 307 indicates that fact to message interface 113 (arrow 319), which responds to the indication by sending a call complete message 125 back to the node 103 from which name 109 came. If the verification of the name 109 fails, name verification code 307 provides the name 109 to message interface 113 (arrow 317), which sends an unknown destination message 127 containing the name back to the node 103 from which name 109 came.
In the embodiment presently being described, local name table maintenance code 321 maintains local name table 301 in response to name changes 133 received in node 103(b). Each name change specifies whether the correspondence for the name 109 is to be deleted from local name table 301 or whether a correspondence for the name 109 is to be added to local name table 301.
When a correspondence is to be deleted, only the name need be supplied; when one is to be added, both the name 109 and the network address 107 are necessary.
As shown by arrows 325 and 327, local name table maintenance code 321 responds to a name change 133 specifying that a name be deleted by locating local name table entry 303 for the name and invalidating it and then sending a bad destination message 121 containing at least the name to name server 119. Local name table maintenance code 321 responds to a name change 133 specifying that a name be added by adding a local name table entry 303 for the name and the corresponding network address and then sending a new destination message 122 containing the name and the network address to name server 119. As shown by arrow 323, if the proper acknowledgement message 120 is not received from name server 119, local name table maintenance code 321 again sends the bad destination message 121 or the new destination message 122.
Conclusion The foregoing Detailed Description has disclosed to one of ordinary skill in the art techniques for determining whether a name translation carried out in a network node is valid and the best mode currently known to the inventor for implementing those techniques. The techniques are examples of a general name translation technique in which the name is first translated using a source which is easily available but may be wrong. The result is then used in a fashion in which a wrong result will be detected, and when a wrong result is detected, the name is again translated using a more reliable but less easily available source.
As will be immediately apparent to those of ordinary skill in the art, the general name translation techniques described herein have uses outside the context of networks and the specific examples given herein may be implemented in networks other than the one disclosed herein. Other implementations of the name translation and name verification components disclosed herein are also possible.
For example, in the disclosed embodiment, a name server is the source of currently-correct correspondences between names and network addresses, the source node responds to an unknown destination message by obtaining the correct correspondence from the name server, and changes in correspondences between names and network addresses are made first in the destination node; in other embodiments, the changes in correspondences may be made first in the name server and the manner in which changes in correspondences are propagated may be different from what is described herein; further, in some embodiments, there may not be a name server. In such an embodiment, the source node might respond to an unknown destination message by sending a broadcast message to all other nodes to determine which node currently has a network address corresponding to the name, and the node having the corresponding network address might send a message to the ~10978~' broadcasting node. Since there are many possible embodiments of the basic principles of the techniques disclosed herein, the foregoing Detailed Description is to be regarded as being in all respects illustrative and exemplary, and not restrictive, and the scope of the invention disclosed herein is to be determined solely by the appended claims as interpreted in light of the Specification and according to the doctrine of equivalents.
What is claimed is:
FILE: fraag016us.1
Claims (31)
1. A method for processing a name in a network that includes a plurality of nodes, comprising the steps of:
translating at a first node said name into a first network address that specifies a second node;
sending from the first node to the second node a first message that includes said name;
determining at the second node if said name corresponds to any second network address served by the second node; and if said name does not so correspond, then sending from the second node to the first node a second message indicating that there is no correspondence between the name and any second network address served by the second node.
translating at a first node said name into a first network address that specifies a second node;
sending from the first node to the second node a first message that includes said name;
determining at the second node if said name corresponds to any second network address served by the second node; and if said name does not so correspond, then sending from the second node to the first node a second message indicating that there is no correspondence between the name and any second network address served by the second node.
2. The method set forth in claim 1 further comprising the step of:
in the first node, responding to the second message by again performing the translation.
in the first node, responding to the second message by again performing the translation.
3. The method set forth in claim 2 wherein:
the step of again performing the translation in the first node includes the step of obtaining the first network address corresponding to said name from a server.
the step of again performing the translation in the first node includes the step of obtaining the first network address corresponding to said name from a server.
4. The method set forth in claim 3 wherein:
the translation of said name is done in a name cache in the first node; and the step of again performing the translation in the first node further includes the step of adding the first network address obtained from the name server to the name cache.
the translation of said name is done in a name cache in the first node; and the step of again performing the translation in the first node further includes the step of adding the first network address obtained from the name server to the name cache.
5. The method set forth in claim 3 wherein a correspondence between said name and the second network address is changed in the second node, and further comprising the steps of:
determining if a correspondence between said name and the second network address has changed in the second node;
if a correspondence is determined to have changed, then sending from the second node to the name server a third message indicating that the correspondence has changed between said name and the second network address.
determining if a correspondence between said name and the second network address has changed in the second node;
if a correspondence is determined to have changed, then sending from the second node to the name server a third message indicating that the correspondence has changed between said name and the second network address.
6. The method set forth in any of claims 1, 2, 3, 4 or 5 wherein:
the first message further includes the first network address;
and the method further includes the steps of:
in the second node, if said name corresponds to any second network address served by the second node, determining whether that second network address is the same as the first network address included in the first message; and sending the second message when that second network address is not the same as the first network address included in the first message.
the first message further includes the first network address;
and the method further includes the steps of:
in the second node, if said name corresponds to any second network address served by the second node, determining whether that second network address is the same as the first network address included in the first message; and sending the second message when that second network address is not the same as the first network address included in the first message.
7. A method for processing a name in a network that has a plurality of nodes, comprising the steps of:
receiving at a second node from a first node a first message that includes said name;
determining if the name received in the first message corresponds to any second network address served by the second node;
if the name does not correspond to any second network address served by the second node, then sending a second message from the second node to the first node indicating that there is no correspondence between the name and any second network address served by the second node.
receiving at a second node from a first node a first message that includes said name;
determining if the name received in the first message corresponds to any second network address served by the second node;
if the name does not correspond to any second network address served by the second node, then sending a second message from the second node to the first node indicating that there is no correspondence between the name and any second network address served by the second node.
8. The method set forth in claim 7 wherein:
the first message further includes the first network address;
and the method further includes the steps performed in the second node of:
if the name corresponds to any second network address served by the second node, determining whether that second network address is the same as the first network address included in the first message; and sending the second message when that second network address is not the same as the first network address included in the first message.
the first message further includes the first network address;
and the method further includes the steps performed in the second node of:
if the name corresponds to any second network address served by the second node, determining whether that second network address is the same as the first network address included in the first message; and sending the second message when that second network address is not the same as the first network address included in the first message.
9. The method set forth in claim 7 wherein:
correspondences between names and network addresses are maintained in a name server; and the method further includes the step of:
when a correspondence changes in the second node, sending a third message indicating the change from the second node to the name server.
correspondences between names and network addresses are maintained in a name server; and the method further includes the step of:
when a correspondence changes in the second node, sending a third message indicating the change from the second node to the name server.
10. A method for translating a name into a first network address in a first node of a network, the method comprising the steps performed in the first node of:
translating the name into the first network address;
sending a first message containing at least the name to a second node specified by the first network address;
on receipt of a second message from the second node indicating that the name does not properly specify a second network address served by the second node, again performing the translation.
translating the name into the first network address;
sending a first message containing at least the name to a second node specified by the first network address;
on receipt of a second message from the second node indicating that the name does not properly specify a second network address served by the second node, again performing the translation.
11. The method set forth in claim 10 further including the step of:
in the first node, responding to the second message by again performing the translation.
in the first node, responding to the second message by again performing the translation.
12. The method set forth in claim 11 wherein:
the step of again performing the translation in the first node includes the step of obtaining the first network address corresponding to the name from a name server.
the step of again performing the translation in the first node includes the step of obtaining the first network address corresponding to the name from a name server.
13. The method set forth in claim 12 wherein:
the step of translating the name is done using a name cache in the first node;
and the step of again performing the translation in the first node further includes the step of adding the first network address obtained from the name server to the name cache.
the step of translating the name is done using a name cache in the first node;
and the step of again performing the translation in the first node further includes the step of adding the first network address obtained from the name server to the name cache.
14. The method set forth in any of claims 10, 11, 12 or 13 wherein:
the first message further includes the first network address; and the second message is also received when any second network address corresponding to the name in the second node is not the same as the first network address included in the first message.
the first message further includes the first network address; and the second message is also received when any second network address corresponding to the name in the second node is not the same as the first network address included in the first message.
15. A communications network of a type wherein network addresses may be represented by names and nodes of the network may exchange messages, the communications network being characterized by:
means in a first one of the nodes for translating a name into a first network address and sending a first message including the name to a second one of the nodes which is specified by the first network address; and means in the second node responsive to the first message for determining whether the name corresponds to any second network address served by the second node and when the name does not so correspond, sending a second message indicating that there is no correspondence to the first node.
means in a first one of the nodes for translating a name into a first network address and sending a first message including the name to a second one of the nodes which is specified by the first network address; and means in the second node responsive to the first message for determining whether the name corresponds to any second network address served by the second node and when the name does not so correspond, sending a second message indicating that there is no correspondence to the first node.
16. The communications network set forth in claim 15, further characterized by:
means in the first node for responding to the second message by again translating the name into the first network address and sending the first message.
means in the first node for responding to the second message by again translating the name into the first network address and sending the first message.
17. The communications network set forth in claim 16, further characterized by:
a name server accessible to the first node which establishes correspondences between names and network addresses in the network; and the means for responding to the second message obtains the second network address currently corresponding to the name from the name server.
a name server accessible to the first node which establishes correspondences between names and network addresses in the network; and the means for responding to the second message obtains the second network address currently corresponding to the name from the name server.
18. The communications network set forth in claim 17 further characterized in that:
the means for translating further includes a name cache; and the means for again translating adds the name and the first network address obtained from the name server to the name cache.
the means for translating further includes a name cache; and the means for again translating adds the name and the first network address obtained from the name server to the name cache.
19. The communications network set forth in claim 17 further characterized in that:
the correspondence between the name and the second network address may change in the second node; and there are further means in the second node which, when the correspondence changes in the second node, send a third message indicating the change from the second node to the name server; and the name cache responds to the third message by establishing the changed correspondence between the name and the second network address.
the correspondence between the name and the second network address may change in the second node; and there are further means in the second node which, when the correspondence changes in the second node, send a third message indicating the change from the second node to the name server; and the name cache responds to the third message by establishing the changed correspondence between the name and the second network address.
20. The communications network set forth in any of claims 15, 16, 17, 18 or 19 further characterized in that:
the first message further includes the first network address; and if the name corresponds to a second network address served by the second node, the means responsive to the first message further determines whether that second network address is the same as the first network address included in the first message and also sends the second message when that second network address is not the same as the first network address included in the first message.
the first message further includes the first network address; and if the name corresponds to a second network address served by the second node, the means responsive to the first message further determines whether that second network address is the same as the first network address included in the first message and also sends the second message when that second network address is not the same as the first network address included in the first message.
21. Apparatus for use in a node of a communications network of a type wherein network addresses may be represented by names and nodes of the network may exchange messages, the apparatus comprising:
means responsive to a first message from another node containing one of the names for determining whether the name corresponds to any network address served by the node in which the apparatus is being used, and when the name does not so correspond, sending a second message indicating that there is no correspondence to the first node.
means responsive to a first message from another node containing one of the names for determining whether the name corresponds to any network address served by the node in which the apparatus is being used, and when the name does not so correspond, sending a second message indicating that there is no correspondence to the first node.
22. The apparatus set forth in claim 21 wherein:
the message further contains one of the network addresses: and if the name corresponds to a second network address served by the second node, the means responsive to the first message further determines whether a first network address contained in the message is the same as that second network address and also sends the second message when that second network address is not the same as the first network address included in the first message.
the message further contains one of the network addresses: and if the name corresponds to a second network address served by the second node, the means responsive to the first message further determines whether a first network address contained in the message is the same as that second network address and also sends the second message when that second network address is not the same as the first network address included in the first message.
23. The apparatus set forth in claim 21 wherein:
correspondences between names and network addresses are maintained in a name server; and the apparatus includes means responsive to a change in a correspondence for sending a third message to the name server which indicates the change in the correspondence.
correspondences between names and network addresses are maintained in a name server; and the apparatus includes means responsive to a change in a correspondence for sending a third message to the name server which indicates the change in the correspondence.
24. Apparatus for use in a node of a communications network of a type wherein network addresses may be represented by names and nodes of the network may exchange messages, the apparatus comprising:
means for translating a name into a first network address and sending a first message including the name to a second one of the nodes which is specified by the first network address; and means for again performing the translation in response to a second message from the second node indicating that the name does not properly specify a second network address served by the second node.
means for translating a name into a first network address and sending a first message including the name to a second one of the nodes which is specified by the first network address; and means for again performing the translation in response to a second message from the second node indicating that the name does not properly specify a second network address served by the second node.
25. The apparatus set forth in claim 24 wherein:
the communications network further includes a name server for establishing correspondence between names and network addresses; and the means for again performing the translation into a first network address obtains the first network address corresponding to the name from the name server.
the communications network further includes a name server for establishing correspondence between names and network addresses; and the means for again performing the translation into a first network address obtains the first network address corresponding to the name from the name server.
26. The apparatus set forth in claim 24 wherein:
the means for translating a name includes a name cache; and the means for again performing the translation adds the first network address obtained from the name server to the name cache.
the means for translating a name includes a name cache; and the means for again performing the translation adds the first network address obtained from the name server to the name cache.
27. The apparatus set forth in any of claims 23, 24 or 25 wherein:
the first message further includes the first network address; and the second message is also received when any second network address corresponding to the name in the second node is not the same as the first network address included in the first message.
the first message further includes the first network address; and the second message is also received when any second network address corresponding to the name in the second node is not the same as the first network address included in the first message.
28. The method of claim 5, wherein the third message includes the name and a third network address to which the name corresponds.
29. A method for translating a first value representing an alias to an address to a second value representing a location address and verifying that the first value corresponds to the second value, comprising the steps of:
a) translating a first value to a second value at a first location;
b) sending the first value to a second location specified by the second value;
c) determining at the second location if the first value corresponds to the second location;
d) if the first value does not correspond to the second location, then sending the first value to a third location.
a) translating a first value to a second value at a first location;
b) sending the first value to a second location specified by the second value;
c) determining at the second location if the first value corresponds to the second location;
d) if the first value does not correspond to the second location, then sending the first value to a third location.
30. The method of claim 29, further comprising the step of translating at the third location the first value to a third value.
31. The method of claim 30, further comprising the step of sending from the third location to the first location the first value and the third value.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US07/999,336 US5434914A (en) | 1992-12-31 | 1992-12-31 | Name translation in communications networks |
| US999,336 | 1992-12-31 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2109787A1 CA2109787A1 (en) | 1994-07-01 |
| CA2109787C true CA2109787C (en) | 2001-03-06 |
Family
ID=25546209
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002109787A Expired - Fee Related CA2109787C (en) | 1992-12-31 | 1993-11-23 | Name translation in communications networks |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5434914A (en) |
| EP (1) | EP0606720B1 (en) |
| JP (1) | JP3378071B2 (en) |
| AT (1) | ATE260526T1 (en) |
| CA (1) | CA2109787C (en) |
| DE (1) | DE69333427T2 (en) |
Families Citing this family (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| DE4210407C1 (en) * | 1992-03-30 | 1993-09-30 | Siemens Ag | Number signaling method in a telecommunications network |
| GB2281793A (en) * | 1993-09-11 | 1995-03-15 | Ibm | A data processing system for providing user load levelling in a network |
| EP0710042A2 (en) * | 1994-10-26 | 1996-05-01 | AT&T Corp. | Means and method for providing local telephone number portability |
| JPH08204822A (en) * | 1995-01-25 | 1996-08-09 | Fujitsu Ltd | Double registration avoiding system and method thereof |
| US5706501A (en) * | 1995-02-23 | 1998-01-06 | Fuji Xerox Co., Ltd. | Apparatus and method for managing resources in a network combining operations with name resolution functions |
| JPH0936958A (en) * | 1995-07-17 | 1997-02-07 | Fujitsu Ltd | Service control node and service exchange node for performing traffic data collection |
| US5717750A (en) * | 1995-09-18 | 1998-02-10 | Lucent Technologies Inc. | Method for prohibiting continual routing of a call between central office switches due to translation data error |
| US5860153A (en) * | 1995-11-22 | 1999-01-12 | Sun Microsystems, Inc. | Memory efficient directory coherency maintenance |
| US5826014A (en) | 1996-02-06 | 1998-10-20 | Network Engineering Software | Firewall system for protecting network elements connected to a public network |
| US5898830A (en) | 1996-10-17 | 1999-04-27 | Network Engineering Software | Firewall providing enhanced network security and user transparency |
| GB2310566A (en) * | 1996-02-20 | 1997-08-27 | Ericsson Telefon Ab L M | Telephone call handling system |
| US5754791A (en) * | 1996-03-25 | 1998-05-19 | I-Cube, Inc. | Hierarchical address translation system for a network switch |
| US6487200B1 (en) | 1996-04-04 | 2002-11-26 | At&T Corp. | Packet telephone system |
| US5793970A (en) * | 1996-07-11 | 1998-08-11 | Microsoft Corporation | Method and computer program product for converting message identification codes using a conversion map accesible via a data link |
| GB9615029D0 (en) * | 1996-07-17 | 1996-09-04 | British Telecomm | Internet call centre |
| FI972911A (en) * | 1997-07-09 | 1999-01-10 | Ericsson Telefon Ab L M | E-mail system and method |
| US6016512A (en) * | 1997-11-20 | 2000-01-18 | Telcordia Technologies, Inc. | Enhanced domain name service using a most frequently used domain names table and a validity code table |
| US6496862B1 (en) | 1998-08-25 | 2002-12-17 | Mitsubishi Electric Research Laboratories, Inc. | Remote monitoring and control of devices connected to an IEEE 1394 bus via a gateway device |
| US6505255B1 (en) | 1999-04-29 | 2003-01-07 | Mitsubishi Electric Information Technology Center America, Inc. (Ita) | Method for formatting and routing data between an external network and an internal network |
| US6553421B1 (en) * | 1998-09-15 | 2003-04-22 | International Business Machines Corporation | Method and system for broadcast management in a data communication network that permits namesharing |
| US6374294B1 (en) * | 1998-12-23 | 2002-04-16 | Nortel Networks Limited | Method and apparatus for negating invalid networking addresses |
| US6378000B1 (en) | 1999-04-29 | 2002-04-23 | Mitsubish Electric Research Laboratories, Inc | Address mapping in home entertainment network |
| US6633547B1 (en) | 1999-04-29 | 2003-10-14 | Mitsubishi Electric Research Laboratories, Inc. | Command and control transfer |
| US6523064B1 (en) | 1999-04-29 | 2003-02-18 | Mitsubishi Electric Research Laboratories, Inc | Network gateway for collecting geographic data information |
| US7778259B1 (en) * | 1999-05-14 | 2010-08-17 | Dunti Llc | Network packet transmission mechanism |
| US6449657B2 (en) | 1999-08-06 | 2002-09-10 | Namezero.Com, Inc. | Internet hosting system |
| US6714981B1 (en) * | 2000-02-07 | 2004-03-30 | Hewlett-Packard Development Company, L.P. | Addressing system and method for communicating data |
| US7117239B1 (en) * | 2000-07-28 | 2006-10-03 | Axeda Corporation | Reporting the state of an apparatus to a remote computer |
| US8392612B2 (en) * | 2003-12-24 | 2013-03-05 | Apple Inc. | Replication server selection method |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4191860A (en) * | 1978-07-13 | 1980-03-04 | Bell Telephone Laboratories, Incorporated | Data base communication call processing method |
| US4224477A (en) * | 1978-09-11 | 1980-09-23 | Bell Telephone Laboratories, Incorporated | Arrangement for translating telephone station equipment numbers into directory numbers |
| US4310727A (en) * | 1980-02-04 | 1982-01-12 | Bell Telephone Laboratories, Incorporated | Method of processing special service telephone calls |
| US4348554A (en) * | 1980-03-21 | 1982-09-07 | Bell Telephone Laboratories, Incorporated | Method of providing virtual private network telephone service |
| US4644468A (en) * | 1984-07-20 | 1987-02-17 | International Business Machines Corp. | Name usage support through distributed processing networks linked by bridges and/or gateways |
| US4706081A (en) * | 1984-12-14 | 1987-11-10 | Vitalink Communications Corporation | Method and apparatus for bridging local area networks |
| US4683584A (en) * | 1985-02-07 | 1987-07-28 | American Telephone And Telegraph Company, At&T Bell Laboratories | Directory number translation in a distributed control switching system |
| US4694396A (en) * | 1985-05-06 | 1987-09-15 | Computer X, Inc. | Method of inter-process communication in a distributed data processing system |
| US4748661A (en) * | 1986-02-11 | 1988-05-31 | Pacific Bell | Circuit for translating telephone numbers |
| NL8602275A (en) * | 1986-09-10 | 1988-04-05 | Philips Nv | TELECOMMUNICATIONS NETWORK WITH CENTRAL SHADOW MEMORY. |
| US5025491A (en) * | 1988-06-23 | 1991-06-18 | The Mitre Corporation | Dynamic address binding in communication networks |
| US4924510A (en) * | 1988-12-28 | 1990-05-08 | American Telephone And Telegraph Company | Telecommunications database accessing method |
| US5253288A (en) * | 1990-03-28 | 1993-10-12 | At&T Bell Laboratories | Alternate destination call redirection for telecommunications systems |
| US5274696A (en) * | 1991-04-05 | 1993-12-28 | Rolm Company | Protocol for transmitting messages in a network |
| US5255315A (en) * | 1991-04-24 | 1993-10-19 | At&T Bell Laboratories | Method of rerouting telecommunications traffic |
| US5311572A (en) * | 1991-10-03 | 1994-05-10 | At&T Bell Laboratories | Cooperative databases call processing system |
| US5259026A (en) * | 1991-12-18 | 1993-11-02 | Bell Communications Research, Inc. | Method for speed calling automatic update |
| US5293376A (en) * | 1992-01-10 | 1994-03-08 | Bell Communications Research, Inc. | Upgraded telecommunication network |
-
1992
- 1992-12-31 US US07/999,336 patent/US5434914A/en not_active Expired - Lifetime
-
1993
- 1993-11-23 CA CA002109787A patent/CA2109787C/en not_active Expired - Fee Related
- 1993-12-06 DE DE69333427T patent/DE69333427T2/en not_active Expired - Lifetime
- 1993-12-06 AT AT93309770T patent/ATE260526T1/en not_active IP Right Cessation
- 1993-12-06 EP EP93309770A patent/EP0606720B1/en not_active Expired - Lifetime
-
1994
- 1994-01-04 JP JP00822494A patent/JP3378071B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP3378071B2 (en) | 2003-02-17 |
| DE69333427T2 (en) | 2004-12-16 |
| EP0606720B1 (en) | 2004-02-25 |
| DE69333427D1 (en) | 2004-04-01 |
| CA2109787A1 (en) | 1994-07-01 |
| JPH06244942A (en) | 1994-09-02 |
| ATE260526T1 (en) | 2004-03-15 |
| US5434914A (en) | 1995-07-18 |
| EP0606720A2 (en) | 1994-07-20 |
| EP0606720A3 (en) | 1995-07-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2109787C (en) | Name translation in communications networks | |
| CA2109191C (en) | Automatic network element identity information registration apparatus and method | |
| US5883946A (en) | Method and apparatus for provisioning customized telecommunications services | |
| US6684073B1 (en) | Signalling method and conversion device for telecommunications networks | |
| EP0804841B1 (en) | Method for comparing attribute values of controllable object expressions in a network element | |
| US9397963B2 (en) | Wireless device address book updates | |
| JP4652653B2 (en) | Assign server address to terminal | |
| CA2313043A1 (en) | Communications network | |
| CA2109192C (en) | Automatic network element identity information distribution apparatus and method | |
| JPH08505274A (en) | How to verify the identity of a subscriber device | |
| WO2004052034A1 (en) | Method and system for file management in a mobile network | |
| CA2109190C (en) | Automatic detection of reachable network elements | |
| CN109660979A (en) | Internet of Things opens chucking method and device in the air, calculates equipment and storage medium | |
| AU750033B2 (en) | Method for managing a foreign mobile subscriber in VLR of a mobile switching center | |
| CN1126329C (en) | Method and system for routing agent programs through communications network | |
| CN1164141C (en) | Structure for supporting radio paging service property in radio telecommunication system | |
| CN111970688A (en) | eSIM number-carrying network switching method, terminal equipment and computer readable storage medium | |
| US5966713A (en) | Method for determining the contents of a restoration log | |
| CA2109189C (en) | Logical integration of multiple network elements in a telecommunications management network | |
| JP3067712B2 (en) | SCP call control system | |
| KR20030042507A (en) | A method for analyzing address for the integrated network service of the next generation | |
| JPH09331325A (en) | Network management system | |
| CN107820222B (en) | Method and device for managing multiple tenants | |
| US20040030720A1 (en) | File sharing device in an integrated circuit | |
| KR100333732B1 (en) | Method for registering destination terminal address and method for translating destination number in b-isdn |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |