|
Description  |
|
|
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to network management in general, and in particular,
to discovering the location of Management Stations and managed devices in
the network.
2. Prior Art
The proliferation of computer networks has created a demand for improved
apparatus and method for managing such networks. The management need is
even greater because the networks are growing larger and more complex.
Most conventional computer networks are comprised of stations (for
example, word processors, personal computers, etc.) interconnected by
communications infrastructure. Included in the communications
infrastructure are routers, bridges, transmission media, gateways,
switches, etc. The computer networks could be simple ones in which the
stations are configured in a room, or a more elaborate ones in which the
stations are distributed over a large geographical area, such as a large
building, company site, a campus or several towns.
In more complex networks, one or more of the stations are designated
Management Stations. One of the functions provided by Management Stations
is keeping track of devices (called managed devices) as they (the managed
devices) enter and/or leave the network. To provide tracking and other
management functions, a Management Program, such as the Simple Network
Management Protocol SNMP is executed in the Management Station and in the
managed device. The portion of SNMP which is executed in the managed
device is termed SNMP agent. Usually, the activities of managed devices
are maintained in a data base (file) at the Management Station and can be
used by the Management Station itself or a network operator to detect
and/or correct fault in the network.
The conventional approach, to network management, addresses SNMP Management
Stations and the SNMP managed devices operating at the LLC level of the
protocol stack. The conventional technique uses an appropriate protocol,
such as the well-known Internet Protocol (IP), to communicate and to
"auto-discover" the SNMP managed devices or devices. Even though the
approach works well for discovering LLC level devices, there are other
network devices, termed MAC layer devices, which do not respond very well
to LLC level protocols. The MAC (Medium Access Control) layer devices may
include routers, concentrators, hubs, switches or like devices. As a
consequence, these MAC layer devices are usually not discovered, by the
Management Stations, using the conventional approach.
Several prior art patents describe devices and method for managing computer
networks. The following patents are examples of the prior art devices and
methods.
U.S. Pat. No. 5,233,510 describes a method of continuously self-configuring
of a computer control system used in a manufacturing process. Each object
in the process is assigned a unique ID or address. Each object in the
manufacturing process uses its unique ID in all communications with other
objects in the process. With this information, a control computer can
locate and map all of the objects that are in the process.
Japanese patent number JP-3-123137 deals with the manual configuration of a
MAC address into the forwarding table of a MAC layer bridge and storing
these addresses into an NVRAM. Most MAC layer bridges "listen" to the MAC
addresses on either side of the bridge and dynamically build forwarding
tables. This patent provides a way to manually build this table
eliminating the need for the bridge to "learn" the addresses.
U.S. Pat. No. 5,282,270 deals with the discovery of network devices that
exists in a network running the AppleTalk protocol. The patent defines how
routers within the AppleTalk protocol determine the location of the
network element. The patent uses a multicast address which all routers
running the AppleTalk recognize. The information passed between routers in
these multicast frames is used to locate network elements.
U.S. Pat. No. 4,991,089 deals exclusively with workstations attached to a
SNA network using the LU6.2 specification. The patent defines the method
where the workstation notifies a host system of its terminal address via
the SNA protocol.
U.S. Pat. No. 4,914,571 describes a method for locating resources in a
computer network so that a session can be established between an origin
and a destination station. The patent relates specifically with the SNA
protocol. The LOCATE METHOD defined in the patent uses the SNA protocol to
search for the destination target.
U.S. Pat. No. 5,408,618 discloses an Automatic Configuration Mechanism
(ACM) which can be used by a node in a LAN to obtain configuration
information from other nodes, to provide configuration information to
other nodes and to respond to other nodes which seek configuration
information. The frame format of this patent operates at the LLC layer of
the ISO protocol stack.
U.S. Pat. No. 5,185,860 describes a method by which a Network Management
Station (NMS) can "auto" discover devices containing SNMP agents in a
network using TCP/IP protocol. Of all the above cited prior art, this
patent appears most relevant to the field in which applicants' invention
operates. However, it covers the discovery process as it relates to the
Management Station only and does not address discovery as it applies to an
agent.
As networks become more complex and dynamic, addition and relocation of
devices are likely to occur more frequently. As a consequence, new
procedures and devices are required to "auto" discover changes in the
network.
SUMMARY OF THE INVENTION
It is, therefore, an object of the invention to provide a more efficient
and comprehensive "auto" discovery process than was heretofore been
possible.
It is another object of the invention to provide the "auto" discovery
process in devices to make their discovery more likely, by a Network
Management System (NMS).
It is still another object of the invention to provide the "auto" discovery
process in a network using TCP/IP Protocol to communicate and SNMP
protocol to manage the network.
These and other objects are achieved by enabling a managed device to send
special "auto" discovery frames to a Network Management Station or an
intermediate station, such as a router, until the managed device is
discovered. Thereafter, the device then monitors communications between
itself and the Management Station and restarts the registration process if
communication is lost or impaired. As a consequence, discovery of SNMP
devices and continued knowledge of the whereabouts of the SNMP devices are
ensured.
More particularly, a device on receiving a frame termed GET REQUEST FRAME
(described below) from a Network Management Station, sets a "Watch Dog"
timer. The Watch Dog timer is used to start a registration process if
contact is lost with the Network Management Station. Lost contact is
determined when an SNMP GET REQUEST FRAME has not been received from the
Management Station during the "Watch Dog" timer interval.
In the case where the Watch Dog timer expires, and an SNMP GET REQUEST
Frame has not been received during the Watch Dog interval, the
Registration Process is restarted. Two Registration Processes, termed
Auto-Discovery Trap and Router ARP Cache, are described.
In the Auto-Discovery Trap, the device sends Auto-Discovery Trap Frames at
timed intervals selected by a user. The Auto-discovery Trap Frames contain
Enterprise specific information (e.g., identifying the device as a hub,
switch, etc.) about the managed device. The Trap Frames are sent to a
Network Management Station until an SNMP GET REQUEST Frame is received.
The reception of SNMP GET REQUEST Frame indicates that the device has been
discovered by the Network Management Station.
In the case where the Watch Dog timer expires, and an SNMP frame has not
been received during the "Watch Dog" timer interval, then the process is
started again with the sending of the Auto-Discovery Trap.
In the Router ARP Cache process, the managed device sends frames termed
"Ping Frames" to an address for a default router. When the default router
receives the ping frames, it places the address of the device in its ARP
cache. The Network Management Station obtains the ARP cache information
from the router and uses the information to "discover" the device. The
device sends the ping frames until an SNMP GET RESPONSE Frame is received
indicating that the device has been discovered by the Management Station.
Once an SNMP GET RESPONSE Frame is received, a "watchdog" timer is set at
the user configured interval. The Watch Dog timer is used to start the
process over again if contact is lost with the Network Management Station.
Lost contact is determined when an SNMP GET REQUEST Frame has not been
received from the Management Station during the "watch dog" timer
interval.
In the case where the watch dog timer expires, and an SNMP frame has not
been received during the "watch dog" timer interval, then the process is
started again with the sending of the ping frames.
The invention also includes a novel way to set the "Watch Dog" timer
dynamically. One of the many advantages of the invention is that it
ensures discoverability regardless of network configuration. Another one
of the many advantages of the invention is that continued contact between
managed devices and Management Stations are maintained.
Still another one of the many advantages of the present invention is that
if contact is lost between Management Stations and managed devices, a
re-registration process is initiated automatically. Consequently, operator
intervention is not required.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 shows a network in which the present invention can be used.
FIG. 2 shows a block diagram of a device in which the "auto" discovery
invention according to the teachings of the present invention are
embedded.
FIG. 3, consisting of FIG. 3A and FIG. 3B, shows a flow chart for
configuring the device of FIG. 2.
FIGS. 4A and 4B show flowcharts for a program implementing the auto
discovery features of the present invention.
FIG. 5 shows a flowchart of the device processing a frame received from the
network.
FIG. 6 shows a flowchart for setting the "Watch Dog" timer dynamically.
FIG. 7 shows the structure of the Management Table according to the
teachings of the present invention.
FIG. 8 shows graphical representations for frames used in the present
invention.
FIG. 9 shows a functional representation of the Management Station.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Before describing the details of the invention, the environment in which
the invention will be described is worthwhile discussing. In addition,
certain words of art as they apply to the environment will also be defined
in the hope that it will enhance understanding of the invention.
The present invention can be used in any communications network in which
connection between a Management Station and a managed device is to be
established.
The present invention, described herein, works well in a network utilizing
the TCP/IP (Transmission Control Protocol/Internet Protocol)
communications protocol and SNMP Simple Network Management Protocol and as
such will be described in this environment. However, this should not be
construed as a limitation on the scope of the present invention. Since it
is within the skill of one skilled in the art to use the invention in
other environments without deviating from the scope or spirit of the
present invention.
DEFINITIONS
ARP (Address Resolution Protocol) allows a station to find the physical
address of another station given the IP address.
IP means Internet Protocol.
ARP Cache means a memory mapping of IP-to-physical address kept by all
stations which use ARP.
TCP means Transmission Control Protocol.
TCP/IP is a standard transport level protocol that provides reliable, full
duplex stream service.
SNMP means Simple Network Management Protocol.
Managed Devices can be primarily defined as network interconnect devices
such as hubs, switches, bridges and routers. It could also include
workstations.
A more extensive discussion on TCP/IP, SNMP, etc. are set forth in
InternetWorking with TCP/IP, Volume 1, Principals, Protocols and
Architecture by Douglas E. Comer, and RFC 1157-The SNMP Protocol (Version
1) Specification. The cited literature can be reviewed for more background
information on the environment in which the present invention is
implemented and to the extent necessary are incorporated herein by
reference.
FIG. 1 shows a block diagram of the communications network in which the
present invention could be implemented. The network includes Ethernet LANs
10, 12, FDDI Ring 14, Token Ring 26, Router 1, Router 2, and TCP/IP
Subnets 1, 2, 3 and 4. The Router 1 is connected through the TCP/IP Subnet
1 to Ethernet Switch 18 which is connected to Ethernet LAN 10. Management
Station 1 is also connected to Ethernet LAN 10. Bridge 20 is connected to
FDDI Ring 14. Bridge 20 and Router 1 are connected by TCP/IP Subnet 2. The
Router 1 is connected by TCP/IP subnet 3 to Router 2. The Router 2 is
connected to Fast Ethernet Hub 20 which is connected to Ethernet LAN 12.
Management Station 2 is also connected to Ethernet LAN 12.
Still referring to FIG. 1, Router 2 is connected through TCP/IP Subnet 4 to
Token Ring Switch 24 which is connected to Token Ring 26. Management
Station 3 is also connected to the Token Ring 26. Preferably, the managed
devices include the Ethernet Switches, Token Ring Switch 24, Router 1 and
Router 2 and Bridge 20. Each of the Routers 1 and 2 is fitted with a ARP
Cache. As described above, each of the ARP Cache is storage, located in
the Router, which stores information that a Management Station can recall
and detect the location of managed devices in the network. Consequently,
the Management Table (described below) in each managed device has an entry
for the three Management Stations. If the management feature in each of
the managed devices is enabled, Router 1 has ARP Cache entries for
Ethernet Switch 18 and FDDI Ring 14. Similarly, Router 2 has ARP Cache
entries for the Token Ring Switch 24 and the Fast Ethernet Hub 20. It
should be noted that in an actual system, the ARP Cache is located in the
associated Router and not externally as shown in FIG. 1.
The invention (details set forth below) establishes and maintains contact
between Management Stations and managed devices. To this end, a portion of
SNMP management program is executed on the Management Stations and another
portion termed SNMP agent, is executed on the managed devices.
The Management Stations then discover all of the managed devices by
querying the ARP Caches of each of the routers. As described below, when
the discovery trap feature is enable, all of the managed devices send SNMP
traps (frames) to the Management Stations that are defined in their
Management Tables. The Auto Discovery TRAP (details set forth below) is
also used to establish contact between Management Stations and managed
devices. As a result, the Management Stations learn/discover the managed
devices. Once the managed devices are discovered, the Management Stations
start to poll the managed devices on a periodic basis to maintain a
connection with the managed device. In the event that a connection with
one of the Management Stations is lost, the ARP Cache feature (pings) or
the discovery trap starts and runs until the connection is re-established.
Thus, the present invention allows the discovery of managed devices and
maintenance of the connection so long as the managed device and/or the
Management Station is active in the network.
FIG. 2 shows a functional configuration for an SNMP managed Device. The
SNMP managed device includes a System Bus 28, Media Access Control Chip
30, CPU 32, RAM 34, Flash Memory 36, and NVRAM 38. A managed device is an
embedded system in which the system bus provides communication between the
above-named components. The RAM forms the working memory of the device.
The NVRAM stores configuration information. Similarly, the FLASH EMPROM 36
stores the operational and boot-up code. The processor or CPU executes the
code instructions. The Media Access Control Chip 30 connects the device to
the network. In most cases, the operational code and the frame processing
code execute in the Flash Memory or in the RAM. Even though the TCP/IP
protocol stack and the SNMP agent and operational code are shown as
separate agents connected to the System Bus 28, this is done for emphasis
only. In actuality, the operational code and frame processing code are in
the RAM or the FLASH EPROM. The discovery code of the present invention
operates as part of the operational code (microcode or firmware) of the
embedded device.
The SNMP Network Management frames (described below) and ping frames are
received via MAC Chip 30. The MAC chip copies the frames into RAM 34 and
then notifies the processor (usually via interrupt) that a frame is ready
for processing. At this point, the operational code gets control and
processing starts with step 200 (FIG. 5).
Turning to FIG. 8 for the moment, a graphical representation of the general
format for an ethernet frame is shown. The frame can be used to transport
information according to the teachings of the present invention. The frame
includes the following fields: Preamble, Destination Address (DA), Source
Address (SA), ethernet type (0800), IP and TCP headers, Data and Frame
Check Sequence (FCS). The SNMP Requests, SNMP Responses, SNMP Traps and
ICMP Ping Frames are coded in the IP and TCP header field of the frame.
The functions of the other fields and the information that goes into them
are so well known that further descriptions are not warranted. In
addition, other frame formats, such as IEEE 802.3 or IEEE 802.5 (Token
Ring), are well known and further description of such well known formats
will not be given.
A functional block diagram for the Management Station is shown in FIG. 9.
The Management Station manages the network and uses the management frames
to exchange information with the managed devices. Likewise, the managed
devices use the frames set forth above to communicate with the Management
Station. The Management Station executes the management portion of SNMP
protocol. The Management Station includes a Processor (CPU) with a bus to
which memory RAM, Disk (DASD), other peripherals (CDROM, tape, etc.),
display monitor, keyboard, mouse and network interface card are connected.
The structure of the Management Station is conventional and further
description is not warranted.
FIG. 5 shows a flowchart illustrating the processing that occurs in the
managed device after it receives the frame from the network. After the
frame is received from the network (step 200), the program descends into
decisional block 210. In decisional block 210, the program tests to see if
the frame type of the received frame is an SNMP frame or a ping frame
(ICMP echo request). If the result is yes, the program descends into block
220. If the received frame is of some other type, the processing is
continued in block 260. It should be noted that the Management Station
uses SNMP frames and/or Ping frames to communicate with managed devices.
Still referring to FIG. 5 and in particular, step 220, if the frame is an
SNMP or Ping frame, the program gets the source IP address from the frame.
The program then descends into decisional block 230 where it compares the
source IP address from the received frame to the entries in the Management
Table (to be described subsequently). If there is a match, the program
continues processing in step 240. If there is no match between the source
address from the received frame and an entry in the Management Table, the
program continues processing in step 260. It should be noted that step 260
indicates continuation of normal frame processing which is not part of the
present invention and further description of normal frame processing is
not discussed in this application. With respect to step 240 and step 250
for the entry in the Management Table where the Source IP Address from the
received frame matches the Management Station address, the entry is
updated as follows: Set the connection state to True and set the
connection time to the current time and processing is continued in 260.
Turning to FIG. 7 for the moment, the format of the Management Table in a
managed device is shown. The Management Table includes a Management
Station field, a Connection State field, a Table Time field, and a Connect
Time field. The Management Station field contains the IP address of the
Management Station that will manage this device. As shown by the blank
entries in the figure, multiple Management Stations can manage a single
managed device. It should also be noted that this Management Table is a
storage embedded in the managed device.
The Connection State field has a True column (T) and a False column (F).
The Connection Field contains the connection information of the station
relative to the Management Station. If the values of the Connection State
are true, the Management Station for this entry in the Management Table
has established a connection with this device. As used herein, this device
refers to the device that has the Management Station IP address in it. If
the state of the Management Station is false, the Management Station for
this entry in the Management Table has not established a connection with
the device.
The Table Time field contains the value of the current time when the table
entries were last updated.
The Connect Time field contains the current time when the connection
between the Management Station and the managed device has been
established.
As will be described subsequently, the Management Table is built initially
at the time the device is first configured. During this configuration, the
user identifies the Management Station that will be managing the managed
device. Once these configurables have been established, the Management
Table can be updated, after the initial configuration, via Management
Frames using Telnet or local console. For updating with Management frames,
the Management Station can add/or delete entries in the Management Table
via an SNMP Management frame. To update via Telnet, the Telnet interface
into the managed device can change configuration parameters. Entries in
the Management table can be added and/or deleted via a Telnet session.
Finally, changes to the Management Table can be made via a local console
over an RS232 serial port which is usually connected to the managed
device. The local console can be used to change configuration parameters
in the device. Entries in the Management Table could be added and/or
deleted via a local session.
FIG. 3 shows a flowchart defining the information that is initially
configured into the SNMP managed device. Usually, the information is
installed in the managed device before it is deployed into a network. In
steps 32, 34 and 36, the device is configured with the IP address, Subnet
Mask, and Default Router. In step 40, the Management Stations to manage
this device are built in the Management Table previously described.
The IP address, the Default Router Address and Subnet Mask are required
information for devices that are to be managed in TCP/IP networks. This
information is common among all SNMP managed devices that ship today.
Also, common among devices initial configurations is to specify which
Management Station(s) will manage the device. As discussed above, these
management station addresses are entered in the Management Table of the
device.
In addition to the basic requirements defined above, this invention
requires the following information to be configured initially into the
managed device. It should be noted that the additional requirements are
required for the invention to start working immediately in a network.
However, these functions could be enabled/disabled later via management
frames, Telnet or via the devices' local console as described above.
Notwithstanding, to realize the full impact of the invention, it is
recommended that this information be configured at the same time the
device is initially configured.
Watch Dog Timer Interval--this timer interval specifies the time to
dispatch the discovery feature task that is specified in this invention
and is described below. The value correlates to the poll period used by
the Management Stations. This value should be set to the longest poll
interval from the list of management stations (plus a buffer of up to 60
seconds to account for network and/or processing delays).
Watch Dog Timer Maximum Value--this timer interval is the upper bound that
can be used for the Watch Dog timer interval. An important feature of this
invention is that it automatically adjusts the value of the Watch Dog
timer interval based on actual responses received from the Management
Station. This maximum value is required to handle the case where a
Management Station has been defined in the device, but for some reason
never establishes a connection with a device. Without the maximum value,
the Watch Dog timer interval would grow infinitely large to try and
accommodate this Management Station. The maximum value prevents this from
happening. The safe value for the maximum is two times the size of the
initial Watch Dog timer that was set in the previous step.
ARP Cache Feature--this configuration option simply allows a customer to
enable or disable this feature of the invention. It is recommended to be
enabled for TCP/IP networks that have routers installed.
Discovery Trap Feature--this configuration option simply allows the
customer to enable or disable this feature of the invention. It is
recommended to be enabled for networks that do not have routers installed.
Finally, for networks including Routers and other types of interconnecting
devices, the ARP Cache Feature and the Discovery Trap Feature should be
activated.
Still referring to FIG. 3, once the station or stations to manage this
device is configured in the Management Table (step 40), the program
descends into decisional block 42. In decisional block 42, t | | |