Patent Application
20090006435
The present disclosure relates generally to the field of networking.
A network device may have multiple traffic processors that process different data for communication links and a control processor that operates as a Simple Network Management Protocol (SNMP) management point. The single SNMP management processor has connectivity with an outside SNMP manager and processes all SNMP requests from outside of the network device.
The control processor may also be responsible for assuring SNMP notifications to the outside SNMP manager correctly identify the processor generating the notification. Otherwise, the SNMP manager cannot identify particular Management Information Bases (MIBs). As far as SNMP is concerned, each MIB has a unique identifier that distinctly identifies an associated processor. However, unique identifiers are not standard across MIBs and each traffic processor have no way of distinguishing associated MIB objects from the MIB objects of other traffic processors.
There currently is no efficient scheme for uniquely identifying which processors in a multi-processor system send SNMP notifications. The SNMP notifications lose relevance and utility in multi-processor system because there is no correlation between the processor that generated the SNMP notification and the notification itself.
In one embodiment, a control processor sends unique identifiers to each traffic processor in a multi-processor system of different unique identifiers may be sent for each traffic processor supported Management Information Base (MIB). The traffic processors modify MIB object identifiers to include the unique identifiers and then transmit notifications that include the unique identifiers, MIB object identifiers, and associated traffic processor parameter values. In another embodiment, the control processor handles the task of attaching unique identifiers so each MIB object identifiers are uniquely correlated with a particular traffic processor.
Referring to
In one embodiment, the network processing device 12 may be a blade in a rack containing multiple network processing devices. The network processing device 12 can be a server, router, switch, gateway, or any other device that processes network traffic from communication links 14. In this embodiment, the network processing device 12 may manage data and voice calls from different cellular, land-line, Digital Subscriber Loop (DSL), cable, Ethernet, etc. communication links 14. The network processing device 12 then routes packets for these different data or voice calls over the Internet network 32.
In another application, traffic processors 16 may be different home computing devices and the control processor 22 may be a router that is connected to the external Internet network 32 through a cable modem. Of course these are only example embodiments, and the unique identifier scheme described below can be used in any application where information needs to be uniquely associated with particular processors.
Each one of the traffic processors 16 may need to send uniquely identifiable information to a management station 30 in the external network 32. For example, each traffic processor 16 may need to send notifications 26 to the management station 30 whenever certain operating thresholds, operating conditions, or communication link problems are detected. For example, any of the traffic processors 16 may send a notification 26 to management station 30 whenever one of the communication links 14 exceeds a specified bandwidth. Alternatively, the traffic processors 16 may periodically send notifications 26 to the management station 30 that contain different traffic processor statistics. For example, the notifications 26 may identify the number of packets a particular traffic processor 16 received over the last hour.
Unfortunately, the traffic processors 16 may be unaware of other traffic processors in the same network processing device 12. In some systems only a single Internet Protocol (IP) address is associated with all of the multiple processors contained in network device 12. Thus, there is no way to uniquely associate the traffic processors 16 with the information in notifications 26.
In one embodiment, the control processor 22 sends Unique IDentifiers (UIDs) 24 to all of the traffic processors 16 for all supported MIBs 20. For example, control processor 22 may send unique identifiers 24A and 24B to traffic processor 16A for MIBs 20A and 20B, respectively. A UID value of ‘3’ is shown associated with MIB 20A and a UID value of ‘4’ is shown associated with MIB 20B in traffic processor 18 of course, any UID value can be used, The UID values ‘3’ and ‘4’ are uniquely assigned to MIBs #1 and #2, respectively. Other unique UID values 24 are selected and used for other MIBs #3-#N in traffic processors 16B-16N. The UIDs 24 are used by the traffic processors 16 when preparing notifications 26 for sending to management station 30.
The UIDs 24 uniquely associate MIB Object IDentifiers (OIDs) 64 in notifications 26 with a specific traffic processor 16 even though all of the traffic processors 16 are managed through a single control processor 22. For example, the UID 24A uniquely associates the object identifiers for MIB #1 with traffic processor 16A and UID 24B uniquely identifies the object identifiers for MIB #2 with traffic processor 16A.
The traffic processor 16A then modifies the OIDs for MIB #1 to include UID 24A and modifies the OIDs for MIB#2 to include UID 24B. For example, the traffic processor 16A may generate and store a parameter value 64. Parameter value 66 can be any piece of data generated by traffic processor 16A, but in one example is a traffic processor a statistic, such as the percentage of CPU utilization over some time period. The data value 66 is associated with the MIB object identifier (OID) variable 64.
The OID 64 is modified by the traffic processor to include the unique identifier ‘3’. The UID ‘3’, OID 64, and associated data value 66 are all sent in a notification 26A to management station 30. The management station 30 can then use the UID to uniquely associate the information in notification 26A with traffic processor 16A.
The traffic processors 16 may encapsulate notifications 26 in a header that is used for inter-processor communications within network processing device 12. The control processor 22 strips off the internal header and then forwards the de-capsulated notification to the management station 30.
In both embodiments shown in
In
When a particular event is detected in one of the traffic processors 16, the SNMP agent 18 in that traffic processor formats the MIB information into a SNMP notification 26 which is then sent to the SNMP manager 34. Similarly to
The UIDs are then sent to the associated traffic processors in operation 58. As described above, the notifications 26 may have to be sent back to the management station 30 (
The object identifier 64A (OID #1) is a MIB variable associated with a particular operating parameter generated by one or the traffic processors. For example, OID#1 may be associated with a CPU utilization value over the last 5 minutes. In the example in
The same SNMP notification 26A may include multiple object identifiers each associated with different parameter values. For example, object identifier 64B (OID#2) identifies the average CPU utilization in traffic processor 16A over the last 5 seconds. In this example, the traffic processor 16A had an average CPU utilization value 66B of 100%. The second object identifier 64B is again modified to include UID 24A to associate the OID 64B with the same MID #1 and traffic processor 16A. The SNMP agent 18 (
Another SNMP notification 26B is built and sent by the same traffic processor 16A for other threshold conditions in traffic processor 16A. In this example, the object identifiers 64C and 64D are still associated with parameters or statistics generated by traffic processor 16A but associated with the second MIB #2. According, the second unique identifier 24B is attached to OIDs 64C and 64D. In this example, the OIDs 64C and 64D are associated with Bits Per Second (BPS) value 66C and a Packets Per Second (PPS) value 66D. But of course, any type of traffic processor information may be sent.
In operation 74, the traffic processor performs normal network traffic operations and at the same time derives different traffic processor operating parameters and statistics. For example, as described above, the traffic processor may have been configured to calculate the CPU utilization over different periods of time, such as every 5 seconds and every 5 minutes. Other traffic processor operating parameters may also be monitored, such as, number of dropped packets, packet delay, and other Quality of Service (QoS) or Denial of Service (DoS) information. The traffic processor may also save statistics related to the network traffic itself, such as the amount of packets received, packet sizes, types of packets, and packet source or destination information. Any information needed by the management station 30 for analyzing the operation of the traffic processor may be obtained.
In operation 76, these traffic processor parameters and statistics are structured with MIB object identifiers. For example, the CPU utilization value for the last 5 minutes is assigned a first OID variable 64A as shown in
The traffic processor obtains the MIB object identifiers for the SNMP notification when a particular notification condition is detected in operation 78. The identified OIDs are then modified to include the unique identifier. The unique identifiers may be combined with the MIB object identifiers either before or after the notification condition is detected in operation 78. The values for the MIB OIDs are read from memory in operation 82. The SMNP notification is built in operation 84 and includes all of the UIDs, OIDs, values, and SNMP header information. The SNMP notification is then either sent to the management station 30 or to the control processor 22 in operation 86.
The SNMP manager 34 in management station 30 (
The control processor 22 receives the notification 90 and locates the unique identifiers 24 for the associated traffic processor MIBs. Each traffic processor 16 may send some internal information 92 in notification 90 that allows the control processor 22 to distinguish it from other traffic processors. The control processor 22 determines which traffic processor 16 sent the notification 90 and the type of notification. Based on the type of notification, the control processor 22 determines which OIDs 64 in the notification 90 need to be translated.
The control processor identifies the unique identifier 24 for the traffic processor and MIB associated with the OIDs 64 in notification 90. The OIDs 64 are replaced or modified to include the unique identifier 24. The control processor 22 then sends a modified notification 94 with the translated OID/UID values 64/24 to the management station 30.
Thus, notifications 32 can be associated with specific traffic processors even though multiple traffic processors are managed through a single control processor 22. With this approach, the control processor 22 manipulates the OIDs 64, and no extraneous OID modifications are required by any traffic processors 16. This approach still more devices to be managed through a single control point and also saves IP address space.
Several preferred examples of the present application will now be described with reference to the accompanying drawings. Various other examples of the invention are also possible and practical. This application may be exemplified in many different forms and should not be construed as being limited to the examples set forth herein.
The figures listed above illustrate preferred examples of the application and the operation of such examples. In the figures, the size of the boxes is not intended to represent the size of the various physical components. Where the same element appears in multiple figures, the same reference numeral is used to denote the element in all of the figures where it appears. When two elements operate differently, different reference numerals are used regardless of whether the two elements are the same class of network device.
Only those parts of the various units are shown and described which are necessary to convey an understanding of the examples to those skilled in the art. Those parts and elements not shown are conventional and known in the art.
The system described above can use dedicated processor systems, micro controllers, programmable logic devices, or microprocessors that perform some or all of the operations. Some of the operations described above may be implemented in software and other operations may be implemented in hardware.
For the sake of convenience, the operations are described as various interconnected functional blocks or distinct software modules. This is not necessary, however, and there may be cases where these functional blocks or modules are equivalently aggregated into a single logic device, program or operation with unclear boundaries. In any event, the functional blocks and software modules or features of the flexible interface can be implemented by themselves, or in combination with other operations in either hardware or software.
Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention may be modified in arrangement and detail without departing from such principles. We claim all modifications and variation coming within the spirit and scope of the following claims.
The present application claims priority from U.S. Provisional Patent Application Ser. No. 60/946,938, filed Jun. 28, 2007, incorporated herein by reference in its entirety for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 60946938 | Jun 2007 | US |
