Protocol Flexibility: Why It’s Essential to an NMS

Management protocols come in different flavors. SNMP (Simple Network Management Protocol) is the most common. SNMP is everywhere and it’s far and away the most dominant management protocol around today in the networking space. Another widely used protocol is a CLI or Command Line Interface, the method of communication preferred by many engineers who want to work directly with the devices.

The CMIPs and CORBAs of the protocol world still live, but their popularity has faded. As technology adoption evolves, their function today is to integrate older legacy equipment and systems.

Then there’s TL1. Designed for the RBOCs in 1984, it’s mainly used for SONET and broadband networks, so – by design – it will never achieve the widespread use of SNMP. TL1 is still being actively developed and used, mainly in hope of getting a design win into the former RBOC networks, but it seems to be falling into that legacy category.

Besides SNMP and CLI, some network equipment providers implement other protocols such as SOAP over XML to gather data from the device or NETCONF, which is gaining popularity, particularly in configuration management or using Netflow, JFlow or SFlow for bandwidth utilization reporting.

OK, so what’s all of this got to do with management frameworks like Zoho’s WebNMS? Well, as a framework provider, we need to keep our solution flexible enough to support the hot protocols of the day as well as those that peaked in the 1970s or ‘80s.

At WebNMS, we’re unabashedly protocol neutral: the Switzerland of management systems. And to make that happen, WebNMS has a protocol-provider feature that allows an architect to choose many of the common protocols out of the box. Or even plug in their own protocol and transport.

As protocols go, NETCONF is the new kid. Conceived originally by Juniper and later joined by Cisco and Ericsson, NETCONF RFC was only published four or five years ago. Now while SNMP is a great protocol for the data collection task of fault monitoring and service assurance, NETCONF was specifically designed for configuration.

The CLI command prompt is also quite popular in configuration applications. But the problem with CLI is you need to know the particular syntax. And that syntax may be kludgey and typically used for one device at a time, which is where a management system comes in handy because you can build a GUI on top of that syntax to help with those configurations. WebNMS has a configuration and provisioning module that enables you to wrap the provisioning functions and managed-object behavior in a common set of objects and be exposed via the extension APIs.

So what’s the attraction of using NETCONF versus SNMP or CLI?

Well, NETCONF is designed to utilize a lot of the device’s intelligence. And by enabling more device self-configuration, the network-management system needs to do less work. SNMP puts the onus on the management software to do the work – the EMS or NMS needs to have lots of business logic to handle the many configuration scenarios.

Despite the many virtues of NETCONF, it is by no means taking over the management world. In fact, adoption seems rather slow, which could be because of the time and effort to develop the device intelligence and the learning curve of new technology.

Big players like Juniper, Cisco and Ericsson can afford to invest in a NETCONF solution, but the smaller players are satisfied to use SNMP because it has wide adoption and doesn’t require as much investment in creating device-agent logic. It’s a road that needs to be chosen.

Why a Framework Needs to be Protocol-Agnostic

From what we’ve talked about so far, it should be pretty clear by now that the communications industry is not going to put all its protocol eggs into one basket. And for that reason, we at WebNMS are committed to being protocol-agnostic. For the widely used protocols, we maintain protocol-specific code. It’s the reason we were one of the early adopters of TL1 and it‘s why we recently added NETCONF to our portfolio. If we don’t support a desired protocol out-of-the-box, the customer merely needs to put a little extra effort into creating a protocol adapter for our protocol layer. The most common protocol adapter people write is SOAP over XML or other proprietary XML-type protocol.

To support our one-for-all strategy, we keep protocol business logic at a single layer in WebNMS. So when you need to support the protocols of four different vendors with two supporting SNMP, one supporting TL1, and still another supporting CLI, the code is common. We write a small interface to connect to each of these protocols. The protocol plumbing is done for you and you can get on to the real task at hand, customizing the management system to your requirements.

One final area of management-system communication that doesn’t get a lot of attention is the internal kind – the protocol used to communicate between the front end and back end of a management system. The front end serves the presentation layer; the GUI and the back end serve the business logic of managing and controlling the network.

Now most of our customers go with our standard means of front-to-back communications, but still, if a customer has a special need, WebNMS allows them to customize the communications between front end and back end of their application. 

I know that some software vendors would consider this sort of flexibility unnecessary or a bit of overkill. But to the contrary, we think it speaks to the very purpose of a framework: allowing the product manager or architect to choose whatever technical requirements he or she wants.

From a technical standpoint, it would certainly be a lot easier to lock our customers into doing things a certain way. But over the long term, that strategy wouldn’t work because customers expect a framework to provide them with maximum flexibility. Or else, you are stuck with HPOV or Netcool.

Broad Protocol Support Matters

To conclude, we feel the ability to support the full breadth of communications protocols – from the most popular and trendy ones … to the oldest and even custom protocols – is a key requirement for a management framework. When you select a protocol-neutral and fully customizable management framework, the essential plumbing has been done for you. And when you’re not locked in, the power of design choice is yours and your investment lasts longer.

Eric Wegner is a 20-year veteran of the industry and has 10 years of experience with ZOHO Corp . (formerly AdventNet) working on large and complex network management infrastructures for network equipment manufacturers, service providers and military contractors. Eric joined the company as the first sales person and is now business development manager leading the WebNMS division in North America.