One of our projects at MapleWorks in the last year required us to integrate Open Shortest Path First protocol (OSPF) into a residential gateway product. Since OSPF is a mature protocol, and many implementations existed, it was our task to determine which OSPF stack was most suitable given timeline constraints that surround any onshore software development project.

Based on our experience, IP Infusion was the natural choice as it provided everything we needed in a modular architecture. However there was some natural scepticism about our decision, and this resulted in a survey of all the OSPF offerings that we knew of or could find on the Internet. We summarized our findings in the table below. Our survey was performed in May 2007, and much of the accuracy of the information was dependant on technical documentation publicly available at the time.

Description of columns:

Modular Architecture: Is OSPF decoupled from the RTM and other routing protocols? In the future there may be a requirement to have RIP and OSPF running at the same time. A non modular architecture would make it difficult to integrate RIP with OSPF so that both protocols run at the same time.

Management API: Does OSPF come with a clean management API to provision the protocol?

Maturity: How long has the protocol been around? Usually the longer its been around, the more bugs it has resolved making it a more solid product. This is where commercial offerings beat Open Source options.

Cross compiling: Has the code been written to support processors with big endian as well as little endian? Most development is done on PCs which uses little endian, and all too often when code goes from one processor to another, issues with byte alignment arise. These automatically introduce bugs, and will take incur additional costs in time and money.

Open Source: Is the product open source, and if not, how much does it cost?

Extra cost incurred relative to IP Infusion: Since the IP Infusion stack contained everything that was required for the project, it was used as a baseline to compare against all other offerings.

(Luan Pham is a Senior Software Engineer of MapleWorks Technology Inc, the smart choice for onshore software development for networking and telecom companies.)

In my last post (actually my first contribution as a blogger!), I discussed how for many small to medium sized equipment vendors, developing a good EMS/NMS solution is an afterthought. In trying to decide how to build it right, time and money are often sacrificed out of proportion to the actual task due to lack of domain expertise. Even if you disagree with that observation, I want to pick up on the last post by sharing some how-to on building a great solution based on what we’ve learned here at MapleWorks.

Let’s start with the main application screen. This screen should present a comprehensive view of the managed network. In a typical network this will include the list of all managed nodes, status of the nodes, fault summary, server status information, logged in user information, etc. In addition the most common/important detailed information can also be shown. In a telecom network this could the topology view of the managed network.

The layout of the screens is important as this is what gives the first impression about the application. The information presented here should be grouped according to relevance and mapped on the screen. Foremost is to show the nodes that are being managed, and this typically would be in a tree view on the left area of the screen. If groups features are supported then the groups should be displayed and the nodes under the groups can be viewed by expanding the group.

The individual nodes should display current status to the NMS server and both the nodes and the groups should display alarm summary counts. The main area of the screen should be used to view and configure functionality provided by the NMS application, like topology view, PM data, admin functions, error logs, etc. The user should be able to easily navigate between these views to access different functionalities while the rest of the screen displays real-time status information.

The colors and icons used in the GUI should be carefully coordinated so that the user is not confused when viewing the information presented. In general neutral colors should be used as much as possible making sure that the color coded alarm information is easily distinguishable. One of the areas where there is a lot of room for creativity is in the display of topology information. This is due to the number of nodes being displayed as well as the type of network connectivity.

Displaying mesh connectivity is not the same as displaying a linear network! Regardless, the graphics used to represent the topology (nodes and links) should be well designed and suitable for the entity they represent, otherwise the view can look a mess. This can be more challenging in applications that do multi-vendor network management. Some implementations have used photo images of the actual vendor equipment to distinguish the nodes but this can easily make the topology view quite an eyesore,

The information presented in your application should be clear and concise. The user should be able to easily navigate the screens and also be able to drill down to get more information.

In the case of the topology display there are several options to present the information. Among these are the use of expand/collapse capability for the node graphics, node annotations, layered view and/or drill down views, etc. The objective is to present the network topology in a clutter free form and at the same time provide the capability to delve further in to obtain more detailed information as required.

Let’s take the example of a long haul SONET network. In between the ADM nodes it may use optical repeaters (amplifiers) but the default topology view could just show the ADM nodes with the interconnecting links. There could be two options to show the components at the optical layer; one is to launch a dialog from the link of interest to view the supporting optical repeaters, and the other would be to give an option to expand the current view to redraw it showing the optical repeaters between the ADM nodes. This is an example of how the topology view can be managed as well as provides drill down capability to access information as needed.

A well designed GUI for a Network Management system should be pleasant to the eyes, provide easy to use features, and have well thought out functionality. In a crowded and competitive market space it could make or break sale of networking equipment.

(Ravi Ravishankar is a Senior Software Engineer at MapleWorks Technology Inc., the smart choice for onshore software development for networking and telecom companies.)