Electrical computers and digital processing systems: multicomput – Computer network managing
Reexamination Certificate
1999-09-15
2003-05-06
El-Hady, Nabil (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer network managing
C709S220000, C709S222000, C709S238000
Reexamination Certificate
active
06560644
ABSTRACT:
FIELD OF THE INVENTION
This invention relates to management of network resources, and more particularly to a central directory for network resources.
BACKGROUND OF THE INVENTION
It is standard engineering practice to generate a map of a computer network for the purpose of managing the network. Network management is ordinarily performed by software running on a server, where the software is referred to as a “Network Management Platform”. Well known commercial Network Management Platforms include the Hewlett Packard “open view” product, the IBM “Net View” product, etc. Network Management Platforms ordinarily use Simple Network Management Protocol (SNMP) standard methods for creating a directory of SNMP capable devices. The Network Management Platforms locate all SNMP capable devices on the network. Information held in the Network Management Platform for each SNMP device includes, at a minimum, the network address of the device, the protocol needed to reach the device, and the type of device such as router, end station, bridge, etc.
It is desirable for users of data link switching routers (DLSW) routers, which forward packets according the protocol described in RFC 1795, to construct a map of the DLSw routers. RFC 1795 stands for “Request For Comments” Number 1795, published by the Internet Engineering Task Force (IETF) in April 1995, and available at the IETF website at the URL www.ietf.org. All disclosures of RFC 1795 are incorporated herein by reference. As additional references are made hereinbelow to various RFC documents, it is to be understood that they refer to “Request for Comments” of the IETF, and that they are available at the IETF web site.
A map of the DLSw routers, ideally, gives the topology of the DLSw devices, gives the address of each DLSw device, and in many cases gives important management information such as the types of encapsulation being forwarded by the router, the number of errors recorded by the router, the data rates (bytes or packets per second, etc.) at any particular time arriving at the router, etc. Detailed information which is valuable to management of a DLSw router network is not ordinarily available in the entries of a Network Management Platform. Accordingly, a DLSw router management function must use a two level polling operation in order to utilize a standard Network Management Platform.
The two level polling operation requires that the Network Management Platform first polls all SNMP capable devices in order to build up its directory. The DLSw router management tool must then obtain the network address of all devices in the Network Management Platform directory, and using that address send each device a polling message asking if the device is a DLSw router. The directory may contain thousands of SNMP capable devices scattered throughout the network, and only a few hundred of these devices may be DLSw routers. Thus only about one in ten (perhaps only one in a hundred) of the polling messages sent out by the DLSw router management tool is useful, and the other nine to ninety nine out of a hundred polling messages waste network bandwidth.
An alternative to using a two level polling system in connection with a Network Management Platform is to have “seed” routers configured in the DLSw router network. A seed router has the address of all “peer” DLSw routers: Often the seed and peer routers are logically arranged in a hub and spoke topology, with the seed router at the hub and connected logically with the various peer routers connected as spokes. The seed router can then obtain detailed information about the“spoke” peer routers. The seed router then constructs maps of the DLSw network by polling its peer routers, and can include as much detailed information as the user desires on the maps.
However, a disadvantage to the seed router is that many of the peer routers on the spokes of the seed router have other peer routers which are not logically connected to the seed router. Thus two classes of routers are introduced, those connected to the seed router, and those not connected. Protocols must be developed to handle various exceptions. Accordingly, the seed router has no direct way of knowing about these further distant DLSw routers, and cannot include them in the maps which it constructs. A solution to this difficulty is for the spoke peer routers of the seed router to forward management messages from the seed router. However, this arrangement increases the complexity of the DLSw router management system.
A further standard engineering practice which is used to build a database of specialized devices is to have the device log into an account maintained on a server, and then to have a person enter verification data such as a password to establish the connection. The server then maintains a list of all verified connections as the database. For example, the specialized devices may be desktop computers and the verified connections may be to a network 'server which provides connectivity between the desktop computers and a computer network. The list of verified connections to the network is then maintained as a database in the server. However, this method of using a verified connection to help build a database of devices is not suitable for building a database of routers. Topologically, routers do not log into a central server to establish a network connection, rather, in contrast, the routers are links in the network. That is, routers connect various local area networks (LANs) together, connect the LANs to wide area connections, etc. Also, a router does not have a person enter a password to establish a verified account in a server. Therefore, the verified account method of building a list of devices on a server is unsuitable for establishing a database of routers.
For routers using any protocol, in addition to the DLSw example, there is a need to create a topological map of the network connection of the routers. Each router will normally utilize a particular protocol, or perhaps a router may be capable of using several different specialized protocols such as the DLSw example. In any case, the Network Management Platform can be used to create the topological map and show the protocols is used by each router, but again two levels of polling are required. In the first level of polling, the Network Management Platform makes a list of SNMP capable devices, and in the second level of polling, each of these devices is sent a message asking if it supports a specific type of specialized routing protocol. Also, in each case, a seed router can be set up to develop a list of specialized routers, but then the same limitations of the hub and spoke connections create complexity in the system.
There is needed a method and apparatus to provide a complete management system for specialized routers, such as for example DLSw routers. The method and apparatus should avoid the waste of network bandwidth which occurs when two levels of polling are used by a standard Network Management Platform, and should avoid the complexity introduced by use of seed routers.
SUMMARY OF THE INVENTION
A complete management system for specialized routers such as, for example, DLSw routers is provided. The management system avoids the waste of network bandwidth which occurs from use of two levels of polling as used by a standard Network Management Platform, and also avoids the complexity introduced by use of seed routers.
The management system uses, for example, an LDAP server to maintain a DLSw Directory. Whenever a DLSw router is booted, the DLSw router sends a registration message to the LDAP Server giving the network address of the DLSw router. The LDAP Server then maintains a directory of all DLSw routers in the network (the DLSw Directory). The information maintained in the DLSw Directory has at least the network address of each DLSw router, and it receives at least this amount of information from the registration message received as the router is booted up.
Also, at a later time, the Network Management Application sends a message to the routers in the directory requesting further
Denny Mark
Lautmann John
Cesari and McKenna LLP
Cisco Technology Inc.
El-Hady Nabil
LandOfFree
Directory services network management locator does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Directory services network management locator, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Directory services network management locator will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3008100