CHAPTER 6NETWORK MANAGEMENT

SOFTWARE COMPONENTS

PRESENTATION

BY

DON KELLER

NETWORK MANAGEMENTSOFTWARE COMPONENTS

There are many possible solutions to NMS development- this chapter describes one possible structure.Server-side componentsNetwork-receiving asynchronousNetwork-receiving synchronous Network-sendingDatabase accessClient-side componentsMiddleware componentsData presentation, such as XMLNorthbound interface

Figure 1

`

. Typical servers provide the following

functions.Servicing client user requests

Issuing provisioning operations, such as writing to agent MIBS(inserting table entries, updating/deleting existing objects)

Special-purpose listening operations, such as monitoring LSP operational state

Providing generic service, such as scheduling

Providing specific service, such as NE, firmware and configuration data-base back-up, restore, and distributionHandling incoming notifications from networkDatabase form the glue that ties together the major componentClientsMiddlewareServerNEs

Thin client tend not to use database directly and instead rely on the server to manage the database

Recording client-initiated operations, such as creating FR or ATM virtual circuits

Storing the detail of scheduled operations and associated result

Thin client can be based on standard Web browser, there can be many such clients, and where to carry out bulk of the processing is an important design decision. If the principal requirement for client software is fast execution, then as much as possible of the MIB and database access should be carried out by the client rather than the MIB. If the client software is required to be simple and intuitive to use, then it should be designed to be as generic as possible. Generic software hide complex network data as much as possible and presents simple visual object proving default values where appropriate.

. This involves setting the MIB object values for

Bit rate

Parity

Number of data bits

Number of start bits

Number of stop bits, and so on

Fault Server

The purpose of the Fault Server is to process NE notification. It faces into the network and seeks to maintain parity between the NMS picture of network faults and the real situation in the network. A Fault Server will generally provide the following features:

Listening for notifications

Determining the underlying problem(root-cause analysis)

Updating persistent repositories and any GUI visual indicators

Fault Server Database Tables

Node ID(the Key)Description: A text string embedded in the notification explaining the faultOrigin: The originating NE(processor, card, fabric,etc..) for the faultStatus: active, cleared, acknowledged( the user know about the fault but has not cleared it)Color: Red for active, blue for acknowledged, green for clear

Topology update

CORBA

J2EE

JAVA RMI

RPC

Database update

Configuration Server

The purpose of the configuration server is to execute client-initiated directives made against NEs. Like the Fault Server, it also faces into the network but operate s in less open-ended way because it is not required to process asynchronous NE-originated notifications.

Let’s assume that a client user creates an LSP (label Switched Path) there are three

types

Signaled

Best-effort

Unidirectional

Origin Destination

Signaling Protocol

Required QoS

Explict Route Object

LER1 LER2 LDP BEST EFFORT

NONE

Secure User

Security Setting;

No authentication and no encryption

Authentication and no encryption

Authentication and encryption

Trace Files

Software bugs

SNMP timeouts, such as a third-party NE that has a slightly slow (or heavily loaded) agent

Bad values in MIB operations, such as trying to write an illegal value to a MIB object

Generic Connection Table Update

ATM virtual connection (PVX and SPVX0

MPLS LSP( signaled and unsignaled)

FR cross connections into an MPLS core

SONET path

Topology Update

Change the administrative status of a connection from up to down

Creating a new LSP

Deleting an existing LSP

Configuration Server Database Tables

Generic connection table: these contain data relevant to all connection types Keyes by index value or origination/ destination node IDsTechnology-specific connection tables: These contain data relevant to specific connection types, such as ATM PVX and LSPsOperations log tables: These are for recording configuration changeOperations result log tables: These are recording all configuration change results

ACCOUNTING SERVER

Accounting and performance software share a number of similarities. The Accounting Server faces into the network and receives data record periodically generated by NEs. Often, the data records are emitted based on a preconfigured time. It is also possible for an accounting Server to poll MIBs for specific data ultimately, accounting data is concerned with billing users for network resources consumption.

Mediation

Mediation is the process of analyzing the raw data generated by NEs to produce standard format billing details for downstream use by third-party applications (from organizations such as ACE*COMM). It is not necessary to use standard formats if the billing application is proprietary. However, standard format have the merit of allowing different third-party application to be swapped in as required.

Aggregation

This is the process by which separate CDRs are combined. An example is an ATM PVC that spans a number of NEs Number of IP packets transported (if the circuit is an LSP)Number of cells transported per second (if the circuit is an ATM connection)Number of cells dropped due to excessive input trafficAverage bandwidth used by the cell trafficNumber of SLA contract violations

Correlation

Correlation is the process of combining multiple units of aggregated data with the details of the ultimate bill recipient, that is, one customer. Number of cells sent to or received from the SP networkBandwidth used in transporting the data across the ATM link

Reports

Utilization of objects, such as LSPs

The average and peak numbers of IP packets transported by the LEP

The bandwidth consumed

Performance Server

The purpose of the Performance Server is to analyze network data in order to Determine if problems exist prior to their affecting servicesMaximize network utilizationPre-empt the occurrence of congestionDemonstrate compliance with agreed SLAsIndicate when extra network investment is needed(capacity planning)

SLA Alert

It is very important for enterprises to avoid violating SLA terms because there may be financial penalties.SLA alert can be issued based on ongoing analysis of trends in an effort to pre-empt violations before they actually occur.

Source IP address 10.81.1.45

Source Port 444

Destination IP address 10.81.2.89

Destination Port 445

Link Bandwidth 10Mbps

Interpacket Delay 1ms

Ordered Delivery Yes

Packet Loss 0.0001%

Jitter No

Round Trip Delay 30ms

This SLA indicates that IP traffic from 10.81.1.45 port 444 will land in the SP network on a 10Mbps link destined for 10.81.2.89 port 445. The interpacket arrival time is specified to be no more than 1 millisecond with no packet arriving out of order. A tunneling technology such as MPLS or L2TP could be employed to achieve the latter

Topology Update

When congestion is imminent on a given link

When a virtual circuit is being presented with excessive traffic-it may be necessary to add extra bandwidth to the circuit

Performance Server Database Tables

Nodes

Interface

Links

Virtual connections

Each table has separate columns for relevant performance

Number of incoming and outing packets, cells, and frames

Bandwidth in use

SLA status

Security Server

If there is one area of network management that has moved to the top of the operator’s, agenda, it is security, Access application: SNMP, telnet, secure shell, Web, console( serial port)Authentication ; Password, community string, Kerberos, user-based security Remote Access Dial-In User Service (RADIUS)Privilege level: Superuser, Read-only, and UserPermitted views: Specific objects and soures

Access Applications

Limited or no logging apart from that provided by the NE or CLi

Fairly open access to sensitive NE data

It may be error-prone, and help facilities may be quite limited

Some popular access applications are:

SNMP

Telnet

Secure Shell

Web

Authentication: Privilege Level

Read-only

User-level

Superuser

Read-only access allow only MIB get; user-level allows gets and some sets; superusers can get and set all appropriate

Permitted Views

Access control list

Permitted object views

An access control list contain the source IP addresses allowed to connect to an NE. Permitted object views specify a subset of MIB object accessible to a given NMS user

A discovery Server exist to keep up with the detail of the deployed NEs

Discovery keep track of:NodesInterface and underlying stacksLinksVirtual connection Cross connections between different technologiesRouting protocolsRouting TablesSignaling protocolsICMPSNMPStandard and proprietary signaling protocols

NE Software Distribution

FTP/TFTP

Proprietary download mechanisms

Using an NMS

Distributing NE in step:

Preparing the NE for a new firmware loadRerouting traffic around any nodes to which downloads are pendingInitiating the transferHandling rollback if the transfer failsVerifying the transfer succeededStarting up the new NE software

Preparing the NE may involve

Bring the NE into a quiescent state

Closing down existing connections

Ensuring that no resource are in use on the NE

Determining the available FLASH and RAM free space

Taking a copy of the existing firmware

NE Configuration Database Backup and Restore

Some reason for backing up:

New firmware build may upgrade the configuration, making rollback difficult

Disaster recovery

Creating Mirror network

Using a given configuration as a template

NMS should handle the complexities of:

Knowing where the appropriate configuration data flies are locatedHandling the transfer via FTP, TFTP, and so onRestart the NEs or reloading the data filesInforming the operator when the operation is completeRerouting traffic around the nodes being restored

Middleware

Middleware is the part of an NMs that allow communication between the clients and servers, There is a broad range of software technology choices for achieving this, including RPC,JAVA,COBRA, J2EE, and Microsoft.Net

SUMMARY

The implementation of NMS software can take the form of sever .These are high perform software objects that can support interaction with both external clients and NEs, It is essential that server are resilient and designed so that they are unlikely to fail except in exceptional circumstances. They form the intermediate layer through which end users can securely communicate with NEs.

The need for generic software components is growing with the increasing deployment of dense, multiservice NEs Generic software attempts to abstract complex Ne data as much as possible and present simple GUIs applicable across a broad range of devices.On the client side, GUI views are often depicted as network topologies accompanied by fault listings, It is a major challenge for the NMS software to keep these views synchronized with the network. It is always hard to escape form legacy NEs, and for this reason it is often necessary for server components to be SNMP multilingual, that is able to use any of SNMPv1/2c/3.