CHAPTER IV

INTERNET MANAGEMENT
 Internet Management
Internet Management

This chapter discusses and analyses the management approach that is standardized
by the Internet Engineering Task Force (IETF). This approach is also known as the
Simple Network Management Protocol (SNMP) or the TCP/IP management
approach.

In the second half o f the past decade the Internet grew to a size that management of
the Internet could no longer be provided on an ad hoc basis: a structured and
standardized approach to Internet management was required. In 1987 three
management proposals therefore appeared. One of these, the High-level Entity
Management System / Protocol (HEMS / HEMP)[ RFC 1021-1022: "High-level
Entity Management System (HEMS)", Partridge C., Trewitt G., October 1987] was
withdrawn soon, so only two remained: the Simple Network Management Protocol
(SNMP) and Common Management Over TCP/IP (CMOT). At the March 1988
meeting of the Internet board, the decision was made to use SNMP in the short-term
and CMOT in the long-term.[ RFC 1052: "IAB recommendations for the
development of Internet network management standards", Cerf V.G., April 1988 ]

CMOT was an attempt to use OSI systems management standards (such as CMIP)
in the Internet environment. CMOT faced the same problems as OSI management:
the specifications did not appear in time, there were virtually no implementations and
operational experience could not be obtained. As a result, the support for CMOT
slowly diminished. In 1992 all work on CMOT was stopped.

SNMP [RFC 1157: "Simple Network Management Protocol (SNMP)", Case J.D.,
Fedor M., Schoffstall M.L., Davin C., May 1990] is actually a further development
of SGMP (Simple Gateway Monitoring Protocol)[Case J.D., Davin J.R., Fedor M.S.,
Schoffstall M.L.: "Introduction to the Simple Gateway Monitoring Protocol", in:
IEEE Network, page 43-49, March 1988] . SGMP was aimed at management of
Intermediate Systems (gateways). Because SGMP appeared to be a success, it was
decided to extend its scope and include management of End Systems. To reflect this
change, the protocol was renamed into SNMP.

An interesting difference between the IETF and ISO is that the IETF takes a more
pragmatic and result driven approach than ISO. In the IETF it is for instance unusual
to spent much time on architectural discussions; people prefer to use their time on
the development of protocols and implementations.
This different attitude explains why no special standards have been defined for the
Internet management architecture; only protocols and MIBs have been standardized.
Fortunately many articles and books have been written (even by the editors of the
standards) that describe the principles behind Internet management [e.g.

Ben-Artzi A., Chandna A.,Warrier U., "Network management of TCP/IP Networks:

Present and Future", in: IEEE Network Magazine, page 35-43, July,1990,

Case J.D., Davin J.R., Fedor M.S., Schoffstall M.L.: "Network management and the
design of SNMP", in: Connexions, the Interoperability Report, page 22-26,March
1989

Case J.D., Davin J.R., Fedor M.S., Schoffstall M.L.: "Internet network management
using the Simple Network Management protocol", in Proceedings of the 14th IEEE
Conference on Local Computer Networks, page 156-159, Oct.1989

Case J.D., Davin J.R., Fedor M.S., Schoffstall M.L.: "Keeping it simple (network
management)", in Unix Review, Vol. 8, No. 3, page 60-66, March 1990

Rose M.T.: "The Simple Book - Second edition", Prentice-Hall International

Editions, 1994

Rose M.T., "Network management is Simple, you just need the right framework", in:
Proceedings of the IFIP TC6/WG 6.6 Second International Symposium on Integrated
Network Management, page 9-25, North-Holland, 1991 ]

• From the above publications the following ideas appear:

• All systems connected to the network should be manageable with SNMP.

• The cost of adding network management to existing systems should be minimal.

• It should be relatively easy to extend the management capabilities of existing

systems (by extending the Management Information Base).

• Network management must be robust. Even in case of failures, a small set

of management capabilities must still be available.

Apparently SNMP was the right solution at the right time. Already a few years after
Publication of the standard most data communication equipment could be managed
 via SNMP; SNMP had become the de facto standard for management of data
communication networks. Still SNMP has some deficiencies. In 1992 work was
therefore started to develop an improved version of SNMP; this new version was
called SNMPv2.

In this chapter both protocol versions will be presented. Section 4.1 discusses the
original SNMP protocol, while SNMPv2 will be discussed in Section 4.2. It should
be noted that both protocols only define how management information should be
exchanged; they do not define which management information exists. Such
information is defined by the various MIB standards; Section 4.3 discusses some of
the most important ones. Section 4.4 provides an analysis of Internet management.

4.1 The original SNMP protocol

The ideas behind SNMP are relatively straightforward and easy to understand. In
fact, there is little difference between the ideas behind SNMP and the ideas that
existed in ISO around 1987, thus before ISO adopted the Object Oriented approach
for management. Examples of such common ideas are the manager agent concept,
the idea to use the managed functions also for the exchange of management
information, the idea to use GET and SET PDUs for operations on management
information, the idea to use ASN. 1 for the definition of management information and
the idea of a MIB.

rasrapar agent

>■SNMP

Figure 4.1: Internet management structure

With SNMP, a single manager may control many agents. As shown in Figure 4.1. the
SNMP protocol is built upon the User Datagram Protocol (UDP), which is a
connectionless transport protocol [RFC 768: "User Datagram Protocol", Postel, J.B.,
August 1980 ]. Since the Internet management information as well as the formats of
SNMP PDUs are defined according to (a subset of) the ASN.l syntax, encoding
functions are needed immediately on top of UDP. These functions operate according
to the Basic Encoding Rules (BER). Five types of SNMP PDUs are defined:
GetRequest, GetNextRequest, SetRequest, Response and Trap. The SNMP protocol
standard does not address the functions that are specific for managers or agents; the
SNMP standard is thus restricted to the functions below the dotted line (Figure 4.1).
This implies that the scope of SNMP is equivalent to the one of CMIP; as opposed to
CMIP no standard exists, however, which defines the service that is provided on top
of SNMP.

The IETF has not (yet) defined manager specific functions; further work in this area
is therefore urgently needed[Rose M.T.: "The Simple Book - Second edition",
Prentice-Hall International Editions, 1994]. The lack of manager specific functions
sharply contrasts to the overwhelming number of agent specific functions (primarily
MIBs) that have been defined. Section 4.3 gives an overview of these MIBs.

4.1.1 Transport mappings

The choice to operate SNMP over the connectionless UDP has several implications.

In the first place UDP is unreliable, which means that user data may get lost. The
decision to use an unreliable transport service provider, has been taken deliberately.
The reason is that even in case of repeated provider failures, it should still be
possible to exchange some part of the management information. With a reliable
(connection-oriented) provider this may not be possible. Connection- oriented
providers are designed according to an 'all or nothing' approach: either all data will
be delivered or nothing will be delivered. If data can not be delivered, the connection
will be released. Connectionless providers are designed according to an 'best-effort'
approach: even in case of failures some of the data may amve at the destination.
Management may therefore still be possible, although in a limited way.

It is interesting to see that the SNMP protocol does not itself perform
retransmissions. The responsibility to detect data loss and initiate retransmission is
left to the manager, because it is assumed that managers are usually better equipped
to determine whether and when retransmissions are required.

A second implication of using a connectionless transport protocol, is that managers

should perform some kind of polling to detect whether agents are still operational.
With connection-oriented providers (e.g. OSI's presentation service) this would not
be necessary, because such providers already include lifetime control functions 1.
Such functions periodically check whether the remote systems (in our case the
agents) are still operational. In case they went down, the provider takes the initiative
to release the connection and informs the user (in our case the manager).
A characteristic of UDP is that packets can not exceed a certain size. To ensure that
only limited size packets will be generated, the SNMP protocol has defined a number
of rules. One of these rules is that, if the response to a certain SNMP request would
exceed the maximum packet size, no information will be returned at all. Managers
should be aware o f this rule and, instead of issuing a single all-embracing request,
issue multiple smaller request to get the information piece by piece. Unfortunately,
managers will in many cases not be able to predict the amount of information that
can be obtained via a single request.

Although SNMP is intended to operate over UDP, there are also RFCs that define
how to operate SNMP on top of other protocols (e.g. Ethernet, IPX or even OSI).

4.1.2 Protocol operations

In SNMP, communication from the manager to the agent system is performed in a

confirmed way. The SNMP entity at the manager's side takes the initiative by
sending one of the following PDUs: GetRequest, GetNextRequest or SetRequest.
The GetRequest and GetNextRequest are used to retrieve management information
from the agent, the SetRequest is used to store (or change) management information.
After reception of one of these PDUs, the SNMP entity at the agent's side responds
with a Response PDU (Figure 4.2). This PDU carries the requested information or
indicates failure of the previous request.

Manager agent manager agent manager agent

Side side side side side side

GetR quest
GetN :xtRequest Set Request
x
X

Response ^ Response
Response -

Figure 4.2: Managing system takes the initiative

 It is also possible that the SNMP entity at the agent's side takes the initiative. This
happens in case the agent detects some extraordinary event, such as a re-initialization
or a status change at one of its links. As a reaction, the agent's SNMP entity sends a
Trap PDU to the managing system (Traps may be compared to OSI Event-Reports).
Reception of the Trap is not confirmed (Figure 4.3).

SNMP does not describe how to relate the various Get, Set and Trap interactions.
What to do after reception of a Trap is, for example, not defined by SNMP.
Instead, determination of this relationship is considered to be a responsibility
of the manager specific functions.

manager agent
side side

Figure 4.3: Agent system takes the initiative

4.2 SNMPv2

Since publication o f the original SNMP protocol, several proposals have been
presented to improve SNMP. In 1992 it was decided to collect these proposals and
produce a new standard: SNMPv2. Unfortunately SNMPv2 became far more
complex than the original SNMP[ Pras A.: "TMN - Introduction and Interpretation”,
TIOS 92-16, Memoranda Informatica 92-40]; whereas the description of the original
SNMP protocol required, for example, only 35 pages, the description of SNMPv2
required about 250 pages.
 The main achievements of SNMPv2 are the improved performance (Subsection
4.2.1), the better security (Subsection 4.2.2) and the possibility to build a hierarchy
of managers (Subsection 4.2.3).

4.2.1 Performance

As explained on page 64, the original SNMP protocol includes a rule which states
that if the response to a Get or GetNext request would exceed the m aximum size of a
packet, no information will be returned at all. Since managers can not determine the
precise size of response packets in advance, they usually take a conservative guess
and request per PDU just a small amount. To obtain all information, managers may
be required to issue a large number of consecutive requests.

To improve performance, SNMPv2 introduced the GetBulk PDU. As opposed to the

Get and GetNext, the response to the GetBulk always returns as much information as
possible. If the requested information exceeds the maximum size of an UDP packet,
the information will be truncated and only the part that fits within the packet will be
returned.

4.2.2 Security

The original SNMP protocol had, except for a simple mechanism which involved the
exchange of passwords (the term 'community string' was used to denote this
password), no security features. To solve this deficiency, SNMPv2 introduced a full-
fledged security mechanism. This mechanism is based upon the use of 'parties' and
'contexts'; two concepts that can not be found in other management approaches.
Although the SNMPv2 standards include definitions of both concepts, these
definitions are difficult to understand. This subsection presents a somewhat
simplified view o f these concepts.

Parties have some resemblance to protocol entities. Usually multiple parties are
active in a single SNMPv2 subsystem and these various parties will be configured in
different ways. One party may, for instance, be configured such that it is prepared to
communicate with every other party in every other system. These numbers do not
include the pages describing the Structure of Management Information.

Mother party may be configured such that it is only prepared to interact with one
Particular remote party. In such case, the MD5 authentication mechanism is used to
ensure the authentication of the other party. Finally parties may be confipired in a
way that they are only prepared to interact with particular remote parties and in
 addition require that all management information is encrypted according to the DES
algorithm. 6

A graphical representation of parties is provided in Figure 4 4 In this figure three

parties have been configured in the manager system (Pal, Pa2 and Pa3) and three
parties in the agent system (Pb 1, Pb2 and Pb3).

UDP

Figure 4.4: Parties and contexts

o control access to the various parts of a MIB, SNMPv2 has introduced the context
concept. Each context refers a specific part of a MIB. In the example of Figure 4.4,
context Cl and context C2 refer to the two dotted areas in the MIB. Contexts may be
overlapping and are dynamically configurable, which means that contexts may be
created, deleted or modified during the network's operational phase. Different
contexts may be configured for different systems.

Local party Context Operation

Pbl Cl Get
Pb2 Cl Get
Pb3 Cl Get + set
Pb3 C2 Get

Figure 4.5: Example of an Access Control List (ACL)

 To determine which parties are allowed to perform which operations upon which
part of the MIB, SNMPv2 has associated with each agent an Access Control List
(ACL). Figure 4.5 shows an example of such a list. The first row indicates that party
Pal (in the manager system) may perform Get operations via party Pbl (in the agent
system) on that part of the MIB that is identified by context Cl. The third row shows
that Pa3 may via Pb3 also perform Set operations on this MIB part.

4.2.3 Management hierarchy

Practical experience with the original SNMP protocol showed that in many cases
managers are unable to manage more than a few hundred agent systems [3]. The
cause for this restriction is in SNMP's polling nature: the manager must periodically
poll every system under his control, which takes time. To solve this problem,
SNMPv2 introduced the idea of intermediate level managers.

Polling is now performed by a number of such intermediate level managers under

control of the top level manager. Figure 4.6 shows an example. Before the
intermediate level managers start polling, the top level manager tells the intermediate
level managers which

TLM = Top Level Manager

TLM ILM = Intermediate Level Manager
A = Agent

Figure 4.6: Intermediate Level Managers

variables must be polled in which agents. Besides, the top le v e l manager tells the
intermediate
intermediate level
level managers
managers o f the events he wants to be informed about. After the
intermediate level managers are configured, they start polling. In case an
 intermediate level manager detects in a particular agent an event about which the top
level managers wanted to be informed, a special Inform PDU is generated.

After reception o f this PDU, the top level manager directly operates upon the agent
that caused the event.

4.3 MIBs

To identify all variables that can be managed, a large number of Management

Information Base (MIB) standards have been developed. Next to these standards, one
special standard exists defining how to describe MIB variables. This TLM standard
is called the Structure o f Management Information (SMI). It defines for instance the
subset of ASN.l constructs that can be used to describe management variables. [ RFC
1155: "Structure and identification of Management Information for TCP/ IP-based
internets", Rose M.T.; McCloghrie K., May 1990]

To ensure the unique identification of each management variable, the SMI introduces
the concept of a naming tree. The leaves of this tree represent the actual management
information.

The MIB-II[RFC 1157: "Simple Network Management Protocol (SNMP)", Case

J.D., Fedor M., Schoffstall M.L., Davin C., May 1990] is the most important and
probably best known MIB; it contains all the variables to control the major Internet
protocols (e.g. IP, ICMP, UDP, TCP, EGP and SNMP). The structure of this MIB is
simple: all management variables that belong to the same protocol are grouped
together (Figure 4.7). Within a protocol group there is hardly any additional structure
that helps understanding the various variables within that group. Soon after
definition of the MIB-II other MIBs appeared; Figure 4.8 shows some of the
standardized ones.

Figure 4.7: The various protocol groups of the MIB-II

 Next to the standardized MIBs there are also a large number of enterprise specific
MIBs. Together these MIBs define more than twenty-thousand management
variables[Jander M.: "SNMP: coming soon to a network near you", Data
Communications, November 1992, page 66-76]. Unfortunately no clear structure has
been developed to explain the relationship between these MIBs; the only indication
of a MIBs purpose is its name.

Title RFC Date

MIB-II 1213 March 1991
IEEE 802.5 Token Ring 1231 May 1991
Appletalk 1243 July 1991
OSPF version 2 1253 August 1991
Remote Network Monitoring 1271 November 1991
IP Forwarding Table MIB 1354 July 1992
RIP Version 2 1389 1389 January 1993
DS1 and El Interface Types 1406 1406 January 1993
DS3 and E3 Interface Types 1407 1407 January 1993
X.25 1461 1461 May 1993
Point-to-Point Protocol 1471-1474 June 1993
Bridges 1493 July 1993
FDDI 1512 September 1993
Remote Network Monitoring - 1513 September 1993
_Token Ring
Host Resources 151 September 1993
IEEE 802.3 Medium 1515 September 1993
Attachment Units
JEEE 802.3 Repeater Devices 1516 September 1993
Source Routing Bridges 1525 September 1993
JJECnet Phase IV Extensions 1559 December 1993
^Network Services Monitoring 1565 January 1994
_Mail Monitoring 1566 January 1994
J^500 Directory Monitoring 1567 January 1994
_§Na APPN Node 1593 March 1994
SONET/SDH Interface 1595 March 1994
Jljftfne Relav Service 1604 March 1994
J^omain Name Svstem 1611-1612 May 1994
-Uninterrupted Power Supolv 1628 May 1994
J^tarnet-like Interface Types 1643 July 1994
J ^ d e r Gatewav Protocol 1657 Julv 1994
L^haracter Stream Devices 1658 July 1994
1^2324ike Hardware 1659 July 1994
Devices
Parallel-printer-like Hardware 1660 July 1994
Devices
SNANAU 1666 August 1994
SMDS - SIP Interface Type 1694 August 1994
ATM 1695 August 1994
Modem 1696 August 1994
Relational Database 1697 August 1994
Management System

Figure 4.8: Some existing MIB definitions

4.4 Analysis

Internet management can be compared to OSI management. In fact, Internet

management uses many of the concepts that existed in OSI at the time SNMP started
(around 1988). As a result, the remarks that were made in the analysis section of OSI
management (Section 2.3) are to some extent also applicable to Internet
management. As opposed to OSI management, however, Internet management uses
only a small part o f the managed functions for the exchange of management
information. Problems with fault management (see Subsection 2.3.2) are therefore
less likely to occur.

4.4.1 The management architecture has not been described

No standards have been produced defining the Internet management architecture. To

get an understanding of the architectural concepts behind Internet management,
readers have to derive the meaning of the various concepts from the protocol
standards. Although this may not be a problem in case of the original version of
SNMP, it certainly is a problem with SNMPv2. Experience has shown that without a
good understanding of these concepts, it is difficult to implement SNMPv2. A
recommendation for the IETF is therefore to develop such a standard.

The concepts that cause most of the problems, are parties and contexts. Although the
interpretation o f these concepts given in this thesis (Subsection 4.2.2) may be
sufficient to understand most parts of the SNMPv2 standards certain parts of the
standards are based upon some other interpretation. A goo ^ examp e o s c
alternative interpretation can be found in the standards that e e ow
intermediate level managers.
 According to these standards a context does not only refer to the specific part of a
MIB, but also identifies one of the agents that is controlled by the intermediate level
manager.

4.4.2 Too many management variables

Now that thousands of management variables have been defined, the lack of a good
functional structure to classify these variables has become a problem. Without such
structure, managers will be confronted with large lists of management variables. To
determine which variables must be watched and which modifications must be made,
managers must understand the precise meaning of many variables.

In case management is performed by human beings, it is unlikely that there will be

many people with sufficient ready knowledge. As a consequence, it can be expected
that managers need a lot of time before they decide what to do. Network
management may therefore become a time-consuming and thus expensive activity.

4.4.3 Manager specific functions have not been defined

The Internet management standards explain how individual management operations,

such as GET and SET, should be performed. Currently they do not specify, however,
the sequence in which these operations should be performed to solve particular
management problems. Such sequences are part of the 'manager specific functions'
(see Figure 4.1); until now the IETF has not defined such functions.

Example: Suppose a router breaks down. Actions must be initiated by management

to prevent data from getting lost. These actions include the change of routing tables.
Since networks consist of thousands of systems, management must decide which
tables to changeand which not. Of course, management must also specify the exact
contents of the modified routing tables.

Internet management standards do not describe any of these actions. Instead, Internet
management provides only a general approach to read and modify individual
management variables.

The approach that is taken by Internet to manage networks is comparable to an

approach in which debuggers are used to 'manage' computer programs. Ordinary
debuggers allow programmers to watch and modify program variables. A dlebug
Program does not help, however, to determine which variables must be watched an
which modifications must be made. Such decisionsmust be made by the
program mer; the debugger only helps to access the variables.

Internet management standards define distributed 'debuggers'. These 'debuggers'

allow managers to watch and modify management variables; they do not tell which
variables must be watched and which modifications must be made. Such decisions
must be taken by the 'manager specific functions' (e.g. the operator); Internet
management standards only tell how to access management variables.