Abstract:
A domain based tunneling scheme allows a Network Management System (NMS) to manage devices in a private network operating behind a NAT boundary. A device in the private network provides the NMS with information including a public NAT IP address, a private device IP address, and a unique device identifier. The NMS uses the public NAT IP address to set up and maintain a tunnel to the private network. The NMS stores the NAT information and a tunnel identifier in a table entry associated with the device. The NMS then uses the tunnel and the contents of the table entry to conduct management operations with the device operating in the private network.

Description:
BACKGROUND OF THE INVENTION 
   This invention relates generally to network management and more particularly to managing devices across Network Address Translator (NAT) boundaries using tunnels. 
   A Network Management System (NMS) can manage many devices including computers and Internet Protocol (IP) telephones. Management can include network management, changing system settings, recording failures of network devices, discovering what hardware components are installed in network devices, discovering what software is installed on the device, etc. 
     FIG. 1A  shows an NMS  3  used for managing computers  1  and  2 . A table  5  stores the IP addresses of the devices managed by the NMS  3 . The table  5  is shown in more detail in  FIG. 1B  and includes entries listing the IP addresses of the computers  1  and  2  managed by NMS  3 . The NMS  3  communicates with the computers  1  and  2  using the public IP addresses X and Y, respectively. For example, the NMS uses IP address X in table  5  to communicate with computer  1 . 
   Referring back to  FIG. 1A , Network Address Translator (NAT)  20  and computers  16 A and  16 B reside within a private network  15 . The NAT  20  has a public IP address  38  and assigns private IP addresses to computers  16 A and  16 B. The NAT  20  is designed for IP address simplification and conservation, by enabling the private IP network  15  to use non-registered (private) IP addresses. The NAT  20  operates as a router connecting the private network  15  together with the public network  14 . The NAT  20  translates the private (not globally unique) addresses used in the private network  15  into public IP addresses. As part of this functionality, NAT  20  can be configured to advertise only one public address to the public network  14  that represents for the entire private network  15 . 
   For example, computers  16 A and  16 B communicate over Internet network  14  using the public IP address  38  provided by the NAT  20 . The NAT  20  receives a packet  7 A from a device on private network  15 , such as computer  16 A. The packet  7 A includes a private source address  8  and a destination IP address  9  for an endpoint such as IP phone  6 , packet  7 A also includes a payload  10 . The NAT  20  reformats packet  7 A into a packet  7 B that replaces the private source address  8  with the NAT&#39;s public IP address  38  and a port number  40  that the NAT  20 , associates with computer  16 A. The NAT  20  then forwards the reformatted packet  7 B to IP phone  6 . 
   The IP phone  6  sends packets (not shown) back to the computer  16 A that includes the public IP address  38  and port number  40  for the NAT  20 . The NAT  20  receives and forwards the packet from IP phone  6  to computer  16 A based on the port number  40 . 
   The NMS  3  cannot manage computers  16 A and  16 B behind NAT  20  for several reasons. First, the table  5  in NMS  3  only includes public IP device addresses. The NMS  3  does not have the ability to obtain the private IP addresses and port numbers needed for communicating with computers  16 A and  16 B. Even if the NMS  3  could obtain the private IP addresses and port numbers associated with of computers  16 A and  16 B, these addresses are not routable from the NMS. Additionally, the private IP addresses may be dynamically reassigned whenever the NAT  20  is reset. Port numbers are also typically refreshed in unison with the private IP address reassignment. 
   Because of the foregoing limitations, network management servers are unable to manage devices operating in private networks behind NATs. The disclosure that follows solves this and other problems associated with the prior art. 
   SUMMARY OF THE INVENTION 
   A domain based tunneling scheme allows a Network Management System (NMS) to manage devices in a private network operating behind a NAT boundary. A device in the private network provides the NMS with information including a public NAT IP address, a private device IP address, and a unique device identifier. The NMS uses the public NAT IP address to set up and maintain a tunnel to the private network. The NMS stores the NAT information and a tunnel identifier in a table entry associated with the device. The NMS then uses the tunnel and the contents of the table entry to conduct management operations with the device operating in the private network. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1A  is a diagram of an NMS managing two devices. 
       FIG. 1B  is a diagram of a table used by the NMS in  FIG. 1A . 
       FIG. 2A  is a diagram showing an NMS setting up a tunnel and managing a device in a private network through the tunnel. 
       FIG. 2B  is a table used by the NMS in  FIG. 2A . 
       FIG. 3A  is a diagram showing the NMS setting up two tunnels and managing two devices in different private networks. 
       FIG. 3B  is a table used by the NMS in  FIG. 3A . 
       FIG. 4A  is a diagram showing how the NMS uses a gateway to manage devices in different private networks. 
       FIG. 4B  is a table used by the NMS in  FIG. 4A . 
       FIG. 5  is a diagram showing in more detail the device operating in the private network. 
       FIG. 6  is a flowchart showing how the device in the private network operates. 
       FIG. 7  is a diagram showing in more detail the NMS shown in  FIGS. 2A ,  3 A, and  4 . 
       FIG. 8  is a flowchart showing how the NMS in  FIG. 7  manages devices in a private network. 
       FIG. 9  is a diagram showing in more detail the gateway shown in  FIG. 4 . 
       FIG. 10  is a flowchart showing how the gateway in  FIG. 9  relieves the NMS of tunnel management. 
   

   DETAILED DESCRIPTION 
     FIG. 2A  shows an NMS  51  that manages devices  16 A,  16 B, and  18  in a private network  21  defined by NAT  20 . The NMS  51  includes a table  52  that includes address information associated with devices  16 A,  16 B, and  18 . The NMS  51  utilizes the information in table  52  in conjunction with domain based routing and tunneling to send management communications to  16 A,  16 B, and  18 . 
   Any of the devices  16 A,  16 B, or  18  can be managed by NMS  51 . However, the example better describes IP phone  18  being managed by NMS  51 . The IP phone  18  generates a packet  30 A that includes a private source address  32  for the IP phone  18  and a destination address  34  for the NMS  51 . Packet  30 A also includes a payload  36  that contains a private IP address  32  and a unique identifier  48  for the IP phone  18 . The unique identifier  48  may be a MAC address, certificate, user name, or any other identifier that is unique to IP phone  18 . 
   The NAT  20  receives and reformats packet  30 A into packet  30 B. Packet  30 B replaces the source address  32  with the public IP address  38  for NAT  20  and the port number  42  that NAT  20  associated with IP phone  18 . The NAT  20  then forwards the reformatted packet  30 B to the NMS  51 . 
   The NMS  51  receives packet  30 B and adds an entry  53  for IP phone  18  into table  52 . The table  52  is shown in more detail in  FIG. 2B . Entry  53  includes the public NAT IP address  38 , the private IP address  32  of the IP phone  18 , a unique identifier  48  for the IP phone  18 , and a tunnel identifier  49 . The tunnel identifier  49  is entered once the NMS  51  sets up a tunnel to private network  15 . The NMS  51  gets the public NAT IP address  38  from the source field of packet  30 B ( FIG. 2A ). The NMS  51  gets the private IP address  32  and the unique device identifier  48  from the payload  36  in packet  30 B. 
   The NMS  51  may have outdated contact information for devices  18 ,  16 A and  16 B in table  52 . The unique identifier,  48 , in one example is a Media Access Control (MAC) address and allows the NMS  51  to still reliably access the different devices. For example, the NAT  20  can frequently reassign private device IP addresses  32  to the different devices  18 ,  16 A and  16 B but will not vary their unique identifiers  48 . If NAT  20  is rebooted for instance, NAT  20  may reassign private device IP addresses to devices  18 ,  16 A and  16 B. Even if NAT  20  swaps the private device IP addresses assigned to IP phone  18  and computer  16 A, NMS  51  will still be able to access the devices using their associated MAC addresses  48  in table  52 . 
   Returning still to  FIG. 2A , the NMS  51 , when managing IP phone  18 , sets up a tunnel  15  to private network  21 . Tunnel  15  in this example has endpoint  33  at IP address  9 . 9 . 10 . 10  and endpoint  35 A at IP address  9 . 9 . 10 . 60 . The NMS  51  also populates the tunnel identifier  49  for entry  53  in  FIG. 2B  with identifier tunnel  15 . 
   To manage IP phone  18 , the NMS  51  prepares packet  30 C. Packet  30 C includes a tunnel header  31  with a source address  33  for tunnel endpoint  33  and a destination address  35 A for tunnel endpoint  35 A at NAT  20 . Packet  30 C also includes an IP header  39  with a source address for tunnel endpoint  33  and a destination IP address  32  for IP phone  18 . Packet  30 C also includes payload  37  that contains management communications for IP phone  18 . 
   Packet  30 C is sent through tunnel  15  to endpoint  35 A. The NAT  20  removes the tunnel header  31  forming packet  30 D. Packet  30 D includes the source address  33  for NMS  51 , the destination IP address  32  for IP phone  18 , and payload  37 . The IP phone  18  receives packet  30 D from NAT  20  and processes the payload  37 . In one embodiment, the payload  37  includes management instructions compliant with a Simple Network Management Protocol (SNMP) that are executed by the IP phone  18 . 
   The IP phone  18  may also periodically run local processes to determine whether the private IP address  32  has been reassigned to another device or whether the unique identifier  48  has changed. The local processes will be described in more detail below. If the private IP address  32  or the unique identifier  48  has changed, the IP phone  18  updates the NMS  51  with the current information by sending another packet similar to packet  30 A. 
   The updates can also notify the NMS  51  when the public NAT IP address  38  has changed, for example, due to an expired IP address lease. The NMS  51  is notified of the change to the public NAT IP address  38  when the NAT  20  inserts the new public NAT IP address  38  into the source field of the update packet  30 B. 
     FIG. 3A  shows how the NMS  51  manages two devices with the same private IP address using domain based tunneling. Computer  19 A and computer  19 B reside in different private networks  25 A and  25 B, respectively. In this example, NAT  23 A has assigned computer  19 A the private IP address  192 . 168 . 01  and NAT  23 B has assigned computer  19 B the same IP address  192 . 168 . 0 . 1 . 
   Computer  19 A sends the private IP address  192 . 168 . 0 . 1  and associated unique identifier  48  to NMS  51  (not shown). The NMS  51  adds an entry  53  for computer  19 A into table  52  and associates computer  19 A with a tunnel identifier  17 A in the table  52 . Table  52  is shown in more detail in  FIG. 3B . 
   Computer  19 B provides the private address and unique identifier information to the NMS  51  in the same manner as computer  19 A. NMS  51  accordingly sets up another tunnel  17 B for managing computer  19 B. The private IP address values of computers  19 A and  19 B are the same in this example. However, the tunnels connecting to private networks  25 A and  25 B are different. This allows the NMS  51  to uniquely access computers  19 A and  19 B. For example, NMS  51  sends packet  60 A when managing computer  19 A. Packet  60 A includes a tunnel header  83 A containing source address  81 A and destination address  82 A. Packet  60 A also includes an IP header  89 A containing source address  81 A and a destination address  13 A. Packet  60 A also includes payload  99 A that contains management instructions. 
   Packet  60 A travels through tunnel  17 A until it reaches tunnel endpoint  82 A. The NAT  23  removes the tunnel header  83 A and delivers the remaining part of the packet to computer  19 A based on IP destination address  13 A. Computer  19 A then processes the management information in payload  99 A. 
   The NMS  51  sends packet  60 B to manage computer  19 B. Packet  60 B includes a tunnel header  83 B with a source address  81 B and a destination address  82 B. Packet  60 B also includes an IP header  89 B with source address  81 B, destination address  13 B, and a payload  99 B containing management instructions. 
   Packet  60 B travels through tunnel  17 B until it reaches tunnel endpoint  82 B. The NAT  23 B removes the tunnel header  83 B and delivers the remaining portion of the packet to computer  19 B based on the destination address  13 B in the IP header  89 B. Computer  19 B then processes the management information in payload  99 B. 
     FIG. 4A  shows another embodiment of the system that uses a gateway  90  to relieve the NMS  51  from the processing burden of setting up and maintaining tunnels. Tunnel  17 C is established between NAT  69 A and gateway  90 . In one embodiment, NAT  69 A includes an Easy VPN Remote  78 A (available from Cisco Systems) and gateway  90  includes an Easy VPN Server  77  (available from Cisco Systems). The Easy VPN Remote  78 A is configured to initiate a tunnel  17 C from NAT  69 A to gateway  90 . Other embodiments use Dynamic Multipoint VPN or any other method to initiate tunnel  17 C. Gateway  90  maintains a mapping of tunnel  17 C, and is configured to tag any packets that arrive from tunnel  17 C with an identifier  94 A. The identifier  94 A is a VLAN tag ( 802 . 1 q). 
   After tunnel  17 C has been established, computer  59 A sends an update packet  91 A to NMS  51 . Packet  91 A includes source address  68 A and destination address  92 . Packet  91 A also includes a payload  88  that contains a private IP address  68 A and a unique identifier  48  for the computer  59 A. NAT  69 A receives a packet  91 A and sends packet  91 B over tunnel  17 C. Packet  91 B includes a tunnel header  74  with source address  96 A and destination address  95 A and an IP header  75  with source address  96 A and destination address  92 . Packet  91 B also includes payload  88 . 
   Packet  91 B travels through tunnel  17 C until it reaches tunnel endpoint  95 A at gateway  90 . Gateway  90  removes the tunnel header  74  and tags packet  91 B with the VLAN tag identifier  94 A to create packet  91 C. Packet  91 C is sent to NMS  51 . The NMS  51  receives the information and adds an entry  53  for computer  59 A into table  52 . Entry  53  associates computer  59 A with VLAN tag identifier  94 A. Table  52  is shown in more detail in  FIG. 4B   
   To manage computer  59 A, the NMS  51  sends packet  91 D with VLAN tag identifier  94 A and payload  98  to gateway  90 . Payload  98  includes instructions for managing computer  59 A. Gateway  90  receives packet  91 D and determines the appropriate tunnel  17 C based on VLAN tag identifier  94 A. Packet  91 E is formed to travel over tunnel  17 C. Packet  91 E includes a tunnel header  84  with source address  95 A and destination address  96 A and an IP header  85  with source address  95 A and destination address  68 A. Packet  91 E also includes payload  98  that includes instructions for managing computer  59 A. 
   Packet  91 E travels through tunnel  17 C until it reaches tunnel endpoint  96 A at NAT  69 A. NAT  69 A removes the tunnel header  84  and delivers the remaining packet portion to computer  59 A. Computer  59 A then processes the management information in payload  98 . 
     FIGS. 5 and 6  describe a device  500  that provides contact information to an NMS. The device  500  includes a processor  501  and a memory  502 . The memory  502  includes instructions that, when executed by the processor  501 , perform the functions described in the flowchart of  FIG. 6 . 
   Referring to  FIG. 6 , the device  500  runs two scheduled local processes to determine whether a private device IP address or a unique device identifier has changed. Since the unique device identifier is relatively static in this embodiment, the device in block  600  runs a first scheduled local process at a rate of T 1  to determine if the unique identifier has changed. The device  500  runs a second scheduled process in block  601  at a rate of T 2  to determine whether the private device IP address has changed. In one example, rate T 2  is more frequent that rate T 1 . If a change in the unique identifier or private IP address is detected, the device  500  udpates the NMS in block  602  by sending an update packet  30 A ( FIG. 2A ). 
     FIGS. 7 and 8  shows how the NMS  700  manages the device in the private network. The NMS  700  includes processor  701 , memory  702  and table  703 . The memory  702  includes instructions that, when executed by a processor, perform functions described in the flowchart of  FIG. 8 . 
   Referring to  FIG. 8 , the NMS  700  in block  800  waits to receive a communication containing information on a device that is being managed. When the communication is received, the NMS  700  adds a table entry for the device in block  801 . The table entry includes a private device IP address, a public NAT IP address, and a unique device identifier. 
   At substantially the same time, the NMS  700  executes either the function in block  802 A or the function in block  802 B. In one embodiment, the NMS  700  executes the function in block  802 A unless the resources required for setting up and maintaining tunnels are low, in which case the NMS  700  executes the function in block  802 B. 
   In block  802 A, the NMS  700  locally sets up and maintains a tunnel with the private network NAT for communicating with the device. Alternatively, in block  802 B the NMS  700  waits to receive a communication from a gateway indicating that a tunnel has been established. In block  803 , the NMS  700  updates the table entry for the device with the tunnel identifier and, if block  802 B was used, a VLAN tag identifier. 
   In block  804 , the NMS  700  needs to communicate with a device operating in the private network. The NMS  700  searches the table for an entry associating the device in the private network with a tunnel or a VLAN tag identifier. In block  805 , the NMS  700  communicates with the device in the private network by sending a communication including the private device IP address to the tunnel endpoint. If the NMS  700  successfully contacts the device, the device is managed in block  806 S. 
   If the NMS  700  fails to contact the device, the private device IP address in the table may not be the current private IP address for the device. The NSM  700  in block  806 F waits a certain amount of time, for example, up to n hours, for the updated private device IP address to be sent by the device. If the correct private device IP address is received within n hours in block  807 S, the NMS  700  uses the received revised IP address to communicate with the device in block  805 . Optionally, if the NMS  700  fails to receive the correct private device IP address within n hours, the NMS  700  deletes the table entry for that device in block  807 F. 
   Referring now to  FIGS. 9 and 10 , a gateway  900  for setting up tunnels to private networks is shown. The gateway  900  includes a processor  901  and a memory  902 . The memory  902  includes instructions that, when executed by a processor  901 , perform functions described in the flowchart of  FIG. 10 . 
   Referring to  FIG. 10 , in block  1000  the gateway  900  waits for a private network to establish a tunnel with the gateway  900 . Once the tunnel has been established, the gateway  900  in block  1001  waits to receive a packet from the tunnel. When a packet is received, the gateway  900  tags the packet with a VLAN tag and sends the packet to an NMS based on a destination address of the packet. 
   The gateway  900  waits to receive a management communication from the NMS. When the management communication is received in block  1004 , a VLAN tag will indicate that the management communication should be transported through a particular tunnel. The gateway  900  in block  1004  places the packet in a particular tunnel for encapsulation and transport to the indicated private network. 
   The system described above can use dedicated processor systems, micro controllers, programmable logic devices, or microprocessors that perform some or all of the operations. Some of the operations described above may be implemented in software and other operations may be implemented in hardware. 
   For the sake of convenience, the operations are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. In any event, the functional block and software modules or features of the flexible interface can be implemented by themselves, or in combination with other operations in either hardware or software. 
   Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention may be modified in arrangement and detail without departing from such principles. I claim all modifications and variation coming within the spirit and scope of the following claims.