By Yi Liang

Network management and support systems are needed for all three layers in the NGN.  Management of infrastructure in an Enterprise or Carrier environment is getting more complex as data, voice and video converge into one ubiquitous IP packet based network.  The challenge comes from migrating legacy equipment with next generation infrastructure to work harmoniously to provide a high quality of service to its users.  Providers today are already seeing the commoditization of their services by increased competition.  Therefore next generation management systems need to manage more, reduce costs, and be agile to meet further business needs.

Key areas to focus on are:

• Understanding trends in management protocols like NETCONF and WS-Management
• Using cutting edge Rich Internet Application technologies to enable interfaces to the web without compromising usability or functionality that customers have grown accustomed to
• Developing new methods for fast data store and retrieval to make data collection more scalable
• Devise new algorithms to ensure QoS is maintained across different services
• Devise new methods for quicker fault detection and fault resolution
• Create ways of making the management of devices as generic as possible so that systems can support next generation infrastructure

By Yi Liang

Call Control is one of the most important parts in the control layer of the NGN.  Signaling is used in the network to set up calls between two end users and to pass information about the call state between the various call agents involved in handling the call.  IMS uses Session Initiation Protocol (SIP) to create a signaling network over the IP network.  The Real-time Protocol (RTP) is used for media transport

Research and development work in the following areas is very important.

• Protocol stack development and analysis
• System high availability
• System scalability
• Network security

The open source community is involved in some important areas. Particularly in integrated access devices and IP PBX software projects.  An example is the Freeswitch project.

By Yi Liang

The next-generation network is a high speed packet or cell based network which can provide multiple services such as voice, data, video and multimedia. It has a high bandwidth multi-service core and intelligent edge. It provides quick service delivery and provisioning. Next-generation networks are based on internet technologies including Internet Protocol (IP), Multiprotocol Label Switching (MPLS), and Session Initiation Protocol (SIP).

Network convergence is one of the key subjects in the next-generation network. The goal is to bring together voice, data and video at the network level, at the system level, at the application level, and at the device level. Convergence in transport means all traffic sharing a common packet-based network which is usually IP based. At the system level, the softswitch will replace the traditional circuit switch. It enables voice communication over the IP backbone. IP PBX and multi-service devices enable the enterprise to access the network easily and reduce cost. More and more applications will be developed to use the new infrastructure. These new applications integrate voice, data and video at the desktop as well as in the server. Examples of this include multimedia conferencing, multimedia messaging etc.

The IP Multimedia Subsystem (IMS) is a standardized NGN architecture originally developed by the 3G Partnership Project (3GPP). It defines a generic architecture that offers VoIP and other multimedia services within wireless and wireline infrastructures. The IMS architecture is divided into three layers: service (application), control and transport (access). Following diagram is a simplified view of the layered architecture of IMS. Major vendors like Ericsson, Lucent, Nortel and Siemens have made substantial investment in IMS software. There are a lot of challenges and also a lot of opportunities in this technology evolution process.

By David Zinman

To expedite development and quality assurance cycles, many software projects incorporate automated testing. Automation of testing can greatly reduce phase times and reduce costs for the any outsourced or internal project. By analyzing the way test automation is done, Mapleworks has developed a solution called Mapleworks Automated Testing System or MATS.

What is required from a test automation system?

1. The ability to run different types of tests:
   • Unit testing
   • Full system testing
   • Integration testing
   • Regression testing
   • Performance testing
2. Consistency and reliability
3. Observable detailed results with comparison ability
4. Flexibility – test and test suites

At Mapleworks we’ve found some practical problems with test automation. Take the case of a long and involved test script. These types of scripts can be recorded by a test platform or created manually with a sustained effort. If an essential piece of functionality has to be modified, then the script must be re-recorded or re-factored in some way. And say this modification is applicable to several different places in the delivery, the cost rises exponentially to the quality assurance cycles.

At Mapleworks, we have designed a novel approach to solving this problem. Using the TestComplete platform, we have added an abstraction layer that takes an arbitrary label and points it to each testable object. This de-couples the test script and testing engine from the tested program.

What we can now do is record an intricate test procedure, convert it to a MATS (Mapleworks Automation Test System) script and create the mapping file for the testable components.

An added benefit from this architecture is that the QA team can write tests before the project is completed. All that is required to run testing suites is the mapping file to be filled in with the actual component internal name which can be obtained using the TestComplete ‘map object from screen’ tool.

The mapping syntax is straightforward: an arbitrary descriptive name, its object type (button, list, etc), and its component internal name which is implementation specific.

Sample Component Definition File:

Template Editor|Catalogs, Tab,.WinFormsObject(’WindowDockingArea’, ”, 3).Pane.Panes.item[1]

Template Editor|Catalogs|=Catalogs|,Copy,WinFormsObject(’TemplateEditorFramework’). WinFormsObject(’splitContainer1′).WinFormsObject(’SplitterPanel’, ”, 1).WinFormsObject(’Navigation’). WinFormsObject(’CatalogTab’).WinFormsObject(’CatalogFramework’).WinFormsObject(’tableLayoutPanel11′)=WinFormsObject(’FormFramework’).WinFormsObject(’mainContent’).WinFormsObject(’caiTableLayoutPanel1′).WinFOrmsObject(’panel’).WinFormsObject(’CatalogFramework’).WinFormsObject(’tableLayoutPanel11′)

Template Editor|Firewall and QoS|Port Triggering|Table|Service,Table, WinFormsObject(’TemplateEditorFramework’).WinFormsObject(’splitContainer1′).WinFormsObject(’SplitterPanel’, ”, 2). WinFormsObject(’ContentPanel’).WinFormsObject(’PortTriggering’).WinFormsObject(’panel1′).WinFormsObject(’ports’).WinFormsObject(’Port’, ”, %row%+3)

The test script has a similar syntax: the arbitrary descriptive name, an action, and any optional parameters.

Sample Test:

Test=Set Service in Port Trigger to ‘aci’ using drag and drop

Template Editor|Catalogs,Click Template Editor|Catalogs|Services|Tree|TCP,Click
Template Editor|Catalogs|Services|Tree|TCP|,Find,aci
Template Editor|Catalogs|Services|Tree|TCP|%currentEntry%,Click
Template Editor|Catalogs|Services|Tree|TCP|%currentEntry%,Drag, Template Editor|Firewall and QoS|Port Triggering|Table|0|Service

Mats simplifies testing since creating tests does not require programming just simple scripting, the tests are flexible to most application changes, and developers only need modify the script to update, create, and run tests that support changed functionality/implementation.

What can be tested?

• Files
• dBs (via ADO)
• Native Windows applications
• Web applications
• Visual properties of controls (fonts, colors etc.)
• Input/output text (variable text such as user names and fixed text such as prompts for multi-lingual applications)

Here is what the architecture looks like:

Notice that TestComplete is not required to run the tests, the much cheaper TestExecute is all that is needed. At least one instance of TestComplete is required however to record any scripts.

Benefits

There are several advantages that MATS gives to the testing procedure. The use of arbitrary component names permit implementation to be changed without changing tests. Tests are easier to create since they can be written by testers in simple script before the application is available. Testing can easily be performed by developers before committing changes. This assures addition problems are not introduced.

What started as a convenient and cost effective way for an us to offer a value added service has become a product in its own right. We have found customers who are interested in adding this novel approach to automated testing to their QA procedures as a way to cut costs, and expedite testing cycles.

By David Zinman

Software programming can be a solitary or collaborative effort. Similarly, so is creating music. The idea for both can be a singular endeavor, but it most often takes a combined effort to reach the finish. This similarity is described in the book by Andrew Johnston and Chris S. Johnson “Extreme Programming: A More Musical Approach to Software Development?“ where they hypothesize on the resemblance between musical and software development environments:

The characterization of software development as a craft rather than an engineering discipline has been proposed recently and it is felt that by considering the similarities and differences between the working and learning environments of musicians and developers that some further weight can be given to calls for a more collaborative approach to software development.

The debate that writing software code is an art has been around almost since coders have existed. I would not go so far as to say anything I have coded is “artistic” but some of the novel ideas that come from very focused coding fit with the idea of creating a piece of music.

Music is the organization of sounds with some degree of rhythm, melody, and harmony. I would argue that harmony should not be included in this definition since even a single voice is considered music where no harmony is present.

But the important idea in this definition is organization: it is the idea of organization and patterns that is common to both music and software. Design patterns are now an integral part of software development. A design pattern is a general reusable solution to a commonly occurring problem in software design. The most famous pattern in music is probably the opening sequence of Beethoven’s Fifth Symphony (G G G E-flat). Beethoven repeats this pattern several times in the movement in several variations. Once we understand the pattern of a particular piece, be it coded or musical, we are well on our way to a solution.

Jonathon Kohl explains the tension/resolution that makes up music is applicable in software testing. I would go further and say that it also applies to software coding. There is the intangible feeling of tension when an algorithm is in development, and the feeling of relief upon its successful resolution. For a great example of tension/resolution in music listen to Lenny Kravitz’ Mr. Cabdriver.

I would like to think that we should not be so pragmatic as to look at software development as being”solving a problem in order to start creating.”

It doesn’t really matter though because when I am done I put on the headphones and crank some Zeppelin. Anybody want to jam?

By David Zinman

A problem that often occurs in any software system is related to resource constraints or limitations; how do you make the best use of the resources that you have? This article will examine the challenge of designing a functional web user interface utilizing light server processing.

Modern hardware that handles copious amounts of sensitive data requires faultless processing, uninterruptible operation, and ease of use. The term ‘ease of use’ implies a user interface of some sort, in this case a web GUI. However, a highly interactive web interface can have an impact on the operation of the hardware if general processing is interrupted in order to handle user interface requests. In environments such as HTML: java script(.js), active server pages (.asp), or proprietary GUI development in C++, C# or Visual Basic, how do we maximize user interface functionality while minimizing processing on the server?

Maximize Client Processing

One solution is to limit the amount of processing on the data server that is devoted to the user interface. This may or may not be used with a third party user interface proxy server (UIPS) depending on the environment. A system that expects few concurrent users (typically 5 or less) can operate as:

UI client <–> data server

where there is not a huge demand on the processor.

A system that demands more concurrent users (6 or more) can benefit from a third party UI server operating as:

UI client <–> UIPS <–> data server

that will offload more processing power to the user interface proxy server.

Data Processing in the GUI

Giving some thought as to defining the structure of the data can be very significant in efficient data handling. Web Service Definition Language (WSDL) for SOAP, Management Information Base (MIB) for SNMP or other data syntax design for generic or specific data driven protocols should be given a high priority to assure non-redundant, efficient and light but complete coverage of information. Both the server and the web client will use the same data syntax for their respective communication layers, and as such, a data format that integrates to the system in an efficient way must be chosen.

One of the biggest burdens that is dumped on the server by data acquisition is table processing, especially large two dimensional lists. To alleviate as much overhead as possible make sure any sorting routines are carried out on the client. Table indexing in the data definition can be a big help in facilitating efficient data access.

Scripting languages can be slow and cumbersome. If possible, there should be no scripting engine residing on the server. The data is to be served in as raw a form as possible and all scripting should be carried out by the client.

Statistical data can pose a problem. Multiple server access for several statistics can put a heavy load on the server. Polling intervals should be set for a span that reports relevant information but does not overload the server.

Tradeoffs

These solutions do not come without a price. No server side scripting puts an extra effort on client development. Often the question of adding more data to a network request or supporting functionality on the server must be decided. The GUI itself must handle many of the routines easily handled on the server. This in turn can make the GUI slow and cumbersome. Consequently expert and efficient programming methods will help alleviate this issue.

By Luan Pham

One of our projects at MapleWorks in the last year required us to integrate the 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:

OSPF Stack Vendor: IP Infusion, Data Connection, Aricent, XORP, Vyatta, Ospfd, OpenOSPFD, Zebra

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?

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.)

(second of a two-part series)

By Ravi Ravishankar

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.)