Electrical computers and digital processing systems: multicomput – Computer network managing
Reexamination Certificate
2000-02-08
2004-07-20
Harvey, Jack B. (Department: 2142)
Electrical computers and digital processing systems: multicomput
Computer network managing
C707S793000
Reexamination Certificate
active
06766367
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to communication systems and more particularly to networks having managed devices.
2. Description of the Related Art
The following description is concerned with a data communications system such as a local area network (LAN), that is an Ethernet network. However, the skilled person will appreciate that the present invention will have more general applicability to other types of managed communications systems including wireless networks.
A local area network (LAN) typically comprises a plurality of computers, computer systems, workstations and other electronic devices connected together by a common media such as twisted pair or coaxial cable or fibre optic cable. Data can be communicated between devices on the network by means of data packets (or frames) in accordance with a predefined protocol.
Computers and other devices connected to a network can be managed or unmanaged devices. A managed device has processing capability which enables it to monitor data traffic sent from, received at, and passing through the ports of the device. Monitored data associated with the ports oft he network device is stored in memory on the network device.
Network devices typically represent data in the form of a MIB (Management Information Base), as is well known in the art. A typical managed device may implement a number of MIBs (defined in RFCs), of which one (or more) represents data used in network management, as described below.
An example of a MIB containing network management data is MIB-II (formerly MIB-I) as specified by the IETF (Internet Engineering Task Force). MIB-II is common to core managed network devices of most vendors. Another MIB containing more complex management data is RMON (Remote Monitoring). As is well known in the art, each class or type of management information represented in a MIB is called an “object”. A specific instance from a data object is called an “object instance”. An object may be defined to have one instance (a scalar object), or multiple instances (a columnar object). Columnar objects are typically organised into “conceptual tables” (hereinafter referred to as “tables”) and all the objects in a table use the same indexing scheme for identifying instances of that object. Thus, tables can be thought of as an array of rows and columns, each column comprising all instances of a particular object and each row comprising the instances of all objects at a common index (the index for the row).
It is becoming increasingly common and necessary for an individual to be appointed to manage a network. The appointed network manager (or administrator) utilises a network management station which includes network management hardware and software. In particular, the network management station is able to access management data from managed network devices using an appropriate management protocol (e.g. the SNMP protocol) and display this data for use by the network manager.
The SNMP (Simple Network Management Protocol) defines the procedure and data packet format for the network management station to access network data from MIBs in managed network devices for TCP/IP-based networks. In SNMP the data packet or PDU (Protocol Data Unit) is defined to have a size of 1500 bytes. The SNMP protocol utilises five main commands: GET, SET, GETNEXT, GETRESPONSE and TRAP.
The GET request is sent by the network management station to a network device to fetch a value of an object or objects from a MIB. The GET request specifies an object using a unique “object identifier” which is defined in the MIB, which includes an index to identify the required instance of the object.
The SET request is sent by the network management station to write a value to a MIB. Like the GET request, the SET request specifies an object identifier of the object whose value should be modified and additionally specifies the new value to be written to the object.
The GETNEXT request, an example of an approximation operation as explained below, is used by the network management station to inter alia fetch object data in MIB tables. The network management station can use the GETNEXT command to fetch the data in a complete MIB table or a part thereof without knowing, in advance, the index values of data stored in the MOB table or part thereof. For example, the network management station will initially send a GETNEXT request specifying the “table root”. The table root can be thought of as the “column titles” since it is a placeholder after which the first row in the table, that is the row having the lowest index value, is guaranteed to appear. Thus, a GETNEXT request specifying the table root retrieves the first row in the table. The network management station will then use the response to this request in the subsequent GETNEXT command to fetch the next row in the table. The network management station will continue to iterate using the GETNEXT command until the data for all the rows in the relevant MIB table have been fetched.
Thus, because the GETNEXT command is an approximation operation, it does not need to specify the exact index of the object instance to be fetched at each command, as is necessary for the GET and SET commands, but merely an approximation of the index.
If a MIB table is indexed systematically with all indices within a bounded range present, for example 1 to 10, the network management station can issue a direct SNMP GET request for the values in the indexed rows and can pack the maximum number of requests into a single SNMP data packet (1500 bytes for an SNMP PDU) for transmission to the network device. However, if the table index values are sparse, then in the prior art the management station has no choice but to fetch the rows using the GETNEXT command. Because each GETNEXT request uses the response from the previous request, the management station can only fetch one row at a time, since it must wait for the information (i.e. the index value) contained in the response of the previous request before it can formulate the next request (i.e. using the index value as the approximation).
By way of example, a simple MIB table is represented in Table 1 below.
TABLE 1
testTable
testA (index)
testB
row 1
2
6
row 2
3
13
row 3
7
9
This MIB table, called “testTable”, has two columns, with object identifiers “testA” and “testB” of which “testA” is identified in the MIB as being an index for testTable. Values for testA and testB values are integer values. Thus, the value stored in the “testA” column is the value used to identify (i.e. index) the row in the table. Accordingly, the index which identifies the first row in the table is “2”, the index which identifies the second row in the table is “3” and the index which identifies the third row in the table is “7”. Thus, the rows of testTable are sparsely indexed as 2, 3 and 7 (instead of the systematically indexed 1, 2 and 3).
To fetch the whole of testTable, the network management station will typically send a GETNEXT request for the table root which will retrieve data at the lowest index value, and will then iterate using the previous response as the request each time until all the rows have been fetched. This looks like:
GetNext request:
testA
testB
response:
testA.2 = 2
testB.2 = 6
GetNext request:
testA.2
testB.2
response:
testA.3 = 3
testB.3 = 13
GetNext request:
testA.3
testB.3
response:
testA.7 = 7
testB.7 = 9
GetNext request:
testA.7
testB.7
response:
off end table
off end table
<finished>
The main problem with the above described known method is that fetching of sparsely indexed MIB tables by the network management station is very slow, which causes delays and generates a lot of data traffic on the network. Furthermore, the utilisation oft he available byte space in data packets is poor.
In network management, it is very common for MIBs to include sparsely indexed MIB tables due to deletions, additions and changes to rows of data which arise during the dynamic operation of a network. Thus, as demands on the network re
Chisholm Alastair Hugh
Duncan Robert James
Gray Andrew Hunter
Serra Vanessa
Stevenson David James
3Com Corporation
Blair Douglas
Harvey Jack B.
Hulbert & Berghoff LLP
McDonnell Boehnen
LandOfFree
Method and apparatus for fetching sparsely indexed MIB... 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 fetching sparsely indexed MIB..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for fetching sparsely indexed MIB... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3250329