SNMP Protocol Extension for Error Code Compatibility

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The SNMP protocol, particularly in versions 1 and 3, lacks the ability to expand error codes, leading to compatibility issues between network management stations and devices from different manufacturers, and often results in timeouts due to insufficient processing time for SET requests.

Innovation Solution

An extension to the SNMP protocol is introduced that allows for the transmission of additional data content, including error codes, using Object Identifiers (OIDs), enabling compatibility and expanded functionality while maintaining standard compliance, and allowing agents to process requests within specified times.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If the SNMP protocol uses standardized predefined error codes, then compatibility between different manufacturers is maintained, but the ability to transmit manufacturer-specific error codes is lost

Engineering Contradiction:
Improveerror code extensibilityVSAvoidmanufacturer compatibility
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The error code transmission is segmented into two parts: a standardized error code field for basic error types (maintaining compatibility) and an additional manufacturer-specific data field for extended error information (enabling versatility). This segmentation allows both standardized and customized error codes to coexist without conflict.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

An intermediary data structure is introduced that includes both the standardized error code and an additional manufacturer-specific field. This intermediary structure acts as a bridge between the standardized SNMP protocol and manufacturer-specific error code requirements, allowing both to function together.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Speed

If the network management station specifies a short processing time for SET requests, then response time is improved, but the agent cannot complete internal processes leading to timeouts

Engineering Contradiction:
Improveresponse timeVSAvoidrequest processing completion
Core Design Contradiction:
SpeedVSReliability

Solution Approach 1:

The agent performs preliminary actions by preparing and sending a preliminary response within the specified time frame, indicating that the request is being processed. This preliminary response prevents timeout errors while allowing the agent additional time to complete its internal processes and send the final result.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The response is sent in periodic stages: first a preliminary response within the specified time frame to acknowledge receipt and prevent timeout, then a subsequent response when processing is complete. This periodic action pattern ensures both timely acknowledgment and complete processing.

Inventive Principle:
Principle #19Periodic action

3Measurement precision

If manufacturer-specific error codes are transmitted using extended data packets, then error detection capability is improved, but compatibility between different manufacturers' network management stations and devices is lost

Engineering Contradiction:
Improveerror detection precisionVSAvoidcross-manufacturer compatibility
Core Design Contradiction:
Measurement precisionVSAdaptability or versatility

Solution Approach 1:

The data packet structure is designed to be universal by including both standardized error code fields (for broad compatibility) and manufacturer-specific extension fields (for precise error detection). This multi-functional structure allows the same packet format to serve both standardized and customized error reporting needs across different manufacturers.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentEP2606608B1Extension for the simple network management protocol (SNMP) in order to ascertain information on the status of set-pdus
Publication Date: 2019.12.18 HIRSCHMANN AUTOMATION AND CONTROL GMBH
  • EP2606608B1 patent drawingFigure 1
  • EP2606608B1 patent drawingFigure 2
  • EP2606608B1 patent drawing

AI summary

The invention relates to a method for operating a network management station that exchanges data with the network devices connected to said station via bus connections by means of the SNMP protocol. An agent is integrated in each network device, said agent detecting the state of the network device and also being able to carry out adjustments or trigger actions in said device, wherein said agent communicates with the network management station via SET and GET commands. Furthermore, an error detection and/or an error notification between the network management station and the respective agents is carried out via the SNMP protocol. The method is characterized in that a further data exchange between the network management station and the respective agents is carried in addition to the data exchange provided according to the SNMP protocol in order to exchange further data content between the network management station and the respective agents using said further data exchange.