An Element management system (EMS) consists of systems and applications that are concerned with

managing network elements (NE) on the network element management layer (NEL) of the
Telecommunication Management Network model.

As recommended by ITU-T, the Element Management System's key functionality is divided into five
key areas - Fault, Configuration, Accounting, Performance and Security (FCAPS). Portions of each of
the FCAPS functionality fit into the TMN models. On the northbound the EMS interfaces to Network
Management Systems and or Service Management Systems depending on the deployment scenario.
Southbound the EMS talks to the devices.

An element management system (EMS) manages one or more of a specific type of telecommunications
network element (NE). Typically, the EMS manages the functions and capabilities within each NE but
does not manage the traffic between different NEs in the network. To support management of the
traffic between itself and other NEs, the EMS communicates upward to higher-level network
management systems (NMS) as described in the telecommunications management network (TMN)
layered model. The EMS provides the foundation to implement TMN–layered operations support
system (OSS) architectures that enable service providers to meet customer needs for rapid deployment
of new services, as well as meeting stringent quality of service (QoS) requirements. The
TeleManagement Forum common object request broker architecture (CORBA) EMS–to–NMS
interface heralds a new era in OSS interoperability by making the TMN architecture a practical reality.

[edit] Below are the various types elements in various

markets which can be managed through the ems
interfaces.
Cable Telephony Media Gateway
Media Gateway
Soft Switch
Video Compression Technology Provider
Wireless Broadband Provider and many more
check the below link to know more
[1]

[edit] Network Management System Vs Element

Management System
NMS provides an integrated system for sharing device information across management applications,
automation of device management tasks, visibility into the health and capability of the network, and
identification and localization of network trouble. By using common centralized systems and network-
inventory knowledge, an NMS delivers a unique platform of cross-functional management capabilities
that reduces network administration overhead.

EMS is a carrier class management solution. It is capable of scaling as the network grows, maintaining
high performance levels as the number of network events increase, and providing simplified integration
with third-party systems. It meets the service providers' expectations for integrated operational support
systems (OSS

Network architecture is the design of a communications network. It is a framework for the

specification of a network's physical components and their functional organization and configuration,
its operational principles and procedures, as well as data formats used in its operation.

In telecommunication, the specification of a network architecture may also include a detailed

description of products and services delivered via a communications network, as well as detailed rate
and billing structures under which services are compensated.
The network architecture of the Internet is predominantly expressed by its use of the Internet Protocol
Suite, rather than a specific model for interconnecting networks or nodes in the network, or the usage
of specific types of hardware links.

[edit] Distributed computing

In distinct usage in distributed computing, the term network architecture often describes the structure
and classification of a distributed application architecture, as the participating nodes in a distributed
application are often referred to as a network. For example, the applications architecture of the public
switched telephone network (PSTN) has been termed the Advanced Intelligent Network. There are any
number of specific classifications but all lie on a continuum between the dumb network (e.g., Internet)
and the intelligent computer network (e.g., the telephone network). Other networks contain various
elements of these two classical types to make them suitable for various types of applications. Recently
the context aware network, which is a synthesis of the two, has gained much interest with its ability to
combine the best elements of both.

A popular example of such usage of the term in distributed applications, is the organization of nodes in
peer-to-peer (P2P) services and networks. P2P networks usually implement overlay networks running
over an underlying physical or logical network. These overlay network may implement certain
organizational structures of the nodes according to several distinct models, the network architecture of
the system.

Network architecture is a broad plan that specifies everything necessary for two application programs
on different networks on an Internet to be able to work together effectively

What is an Element Management System?

EMS consists of systems and applications that are concerned with managing network
elements (NE) on the network element management layer (NEL) of the Telecommunication
Management Network model (TMN) shown below.

As recommended by ITU-T, the Element Management System's key functionality is divided

into five key areas - Fault, Configuration, Accounting, Performance and Security (FCAPS).
Portions of each of the FCAPS functionality fit into the TMN models. On the northbound the
EMS interfaces to Network Management Systems and or Service Management Systems
depending on the deployment scenario. Southbound the EMS talks to the devices

What will be the typical feature set for an Element Management System?
The typical set of features depends on the equipment and the market it caters to.
The following grid
exhibits a subset of functionality prescribed by ITU-T and Telcordia for the key
functional areas.

What are the architectural challenges to be kept in mind while building an EMS?
And
Suggest a suitable architecture for building an Element Management System?
In a real world situation, EV's have to cater to different market segments ranging from small
Service
Providers to large ILECs and the EMS requirements of each of these segments are different.
A
simple EMS developed for a small Service Provider may not meet the scalability needs of an
ILEC, while a full-featured highly available and scalable EMS that is suitable for an ILEC
might be overkill for a smaller Service Provider. Finally developing a new EMS for each
segment may not be a practical or a profitable option.
When confronted with the above problem, the EV's attempt to solve it by developing a basic
EMS initially and hoping that it could be scaled up to meet the demanding requirements of an
ILEC. This strategy definitely makes sense if the EMS is architected properly. From our
experience we' ve noticed that in many instances it is not the case because the initial
development of the EMS is done at the last moment and in a rushed manner. Therefore the
EV's face an uphill task of scaling up the EMS. The key issue in most of these situations is
that the EMS was not initially architected to meet the requirements of large Service Providers.
It is therefore essential to choose the correct architecture for the EMS so that it could be
implemented to meet the requirements of different segments effectively.
There are a variety of architectures that could be used to build an EMS. Based on our
experience, we recommend that the EMS be developed using JEE architecture. Since JEE
based applications could be extended to n-tiers (if required) to meet the scalability needs of
the customer, we believe it is a very good fit for EMS development.
The figure below shows a sample application based on JEE architecture (for more indepth
information on JEE architecture please visit http://java.sun.com/j2ee/appmodel.html) that has
five tiers. Tier 1 is the client tier. Tier 2 is the web tier (WT). Tier 3 is the presentation tier
(PT). Tier 4 is the application tier (OT) and Tier 5 is the data tier (represented in the figure as
the database.

What are the various advantages offered by JEE Architecture for an EMS
Development?
JEE architecture offers the following advantages for the development of an EMS:
• When there is clear separation of user-interface-control and data presentation from
application- logic, it enables more clients to have access to a wide variety of server
applications. This allows quicker development of EMS application through the reuse of pre-
built components and a shorter test phase, because most often the server-components have
already been tested.
• Re-definition of the storage strategy won't influence the clients. In well designed systems,
the client still accesses data over a stable and well designed interface which encapsulates all
the storage details. Even radical changes such as switching form an RDBMS to an OODBS,
won't influence the client.
• Business-objects can place applications-logic or "services" on the net.
• As a rule servers are "trusted" systems, data protection and security is simpler to obtain.
Therefore it makes sense to run critical business processes that work with security sensitive
data, on the server.
• The Database & Server tiers can be deployed in a cluster easily enhancing the scalability
and
availability (a key requirement if the EMS needs to be deployed in large networks). Clusters
also allow dynamic load balancing - if bottlenecks in terms of performance occur, the server
process can be moved to other servers at runtime.
• Change management: of course it's easy - and faster - to exchange a component on the
server than to furnish numerous PCs with new program versions.
Also by the judicious use of open source technologies (where possible), the EV can reduce
the development, maintenance and deployment cost of the EMS significantly while at the
same time enjoying the above-mentioned benefits. Finally since the EMS is based on a well-
defined and standardized architecture, future development and enhancement of the EMS will
be easy and cost effective.

What are the challenges in developing an EMS for Wireless Networks?

Wireless Networks provide a different set of challenges to an EMS when compared
to typical wired
networks. The EMS for a wireless network should be able to handle the challenges
discussed below.
To begin with, management of a wireless network does not involve in just managing individual
Base Stations/Access Points/CPEs in the network. It is equally important to discover and
manage the links between the devices and be able to provide a clear picture of the topology
of the network. Tracking the availability of the Access Points is also essential in being able to
have a backup plan - a must for managing wireless networks.
In wireless networks there could be different types of links such as active, standby/backup
etc., It is important for the EMS to distinguish the different types of links so that they can be
portrayed accurately which will be of value to the network administrator.
Another key challenge for the EMS is to track and manage the clients connected to the
wireless access points in a network. Client connectivity maps are useful for network planning
for a service provider. Since clients attached to an Access Point could be extremely dynamic,
that is a client could connect to the network from one Access Point and later on connect to the
network from another Access Point, an EMS needs to have sufficient intelligence to track and
manage the clients efficiently so that it can derive a meaningful usage pattern.
Since the throughput depends on the signal strength and interference from other Access
Points, Clients get different throughput at different locations. EMS should be able to identify
such problematic areas so that the network administrator can try to resolve them.
The ability of the EMS to depict the available throughput for each client pictorially in the
topology diagram will deliver a lot of value for the network operators as it helps them plan for
the throughput requirements. Throughput of a link can be depicted in a variety of ways such
as using a color-coding scheme or varying the thickness of the link.
Only few wireless networks support full-duplex connectivity. Therefore it will be necessary for
the EMS to provide the link health in both directions (upstream and downstream) so that it is
easy for the network administrator to monitor the link.

Since many wireless networks allow dynamic addition of new Access Points, the EMS should
automatically discover new Access Points and be able to provision them as well (using a a
pre- defined policy). This requirement is a must for any EMS that is supporting a dynamic
network.

What are the challenges to be kept in mind while developing an EMS to manage a
device
using TL1 protocol?
Managing a device via TL1 is quite different when compared to SNMP and it offers its own
benefits as well as challenges.
• In simple terms, TL1 messages are text messages that have a structure (with some
standard delimiters) that could be easily understood by humans. It gives the equipment
vendors the flexibility to define their own command-sets provided it follows basic TL1
guidelines. This flexibility makes decoding of TL1 messages quite cumbersome since it
involves parsing of a custom command set that has been defined for each device. The EMS
therefore should have efficient text processing algorithms to ensure that the messages are
processed quickly and efficiently. This parsing ability could limit the processing capabilities
of the EMS which in turn directly affects the scalability of the EMS solution.
• TL1 protocol works over TCP which mandates a permanent socket connection to the device
to receive autonomous messages from the device. (In SNMP, Traps will be sent to port 162 in
the manager so it is not necessary to maintain the connection to receive Traps).
• The key issue in maintaining the TCP connection for all the devices is the management of
these sessions. This involves management of all TCP socket connections and the associated
threads which are required to ensure effective processing of the TL1 messages (that are
received via these sockets) without dropping any of them. Since each TCP connection
requires a thread and even though theoretically there is no strict limit on the number of
threads that could be supported by an operating system, each thread created will lead to
increase in the memory allocated for the process, limiting the scalability (as more devices will
lead to more threads leading to out of memory situation quickly). Also most operating systems
have some hard limits on the number of open sockets per process. Practically a single EMS
server instance may not be able to handle more than 300 – 400 TL1 sessions.
• TL1 standard has support for TL1 Gateway, whereby a network element (NE) can act as a
gateway for a set of NEs. An EMS can make use of the TL1 Gateway support to provide
better scalability, by maintaining session with only one gateway to manage multiple devices.
In general EMS solutions supporting TL1 Gateway inherently, deliver the flexibility to scale
easily, when compared to others.

What are the common approaches used to build an Element Management

System?
Once Equipment Vendors decide to develop an EMS for their device, they would like to get it
developed as quickly as possible, since most often they start thinking about an EMS when
they have to respond to customer RFP's or when they are in "trials" with their customers.
Naturally the burning question on every Equipment Vendors mind is how do we get the EMS
developed quickly and cost effectively. Following three options are available to developing an
EMS. (i) Custom development of EMS (ii) using frameworks to develop an EMS and (iii) using
components to develop an EMS.
In the first approach a team of 10 people develop an EMS from scratch and typically the
development effort lasts for a period of a year [to develop FCAPS (Fault, Configuration,
Accounting, Performance and Security) and Topology modules]. The development of EMS
could be done in house by the Equipment Vendor or outsourced to another company. The
advantage of this approach is that since the application is built from scratch it could be highly
customized and made to represent the device very well. The drawbacks are obviously cost
and time.
The second approach is to buy frameworks that are readily available in the market, customize
it so that it meets the Equipment Vendor's needs. The frameworks that are available in the
market typically have a preset architecture, which cannot be altered. They provide API's using
which an additional layer of application could be developed to customize the framework to
meet individual requirements. The benefit of this approach is that the EMS can be developed
quickly. The drawbacks of this approach are that the ability to build a custom application is
greatly sacrificed for speed of development. Also since the framework is rigid most of the
EMS's developed using this approach tends to have the same look and feel. Finally a key
drawback with this approach is that additional functionality cannot be added easily.
The third approach is the components based approach. In this case the EMS is architected
from scratch but developed using pre-built components. For example, if a fault module needs
to be developed then first the architecture of the fault module is defined based on the
Equipment Vendor's requirements and then the module is developed quickly by using pre-
built fault components such as log management, alarm correlation etc. The advantage of this
approach is that it combines the benefits of the custom approach and framework approach.
Since the architecture is not pre-defined it can be designed to suit individual requirements. At
the same time since the development is done
using pre-built components, the development time is much shorter than custom
development. Another key factor is that with this approach additional functionality
can be added easily

As you can see with the custom approach there is no pre-built functionality that exists when
the development process is started. The addition of functionality varies linearly with time and
the target functionality is achieved in time T1. With the components based approach, since
the development work is done using pre-built components, some amount of functionality is
available at the start of
development process and the addition of more functionality varies linearly and the same
target functionality is achieved in time T2, with T2 being less than T1. With the framework
approach, since pre-built functionality is already integrated into a framework it is more
functional to start with. However since it is rigid, more functionality cannot be added easily
and hence you see the flattening of the curve thereby taking a longer time to achieve the
target functionality. If we make a reasonable assumption that the project cost is directly
proportional to the time it takes to deliver the project (everything else remaining the same),
then it can be easily seen that the component based approach in addition to being flexible,
delivers the EMS application faster and is more cost effective.

What is the Optimum time to start EMS development?

We are glad that you have chosen to have an element management system application for
you device...it warms our heart! The time to get started on an EMS depends on several
factors while we have listed the important ones, there are many more to consider depending
on your particular situation.
(i) Device maturity
(ii) Customer/Market place requirements
(iii) Financial situation
(iv) Skill set availability and prioritization
As you would have noticed, of the four key factors listed above, three of them (device
maturity,
financial situation, skill set availability) are internal to the company while customer/market
place requirement is external to the company and depends to a very great extent on the
market place that you are participating. If you want to be truly a market driven company you
will put item (ii) as
the most important factor which we will discuss as the last factor.
As a first set step let us look at the internal factors of the company over
which the company
presumably has some control. Based on our experience, in general we
recommend that the
customer's start their EMS development when the device development is almost completed
and the device is stable. This allows the MIB definition of the device to be complete and the
MIBS are also stable – a key requirement for a successful and stable EMS.
The second key factor is the current financial situation, since most of the money during the
device development phase are earmarked to developing the device (and rightfully so), there
may not be enough funds to be allocated for the development of an EMS. This would mean
that the development of a full-fledged EMS might have to be postponed for a while till
additional funds are
obtained. In the mean time the device has to do with a CLI or kraft interface.
The third key factor is the skill availability and prioritization. Since the EMS has a different set
of
drivers from your device, the skills required to do EMS development are different that from
your
device. If you were to do the EMS development in-house, then the EMS team needs to be
staffed up and managed. There is a lead-time involved in putting together a good EMS team
which should be
taken into account. Managing another team is a load on the engineering management team
that needs to be prioritized as well.
Lastly the most important of all the factors is the customer/market place requirement. From
our experience we've noticed that some markets (especially when selling to larger service
providers and carriers) and some products (high end devices and devices that need to be
deployed in volume)
require an EMS when the device is introduced to the market. Since a full-fledged EMS
development takes about 9 to 12 months, it is advisable to understand your market
requirements and start the EMS development about a year in advance before you enter the
market in a big way.

What are Different Approaches in Adding Functionalities to EMS?

There are primarily two ways to get your EMS in place. The first approach is to get all the
functional modules such as Fault, Configuration, Accounting, Performance, Security and
Topology developed in one shot. The second approach is to get the base functionality
completed and then add more functionality in phases. In the second approach the
functionality most requested by the customers is put in the first phase (say Topology and
Fault). In addition, the modules in phase 1 may not have all the features in them as well (i.e.
the depth). As you might have readily guessed, the first approach solves primarily for cost and
time whereas the second approach solves for cash flow. Getting the EMS developed in one
stretch would definitely lower the cost of EMS development and reduce the time taken to
develop the EMS. Whereas the second approach is easy on the cash flow. For most startup
companies since cash flow is very important (I've heard that "cash flow is the mother's milk of
a start up!") it is probably better to do the EMS development incrementally.
If we were to assume that cash flow is not a problem then the next step would be to take into
account other factors such as device maturity and market/customer requirements before
deciding on the approach. If the device is well developed and has been stable then the first
approach could be considered. Also if the market that you are addressing insists that you
have a complete EMS (example ILEC and large Service Providers) then first approach makes
sense. However if your device is not fully mature and you are targeting smaller customers
who are not very demanding then it may make sense to go with the second option and get a
basic version of EMS in place and start trials with customers (the trials will also surface many
more requirements giving you the opportunity to add features that you think are appropriate to
your base EMS). It is important to note that if you choose to go ahead with the incremental
approach, then you need to keep an eye on your long term needs and ensure that your
choice of the architecture/technology supports the incremental approach

A Network Management System (NMS) is a combination of hardware and software used to monitor
and administer a network.

Individual network elements (NEs) in a network are managed by an element management system.

[edit] Planning for a Network Management System

Effective planning for a network management system requires that a number of network
management tasks be performed. The network management system should discover the network
inventory, monitor the health and status of devices and provide alerts to conditions that impact
system performance.

NMS systems make use of various protocols for the purpose they serve. For example, SNMP protocol
allows them to simply gather the information from the various devices down the network hierarchy.
NMS software is responsible for identification of a problem, the exact source(s) of the problem, and
solving them. NMS systems not only are responsible for the detection of faults, but also for collecting
device statistics over a period of time. An NMS may include a library of previous network statistics
along with problems and solutions that were successful in the past—useful if faults recur. NMS
software can then search its library for the best possible method to resolve a particular problem.

An NMS manages the Network Elements. These elements or devices are managed by the NMS, so
these devices used to call as managed devices. Device management includes Fault, Accounting,
Configuration, Performance, and Security (FCAPS) management. Each of these five functions is
specific to an organization, but the basic idea to manage these devices is FCAPS.

[edit] See also

FCAPS is the ISO Telecommunications Management Network model and framework for network
management. FCAPS is an acronym for Fault, Configuration, Accounting, Performance, Security, the
management categories into which the ISO model defines network management tasks. In non-billing
organizations Accounting is sometimes replaced with Administration.

The comprehensive management of an organization's information technology (IT) infrastructure is a

fundamental requirement. Employees and customers rely on IT services where availability and
performance are mandated, and problems can be quickly identified and resolved. Mean time to repair
(MTTR) must be as short as possible to avoid system downtimes where a loss of revenue or lives is
possible.

Contents
[hide]

• 1 History
• 2 Fault management
• 3 Configuration management
• 4 Accounting management
• 5 Performance management
• 6 Security management
• 7 References

• 8 External links

[edit] History
In the early 1980s the term FCAPS was introduced within the first Working Drafts (N1719) of ISO
10040, the Open Systems Interconnection (OSI) Systems Management Overview (SMO) standard. At
that time the intention was to define five separate protocol standards, one for each functional area.
Since initial experiences showed that these protocols would become very similar, the ISO working
group responsible for the development of these protocols (ISO/TC97/SC16/WG4, later renamed into
ISO-IEC/JTC1/SC21/WG4) decided to create a single protocol for all five areas instead. This protocol
is called common management information protocol (CMIP). In the 1990s the ITU-T, as part of their
work on Telecommunications Management Network (TMN), further refined the FCAPS as part of the
TMN recommendation on Management Functions (M.3400). The idea of FCAPS turned out to be very
useful for teaching network management functions; most text books therefore start with a section that
explains the FCAPS.

[edit] Fault management

A fault is an event that has a negative significance. The goal of fault management is to recognize,
isolate, correct and log faults that occur in the network. Furthermore, it uses trend analysis to predict
errors so that the network is always available. This can be established by monitoring different things
for abnormal behavior.

When a fault or event occurs, a network component will often send a notification to the network
operator using a proprietary or open protocol such as SNMP, or at least write a message to its console
for a console server to catch and log/page. This notification is supposed to trigger manual or automatic
activities. For example, the gathering of more data to identify the nature and severity of the problem or
to bring backup equipment on-line.

Fault logs are one input used to compile statistics to determine the provided service level of individual
network elements, as well as sub-networks or the whole network. They are also used to determine
apparently fragile network components that require further attention.

The leading[citation needed] Fault Management systems are EMC Smarts, CA Spectrum, HP Software,
NetIQ, IBM Tivoli Netcool, TTI Telecom Netrac, CA Clarity, Objective Systems Integrators
NETeXPERT etc. Fault Isolation tools like Delphi are also available, which are basically used to
isolate the fault in any telecom network.
[edit] Configuration management
The goals of configuration management include:

• to gather and store configurations from network devices (this can be done locally or remotely).
• to simplify the configuration of the device
• to track changes that are made to the configuration
• to configure ('provision') circuits or paths through non-switched networks

[edit] Accounting management

Accounting is often referred to as billing management. The goal is to gather usage statistics for users.

Using the statistics the users can be billed and usage quota can be enforced.

Examples:

• Disk usage
• Link utilization
• CPU time

RADIUS, TACACS and Diameter are examples of protocols commonly used for accounting.

For non-billed networks, "administration" replaces "accounting". The goals of administration are to
administer the set of authorized users by establishing users, passwords, and permissions, and to
administer the operations of the equipment such as by performing software backup and
synchronization.

[edit] Performance management

Performance management enables the manager to prepare the network for the future, as well as to
determine the efficiency of the current network, for example, in relation to the investments done to set
it up. The network performance addresses the throughput, percentage utilization, error rates and
response times areas.

By collecting and analysing performance data, the network health can be monitored. Trends can
indicate capacity or reliability issues before they become service affecting.

Performance thresholds can be set in order to trigger an alarm. The alarm would be handled by the
normal fault management process (see above). Alarms vary depending upon the severity.

[edit] Security management

Security management is the

Simple Network Management Protocol (SNMP) is a UDP-based network protocol. It is

used mostly 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.[1]
SNMP exposes management data in the form of variables on the managed systems, which
describe the system configuration. These variables can then be queried (and sometimes set)
by managing applications.

Overview and basic concepts

In typical SNMP use, one or more administrative computers called managers have the task of
monitoring or managing a group of hosts or devices on a computer network. Each managed
system executes, at all times, a software component called an agent which reports information
via SNMP to the manager.

Essentially, SNMP agents expose management data on the managed systems as variables. The
protocol also permits active management tasks, such as modifying and applying a new
configuration through remote modification of these variables. The variables accessible via
SNMP are organized in hierarchies. These hierarchies, and other metadata (such as type and
description of the variable), are described by Management Information Bases (MIBs).

An SNMP-managed network consists of three key components:

• Managed device
• Agent — software which runs on managed devices
• Network management system (NMS) — software which runs on the manager

A managed device is a network node that implements an SNMP interface that allows
unidirectional (read-only) or bidirectional access to node-specific information. Managed
devices exchange node-specific information with the NMSs. Sometimes called network
elements, the managed devices can be any type of device, including, but not limited to,
routers, access servers, switches, bridges, hubs, IP telephones, IP video cameras, computer
hosts, and printers.

An agent is a network-management software module that resides on a managed device. An

agent has local knowledge of management information and translates that information to or
from an SNMP specific form.

A network management system (NMS) executes applications that monitor and control
managed devices. NMS's provide the bulk of the processing and memory resources required
for network management. One or more NMSs may exist on any managed network.

[edit] Management information base (MIB)

Main article: Management information base

SNMP itself does not define which information (which variables) a managed system should
offer. Rather, SNMP uses an extensible 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 identifies a variable that can be read or set via SNMP. MIBs use the notation
defined by ASN.1.

[edit] Protocol details

SNMP operates in the Application Layer of the Internet Protocol Suite (Layer 7 of the OSI
model). The SNMP agent receives requests on UDP port 161. The manager may send
requests from any available source port to port 161 in the agent. The agent response will be
sent back to the source port on the manager. The manager receives notifications (Traps and
InformRequests) on port 162. The agent may generate notifications from any available port.

SNMPv1 specifies five core protocol data units (PDUs). Two other PDUs, GetBulkRequest
and InformRequest were added in SNMPv2 and carried over to SNMPv3.

All SNMP PDUs are constructed as follows:

IP UDP PDU- request- error- error- variable

version community
header header type id status index bindings

The seven SNMP protocol data units (PDUs) are as follows:

[edit] GetRequest

A manager-to-agent request to retrieve the value of a variable or list of variables. Desired

variables are specified in variable bindings (values are not used). Retrieval of the specified
variable values is to be done as an atomic operation by the agent. A Response with current
values is returned.

[edit] SetRequest

A manager-to-agent request to change the value of a variable or list of variables. Variable

bindings are specified in the body of the request. Changes to all specified variables are to be
made as an atomic operation by the agent. A Response with (current) new values for the
variables is returned.

[edit] GetNextRequest

A manager-to-agent request to discover available variables and their values. Returns a

Response with variable binding for the lexicographically next variable in the MIB. The entire
MIB of an agent can be walked by iterative application of GetNextRequest starting at OID 0.
Rows of a table can be read by specifying column OIDs in the variable bindings of the
request.

[edit] GetBulkRequest

Optimized version of GetNextRequest. A manager-to-agent request for multiple iterations of

GetNextRequest. Returns a Response with multiple variable bindings walked from the
variable binding or bindings in the request. PDU specific non-repeaters and max-repetitions
fields are used to control response behavior. GetBulkRequest was introduced in SNMPv2.

[edit] Response

Returns variable bindings and acknowledgement from agent to manager for GetRequest,
SetRequest, GetNextRequest, GetBulkRequest and InformRequest. Error reporting is provided
by error-status and error-index fields. Although it was used as a response to both gets and
sets, this PDU was called GetResponse in SNMPv1.
[edit] Trap

Asynchronous notification from agent to manager. Includes current sysUpTime value, an OID
identifying the type of trap and optional variable bindings. Destination addressing for traps is
determined in an application specific manner typically through trap configuration variables in
the MIB. The format of the trap message was changed in SNMPv2 and the PDU was renamed
SNMPv2-Trap.

[edit] InformRequest

Acknowledged asynchronous notification from manager to manager. This PDU use the same
format as the SNMPv2 version of Trap. Manager-to-manager notifications were already
possible in SNMPv1 (using a Trap), but as SNMP commonly runs over UDP where delivery
is not assured and dropped packets are not reported, delivery of a Trap was not guaranteed.
InformRequest fixes this by sending back an acknowledgement on receipt. Receiver replies
with Response parroting all information in the InformRequest. This PDU was introduced in
SNMPv2.

[edit] Development and usage

[edit] Version 1

SNMP version 1 (SNMPv1) is the initial implementation of the SNMP protocol. SNMPv1
operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI
Connectionless Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP),
and Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the de facto
network-management protocol in the Internet community.

The first RFCs for SNMP, now known as SNMPv1, appeared in 1988:

• RFC 1065 — Structure and identification of management information for TCP/IP-

based internets
• RFC 1066 — Management information base for network management of TCP/IP-
based internets
• RFC 1067 — A simple network management protocol

These protocols were obsoleted by:

• RFC 1155 — Structure and identification of management information for TCP/IP-

based internets
• RFC 1156 — Management information base for network management of TCP/IP-
based internets
• RFC 1157 — A simple network management protocol

After a short time, RFC 1156 (MIB-1) was replaced by more often used:

• RFC 1213 — Version 2 of management information base (MIB-2) for network

management of TCP/IP-based internets

Version 1 has been criticized for its poor security. Authentication of clients is performed only
by a "community string", in effect a type of password, which is transmitted in cleartext. The
'80s design of SNMP V1 was done by a group of collaborators who viewed the officially
sponsored OSI/IETF/NSF (National Science Foundation) effort (HEMS/CMIS/CMIP) as both
unimplementable in the computing platforms of the time as well as potentially unworkable.
SNMP was approved based on a belief that it was an interim protocol needed for taking steps
towards large scale deployment of the Internet and its commercialization. In that time period
Internet-standard authentication/security was both a dream and discouraged by focused
protocol design groups.

[edit] Version 2

SNMPv2 (RFC 1441–RFC 1452), revises version 1 and includes improvements in the areas
of performance, security, confidentiality, and manager-to-manager communications. It
introduced GetBulkRequest, an alternative to iterative GetNextRequests for retrieving large
amounts of management data in a single request. However, the new party-based security
system in SNMPv2, viewed by many as overly complex, was not widely accepted.[citation needed]

Community-Based Simple Network Management Protocol version 2, or SNMPv2c, is defined

in RFC 1901–RFC 1908. In its initial stages, this was also informally known as SNMPv1.5.
[citation needed]
SNMPv2c comprises SNMPv2 without the controversial new SNMP v2 security
model, using instead the simple community-based security scheme of SNMPv1. While
officially only a "Draft Standard", this is widely considered the de facto SNMPv2 standard.

User-Based Simple Network Management Protocol version 2, or SNMPv2u, is defined in RFC

1909–RFC 1910. This is a compromise that attempts to offer greater security than SNMPv1,
but without incurring the high complexity of SNMPv2. A variant of this was commercialized
as SNMP v2*, and the mechanism was eventually adopted as one of two security frameworks
in SNMP v3.[citation needed]

[edit] SNMPv1 & SNMPv2c interoperability

As presently specified, SNMPv2 is incompatible with SNMPv1 in two key areas: message
formats and protocol operations. SNMPv2c messages use different header and protocol data
unit (PDU) formats from SNMPv1 messages. SNMPv2c also uses two protocol operations
that are not specified in SNMPv1. Furthermore, RFC 2576 defines two possible SNMPv1/v2c
coexistence strategies: proxy agents and bilingual network-management systems.

[edit] Proxy agents

A SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as
follows:

• A SNMPv2 NMS issues a command intended for a SNMPv1 agent.

• The NMS sends the SNMP message to the SNMPv2 proxy agent.
• The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent
unchanged.
• GetBulk messages are converted by the proxy agent to GetNext messages and then
are forwarded to the SNMPv1 agent.

The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards
them to the NMS.
[edit] Bilingual network-management system

Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To

support this dual-management environment, a management application in the bilingual NMS
must contact an agent. The NMS then examines information stored in a local database to
determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the
database, the NMS communicates with the agent using the appropriate version of SNMP.

[edit] Version 3

SNMPv3 is defined by RFC 3411–RFC 3418 (also known as 'STD0062'). SNMPv3 primarily
added security and remote configuration enhancements to SNMP.[2]

SNMPv3 provides important security features:[3]

• Confidentiality - Encryption of packets to prevent snooping by an unauthorized

source.
• Integrity - Message integrity to ensure that a packet has not been tampered with in
transit.
• Authentication - to verify that the message is from a valid source.

As of 2004 the IETF recognizes Simple Network Management Protocol version 3 as defined
by RFC 3411–RFC 3418[4] (also known as STD0062) as the current standard version of
SNMP. The IETF has designated SNMPv3 a full Internet standard,[5] the highest maturity
level for an RFC. It considers earlier versions to be obsolete (designating them "Historic").[6]

In practice, SNMP implementations often support multiple versions: typically SNMPv1,

SNMPv2c, and SNMPv3.[7]

[edit] Applications

This section requires expansion.

[edit] Environmental monitoring

Server, rack and appliance operating temperatures and room humidity could be monitored
remotely for SNMP-enabled HVAC devices.[8][9]

[edit] Implementation issues

SNMP implementations vary across platform vendors. In some cases, SNMP is an added
feature, and is not taken seriously enough to be an element of the core design. Some major
equipment vendors tend to over-extend their proprietary command line interface (CLI) centric
configuration and control systems.[10][not in citation given]

SNMP's seemingly simple tree structure and linear indexing may not always be understood
well enough within the internal data structures that are elements of a platform's basic design.
As a result, processing SNMP queries on certain data sets may result in higher CPU
utilization than necessary. One example of this would be large routing tables, such as BGP or
IGP.[citation needed]

[edit] Resource indexing

 This section may contain original research. Please improve it by verifying the
claims made and adding references. Statements consisting only of original research
may be removed. More details may be available on the talk page. (April 2010)

Modular devices may dynamically increase or decrease their SNMP indices (aka instances)
whenever slotted hardware is added or removed. Although this is most common with
hardware, virtual interfaces have the same effect. Index values are typically assigned at boot
time and remain fixed until the next reboot. Hardware or virtual entities added while the
device is 'live' may have their indexes assigned at the end of the existing range and possibly
reassigned at the next reboot. Network inventory and monitoring tools need to have the device
update capability by properly reacting to the cold start trap from the device reboot in order to
avoid corruption and mismatch of polled data.

Index assignments for an SNMP device instance may change from poll to poll mostly as a
result of changes initiated by the system admin. If information is needed for a particular
interface, it is imperative to determine the SNMP index before retrieving the data needed.
Generally, a description table like ifDescr will map a user friendly name like Serial 0/1 (Blade
0, port 1) to a SNMP index.

[edit] Security implications

• SNMP versions 1 and 2c are subject to packet sniffing of the clear text community
string from the network traffic, because they do not implement encryption.
• All versions of SNMP are subject to brute force and dictionary attacks for guessing
the community strings, authentication strings, authentication keys, encryption strings,
or encryption keys, because they do not implement a challenge-response handshake.
Entropy is an important consideration when selecting keys, passwords and/or
algorithms.
• Although SNMP works over TCP and other protocols, it is most commonly used over
UDP that is connectionless and vulnerable to IP spoofing attacks. Thus, all versions
are subject to bypassing device access lists that might have been implemented to
restrict SNMP access, though SNMPv3's other security mechanisms should prevent a
successful attack.
• SNMP's powerful configuration (write) capabilities are not being fully utilized by
many vendors, partly due to lack of security in SNMP versions before SNMPv3 and
partly due to the fact that many devices simply are not capable of being configured
via individual MIB object changes.
• SNMP tops the list of the SANS Institute's Common Default Configuration Issues
with the issue of default SNMP community strings set to ‘public’ and ‘private’ and
was number ten on the SANS Top 10 Most Critical Internet Security Threats for the
year 2000.

For more detail on SNMP security implications see the CERT SNMP Vulnerabilities FAQ

[edit] Autodiscovery
This section may contain original research. Please improve it by verifying the
claims made and adding references. Statements consisting only of original research
may be removed. More details may be available on the talk page. (April 2010)

SNMP by itself is simply a protocol for collecting and organizing information. Most toolsets
implementing SNMP offer some form of discovery mechanism, a standardized collection of
data common to most platforms and devices, to get a new user or implementor started. One of
these features is often a form of automatic discovery, where new devices discovered in the
network are polled automatically. For SNMPv1 and SNMPv2c, this presents a security risk,
in that your SNMP read communities will be broadcast in cleartext to the target device. While
security requirements and risk profiles vary from organization to organization, care should be
taken when using a feature like this, with special regard to common environments such as
mixed-tenant datacenters, server hosting and colocation facilities, and similar environments