Electrical computers and digital processing systems: multicomput – Multicomputer data transferring via shared memory – Accessing another computer's memory
Reexamination Certificate
1998-04-10
2001-11-20
Sheikh, Ayaz (Department: 2155)
Electrical computers and digital processing systems: multicomput
Multicomputer data transferring via shared memory
Accessing another computer's memory
C709S212000, C709S245000, C709S223000, C710S009000
Reexamination Certificate
active
06321255
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to the field of computer networking. More particularly, the present invention relates to a method and an interface for storing identification information on network devices.
2. The Background Art
A computer network contains a number of hardware devices connected to each other via the network. Each hardware device normally contains information on the identification of that device. This information is usually stored on a programmable read only memory chip (PROM) but any number of non-volatile memory storage media are possible. When the memory device is a PROM, it is usually referred to as the ID PROM of the device, even though it is not necessary that the storage medium be a PROM. The type of information stored on each of these devices usually includes identification information such as the device's serial number or its part number.
Device identification information is used by network devices in a number of different fashions. The device actually storing the information may require the information during its use. For example, a device such as a router may use identification information contained within its memory store in order to determine how to control the network. Also, a management station or other device elsewhere on the network may use identification information from the memory store of a device to aid in the management of the system or for a number of other reasons.
FIG. 1
depicts an example of a network in which the management station requests identification information on a device. The management station
10
requests a piece of identification information (e.g. a serial number) from device A
12
. This request will travel across the network to the device A
12
. An interface
14
built into the device A
12
will then handle the instruction, retrieving the appropriate information from the memory store of the device, and sending the information to the management station
10
. The interface need not be contained on the device itself, as it is possible for the management station
10
control all of the information retrieval for each node on the network. However, due to the complexity of most systems, it is often more efficient to have the interface located on each device and designed in such a way that it is streamlined for use with that device.
Storage of the identification information in the memory store of the device is usually performed by the interface as well.
FIG. 2
depicts the device A
12
of
FIG. 1
in greater detail. The interface
14
receives the information, then stores it in the address or addresses in the memory store
16
that it has assigned to identification information of that type. An example of how an interface may organize identification information is given in table 1. In this example, all of the types of identification information the interface may store are assigned unique register and block addresses in the memory store. “EEPROM version” has been assigned to address 00, while “controller type” has been assigned to address 01, and so on. This is known as a fixed address format, as each type of information is assigned a fixed and unique address or addresses.
There are several disadvantages, however, to using such a fixed address format. As new versions of software and hardware devices are created, there are often additional types of identification information that the manufacturer wishes to place on the memory store of the hardware device. These new fields may not always be foreseen at the time the interface was created. While it is possible to use one of the unused addresses (in the example in Table 1 below there are several unused addresses, including
1
A to
1
E and
26
to
80
), this is a dangerous solution as it is possible that other components of the network may be using those addresses for storage of other types of information. Additionally, this solution requires that the interface be updated to recognize the new information type and to possess the knowledge as to what address the new information type is to be stored.
TABLE 1
Block Address
Description
00
EEPROM Version
01
Controller Type
02
Hardware Version High Byte
03
Hardware Version Low Byte
04:07
Serial Number
08
PCA Item Number - Class Code
09:0A
PCA Item Number - Base Number
0B
PCT Item Number - Version
0C
Test History - RMA Failure Code
0D
RMA number - Byte 2
0E
RMA number - Byte 1
0F
RMA number - Byte 0
10
Board Revision
11
Deviation number - (see note 1)
12
Deviation number - (see note 1)
13
Board Configuration
14
Manufacturing Date Code - YY
15
Manufacturing Date Code - MM
16
Manufacturing Date Code - DD
17
Card Connector Type
18:19
ASIC Revision
1A;1E
Undefined - Program to FF
1F
Development Engineering
20:25
Field Diagnostics
26:30
Undefined - Program to FF
Another drawback of the fixed address format is the fact that it creates the possibility of wasted space on the memory store. All recognized information types must be assigned a unique address or addresses. These addresses must be reserved for the identification information and cannot be used to store other types of information. While it is normally the case that all of the identification information address will be used, there are sometimes situations where some of the addresses may not be used, for example, if a device no longer needs to keep track of a certain information type due to changes in the network setup. It would be preferable to have a system that would not use up any more space than is needed, allowing for the extra space to be used for other functions.
Finally, the fixed address format requires an overly rigid organizational scheme for identification information. The interface must not only keep track of identification information types, but also keep track of the specific addresses where those identification information types are located. The result is an overly complex interface. It would be preferable to have a system that did not require such an overly rigid organizational scheme, and thus would allow for a much simpler interface design.
BRIEF DESCRIPTION OF THE INVENTION
A method for dynamically storing device identification information to allow for the easy addition of new fields as well as simple modification of identification fields. This method involves receiving the device identification information, determining the type and length of the device identification information, choosing one or more symbols to represent the type and length of the identification information, and storing the symbols as well as the identification information in a memory store associated with the device. Choosing the symbols may be accomplished by either choosing a single symbol to represent both the type and length of the identification information, or by utilizing a first symbol which represents the type of the information and a second symbol which represents the length. An extension address symbol may be used if it is not possible to find a symbol to represent the type and length of the identification information.
REFERENCES:
patent: 5250940 (1993-10-01), Valentaten et al.
patent: 5287103 (1994-02-01), Kasprzyk et al.
patent: 5509006 (1996-04-01), Wilford et al.
patent: 5513351 (1996-04-01), Grantz
patent: 5553135 (1996-09-01), Xing
patent: 5621721 (1997-04-01), Vatuone
patent: 5668803 (1997-09-01), Tymes et al.
patent: 5673265 (1997-09-01), Gupta et al.
patent: 5768618 (1998-06-01), Erickson et al.
patent: 5835601 (1998-11-01), Shimbo et al.
patent: 5918241 (1999-06-01), Egy
patent: 5959990 (1999-09-01), Frantz et al.
patent: 5968116 (1999-10-01), Day, II et al.
patent: 5974532 (1999-10-01), McLain et al.
patent: 6021429 (2000-02-01), Danknick
patent: 6047376 (2000-04-01), Hosoe
Brown Derek J.
Haragan, Jr. Robert M.
May, Jr. William B.
Roeck Guenter E.
Cisco Technology Inc.
Hanish Marc. S.
Sheikh Ayaz
Thelen Reid & Priest LLP
Tran Philip B.
LandOfFree
Extensible storage of network device identification information does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Extensible storage of network device identification information, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Extensible storage of network device identification information will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2612306