Is it time to re-engineer SNMP?

For more than a decade, SNMP has been the basis for all IP network and systems management. However, as with all legacy software, there comes a time to break with the past and move into the future with a new management construct and architecture that meets the changing demands of vendors, customers and services.

The first step in re-engineering SNMP is to move the management standards efforts out of the IETF and into the World Wide Web Consortium (W3C). The reason: The next generation of management software will be more system and/or application oriented than infrastructure oriented. In addition, XML, a key component of current software application development, is in the purview of the W3C. The IT industry does not need protocol improvement; it needs standardized Web services engineered for management applications.

It's time to move into the next architectural stage of IT management. For 12 years the industry has attempted to fix, maintain, improve and enhance SNMP within its original architecture. Current software application development uses XML-based Web services as the driving force for application interoperability and communication. Any way you look at it, network and system management is a software application.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

For more than a decade, SNMP has been the basis for all IP network and systems management. However, as with all legacy software, there comes a time to break with the past and move into the future with a new management construct and architecture that meets the changing demands of vendors, customers and services.

The first step in re-engineering SNMP is to move the management standards efforts out of the IETF and into the World Wide Web Consortium (W3C). The reason: The next generation of management software will be more system and/or application oriented than infrastructure oriented. In addition, XML, a key component of current software application development, is in the purview of the W3C. The IT industry does not need protocol improvement; it needs standardized Web services engineered for management applications.

It's time to move into the next architectural stage of IT management. For 12 years the industry has attempted to fix, maintain, improve and enhance SNMP within its original architecture. Current software application development uses XML-based Web services as the driving force for application interoperability and communication. Any way you look at it, network and system management is a software application.

SNMP's large embedded base dictates the need for backward-interoperability between SNMP and its successor. This is easily accomplished using Web services' enveloping concepts and metadata. "Old-gen" SNMP products and management applications therefore will be able to communicate and interoperate with "next-gen" products and applications. This software technique also will let existing management information bases be used or be replaced by a new interoperable XML management schema engineered as an XML-based MIB.

Although SNMP has numerous software architectural flaws, two of these flaws are major. The first is that SNMP is dependent upon User Datagram Protocol (UDP) for messaging. UDP does not require explicit message acknowledgement or receiver authentication. Its original architects believed that to make SNMP messaging trustworthy required the addition of overhead features that have potential vulnerabilities when network problems occur, while also increasing complexity. This architectural flaw is one reason why the IETF working groups have placed so much emphasis on message security and accuracy. Today, processing capacity, storage and bandwidth are no longer constraints requiring that architectural complexity be compromised.

The second flaw is the "pole-select" software concept - in SNMP terms, a manager and an agent. The manager is, in almost all cases, the requester in a synchronous request-respond conversation. This type of architecture is outdated and must be replaced by a modern management event-based bus that allows asynchronous messaging using a publish/subscribe model. Event-based architectures exist today because of the distributed embedded intelligence in all forms of software, and compute and storage resources in hardware. Exception processing within event-based architectures will allow for the management scaling of telemetry devices, networks and systems without additional network and/or processing overhead, and will remove complicated hierarchical management structures that emulate or create a "manager of managers."