Electrical computers and digital processing systems: multicomput – Computer network managing – Computer network monitoring
Reexamination Certificate
2000-04-13
2004-04-27
Wiley, David (Department: 2143)
Electrical computers and digital processing systems: multicomput
Computer network managing
Computer network monitoring
C709S202000, C707S793000
Reexamination Certificate
active
06728768
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention.
This invention relates in general to network management, and more particularly to a method and apparatus for improving dynamic simple network management protocol GetNext processing.
2. Description of Related Art.
Data communication is the foundation upon which the information economy rests. Almost every device we use today is a computer-based system including our phones, cars, personal digital assistants, printers, desktop and portable computers, microwaves, etc. Moreover, the networking of such devices is becoming a reality in the hope that our lives will become more convenient and our leisure time will increase. For example, world-wide networks gather data about such diverse subjects as current events, the stock market, the temperature of our homes, etc. These networks evolved as independent entities without the ability, or, until recently, the need, to interconnect with one another. New technologies, generically named “internetworking”, have emerged making it possible to interconnect many disparate physical networks and make them function as a coordinated unit. Thus, using internetworking technologies, a host, for example, on one network, may traverse multiple networks and communicate with another host on a different network.
In the early days of networking, as the interconnecting of networks grew, the monitoring and maintenance of these networks became more difficult. It soon became evident that a network management protocol needed to be developed. The first protocol used was the Simple Network Management Protocol (SNMP). SNMP was commonly considered to be a quickly designed interim solution to internetwork management difficulties while other, larger and better protocols were being designed. Out of these protocol designs of the 1980's emerged SNMPv2, which incorporated many of the features of the original SNMP (which is still in wide use today) as well as a few added features that addressed the original protocol's shortcomings. Today, SNMP based network management systems are widely used to locate and correct problems in a network.
SNMP normally operates by having one or more central manager node(s) oversee multiple agent nodes as shown in FIG.
1
. As depicted, each agent node
120
supports a local, tree-structured database, called a Managed Information Base
130
(MIB) and software that allows a valid manager node
110
, such as a host computer, to access information in MIB
130
. Agent node
120
, which may reside in any agent device such as routers, database managers, printers, etc., responds to command messages sent by manager node
110
.
SNMP describes the packet layout (or protocol data unit) for messages between management agents and managing processes. The first version of SNMP, included only five possible messages. Manager Messages
140
are messages that can be sent by manager node
110
to agent node
120
and include “Get”, “GetNext” and “Set.” “Get” is a message that is sent to read certain locations in MIB
130
. The GetNext-Request message provides an efficient method for the managing process to search tables of values. “Set” enables the manager to update variables.
Agent Messages
150
that may be sent by agent node
120
to manager node
110
include: “GetResponse” and “Trap.” “GetResponse” is sent in response to a Get, GetNext, or Set command, and returns information to manager
110
. The GetRequest message with one or more object instances asks for the values of those object instances. “Trap” is sent asynchronously or, in other words, upon the occurrence of a predetermined event. Certain traps are predefined by SNMP. Other Traps are “enterprise specific” which means they can be defined to carry information specific to a particular algorithm or service.
SNMP management has two other components in addition to the SNMP messages: the Structure of Management Information (SMI) and the MIB. The SMI is a toolkit for creating a management information base, or MIB. The SMI identifies the permissible data types and spells out the rules for naming and identifying MIB components. It defines the structure of the SNMP naming mechanism. The MIB is a layout or schema for information relevant to managing networks and their component devices. SNMP is most often implemented over IP. However, nothing in the standard prevents SNMP messages from being delivered with TCP, HTTP, or non-Internet protocols, such as IPX or AppleTalk's datagram delivery protocol.
The SMI specifies the allowable data types in the MIB, and it spells out the ways data can be represented. Also, it defines a hierarchical naming structure that ensures unique, unambiguous names for managed objects, which are the components of a MIB. Compared with the objects that general purpose programmers use to build applications, SNMP-managed objects are very simple and stripped-down. MIB objects typically have six or so attributes. For instance, an object usually has a name, such as iflnErrors or tcpAttemptFails; an object identifier in dotted decimal form, such as 1.3.6.1.2.1.2.2.1.14; a syntax field, which selects one of several possible data types such as Integer, IPAddress, or Counter; an access field, which selects among “not-accessible,” “read-only,” “read-write,” and “write-only”; a status field consisting of either “mandatory,” “optional,” “deprecated,” or “obsolete”; and a text description of the object.
MIB objects are static; they're compiled from a text-like description language to a binary form that agents and managing processes can load. MIB-II is the current generic TCP/IP MIB standard, and specific MIBs have been adopted for bridges, printers, and other entities to provide a useful common denominator for management application developers. However, most vendors find it necessary to define their own proprietary objects to take advantage of the capabilities of their own products.
The SMI is two layers of abstraction away from the sort of management data that IT staff and users care about. SMI sets the rules for defining MIB objects, which are one layer of abstraction away from management data. All these abstract rules and reserved words make it possible to have machine-readable specifications that remain comprehensible to humans. The SMI enables a vendor to write an SMI-compliant management object definition, run the text through a standard MIB compiler to create executable code, and install the code in existing agents and in management consoles that could then begin generating reports and charts about such occurrences.
The MIB is a hierarchical name space, with the registration of its nodes administered by the Internet Assigned Numbers Authority (IANA).
FIG. 2
illustrates the hierarchical name space for the Management Information Base (MIB) structure. In
FIG. 2
, the object ID for every relevant MIB object begins with the ISO
1
object identifier
210
, National and International Organizations
3
object identifier
212
, the Department of Defense
6
object identifier
214
, and the Internet Architecture Board
1
object identifier
216
. Thus, according to the hierarchy as illustrated in
FIG. 2
, the object ID for every relevant MIB object must begin with either 1.3.6.1.2.1 (which represents the mib-
2
node
220
) or 1.3.6.1.4.1 (the enterprises node
230
). The term MIB is also used to refer to specific collections of objects used for particular purposes. Thus, MIB objects under the mib-
2
node
220
include the RMON (remote monitoring) MIB objects and other generic MIB objects
250
, while those under the enterprises node include all proprietary MIB objects
260
. It has been estimated that there are at least 10 times as many proprietary MIB objects as there are generic ones.
Each MIB object has a value associated with it according to the syntax part of its specification-for example, the number of packets that have come in since the last system reset, the number of clock ticks since the last reset, or the administrative state of a router. When a MIB object is instantiated on a device or other entity, the value associ
Crawford & Maunu PLLC
Delgado Michael
Wiley David
LandOfFree
Method and apparatus for improving dynamic simple network... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for improving dynamic simple network..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for improving dynamic simple network... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3261430