NETWORKING-MANAGEMENT - National Institute of ...

curvyrawrNetworking and Communications

Oct 23, 2013 (3 years and 8 months ago)

136 views

NETWORK
ING

MANAGEMENT



INTRODUCTION

CHAPTER I
-

NETWORK MANAGEMENT ARCHITECTURES AND APPLICATIONS

CHAPTER II
-

NETWORK MANAGEMENT FUNCTIONS


CONFIGURATION

CHAPTER III
-

SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)

CHAPTER IV
-

SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP): SNMP V1


CHAPTER V
-

NETWORK MANAGEMENT FUNCTIONS


FAULT

CHAPTER VI
-

SIMPLE NETWORK MANAGEMEN
T PROTOCOL
-

SNMP V2

CHAPTER VII
-

NETWORK MANAGEMENT FUNCTIONS


SECURITY

CHAPTER VIII
-

SIMPLE NETWORK MANAGEMENT PROTOCOL
-

SNMP V3

CHAPTER IX
-

NETWORK MANAGEMENT FUNCTIONS
-

ACCOUNTING AND PERFORMANCE

CHAPTER X
-

REMOTE NETWORK MONITORING RMON 1 AND RMON 2


























__

INTRODUCTION TO NETWORK MANAGEMENT


What Is Network Management?


Network management means different things to different people. In some cases, it involves a
solitary network consultant monitoring network activity with an outdated protocol analyz
er. In other
cases, network management 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 tha
t employs a variety of tools, applications, and
devices to assist human network managers in monitoring and maintaining networks.


Network management refers to the activities, methods, procedures, and tools that pertain to
the operation, administration, ma
intenance, and provisioning of networked systems. Network
management is an essential factor in successfully operating a network. As a company becomes
increasingly dependent on networking services, keeping those services running is synonymous with
keeping
the business running. Network Management Fundamentals provides you with an accessible
overview of network management covering management not just of networks themselves but also of
services running over those networks.




Operation deals with keeping the n
etwork (and the services that the network provides) up and
running smoothly. It includes monitoring the network to spot problems as soon as possible, ideally
before users are affected.




Administration deals with keeping track of resources in the network

and how they are
assigned. It includes all the "housekeeping" that is necessary to keep the network under control.




Maintenance is concerned with performing repairs and upgrades
-

for example, when
equipment must be replaced, when a router needs a patc
h for an operating system image, when a
new switch is added to a network. Maintenance also involves corrective and preventive measures to
make the managed network run "better", such as adjusting device configuration parameters.




Provisioning is concerne
d with configuring resources in the network to support a given service.
For example, this might include setting up the network so that a new customer can receive voice
service.


Network Management refers to the broad subject of managing computer networks.

There exists a
wide variety of software and hardware products that help network system administrators manage a
network.


Five areas of Network Management are defined:


1.

Performance Management:

The goal of performance management is to quantify, measure,

report, analyze and control the performance (e.g., utilization, throughput) of different network
components. These components include individual devices (e.g., links, routers, and hosts) as well as
end
-
end abstractions such as a path through the network.

We will see shortly that protocol standards
such as the Simple Network Management Protocol (SNMP) play a central role in performance
management. The goal is to both prepare the network for the future, as well as to determine the
efficiency of the current
network. Performance management is focused on ensuring that network
performance remains at acceptable levels. This area is concerned with gathering regular network
performance data such as network response times, packet loss rates, link utilization, and
so forth.
This information is usually gathered through the implementation of an SNMP management system,
either actively monitored, or configured to alert administrators when performance move above or
below predefined thresholds. Actively monitoring current

network performance is an important step in
identifying problems before they occur, as part of a proactive network management strategy.


2.

Fault Management:

The goal of fault management is to log, detect, and respond to fault
conditions in the network.
The line between fault management and performance management is
rather blurred. We can think of fault management as the immediate handling of transient network
failures (e.g., link, host or router hardware or software outages), while performance management

takes the longer term view of providing acceptable levels of performance in the face of varying traffic
demands and (hopefully rare) network device failures. As with performance management, the SNMP
protocol plays a central role in fault management of IP
networks. Fault management is concerned
with detecting network faults, logging this information, contacting the appropriate person, and
ultimately fixing a problem. A common fault management technique is to implement an SNMP
-
based
network management syst
em
-

such as HP Open View or Sun Solstice (formerly Net Manager)
-

to
collect information about network devices. In turn, the management station can be configured to
make a network administrator aware of problems (by email, paging, or on
-
screen messages),
allowing appropriate action to be taken.


3.

Configuration Management:

Configuration management allows a network manager to track
which devices are on the managed network and the hardware and software configurations of these
devices. The goals of configur
ation management are to gather/set/track configurations of the
devices. Configuration management is concerned with monitoring system configuration information,
and any changes that take place. This area is especially important, since many network issues ar
ise
as a direct result of changes made to configuration files, updated software versions, or changes to
system hardware. A proper configuration management strategy involves tracking all changes made to
network hardware and software. Examples include alteri
ng the running configuration of a device,
updating the IOS version of a router or switch, or adding a new modular interface card. While it is
possible to track these changes manually, a more common approach is to gather this information
using configuration

management software, such as CiscoWorks 2000.


4.

Accounting Management:

Accounting management allows the network manager to specify,
log, and control user and device access to network resources. Usage quotas, usage
-
based charging,
and the allocation of
resource access privileges all fall under accounting management. The goal is to
gather usage statistics for users. Accounting management is concerned with tracking network
utilization information, such that individual users, departments, or business units

can be appropriately
billed or charged for accounting purposes. While this may not be applicable to all companies, in many
larger organizations the IT department is considered a cost center that accrues revenues according to
resource utilization by indivi
dual departments or business units.


5.

Security Management:

The goal of security management is to control access to network
resources according to some well
-
defined policy. The goal of security management is to control
access to assets in the network. It

uses firewalls to monitor and control external access points to
one's network. Security management is not only concerned with ensuring that a network environment
is secure, but also that gathered security
-
related information is analyzed regularly. Securit
y
management functions include managing network authentication, authorization, and auditing, such
that both internal and external users only have access to appropriate network resources. Other
common tasks include the configuration and management of networ
k firewalls, intrusion detection
systems, and security policies such as access lists.


A common way of characterizing network management functions is FCAPS
-

Fault, Configuration,
Accounting, Performance and Security.

Functions that are performed as part o
f network management accordingly include controlling,
planning, allocating, deploying, coordinating, and monitoring the resources of a network, network
planning, frequency allocation, predetermined traffic routing to support load balancing, cryptographic
k
ey distribution authorization, configuration management, fault management, security management,
performance management, bandwidth management, and accounting management.


Data for network management is collected through several mechanisms, including agents
installed on
infrastructure, synthetic monitoring that simulates transactions, logs of activity, sniffers and real user
monitoring. In the past network management mainly consisted of monitoring whether devices were up
or down; today performance management
has become a crucial part of the IT team's role which
brings about a host of challenges
--

especially for global organizations.


A Historical Perspective:


The early 1980s saw tremendous expansion in the area of network deployment. As companies
realized th
e cost benefits and productivity gains created by network technology, they began to add
networks and expand existing networks almost as rapidly as new network technologies and products
were introduced. By the mid
-
1980s, certain companies were experiencing
growing pains from
deploying many different (and sometimes incompatible) network technologies.

The problems associated with network expansion affect both day
-
to
-
day network operation
management and strategic network growth planning. Each new network techn
ology requires its own
set of experts. In the early 1980s, the staffing requirements alone for managing large, heterogeneous
networks created a crisis for many organizations. An urgent need arose for automated network
management (including what is typicall
y called network capacity planning) integrated across diverse
environments.
























CHAPTER I


NETWORK MANAGEMENT ARCHITECTURES AND APPLICATIONS


The architecture of a network management system is conceptually identical to this simple
human

organizational analogy. The network management field has its own specific terminology for
the various components of network management architecture, and so we adopt that terminology here.
There are three principle components of network management archit
ecture: a managing entity (e.g.,
the boss in our above analogy
-

you), the managed devices (the branch office), and a network
management protocol.




The managing entity is an application, typically with a human
-
in
-
the
-
loop, running in a
centralized networ
k management station in the network operations center (NOC). The managing
entity is the central locus of activity for network management
-

it

controls the collection, processing,
analysis, and/or display of network management information. It is here that

actions are initiated to
control network behavior and here that the human network administrator interacts with the network
devices.




A managed device is a piece of network equipment (including its software) that resides on a
managed network. This is t
he branch office in our human analogy. A managed device might be a
host, router, bridge, hub, printer, or modem device. Within a managed device, there may be several
so
-
called managed objects. These managed objects are the actual pieces of hardware within
the
managed device (e.g., a network interface card)
, and

the sets of configuration parameters for the
pieces of hardware and software (e.g., an intradomain routing protocol such as RIP). In our human
analogy, the managed objects might be the departments wi
thin the branch office. These managed
objects have pieces information associated with them that are collected into a management
information base (MIB)
; we’ll

see that the values of these pieces of information are available to (and
in many cases
settable

b
y) the managing entity. In our human analogy, the MIB corresponds to
quantitative
data (
measures of activity, productivity, and budget, with the latter being
settable

by the
managing entity!) exchanged between the branch office and the main offic
e.

Final
ly, also resident in
each managed device is a network management agent,
a process

running in the managed device
that communicates with the managing entity, taking local actions on the managed device under the
command and control of the managing entity. T
he network management agent is the branch manager
in our human analogy.




The third piece of network management architecture is the network management protocol.
The protocol runs between the managing entity and the managed devices, allowing the managing

entity to query the status of managed devices and indirectly effect actions in these devices via its
agents. Agents can use the network management protocol to inform the managing entity of
exceptional events (e.g., component failures or violation of perf
ormance thresholds).

As defined by the ISO/OSI Network management model and its subset of protocols, namely SNMP
and CMIP a Network Management Application (NMA) is the software that sits on the Network
Management Station (NMS) and retrieves data from a Ma
nagement Agent (MA).



A. Management standards and models


The International Organization for Standardization (ISO) under the direction of the OSI group
has created a network management model as the primary means for understanding the major
functions of ne
twork management systems.


The model in question is interchangeably called either the OSI network management model or
ISO network management model so the full name could be the OSI/ISO network management model.


i.
The Five

areas of function of the model


The OSI network management model categorizes five areas of function, sometimes referred to
as the FCAPS model:


a. Fault:


The goal of fault management is to recognize, isolate, correct and log faults that occur
in the network. Errors primarily occur in t
he areas of fault management and configuration
management.

Fault management is concerned with detecting network faults, logging this information,
contacting the appropriate person, and ultimately fixing a problem. A common fault
management technique is to
implement an SNMP
-
based network management sy
stem
-

such
as HP Open View or
Sun Solstice (formerly Net Manager)
-

to collect information about
network devices. In turn, the management station can be configured to make a network
administrator aware of probl
ems (by email, paging, or on
-
screen messages), allowing
appropriate action to be taken.


b. Configuration:


The goals of configuration management are to gather/set/track configurations of the
devices. Configuration management is concerned with monitoring s
ystem configuration
information, and any changes that take place. This area is especially important, since many
network issues arise as a direct result of changes made to configuration files, updated
software versions, or changes to system hardware. A prop
er configuration management
strategy involves tracking all changes made to network hardware and software. Examples
include altering the running configuration of a device, updating the IOS version of a router or
switch, or adding a new modular interface car
d. While it is possible to track these changes
manually, a more common approach is to gather this information using configuration
management software, such as CiscoWorks 2000.


c. Accounting:



The goal is to gather usage statistics for users. Accounting m
anagement is concerned
with tracking network utilization information, such that individual users, departments, or
business units can be appropriately billed or charged for accounting purposes. While this may
not be applicable to all companies, in many larg
er organizations the IT department is
considered a cost center that accrues revenues according to resource utilization by individual
departments or business units.


d. Performance
:



The goal is to both prepare the network for the future, as well as to de
termine the
efficiency of the current network. Performance management is focused on ensuring that
network performance remains at acceptable levels. This area is concerned with gathering
regular network performance data such as network response times, packe
t loss rates, link
utilization, and so forth. This information is usually gathered through the implementation of an
SNMP management system, either actively monitored, or configured to alert administrators
when performance move above or below predefined thr
esholds. Actively monitoring current
network performance is an important step in identifying problems before they occur, as part of
a proactive network management strategy.


e. Security:



The goal of security management is to control access to assets in
the network. It uses
firewalls to monitor and control external access points to one's network. Security management
is not only concerned with ensuring that a network environment is secure, but also that
gathered security
-
related information is analyzed reg
ularly. Security management functions
include managing network authentication, authorization, and auditing, such that both internal
and external users only have access to appropriate network resources. Other common tasks
include the configuration and manag
ement of network firewalls, intrusion detection systems,
and security policies such as access lists.


ii.

Standards


The two standards that have emerged
are:


a. Simple SNMP by
IETF:



Simple Network Management Protocol (SNMP) is used in network management

systems to monitor network
-
attached devices for conditions that warrant administrative
attention. SNMP is a component of the Internet Protocol Suite as defined by the Internet
Engineering Task Force (IETF). It consists of a set of standards for network ma
nagement,
including an application layer protocol, a database schema, and a set of data objects.


SNMP exposes management data in the form of variables on the managed systems,
which describe the system configuration. These variables can then be queried (a
nd sometimes
set) by managing applications.


The Simple Network Management Protocol (SNMP) is an application layer protocol that
facilitates the exchange of management information between network devices. It is part of the
Transmission Control Protocol/Int
ernet Protocol (TCP/IP) protocol suite. SNMP enables
network administrators to manage network performance, find and solve network problems, and
plan for network growth.


Two versions of SNMP exist: SNMP version 1 (SNMPv1) and SNMP version 2
(SNMPv2). Both

versions have a number of features in common, but SNMPv2 offers
enhancements, such as additional protocol operations. Standardization of yet another version
of SNMP

SNMP Version 3 (SNMPv3)

is pending.


b. Common management information protocol CMIP by ITU
-
T:


Common Management Information Protocol (CMIP) is a protocol for network
management;

it provides an implementation for the services defined by CMIS, allowing
communication between network management applications and management agents.
CMIS/CMIP emerged

out of the ISO/OSI Network management model and is defined by the
ITU
-
T X.700 series of recommendations, its more popular correspondent designed by the IETF
being SNMP.


CMIP models management information in terms of managed objects and allows both
modifi
cation and performing actions on managed objects. Managed objects are described
using GDMO and are identified by a distinguished name (DN), similar in concept to the X.500
directory.


CMIP also provides good security (support authorization, access control,

and security
logs) and flexible reporting of unusual network conditions.


B. Network planning and design


It is an iterative process, encompassing topological design, network
-
synthesis, and network
-
realization, and is aimed at ensuring that a new network
or service meets the needs of the subscriber
and operator. The process can be tailored according to each new network or service.


The process can be tailored according to each new network or services. This is an extremely
important process which must be p
erformed before the establishment of a new telecommunications
network or services.


i.

A network planning methodology


A traditional network planning methodology involves four layers of planning, namely:




Business

planning




Long
-
term

and medium
-
term n
etwork planning




Short
-
term

network planning




Operations

and maintenance.


Each of these layers incorporate plans for different time horizons, i.e. the business planning
layer determines the planning that the operator must perform to ensure that the

network will perform
as required for its intended life
-
span. The Operations and Maintenance layer, however, examines
how the network will run on a day
-
to
-
day basis.


The network planning process begins with the acquisition of external information. This in
cludes:




Forecasts

of how the new network/service will operate;




The

economic information concerning costs; and




The

technical details of the network’s capabilities.



It should be borne in mind that planning a new network/service involves implemen
ting the new
system across the first four layers of the OSI Reference Model. This means that even before the
network planning process begins, choices must be made, involving protocols and transmission
technologies.



Once the initial decisions have been ma
de, the network planning process involves three main
steps:




Topological design: This stage involves determining where to place the components
and how to connect them. The (topological) optimisation methods that can be used in this stage come
from an are
a of mathematics called Graph Theory. These methods involve determining the costs of
transmission and the cost of switching, and thereby determining the optimum connection matrix and
location of switches and concentrators.




Network
-
synthesis: This stage

involves determining the size of the components used,
subject to performance criteria such as the Grade of Service (GoS). The method used is known as
"Nonlinear Optimisation", and involves determining the topology, required GoS, cost of transmission,
etc.
, and using this information to calculate a routing plan, and the size of the components.




Network realization: This stage involves determining how to meet capacity
requirements, and ensure reliability within the network. The method used is known as
"Mul
ticommodity Flow Optimisation", and involves determining all information relating to demand,
costs and reliability, and then using this information to calculate an actual physical circuit plan.


These steps are interrelated and are therefore performed ite
ratively, and in parallel with one
another. The planning process is highly complex, meaning that at each iteration, an analyst must
increase his planning horizons, and in so doing, he must generate plans for the various layers
outlined above.


ii. The rol
e of forecasting


During the process of Network Planning and Design, it is necessary to estimate the expected
traffic intensity and thus the traffic load that the network must support. If a network of a similar nature
already exists, then it may be possibl
e to take traffic measurements of such a network and use that
data to calculate the exact traffic
load.
However, as is more likely in most instances, if there are no
similar networks to be found,
then network

planner must use telecommunications forecasting

methods to estimate the expected traffic intensity.


The forecasting process involves several steps as follows:



Definition of problem;



Data acquisition;



Choice of forecasting method;



Analysis/Forecasting;



Documentation and analysis of resu
lts.















__

CHAPTER II


NETWORK MANAGEMENT FUNCTIONS


CONFIGURATION



A. Configuration management


Configuration Management (CM) is a field of management that focuses on establishing and
maintaining consistency of a product's performance and it
s functional and physical attributes with its
requirements, design, and operational information throughout its life. For information assurance, CM
can be defined as the management of security features and assurances through control of changes
made to hardw
are, software, firmware, documentation, test, test fixtures, and test documentation
throughout the life cycle of an information system.


i. History


Configuration management was first developed by the United States Department of Defense in
the 1950s as a t
echnical management discipline. The concepts have been widely adopted by
numerous technical management models, including systems engineering, integrated logistics support,
Capability Maturity Model Integration (CMMI), ISO 9000, Prince2 project management m
ethodology,
COBIT, Information Technology Infrastructure Library (ITIL), product lifecycle management, and
application lifecycle management. Many of these models have redefined configuration management
from its traditional holistic approach to technical ma
nagement. Some treat configuration management
as being similar to a librarian activity, and break out change control and change management as
separate areas of discipline; some break out the traditional elements of revision control and
engineering release
into separate management disciplines; others treat CM as an overarching
management discipline.


ii. What is Network Configuration Management?


Network configuration management allows you to control changes to the configuration of your
network devices, lik
e switches and routers. Using configuration management tools you can make
changes to the configuration of a router,
and then

roll the changes back to a previous configuration if
the changes weren’t successful. Contrast the previous situation with a network

configuration
management system with the situation without a network configuration management system. You
would make the changes, hopefully remembering to document what you changed. If the changes
weren’t successful you would, at best,
and then

have to un
do the changes you made manually from
your documentation. At worst, you would be left with trying to remember what was changed and why.

Network configuration management really comes into its own when multiple engineers make changes
to network equipment. Ho
w does engineer A know what engineer B has been up to? Even if they
communicate well together the chances are that crucial details will be missed out. The changes made
by engineer A may only fail when engineer B is on duty. How is engineer B expected to tr
oubleshoot
the network when he/she doesn’t know exactly what changes engineer A made?


Another area in which network configuration management comes into its own is policy
enforcement. Say you want to roll out the same configuration (with minor differences
like the IP
address) to multiple devices. Performing manual configuration updates can take a long time,
especially if you have a lot of network devices. With the help of intelligent network configuration
management, the more error prone tasks can be automa
ted saving time & reducing the risk of errors.


iii. Why do I need Network Configuration Management?


Networks of any size are in a constant state of flux. Any of the engineers responsible for the
network can change the configuration of the switches and ro
uters at any time. Configuration changes
to live equipment can have devastating effects on the reliability of the network and the services
provided by it. Network configuration management is designed to allow you to take control of network
changes.


Networ
k configuration management is intended to simplify the job of managing medium to
large networks. The aim of network configuration management is to save you time & reduce errors on
your network due to misconfiguration of network devices. Even if your networ
k changes do cause
errors, network configuration management allows you to fix the errors faster.


I’ve often been in the situation where I wished that I could move a system’s configuration back
in time to when the device worked properly. Having a network c
onfiguration management system
means that you can change a device’s configuration with a much reduced risk of downtime. If you
make a mistake, simply roll back your changes to a version of the configuration that you know works.

When a fault has been identi
fied on your network it can be invaluable to have an audit trail of all
configuration changes of your network devices. Not only will you quickly be able to identify which
devices have changed, but also what the changes were, when the changes were made & by

whom.


a. Network Configuration Management Tools:


A wide range of tools are available for network configuration management. Broadly
speaking they can be split into two main categories, vendor specific tools & vendor neutral
tools.


Vendor specific tools,

from vendors like Cisco, Nortel & Checkpoint, only work with their
respective equipment. These can be a good choice in homogenous environments in which a
single vendor’s equipment predominates. Unfortunately, such environments, especially
amongst larger n
etworks, are rare. Usually a range of equipment from a number of vendors is
in use.


In heterogeneous environments a vendor neutral tool would be a better choice.


b. Open Source


The open source world doesn’t have anything that can go toe to toe with any
of the
major commercial vendors. This is unfortunate, though perhaps understandable. The
development of a major network configuration management tool requires access to a wide
range of equipment that is unlikely to be available to many open source develope
rs. High end
network equipment can be very expensive.

Really Awesome New Cisco confIg Differ (Rancid):


Whilst Rancid isn’t a full blown network configuration management system it does
provide some useful features. Rancid’s goal is to make it easy to spot
changes to device
configurations. Rancid can be executed periodically and any changes to device configuration
can then be emailed to one or more network managers. The changes are then stored in CVS
(a software configuration management system).


Rancid sup
ports a number of vendor’s equipment including: Cisco routers and Catalyst
switches, as well as equipment from Alteon, Bay Networks, Extreme, Force 10 Networks,
Foundry, HP, Juniper and Redback. Rancid runs on most flavors of UNIX including Linux &
*BSD. I
t does not work on Microsoft Windows.


c. Commercial


A number of vendors like Relicore & Voyence supply network configuration
management systems. Though, many position their products as application configuration
management systems
i.e.

managing changes to

application configurations like Apache & SQL
Server.


Alterpoint just does network configuration management. The Alterpoint solution is made
up of three main components: an auditing/change management module, a device update
module and a server to tie the
two together in a central server.


iv. Software configuration management


The traditional software configuration management (SCM) process is looked upon as the best
solution to handling changes in software projects. It identifies the functional and physica
l attributes of
software at various points in time, and performs systematic control of changes to the identified
attributes for the purpose of maintaining software integrity and traceability throughout the software
development life cycle

.

The SCM process
further defines the need to trace changes, and the ability to verify that the
final delivered software has all of the planned enhancements that are supposed to be included in the
release. It identifies four procedures that must be defined for each software

project to ensure that a
sound SCM process is implemented. They are:


a
.

Configuration identification


b
.

Configuration control


c
.

Configuration status accounting


d
.

Configuration authentication


These terms and definitions change from standard to s
tandard, but are essentially the same.




Configuration identification is the process of identifying the attributes that define every
aspect of a configuration item. A configuration item is a product (hardware and/or software)
that has an end
-
user purpose.

These attributes are recorded in configuration documentation
and base lined. Base lining an attribute forces formal configuration change control processes
to be effected in the event that these attributes are changed.




Configuration change control is a

set of processes and approval stages required to
change a configuration item's attributes and to re
-
baseline them.





Configuration status accounting is the ability to record and report on the configuration
baselines associated with each configuration it
em at any moment of time.




Configuration audits are broken into functional and physical configuration audits. They
occur either at delivery or at the moment of effecting the change. A functional configuration
audit ensures that functional and performanc
e attributes of a configuration


Item

are achieved, while a physical configuration audit ensures that a configuration item is
installed in accordance with the requirements of its detailed design documentation.

Configuration management is widely used by ma
ny military organizations to manage the technical
aspects of any complex systems, such as weapon systems, vehicles, and information systems. The
discipline combines the capability aspects that these systems provide an organization with the issues
of manage
ment of change to these systems over time.


Outside of the military, CM is equally appropriate to a wide range of fields and industry and
commercial sectors.


v. Computer ha
rdware configuration management


Computer hardware configuration management is the

process of creating and maintaining an
up
-
to
-
date record of all the components of the infrastructure, including related documentation. Its
purpose is to show what makes up the infrastructure and illustrate the physical locations and links
between each ite
m, which are known as configuration items.


Computer hardware configuration goes beyond the recording of computer hardware for the
purpose of asset management, although it can be used to maintain asset information. The extra value
provided is the rich sour
ce of support information that it provides to all interested parties. This
information is typically stored together in a configuration management database (CMDB).


The scope of configuration management is assumed to include, at a minimum, all configuration

items used in the provision of live, operational services.


Computer hardware configuration management provides direct control over information
technology (IT) assets and improves the ability of the service provider to deliver quality IT services in
an ec
onomical and effective manner. Configuration management should work closely with change
management.


All components of the IT infrastructure should be registered in the CMDB. The responsibilities
of configuration management with regard to the CMDB are:




Identification





Control





Status

accounting




Verification


The scope of configuration management is assumed to include:




Physical

client and server hardware products and versions




Operating

system software products and versions




Application

development software products and versions




Technical

architecture product sets and versions as they are defined and introduced




Live

documentation




networking products and versions




Live

application products and versions




Definitions

of pa
ckages of software releases




Definitions

of hardware base configurations




Configuration

item standards and definitions


The benefits of computer hardware configuration management are:




helps to minimize the impact of changes




provides accurate i
nformation on CIs




improves security by controlling the versions of CIs in use




facilitates adherence to legal obligations




helps in financial and expenditure planning



vi. Maintenance System


Configuration management is used to maintain an unde
rstanding of the status of complex
assets with a view to maintaining the highest level of serviceability for the lowest cost. Specifically, it
aims to ensure that operations are not disrupted due to the asset (or parts of the asset) overrunning
limits of p
lanned lifespan or below quality levels.


In the military, this type of activity is often classed as "mission readiness", and seeks to define
which assets are available and for which type of mission; a classic example is whether aircraft
onboard an aircraf
t carrier are equipped with bombs for ground support or missiles for defense.


a. Preventative Maintenance


Understanding the "as is" state of an asset and its major components is an essential
element in preventative maintenance as used in maintenance, rep
air, and overhaul and
enterprise asset management systems.

Complex assets such as aircraft, ships, industrial machinery etc. depend on many
different components being serviceable. This serviceability is often defined in terms of the
amount of usage the com
ponent has had since it was new, since fitted, since repaired, the
amount of use it has had over its life and several other limiting factors. Understanding how
near the end of their life each of these components is has been a major undertaking involving
la
bor intensive record keeping until recent developments in software.


b. Predictive Maintenance


Many types of component use electronic sensors to capture data which provides live
condition monitoring. This data is analyzed on board or at a remote location
by computer to
evaluate its current serviceability and increasingly its likely future state using algorithms which
predict potential future failures based on previous examples of failure through field experience
and modeling. This is the basis for "predict
ive maintenance".


Availability of accurate and timely data is essential in order for CM to provide
operational value and a lack of this can often be a limiting factor. Capturing and disseminating
the operating data to the various support organizations is
becoming an industry in itself.



The consumers of this data have grown more numerous and complex with the growth of
programs offered by original equipment manufacturers (OEMs). These are designed to offer
operators guaranteed availability and make the pic
ture more complex with the operator
managing the asset but the OEM taking on the liability to ensure its serviceability. In such a
situation, individual components within an asset may communicate directly to an analysis
center provided by the OEM or an ind
ependent analyst.


B
. Abstract syntax notation one
(ASN.1)


In telecommunications and computer networking, Abstract Syntax Notation One (ASN.1) is a
standard and flexible notation that describes data structures for representing, encoding, transmitting,
and

decoding data. It provides a set of formal rules for describing the structure of objects that are
independent of machine
-
specific encoding techniques and is a precise, formal notation that removes
ambiguities.


ASN.1 is a joint ISO and ITU
-
T standard, ori
ginally defined in 1984 as part of CCITT
X.409:1984. ASN.1 moved to its own standard, X.208, in 1988 due to wide applicability. The
substantially revised 1995 version is covered by the X.680 series.


An adapted subset of ASN.1, Structure of Management Info
rmation (SMI), is specified in
SNMP to define sets of related MIB objects; these sets are termed MIB modules.

ASN.1 is the acronym for Abstract Syntax Notation One, a language for describing structured
information; typically, information intended to be con
veyed across some interface or communication
medium. ASN.1 has been standardised internationally. It is widely used in the specification of
communication protocols.


Prior to ASN.1, information to be conveyed in communication protocols was typically speci
fied
by ascribing meanings to particular bits and bytes in protocol messages, much as programmers,
before the advent of high level languages, had to deal with the bits and bytes of storage layout.

With ASN.1, the protocol designer can view and describe th
e relevant information and its structure at
a high level and need not be unduly concerned with how it is represented while in transit .Compilers
can provide run
-
time code to convert an instance of user or protocol information to bits on the line.

ASN.1 co
mes into its own when the information being described is complex. This is because the
language allows arbitrarily complex structures to be built up in a uniform way from simpler
components, and ultimately from a few simple information types. ASN.1 is, in e
ffect, a data definition
language, allowing a designer to define the parameters in a protocol data unit without concern as to
how they are encoded for transmission. He merely states a need for an Integer followed by text,
followed by a floating point numbe
r, etc. They can be named and tagged such that two integers can
be differentiated as meaning "file size" or "record number".






i.
Abstract Syntax


To illustrate the concept of abstract syntax consider, for example, a meteorological station,
which report
s on the prevailing atmospheric conditions to a monitoring centre. At the monitoring
centre, the information is input to a weather forecasting program.


With abstract syntax the concern is solely with the information conveyed between the
application progr
am running in the computer at the weather station and the application program
running in the computer at the monitoring centre.


For different reasons, both programs need to "know" what information is included in a report.
The application in the weather s
tation needs to know so that it can create reports from the appropriate
sensor readings. The application in the centre needs to know because it must be able to analyse
reports and make weather forecasts.



This knowledge, which is essential for the program
s to be written, is that of the abstract syntax;
the set of all possible (distinct) reports. The designer of the abstract syntax also defines the meaning
of each possible report, and this allows the developers of the programs at each end to implement the
a
ppropriate actions.


It would be very unusual for a designer to define the abstract syntax of a message type by explicitly
listing all possible messages. This is because any realistic message type will allow an infinite number
of distinct possibilities, i
nteger as a simple example of this. Instead, the abstract syntax will generally
be structured. The set of possible messages and their meanings can then be inferred from knowledge
of the possibilities for each of the components of the structure.



ii. Tran
sfer Syntax


Earlier standards such as ASCII and EBCDIC specified both the abstract syntax (the letter A)
and the encoding, or transfer syntax, (hexadecimal 21 or 41). ASN.1 separates these two concepts,
such that at connect time you can chose to encode th
e data. You can
choose

an encoding which is
efficient on the line or reliable or easy to decode. The first defined for ASN.1 was the Basic Encoding
Rules (BER)


The BER allow the automatic derivation of a transfer syntax for every abstract syntax defined
using ASN.1. Transfer syntaxes produced by application of the BER can be used over any
communications medium which allows the transfer of strings of octets. The encoding rules approach
to transfer syntax definition results in considerable saving of effort
for application protocol designers.
This is particularly pronounced where the messages involved are complex. Perhaps even more
important than the savings to the designers are the potential savings to implementors, through the
ability to develop general
-
pur
pose run
-
time support. Thus, for example, encoding and decoding
subroutines can be developed once and then used in a wide range of applications.


A set of encoding rule can only be developed in the context of an agreed set of concepts such
as those provid
ed by ASN.1. For example, the concepts required in designing the weather report
abstract syntax included the ability to create a message from a sequence of fields, and the concepts
of integer and whole number (restricted to certain ranges).


As the struct
ure of ASN.1 is hierarchical, the basic encoding rules follow this structure. They
operate on a Tag, Length Value (TLV) scheme. This is actually known in ASN.1 as Identifier, Length,
and Contents
. (ILC).
the

structure is therefore recursive such that the c
ontents can be a series of
ILCs. This bottoms out with genuine contents such as a text string or an integer.


iii. Basics of ASN.1


a. Types and
Values


The fundamental concepts of ASN.1 are the inter
-
related notions of type and value. A type is a
(non
-
emp
ty) set of values, and represents a potential for conveying information. Only values are
actually conveyed, but their type governs the domain of possibilities. It is by selecting one particular
value of the type, rather than the others, that the sender of
a message conveys information. The type
may have only a few values, and therefore be capable of conveying only a few distinctions. An
example of such a type is Boolean, which has only the two values true and false, with nothing in
between. On the other han
d, some types, such as Integer and Real, have an infinite number of values
and can thus express arbitrarily fine distinctions.


An abstract syntax can be defined as a type, normally a structured type. Its values are
precisely the set of valid messages und
er that abstract syntax. Should the messages be structured,
as they commonly are, into fields, then the various fields themselves are defined as types. The values
of such a type, in turn, are the set of permitted contents of that field.


A type is a subty
pe of another, its parent (type), if its values are a subset of those of the
parent. Thus, for example, a type "whole number"" whose values are the non
-
negative integers, could
be defined as a subtype of Integer. (ASN.1 does not provide such a type, but on
e could be defined by
the user if needed). Another example would be to define the YEAR as the twelve months and the
subtype SPRING as March, April and May.


A type may be simple or structured. The simple types are the basic building blocks of ASN.1,
and i
nclude types like Boolean and integer. A simple type will generally be used to describe a single
aspect of something. A structured type, on the other hand, is defined in terms of other types
-

its
components
-

and its values are made up of values of the co
mponent types. Each of these
components may itself be simple or structured, and this nesting can proceed to an arbitrary depth, to
suite the needs of the application. All structured types are ultimately defined in terms of simple types.


ASN.1 makes avail
able to the abstract syntax designer a number of simple types, as well as
techniques for defining structured types and subtypes. The designer employs these types by using
the type notation which ASN.1 provides for each such type. ASN.1 also provides value
notation which
allows arbitrary values of these types to be written down.


Any type
(or

indeed value) which can be written down can be given a name by which it can be
referenced. This allows users to define and name types and values that are useful within

some
enterprise or sphere of interest. These defined types (or defined values) can than be made available
for use by others. The defined types within some enterprise can be seen as supplementing the built
-
in
types
-

those provided directly by ASN.1. ASN.1

also provides a small number of useful types, types
which have been defined in terms of the built
-
in types but which are potentially of use across a wide
range of enterprises.


A type is defined by means of a type assignment, and a value is defined by a
value
assignment. A type assignment has three syntactic components: the type reference (the name being
allocated to the new type); the symbol "
:=
", which can be read as "is defined as"; and the appropriate
type notation.


b. ASN.1 versus other data structu
re definition schemes:


As commonly used for defining messages for communication protocols, ASN.1, with its
associated encoding rules, results in a binary encoding.


Other communication protocols, such as Internet protocols HTTP and SMTP, define messages
u
sing text tags and values, sometimes based on the Augmented Backus
-
Naur form (ABNF) notation.


There has been much debate over the two approaches, and both have their merits; the ASN.1
approach is believed to be more efficient, and with Packed Encoding Ru
les, certainly provides a more
compact encoding. The textual approach is claimed to be easier to implement and easier to debug,
as one can simply read an encoded message. In the case of the Megaco protocol, consensus
between the two points of view was not
reached and so two encodings, one based on ASN.1 and one
on ABNF, were defined.


The ASN.1 XML Encoding Rules (XER) attempts to bridge the gap by providing a textual
encoding of data structures defined using ASN.1 notation. Generic String Encoding Rules we
re also
defined for the sole purpose of presenting and inputting data to/from a user.


c. Using ASN.1 in practice:


One may use an ASN compiler which takes as input an ASN.1 specification and generates
computer code (for example in the C programming langua
ge) for an equivalent representation of the
data structures. This computer code, together with supplied run
-
time libraries, can then convert
encoded data structures to and from the computer language representation. Alternatively, one can
manually write enc
oding and decoding routines.


d. Database Functions:

l components connect to the Configuration database, including the MPF Client, Provisioning
Engine, and the Audit and Recovery Service. When a new MPF component is installed on a server,
the Configuration

database is updated to reflect that a new component is available for service.
Whenever you install a Transaction log database on a server running Microsoft SQL Server, an
associated database for the MPF Audit and Recovery Service is also installed. Every
Transaction log
must have an associated MPF Audit and Recovery Service. Transaction logs store transaction data
and state. Provisioning engines load
-
balance across Transaction logs using a round
-
robin algorithm.


In addition, all requests submitted to MPF

are assigned a Client Transaction ID attribute under
the Client Context property in the Transaction log. If you need to verify whether a transaction
succeeded or not, you can use transaction IDs to obtain the status of any transaction from the
Transaction

log database.


In addition, all configuration data is stored by the Configuration database in a dual
-
redundant
configuration (clustered on MPSSQL02 and MPSSQL03). Additional factors that mitigate the single
point of failure for either cluster node includ
e the following:




All MPF components, including the MPF Client, Provisioning Engine, and Audit and
Recovery Service, store their associated data in the registry or in an in
-
memory data store.



All transactions on which a Provisioning Engine is current
ly working are stored in
memory. After each stage of a transaction is performed, the engine updates its local in
-
memory data
store and then updates the appropriate Transaction log.





CHAPTER III

SIMPLE NETWORK MANAGEMENT PROTOCOL (SNMP)


Simple Network
Management Protocol (SNMP) is used in network management systems to
monitor network
-
attached devices for conditions that warrant administrative attention. SNMP is a
component of the Internet Protocol Suite as defined by the Internet Engineering Task Force
(IETF). It
consists of a set of standards for network management, including an application layer protocol, a
database schema, and a set of data objects.


A. Overview and Basic Concepts


In typical SNMP usage, there are a number of systems to be managed, a
nd one or more
systems managing them. A software component called an agent runs on each managed system and
reports information via SNMP to the managing systems.


Essentially, SNMP agents expose management data on the managed systems as variables
(such as "
free memory", "system name", "number of running processes", "default route"). But the
protocol also permits active management tasks, such as modifying and applying a new configuration.
The managing system can retrieve the information through the GET, GETNE
XT and GETBULK
protocol operations or the agent will send data without being asked using TRAP or INFORM protocol
operations. Management systems can also send configuration updates or controlling requests
through the SET protocol operation to actively manag
e a system. Configuration and control
operations are used only when changes are needed to the network infrastructure. The monitoring
operations are usually performed on a regular basis.



The variables accessible via SNMP are organized in hierarchies. Thes
e hierarchies, and other
metadata (such as type and description of the variable), are described by Management Information
Bases (MIBs).


i. SNMP Basic Components


An SNMP
-
managed network consists of three key components:


1.

Managed devices


2.

Agents


3
.

Network
-
management stations (NMSs)



A managed device is a network node that contains an SNMP agent and that resides on
a managed network. Managed devices collect and store management information and make this
information available to NMSs using SNMP. Managed devices, sometimes called netwo
rk elements,
can be any type of device including, but not limited to, routers, access servers, switches, bridges,
hubs, IP telephones, computer hosts, and printers.



An agent is a network
-
management software module that resides in a managed device.
An ag
ent has local knowledge of management information and translates that information into a form
compatible with SNMP.



A

network management system (NMS) executes applications that monitor and control
managed devices. NMSs provide the bulk of the processing

and memory resources required for
network management. One or more NMSs may exist on any managed network.


ii
. The Internet Management Model


SNMP is part of the Internet network management architecture. This architecture is based on
the interaction of man
y entities, as described in the following section.


As specified in Internet RFCs and other documents, a network management system comprises:




Network elements
--

Sometimes called managed devices, network elements are hardware
devices such as computers,
routers, and terminal servers that are connected to networks.





Agents
--

Agents are software modules that reside in network elements. They collect and store
management information such as the number of error packets received by a network element.




Ma
naged object
--

A managed object is a characteristic of something that can be managed.
For example, a list of currently active TCP circuits in a particular host computer is a managed object.
Managed objects differ from variables, which are particular objec
t instances. Using our example, an
object instance is a single active TCP circuit in a particular host computer. Managed objects can be
scalar (defining a single object instance) or tabular (defining multiple, related instances).




Management information

base (MIB)
--

A MIB is a collection of managed objects residing in a
virtual information store. Collections of related managed objects are defined in specific MIB modules.




Syntax notation
--

A syntax notation is a language used to describe
MIBs

manage
d objects in a
machine
-
independent format. Consistent use of a syntax notation allows different types of computers
to share information. Internet management systems use a subset of the International Organization for
Standardization's (ISO's) Open System In
terconnection (OSI) Abstract Syntax Notation (ASN.1) to
define both the packets exchanged by the management protocol and the objects that are to be
managed.




Structure of Management Information (SMI)
--

The SMI defines the rules for describing
managemen
t information. The SMI is defined using ASN.1.




Network management stations (NMSs)
--

Sometimes called consoles, these devices execute
management applications that monitor and control network elements. Physically, NMSs are usually
engineering workstatio
n
-
caliber computers with fast CPUs,
mega pixel

color displays, substantial
memory, and abundant disk space. At least one NMS must be present in each managed
environment.





Parties
--

Newly defined in SNMPv2, a party is a logical SNMPv2 entity that can in
itiate or
receive SNMPv2 communication. Each SNMPv2 party comprises a single, unique party identity, a
logical network location, a single authentication protocol, and a single privacy protocol. SNMPv2
messages are communicated between two parties.
A

SNMPv2

entity can define multiple parties, each
with different parameters. For example, different parties can use different authentication and/or
privacy protocols.




Management protocol
--

A management protocol is used to convey management information
between

agents and NMSs. SNMP is the Internet community's de facto standard management
protocol.


iii. Mana
gement Information Bases (MIBs)


SNMP itself does not define which information (which variables) a managed system should
offer. Rather, SNMP uses an extens
ible design, where the available information is defined by
management information bases (MIBs). MIBs describe the structure of the management data of a
device subsystem; they use a hierarchical namespace containing object identifiers (OID). Each OID
identi
fies a variable that can be read or set via SNMP. MIBs use the notation defined by ASN.1.


The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are
assigned by different organizations. The top
-
level MIB OIDs belong to diffe
rent standards
organizations, while lower
-
level object IDs are allocated by associated organizations. This model
permits management across all layers of the OSI reference model, extending into applications such
as databases, email, and the Java reference m
odel, as MIBs can be defined for all such area
-
specific
information and operations.


A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number
of specific characteristics of a managed device. Managed objects are made up of
one or more object
instances (identified by their OIDs), which are essentially variables.


Two types of managed objects exist:


a
.

Scalar objects define a single object instance.


b

Tabular objects define multiple related object instances that are grouped

in MIB tables.


An example of a managed object is
at Input
, which is a scalar object that contains a single
object instance, the integer value that indicates the total number of input AppleTalk packets on a
router interface. An object identifier (or obj
ect ID or OID) uniquely identifies a managed object in the
MIB hierarchy.


iv. Abstr
act Syntax Notation One (ASN.1)


In telecommunications and computer networking, Abstract Syntax Notation One (ASN.1) is a
standard and flexible notation that describes data

structures for representing, encoding, transmitting,
and decoding data. It provides a set of formal rules for describing the structure of objects that are
independent of machine
-
specific encoding techniques and is a precise, formal notation that removes
a
mbiguities.


ASN.1 is a joint ISO and ITU
-
T standard, originally defined in 1984 as part of CCITT
X.409:1984. ASN.1 moved to its own standard, X.208, in 1988 due to wide applicability. The
substantially revised 1995 version is covered by the X.680 series.


An adapted subset of ASN.1, Structure of Management Information (SMI), is specified in
SNMP to define sets of related MIB objects; these sets are termed MIB modules.





B. Protocol specification



The network management protocol is an application protoc
ol by which the variables of an
agent's MIB may be inspected or altered. Communication among protocol entities is accomplished by
the exchange of messages, each of which is entirely and independently represented within a single
UDP datagram using the basi
c encoding rules of ASN.1 a message consists of a version identifier, an
SNMP community name, and a protocol data unit (PDU). A protocol entity receives messages at UDP
port 161 on the host with which it is associated for all messages except for those whic
h report traps
(i.e., all messages except those which contain the Trap
-
PDU).

Messages which report traps should be received on UDP port 162 for further processing. An
implementation of this protocol need not accept messages whose length exceeds 484 octets
.
However, it is recommended that implementations support larger datagram’s whenever feasible.



i. Elements of Procedure




This section describes the actions of a protocol entity implementing the SNMP. Note,
however, that it is not intended to const
rain the internal architecture of any conformant
implementation.




In the case of the UDP, a transport address consists of an IP address along with a UDP
port. Other transport services may be used to support the SNMP. In these cases, the definition of a

transport address should be made accordingly.




The top
-
level actions of a protocol entity which generates a message are as follows:


a.

It

first constructs the appropriate PDU, e.g., the Get Request
-
PDU, as an ASN.1 object.


b.

It

then passes this ASN.
1 object along with a community name its source transport address
and the destination transport address, to the service which implements the desired authentication
scheme. This authentication service returns another ASN.1 object.


c.

The

protocol entity t
hen constructs an ASN.1 Message object, using the community name
and the resulting ASN.1 object.


d.

This

new ASN.1 object is then serialized, using the basic encoding rules of ASN.1, and then
sent using a transport service to the peer protocol entity.




Similarly, the top
-
level actions of a protocol entity which receives a message are as follows:



a.

It

performs a rudimentary parse of the incoming datagram to build an ASN.1 object
corresponding to an ASN.1 Message object. If the parse fails, it discards

the datagram and performs
no further actions.



b.

It

then verifies the version number of the SNMP message. If there is a mismatch, it discards
the datagram and performs no further actions.



c.

The

protocol entity then passes the community name and user
data found in the ASN.1
Message object, along with the datagram's source and destination transport addresses to the service
which implements the desired authentication scheme. This entity returns another
ASN.1 object
, or
signals an authentication failure.

In the latter case, the protocol entity notes
this failure
, (possibly)
generates a trap, and discards the datagram and performs no further actions.


d.

The

protocol entity then performs a rudimentary parse on the ASN.1 object returned from
the authentica
tion service to build an ASN.1 object corresponding
to

ASN.1 PDUs

Object
. If the
parse fails
, it discards the datagram and performs no further actions. Otherwise, using
the named SNMP community, the appropriate profile is selected, and the PDU is process
ed
accordingly. If, as a result of this processing, a message is returned then the source transport
address that the response message is sent from shall be identical to the destination transport address
that the original request message was sent to.


ii.
Common Constructs




Before introducing the six PDU types of the protocol, it is appropriate to consider.
Request IDs are used to distinguish among outstanding requests. By use of the Request ID, an
SNMP application entity can correlate incoming response
s with outstanding requests. In cases
where an unreliable datagram service is being used, the Request ID also provides a simple means
of identifying messages duplicated by the network.





A non
-
zero instance of Error Status is used to indicate that an

exception occurred
while
processing

a request. In these cases, Error Index may provide additional information by indicating
which variable in a list caused the exception.




The term variable refers to an instance of a managed object. A variable binding
, or
VarBind, refers to the pairing of the name of a variable to the variable's value. A VarBindList is a
simple list of variable names and corresponding values. Some PDUs are concerned only with the
name of a variable and not its value (e.g., the Get Re
quest
-
PDU). In this case, the value portion of
the binding is ignored by the protocol entity. However, the value portion must still have valid ASN.1
syntax and encoding. It is recommended that the ASN.1 value NULL be used for the value portion of
such b
indings.




The implementations of the SNMP support the five PDUs: Get Request
-
PDU,
GetNextRequest
-
PDU, Get Response
-
PDU, Set Request
-
PDU, and Trap
-
PDU.


a. The Get Request
-
PDU:



The Get Request
-
PDU is generated by a protocol entity only at the request o
f its
SNMP
application

entity.



Upon receipt of the Get Request
-
PDU, the receiving protocol entity responds according to any
applicable rule in the list below:



(1) If, for any object named in the variable
-
bindings field, the object's name does n
ot exactly
match the name of some object available for get operations in the relevant MIB view, then the
receiving entity sends to the originator of the received message the Get Response
-
PDU of identical
form, except that the value of the error
-
sta
tus field is no Such Name, and the value of the error
-
index
field is the index of said object name compo
nent in the received

message.



(2) If, for any object named in the variable
-
bindings field, the object is an aggregate type (as
defined in th
e SMI), then the receiving entity sends to the originator of the received message the Get
Response
-
PDU of identical form, except that the value of the error
-
status field is no Such Name, and
the value of the error
-
index field is the index of said object na
me component in the received message.





(3) If the size of the Get Response
-
PDU generated as described below would exceed a local
limitation, then the receiving entity sends to the originator of the received message the Get
Response
-
PDU of identi
cal form, except that the value of the error
-
status field is too Big, and the
value of the error
-
index field is zero.



(4) If, for any object named in the variable
-
bindings field, the value of the object cannot be
retrieved for reasons not covered

by any of the foregoing rules, then the receiving entity sends to the
originator of the received message the Get Response
-
PDU of identical form, except that the value of
the error
-
status field is genErr and the value of the error
-
index field is the index
of said object name
component in the received message.



If none of the foregoing rules apply, then the receiving protocol entity sends to the originator of
the received message the Get Response
-
PDU such that, for each object named in the variable
-
bindings

field of the received message, the corresponding component of the Get Response
-
PDU
represents the name and value of that variable. The value of the error
-

status field of the Get
Response
-
PDU is no Error and the value of the error
-
index field is zero. T
he value of the request
-
id
field of the Get Response
-
PDU is that of the received message.



b. The Get Next Request
-
PDU



The form of the GetNextRequest
-
PDU is identical to that of the
Get Request
-
PDU except for
the indication of the PDU type.



The Get

N
ext

Request
-
PDU is generated by a protocol entity only at the request of its SNMP
application entity.




Upon receipt of the GetNextRequest
-
PDU, the receiving protocol entity responds according to
any applicable rule in the list below:





(1) If, for an
y object name in the variable
-
bindings field, that name does not lexicographically
precede the name of some object available for get operations in the relevant

MIB view, then the receiving entity sends to the originator of the received message the Get
Resp
onse
-
PDU of identical form, except that the value of the error
-
status field is no Such Name, and
the value of the error
-
index field is the index of said object name component in the received message.






(2) If the size of the Get Response
-
PDU gen
erated as described below would exceed a local
limitation, then the receiving entity sends to the originator of the received message
the Get

Response
-
PDU of identical form, except that the value of the error
-
status field is too
big
, and the
value of the er
ror
-
index field is zero.





(3) If, for any object named in the variable
-
bindings field, the value of the lexicographical
successor to the named object cannot be retrieved for reasons not covered by any of the foregoing
rules, then the receiving e
ntity sends to the originator of the received message the Get
Response
-
PDU of identical form, except that the value of the error
-
status field is genErr and the value
of the error
-
index field is the index of said object name component in the rec
eived message.


If none of the foregoing rules apply, then the receiving protocol entity sends to the originator of
the received message the Get Response
-
PDU such that, for each name in the variable
-
bindings field
of the received message, the correspondin
g component of the Get Response
-
PDU represents the
name and value of that object whose name is, in the lexicographical ordering of the names of all
objects available for get operations in the relevant MIB view, together with the value of the name field
of
the given component, the immediate successor to that value. The value of the error
-
status field of
the Get Response
-
PDU is no Error and the value of the error index field is

Zero. The value of the
request
-
id field of the Get Response
-
PDU is that of the r
eceived message.


iii. Example of Table Traversal


One important use of the GetNextRequest
-
PDU is the traversal of conceptual tables of
information within the MIB. The semantics of this type of SNMP message, together with the protocol
-
specific mechanisms f
or identifying individual instances of object types in the MIB, affords access to
related objects in the MIB as if they enjoyed a tabular organization.



By the SNMP exchange sketched below, an SNMP application entity might extract the
destination address
and next hop gateway for each entry in the routing table of a particular network
element. Suppose that this routing table has three entries:



As there are no further entries in the table, the SNMP agent returns those objects that are next
in the lexicogra
phical ordering of the known object names. This response signals the end of the
routing table to the management station.


a.

The Get Response
-
PDU


The form of the Get Response
-
PDU is identical to that of the Get Request
-
PDU except for the
indication of th
e PDU type.


The Get Response
-
PDU is generated by a protocol entity only upon receipt of the Get
Request
-
PDU, GetNextRequest
-
PDU, or Set Request
-
PDU, as described elsewhere in this
document.



Upon receipt of the Get Response
-
PDU, the receiving protocol e
ntity presents its contents to
its SNMP application entity.


b.

The Set Request
-
PDU


The form of the
Set Request
-
PDU is identical to that of the
Get Request
-
PDU except for the
indication of the PDU type. The
Set Request
-
PDU is generated by a protocol enti
ty only at the
request of its SNMP application entity.


Upon receipt of the
Set Request
-
PDU, the receiving entity responds according to any
applicable rule in the list below:






(1) If, for any object named in the variable
-
bindings field, the objec
t is not available for set
operations in the relevant MIB view, then the receiving entity sends to the originator of the received
message the
Get Response
-
PDU of identical form, except that the value of the error
-
status field is
noSuchName, and the value o
f the error
-
index field is the index of said object name component in the
received message.





(2) If, for any object named in the variable
-
bindings field, the contents of the value field does
not, according to the ASN.1 language, manifest a type,
length, and value that is consistent with that
required for the variable, then the receiving entity sends to the originator of the received
message the
Get Response
-
PDU of identical form, except that the value of the error
-
status field is
bad V
alue, and the value of the error
-
index field is the index of said object name in the received
message.





(3) If the size of the Get Response type message generated as described below would
exceed a local limitation, then the receiving entity send
s to the originator of the received
message the Get Response
-
PDU of identical form, except that the value of the error
-
status field is too
big
, and the value of the error
-
index field is zero.





(4)

If, for any object named in the variabl
e
-
bindings field, the value of the named object
cannot be altered for reasons not covered by any of the foregoing rules,
then the

receiving entity
sends to the originator of the received message the
Get Response
-
PDU of identical form, except
that t
he value of the error
-
status field is genErr and the value of the error
-
index field is the index of
said object name component in the received message.



If none of the foregoing rules apply, then for each object named in he variable
-
bindings field of
the
received message, the corresponding value is assigned to the variable. Each variable
assignment specified by the
Set Request
-
PDU should be effected as if simultaneously set with
respect to all other assignments specified in the same message.




The receiv
ing entity then sends to the originator of the received message the Get Response
-
PDU of identical form except that the value of the error
-
status field of the generated message is no
Error and the value of the error
-
index field is zero.



The Trap
-
PDU is ge
nerated by a protocol entity only at the request of the SNMP application
entity. The means by which an SNMP application entity selects the destination addresses of the
SNMP application entities is implementation
-
specific.

Upon receipt of the Trap
-
PDU, the

receiving protocol entity presents its contents to its SNMP
application entity. The significance of the variable
-
bindings component of the Trap
-
PDU is
implementation
-
specific.


iv. Interpretations of the valu
e of the generic
-
trap field are


The cold Sta
rt Trap:


A cold
Start

trap

signifies that the sending protocol entity is reinitializing itself such that the
agent's configuration or the protocol entity implementation may be altered.


The warm Start Trap:



A warms tart
trap

signifies that the sending
protocol entity is reinitializing itself such that neither
the agent configuration nor the protocol entity implementation is altered.


The link Down Trap:


A link
Down
trap

signifies that the sending protocol entity recognizes a failure in one of the
commu
nication links represented in the agent's configuration.


The Trap
-
PDU of type link Down contains as the first element of its variable
-
bindings, the
name and value of the Index instance for the affected interface.






The linkup Trap
:



A linkup
trap

sign
ifies that the sending protocol entity recognizes that one of the
communication links represented in the agent's configuration has come up.


The Trap
-
PDU of type linkup contains as the first element of its variable
-
bindings, the name
and value of the Index

instance for the affected interface.


The authentication Failure Trap:


An authentication Failure
trap

signifies that the sending protocol entity is the addressee of a
protocol message that is not properly authenticated. While implementations of the SNMP

must be
capable of generating this trap, they must also be capable of suppressing the emission of such traps
via an implementation
-
specific mechanism.


The egpNeighborLoss Trap:


An egpNeighborLoss

trap signifies that an EGP neighbor for whom the sending
protocol entity
was an EGP peer has been marked down and the peer relationship no longer obtains.


The Trap
-
PDU of type egpNeighborLoss contains as the first element of its variable
-
bindings,
the name and value of the egpNeighAddr instance for the affected

neighbor.


The enterprise Specific Trap:


A enterprise Specific
trap

signifies that the sending
protocol.
Entity

recognizes that some
enterprise
-
specific event has occurred. The specific
-
trap field identifies the particular trap which
occurred.



























CHAPTER IV

SIMPLE NETWORK MANA
GEMENT PROTOCOL (SNMP): SNMP V1


A. Structure of management information


In computing, the Structure of Management Information (SMI), an adapted subset of ASN.1,
operates in Simple Network Management Protocol (
SNMP) to define sets ("modules") of related
managed objects in a Management information base (MIB).


SMI subdivides into three parts: module definitions, object definitions, and notification definitions.




Module definitions are used when describing infor
mation modules. An ASN .1 macro,
MODULE
-
IDENTITY, is used to concisely convey the semantics of an information module.





Object definitions describe managed objects. An ASN.1 macro, OBJECT
-
TYPE, is used to
concisely convey the syntax and semantics of a ma
naged object.




Notification definitions (aka "traps") are used when describing unsolicited transmissions of
management information. An ASN.1 macro, NOTIFICATION