Approach For Integration Of Third Party Nodes With Proprietary OSS

OSS-TMN Architecture

Operations Support System (OSS) is huge, and several attempts to slice it into understandable pieces exist. One, which has gained a general acceptance, is the TMN (Telecommunications Management Network) model M.3100 by ITU. They introduced the “TMN pyramid” where the management is divided into a number of layers as depicted below:

The meaning of the layers is described below. Please note that each layer is dependent on the services provided by the adjacent layer below:

• Network Elements: Elemental or fundamental units of a network, such as a transmitter, amplifier, repeater, multiplexer, switch, router, copper or fiber optic transmission link, microwave antenna, or receiver constitute a network element.
• Element Management: The management functionality that is required to operate an individual network element. The functionality is divided into five key areas: Fault, Configuration, Accounting, Performance and Security (FCAPS). This layer’s northbound surface interfaces to Network Management System and it’s southbound to the network elements (NE).
• Network Management: When multiple network elements are interconnected they form a network. Network Management refers to the functionality required to monitor and administer a network. It involves a distributed database, auto polling of network devices, and high-end workstations generating real-time graphical views of network topology changes and traffic. In general, network management is a service that employs a variety of tools, applications, and devices to assist human network managers in monitoring and maintaining networks.
• Service Management: The network provides services. A leased line subscription, an email account and a telephone subscription are a few examples. Service management refers to the controlling of these services.
• Business Management: The services are provided to subscribers (customers). The customer management and related issues like billing is referred to as Business Management. The strength of the TMN model is that it provides the capability to reach a level of abstraction that is increased through the layers. Ideally there is no need for interference between layers that are not adjacent. Another contribution from the TMN model is the division of management functionality into a number of functional areas as mentioned before, the FCAPS model:
• Fault Management: Handling of alarms.
• Configuration Management: Installing and configuring the object in questions, be it a service or a physical port.
• Accounting Management: The creation and mediation of resource usage data and the subsequent rating and billing of the service usage.
• Performance Management: The creation, collection and aggregation of statistics related to resource
• usage. The creation and handling of reports related to the collected statistics.
• Security Management: All aspects related to security of the management functionality. The area spans from authentication of the operators to access control, i.e. who is allowed to do what, when, from where.

SNMP – Terminology explained

Simple Network Management Protocol (SNMP) is a popular protocol for network management. It is used for collecting information from, and configuring, network devices, such as servers, printers, hubs, switches, and routers on an Internet Protocol (IP) network.
Basic SNMP components:

• Managed devices.
• SNMP agent.
• SNMP Manager (NMS)

Each managed device runs a process called an agent. The agent is a server process that maintains the MIB database for the device. An SNMP manager is an application that generates requests for MIB information and processes the responses. The manager and agent communicate using the Simple Network Management Protocol.

SNMP agents (like snmpd daemon process) typically have predefined MIB objects that they can access. SNMPD is an SNMP agent which binds to a port (default port: 161) and awaits requests from SNMP manager. Upon receiving a request, it processes the request(s), collects the requested information and/or performs the requested operation(s) and returns the information to the sender.

An SNMP subagent is used to extend the number and type of MIB objects that an SNMP agent can support.

An SNMP manager can issue requests to an agent either to retrieve information from the agent’s MIB (an SNMP Get request), or to change information in the agent’s MIB (an SNMP Set request). An SNMP agent can also send unsolicited messages to the SNMP manager (SNMP traps).

The SNMP agent talks to both subagents and managers. The SNMP manager (which resides on one node in the network) sends requests to the agent (which resides on another). The agent sends responses and traps to the manager.

Fault Management (FM) Integration of 3rd Party Nodes with Proprietary OSS

From the customer’s perspective, fault management forms one of the most important aspects to deal with in their day to day network management activities. It helps them to detect a faulty node in the network remotely and depending on the nature and severity of the alarm, actions are taken accordingly.

The fault management (FM) integration of a network node to an OSS typically means a successful integration resulting in receiving the traps from the network node (hosts SNMP agent) by an OSS (hosts SNMP manager) and displaying it on the alarm monitor with the meaningful information. The alarm monitor would be used by the network operator (FM engineer to be specific) and is responsible for the corrective actions on the faulty node thereafter.

The third party nodes may not be compliant with the proprietary OSS with respect to the format of the trap/PDU (protocol data unit). Hence, it becomes the responsibility of the OSS to convert the traps from the managed node (SNMP agent) into its own desirable format to display it on the alarm monitor. And for the SNMP get and set requests initiated by the SNMP manager, the OSS should be compliant with SNMP get and set PDUs formats specified under standard SNMP.

Some third party platforms may demand supervision of their SNMP agents from OSS. This feature is enabled from the SNMP manager and the agent should be capable enough to respond with appropriate information requested by the manager for supervision.

How To Approach And What To Look For

Fault management is an integral part of a Network Management System, and it entirely depends on the proprietary OSS as to how it would provide this feature.

Before you start the integration process, it is very important to understand the architecture of the third party node to be integrated and identify the crucial elements that can help us to appreciate the flow of the traps within their system. Help should be sought from the third party personnel in the following areas of their system:

• Architecture
• Flow of the traps within their system
• SNMP agents and subagents
• MIB files
• Other general system information based on the need

For integration personnel, the core information of the traps that would be sent by the managed device can be known from what are called as MIB files (Management Information Base). These MIB files are provided by the system where the SNMP agent and subagents are running.

These files provide most of the information about the various traps that the system is likely to send. Apart from this, it also has information about various objects and variables of the system, and the same can be queried and set by the SNMP manager through SNMP. All these traps, objects etc are identified by their OIDs (object Identifier).

These MIB files have to be analyzed in order to understand the format of the trap PDU.

Configuration Steps

As mentioned previously, third party nodes provide the needed information through MIB files. Once the information described in the previous section has been collected, OSS needs to be configured with the same. This configuration lies within the scope of OSS as to how it would facilitate it. For example, some OSSs provide the FM integration personnel with a toolkit which assists them in configuration. Meanwhile the third party should be doing the needed SNMP configuration from their end and they should be provided with OSS details like IP address, SNMP port number where OSS listens for the traps (default UDP port: 162).

The entire process can be broadly understood with the following steps:

• Configuration of the IP address of the managed node in OSS
• Adding the managed object (third party node) to the topology database maintained by the OSS.
• Configuration of the trap information in OSS
• IP connectivity between OSS and the managed node.
• Start receiving traps from the managed node.

The third party node is added to the topology database of OSS which enables the node to be managed from OSS’s TLUI (Top Level User Interface) and to display its alarms on the alarm monitor.

Once the configuration is done, make sure that there is connectivity between OSS and the third party node over the customer’s IP network. Basic connectivity can be confirmed by using ping command. There would be a separate team at the customer’s place taking care of the network. Help can be taken from them. As mentioned above, SNMP manager listens on UDP port 162 for the traps which are being sent over the network. Hence, the managed node should send the traps to port 162.

This completes the integration task and a thorough testing should be done from both the ends. All types of alarms (critical, major and minor) should be tested to declare the integration as successful.

Challenges

There are multiple challenges one faces while integrating the 3rd party nodes with OSS first time

• In few cases, the third party platforms do not send the trap in the expected format. The format is understood from the MIB file of the third party which defines the sequence of variables of the trap. For example, if the first field of the trap is defined in the MIB file to contain “alarm description” and when the OSS receives the trap with first field having “alarm number”, this becomes a case where the third party platform fails to be compliant with its own MIB file, and thus resulting in the unexpected format of the trap. As a consequence of this, the OSS either fails to process the trap or displays wrong information on the monitor. This is a clear error from the third party node. In such a scenario, the same has to be communicated to the third party team and seek a correction from them.
• Another challenge lies in testing of all the possible traps. Since the third party platform would not be sending all the traps without any reason, they will have to be generated manually by the third party team. This also becomes a challenge for them but not impossible. It is usually agreed by all the parties involved in the integration that this is an acceptable and preferred way of testing. When the alarm monitor displays all the information correctly, it indicates that the various fields of the trap have been processed successfully.