Transcript CHAPTER 6

Network Management,
Management Information Base (MIB)s
and
Multiprotocol Label Switching (MPLS)
Principles, Design and Implementation
Stephen B. Morris
Chapter 6
Network Management
Software Components
By
Stanley Zurita
Mohamed Abdallatif
NETWORK MANAGEMENT
SOFTWARE COMPONENTS
There are many possible solutions to NMS
development - this chapter describes one
possible structure
 Server-side components
 Network-receiving asynchronous
 Network-receiving synchronous
 Network-sending
 Database access
 Client-side components
 Middleware components
 Data presentation, such as XML
 Northbound 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 distribution
Handling incoming notifications from network
Database forms the glue that ties
together the major component




Clients
Middleware
Server
NE’s
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
hides 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 fault
Origin: The originating NE(processor, card,
fabric,etc..) for the fault
Status: active, cleared, acknowledged( the
user knows 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
NE’s. Like the Fault Server, it also faces into the
network but operates 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 Explict Route
QoS
Object
LER1
BEST
EFFORT
LER2
LDP
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 IDs
Technology-specific connection tables: These
contain data relevant to specific connection
types, such as ATM PVX and LSPs
Operations log tables: These are for recording
configuration change
Operations 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 traffic
Average bandwidth used by the cell traffic
Number 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
network
Bandwidth 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 services
Maximize network utilization
Pre-empt the occurrence of congestion
Demonstrate compliance with agreed SLAs
Indicate 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 preempt 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: Super user, Read-only, and
User
Permitted views: Specific objects and sources
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
Discovery Server exist to keep up with
the detail of the deployed NE’s
Discovery
keep
track
of:
 Nodes










Interface and underlying stacks
Links
Virtual connection
Cross connections between different technologies
Routing protocols
Routing Tables
Signaling protocols
ICMP
SNMP
Standard 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 load
Rerouting traffic around any nodes to which
downloads are pending
Initiating the transfer
Handling rollback if the transfer fails
Verifying the transfer succeeded
Starting 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 located
Handling the transfer via FTP, TFTP, and so on
Restart the NE’s or reloading the data files
Informing the operator when the operation is
complete
Rerouting 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 NE’s.


The need for generic software components is
growing with the increasing deployment of
dense, multiservice NE’s 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 NE’s, 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.