name Vi&ibleString

size INTEGER
gr aduat e BOOLEAN
I

which ofthe following set of values is (are) compatible with the above ASN.I record structure?

a. ''CS4803B," FALSE, 28
b. CS8.113B; TRUE, 28
c. ''CS4803B.'' 28, TRUE
d. CS4803B, 28, TRUE

10. a. Describe a list and an ordered list in ASN. l syntax

b. IdentifY the differences between tbem
c. Differentiate between lis! constroction and repetitive constroction using eKamples

11. In a ballroom dance, the conductor ask.s the guests to group themselves Into couples made up of a male and a
female (order does not matter) for a dance. Write an ASN.1 module for danceGroup with data type·oanceGroup
that Is composed of data type Couple; couple Is constructed uslne mal e and female.

U. A high school class consists of four boys and four girls. The names of the boys with their heights are Adam (65"),
Chang (63"), Eduardo (72'), and Gopal (62"). The names of the girls are Beth (68"), Dipa (59"), Faye (61"), and Ho
(64"). For each of the foll owing cases, wrlte an ASN.1 description for record values by sel ec:llng appropriate data
types. Start with data type Studentlnfo, I!sting Information on each student

a. A random Iist· of the students

b. An alphabetized list of students
·c, Sorted lineup ofstude.nts with increasing heigh1
d. Any one sludeot to be a class representative to Lhe faculty meeting
e. Two groups, eacb of boys and girls only

13. In Section 3.6.2, we defined the tag for Chapter-number type as APPLICATION 2. Encode this chapter (3) In TLV
format.

14. You are establlshine a small company with your network m·anage<l by a network management system. Give an
exampl e of each oft he fiVe functi onal applications that you woul d impl ement.

4. SN MPvl Network Management: Organjzation and Informa tion

Models

Objectives
? ETF SNMP standard
I o History
 o RFC, SID, and FYI
Otgiini'Uition model
o 2- and 3-~r models
o Manager and agent
Management messages
Structure of management information, SMI
Objecr type and instance
Scalar and aggregate managed.objects
Management information base, MIB
NMS pbysica I and virtual databases
fETF MJB-2 standard

SNMP management is also referred to as Intl-1'rlCt management. We have chosen to call it SNMP management
since it has mature-d to the level that it manages more than the Internet, for example. intranet and
telecommunications networks. Any nerwork thar uses TCP/IP protocol suite is an ideal candidate for SNMP
managemenL SNMP network management systems (NMSs) can manage even non-TCPIIP network elements
through proxy agents.

SNMP management is the rnost widely used NMS. Most nerwork components !hat are used in enterprise network
systems have network agents built in them that can respond 10 an SNMPNMS. Thus, if a new eomponenr, sucb as
a host. a bridge, or a router that h.as an SNMP agent built in. is added to a managed network, the NMS can
automatically start monitoring the added component. The ease of adding components and conf~guring them for
management has contributed to !he acO!ptance and popularity of the SNMP management system. To quote
Marshall Rose [Rose, 1996]. who is one of the early architects ofSNMP management, the fundamental axiom is,
''the impacl of adding network management to maMged nodes must be minimal, reflecring a lowest oommon
denomiMtor_"

SNMP management got started as an interim set of specifications. ihe ultimate standard being OSJ management.
Since !hat did not materialize, SNMP specifications were enhanced by the development ofSNMPv2 and SNMPv3.
The frrSI version of SNMP is informally referred to as SNMPvl, as it Is titled in this chapter. SNMPv2 and
SNM'Pv3 are covered in Chapters 6 and 7, respecti~-ely.

We stan by giving a real-world example of a managed nelwor.k i.n SeC! ion 4. I and show the kind of detailed
information one could gather from an NMS. We then Jearn wbat SNMP manl!gement is and bow that enables us to
obla.in that kind of information. The history of SNMP management goes back to 1970 in managing the lnternet.
lbe Internet Engineering Task Force (IE1F) bas !he responsibility to develop Internet standards including network
management standards. The. standards documents nre available free in Request for Comments documents (RFCs).
Thes.} are covered in Sections 4.2 and 4.3.

The SNMP maD!lgement model is inlroduced in Section 4_4 and addresses primarily organization, information, and
communication. An NMS comprises management process, agent prooess, and network elements. We discuss
various possible configurations in Section 4.5. There are rhree messages tmnsmitted by !he manager and rwo by !he
agent !Or a to!al offive OlCSsages. Managemenl da!a are obtained by the manager by polling the agents. Agents
respond with reqoosted clara. They also generate a few alarms when needed- llli.s simple architecture of SNMP
management is described in Section 4.6.

SNMP information model, described in Seer ion 4. 7, comprises the StruC!ure of Management uwonarion (SMI)
and !he Managemenr Information Bnse (MIB). SM'I uses ASN. I syntax ro define managed objects. SM!v I
documented !he specifications distinct from the forrnalASN.J definition as ir was then eKpected that OSJ would be
!he .fu1ure standard. However. !hat did not happea Beoee, SMiv2 merged the two parts into a concise document.
Tbe MIS defines tbe relationship between managed objec-ts and groups of related objects into MIB modules. MIB-
0 is a superset ofMIB-1 aod is used in SNMPvl.

SNMP architecture, administration, and access policies, which fall under tbe-communication model, are discussed
in the next chapter.

4. 1. Ma naged Nl•hvork: Case Histories ami Exam ples

Let us look at some of tbe real-world experiences that demonstrate the power of network management befOre
learning bow it is accomplished. As with any good technology; the power of technology could result in both
posiiive and negative results. Atomic energy is a great resource, but an atomic bomb is noll An NMS is a powerful
tool, but it could also bring your network down, when not"managed'' properly.

As part of my experience in establishing a network operations center, as weU as in teaching a network managemenl
course, we made several visits to see how various corporations and institutions manage their networks. OrJe of the
visits was to an AT&T Network Control Center, which monitored the network status of their network in the entire
eastern half of tbe United States. We could see tbe network of nodes and links on a. very large S()recn, mostly in
green indiCating that the network was funet inning well. The display screen would automatically refresh every fi:w
minutes. We saw nodes or links change colorto yellow or red. indicating a minor or major alarm. We would also
then see tbem tum back to green without interference by any human being. What we were seeing was monitoring
of a national network from a central monitoring center. Monitoring was done by the NMSs and operations support
systems wilhout any human intervention. Even tbe healing of tbe network after a failure was accomplished
automatically-self-healing network as it is called. Any persistent alarm was pursued by the control center, wh.ich
tested the network remot.ely using management tools to i.wlate and localize the t.rouble. It was an impre~sive
display of network management capability.

ln aootber visit to a major internat ional news network world headquarters. we were shown the monitoring of not
only network failures, but also tbe perfOrmance of networks around tbe _globe. Network Opemtions Center
personnel were able to look at networks in various continents separately, as well as in the global integrated
network.. The system was putting Olll not only alanns, but also the cause of the failure, which was accomplished
using artificial inl:ell igcnce built in the system.

On a more intimate level, one of the directors ofln.furmation Techno logy was narrating his experience of resolving
a network failure problem using the discovery tool that identified new componcnts in the network. A newly added
host interfa.cecard was the culprit! This was done from a network operations center, without sending an engineer to
the remote site.

There is also anotber s ide to the power of this awesome discovery tool which was an experience of another
network manager. He was once asked by one of the departments in the campus to shut off the discovery tool as it
was flooding tlte netwotk and degrading performance. Thus, power fiJI network management tools also need to be
managed to avoid degradation of network performance. There are horror stories o f the network onming down wben
turning on NMSs.

When asked what is the most benefit that he got out of an NMS, one of the managers answered that it is the
consist.eney of adminlSiering. fur e-xample. configuring tbe network. This came-across as an extremely interesting
comment to me as 1 was once involved in automating the inSinUation and maintenance of a telephone netwo.ck. One
of tbe operating telephone company .managers, who helped in specifications then, commented that what we were
trying to accomplish was an impossible task. He said that there were no standard operations procedures for tbe
company that could be automated, and even in one single operations center, no two groups were following the
same procedures! BeUcve it. or not, the project was a success.

Ler us now illu~ate what an NMS could do by monitoring a subnetwork using a commercial NMS. Tbe addresses
of network components have been intentionally modified for security reasons.
Figure 4.1 shows a managed LAN that wos discovered by an NMS. We show here only a subnetwork of a larger
network managed by the NMS. As we roentiooed above, an NMS can auromarically diswver any componenl in the
network as long as the component has a management agent. The management agent could be as simple as a TCPIIP
suite rhnt responds to a ping by !he NMS. However, agents in the modem network componenls are more
sophistica!ed. We will study bow NMS does an autodiscovery of clemems in the network in Chapter 12. Let us
accept for now thnt it hos been accomplished somehow.

flgurt 4.1. Man•ged LAN Ntlwork

~
NMS
192.168.252.110

0 ---112.U2521-- )

The managed subnetwork that we ·are discussing here is an Ethernet LAN that is shown below the backbone cloud
in Figure 4.1. It consists of a router and two hubs and is connected to !he backbone network. The LAN IP address
is 172.16.46.1, and the 1wo hub addresses have been configured as 172. 16.46.2 and 172.16.46.3. The LAN fp
address, 172.16.46.1, is the address assigned 10 the interfuce card in rhe router. Inrerfuce cards in the router Md the
iruerface card in each of the hubs are connected by a cat-5 cable !Orming the Etberoetl..AN.

The NMS, whose IP address is 192.168.252.110, is physically and logically located remotely !rom the 172.16.46.1
LAN. lt is configured on the LAN 192.168.252. 1 and is connected to the backbone network. Information system
managers csmblish conventions 10 designate a network and a subnetwork. A 0 in the ti:lurth decimal position of an
1P address designates a network, and n subnetwork is designated with a I in tbe fourth position of tbe dotted
decimal notation. Thus, 172.16.46.1 is a LAN subnetwork in the network 172.16.46.0.

Once netwo.rk components have been discovered sod mapped by the NMS, we can query and acquire infurmation
on system pammeters and statistics on the network eleroenrs. Pigure 4.2 presents system information on three
network elements in the managed L.AN gathered by the NMS sending specific queries 3Skiog for system
parameters.

l'lgw·• 4.2. System l nfonuation ,\cquir•d by Rn NMS

 Tille: Sys~em lnlorrnalion • 172 16.46 2
N.lmc CJ< II' Ad:lrG:>$. 172 16.462

Sysllh~ Name
System Oescrii>tion 3Com llnkBuik!er FMS. SW \'efSion:31l2
System Contacl
Sy&icm tocabon
Syswm Obje<;tiO • iso.org.dod.lnto<net.pnvato e.<tlliJlllSil$-43.1.8.5
Syste:n UpTII!M! (2475380437)286 days, l2:o3.24.37

(a) System Information on 172.16.46.2 Htb

Tille. System lnf'o<ma1iol 172 10 4(1 3

Name or IP Address: 172.16.48.3

S)<llornN"""'
5) stem Oescrlpllon • 3ComUnkilullde! FMS. SWversion!3.12
S)Stt!fllCmmd
S)S._ l<>c:>lion
S)~tt!fll ObjeCt 10 ISO CK!I docUntemelpriVate.e:ntOfl)tfsesA3.t JI.S
S)$11!fn Up Time . (3141UM182)l04 days. 4:!10:,UI2

(b)SY'lllm lnlonooiJOI\ on t72.16.46.3 Hub

r,:;;;:-System lniOflllllllon r011ter1 .gotedudu

I N~ or IP Adaoss 172 16 2521

r0\Aer1-Qatach edu
Cls:o ltllluwtwork ~ri~Jnv SY"'f" Son"ato;
lOS (tm) 7000 Soliware (C7000 .JS~). Version
• 11.2(6),RELEASE SOF1VIARE (gt1)
; Copyrlgl\t (c) 10a6 1007 toy CieooSyd.omo, lnc
Complied Tuo CG · IAAy •!l7 19. 11 by la.lOfl9
System ConliiCt
System LocatJOn
Sy;tem ObieciiO •S04f9.dod.llltometpnval!l.!lfltfl1PIIses cssco.clscoPIOducts
CtsC07000
System Up TirTle . {31513 \795) 36 days, 11'21:57.95

(c) System lfilormat!Oil on ROUier

Figure 4.2(a) shows that the network element is de~ignated by 172. 16.46.2. No spedfic title or name has been
assigned to it. System description indicates that it is a hub made by a 3Com vendor, with ilS model and software
version. It also gives the system object lD and how long the system has been up without failure. The format of tiJe·
System 10 follows the furmat shown in Figure 3. 10 with the 3Com node under enterprises node being 43. The la.<;t
three node numbers, 1.8.5, following43 describe the pri~ate MIB of3Com. The System Up Time indicates that the
system has been operating wit.bout fitilure for over 286 days. The number in parenthesis is i.o units of one
hundredths of a second. Thus, the hub designated by the IP address 172.16.46.2 has been up for 2,475,3 80,437
hundredths. of seconds, or for 286 days, 12 bours, 3 minutes, 24.37 se«>nds. System Description and System Object
ro are factory set and the rest are user settable.
figure 4.2(b) shows similar parameters fur the second hub, I 72..16.46.3, on the LAN. Figure 4.2{ c) presenlS system
informntion sent by the router on the network to tbe NMS' s queries. Tbe system name fur the router bas been
configured and hence the query received the responseofthe name, routerl.gatech.edu.
Figures 43(a), (b), iUld (c) present the data acquired by the NMS li"om tbe interface cards on the two hubs iUld tbe
router, wblcb are on LAN 172.16.46.1. They arc addresses associated wilh each interface. AI the top of each figure
are the titles and IP address or name of the network imerface card used by the NMS to access the network
component. Thus, in F igure 4.3(a),the title and the name or IP address are 172.16.46.2. Note that theiP address
172.16.46.3 is the addrc.ss as seen by the NMS traversing the router. ln Figure 4.3(b), the I.P address 172.16.46.3 is
the access address ofthe second hub on the 172.16.46. 1 LAN. Figure 4 .3(c) shows the title and name or IP address
ns routerl.gruch.edu. By using a network lookup command, the I.P address of router l.gruech.edu can be recognized
as 172.16.252.1. This is the backbone interface address of tile router and is tbe interface on the router as seen by
theNMS traversing the backbone network.

FlgW't 4.3. Addrt.ssts Information A<quirtd by an SN MP NMS

rruo Aaaresses 172.1& 41!2

Nl11'8 oriPAddrt.a 172. 10.482

(a) Addresses on 172.16.46.2 Hub Ports

Tille Addiesses, 172 16 46 3
Name ortP Addross 172.1o.46.3

(b) Addresses oh 172.16.46 3 Hub Ports

Syott!m ln!Oflllati¢n· rotJinrl gated> t!<lu

Tllkr
Name or IP Address 172.10 2$2 I

maex ll'ltertace IPAO<ll'e$$ Networ< M&i1< NC!!WOO< AOcteSS LIII~AOCII*SS

23 LEC I 0 192 1683 1 255 25b255.0 \92 !68 30 DxOOOOOC3920Q.I

25 LEC39 192.168 252 1 25525$.255.0 192.168.:152 0 OltOoilOOC3920SI
13 Elll&me\2,0 tn 16.46 1 255 255.265.0 tn. 16460 OxOOOOOC392CAC
10 Ethem&t213 172 10.<111. 1 255.UU65.0 172. 10 49.0 Ox()()l)()OC3920AF
17 Ellleme1.214 172 18.521 25525U55.0 172 15.52.0 OxOOOOOC3920BO
9 Elhame11Q 172.16.551 255,255.255.0 172.1655.0 OotOollOOC392QA6
2 Elhomol C/1 tn i6.56 1 25S 255 255.0 17V6560 OxOOOOOC3921)g()
15 Elhomo\212 172 16.67 1 266.26l.255.0 112 u; 57.0 OxOOOOOC3020AE
8 Elllemetl/1 172 16.5&1 255.25b 255.0 172.!8.5&0 OxOOOOOC392QA5
14 Elheme1211 172 18.60.1 255,255 255.0 172 16.60.0 DxOOOOOC3920AD

(C) .Addresses on Rolter Ports (Partial Ust)

ln Figures 4.3(a), (b), and (c), we notice thatlbere are six oohunns of data. The first column Is the index, which
identifies the row in the matrix. Ea.c h row is a collcct·ion of various addresses associated with an interface. The
second column describes tbe port id. For example, hubs I and 2 have 3Com cards in tbem. Column 2 of Figure
4.3(c) ide.ntifies the card and the pon of the interfu.ee . For example, the row wiih index 2 .identifies Ethernet 0
card/port I. The IP address of the interface card is presented in the third column oft he matrix. The IP address in
the third co lumn and the network mask address in lbe.fourth column are "illld·ed" in moduJa..2 aritbmetic to obt.aln
the network address preseoted in the fi11.h column. This implies that all packets destined fbr network address
172.16.46.0 will be accepted by bub I. The siJd.h and the las! column in Figure 4.3, the link address, contains the
MAC address. In the ftrst row of Figure 43(a). 08004E07C25C Is the MAC address of the nub I interface card.
Link addresses in the second rows of Figures 4.3(a) and (b) are presented as " none," as they are non-LAN
interfaces.

The Figure4.3(c) matri.x has m11ny ·rows, as it is a rorrter with many interfuce cards, each with multiple ports. For
example, each Ethernet card has four phys.ical ports. LEC 1.0 and LEC 3.9 are ATM LAN Emulation Card
interfaces.

4.2. H istory ofSNMJ' Ma nagement

SNMP management began in the 1970s. lni.emet Control Message Protocol (lCMP) was developed to manage
AdVIlnced Research Project Agency NETwo[k {ARPANET). It is a IDC()hanism to trnnster control messages
between nodes. A popular example oflhis is Packet Internet Groper (PING), which is pan oft he TCPIIP suite now.
We learned to use this in the exercises in Cbapter I. PING is a very simple tool that is used to investigate the health
of 11 node and tbe robustness ofcommWJication with it fio m the source node. lt Slllrted as an early form of net work-
monitoring too l.

ARPANET, which started in 1969, developed into the lntemet in the 1980s with the advent of UNIX and the
popularization of elient~rver architecture. Data were tmnsmitted in packet form usi ng routers and gateways.
TCPIIP-based networks grew rapldly, mostly In defense and academic oommunhies and in small entrepreoeurlal
companles taki11g advantage of the electron.C medium for infurmntion exchange. National Science FoWJdntion
officially dropped lhe name ARPANET in 1984 and adopted the name l,ntemet. Note duuthe Internet is spelled
with a capital I and is limited to a TCPIIP-ba\led network. An Internet Advisory Board (lAB) was formed to
administer Internet activities, which are covered in the nel\1 section.

W .ilh the growth of the Internet, it became esseruial to have the capability to remotely monitor and configure
gateways. SimpI.e Gateway Monitoring Protocol (SGM i>) wa$ developed for this purpose as 110 interim solution.
The LAB recommended the development of SNMP that is a further enhancement of SGMP. Even SNMI'
managemeDl was intended to be another interim solution, with the long-term solution being migration to the OS1
standard CMlP/CMIS. However, due to the enormous simplicity ofSNMP and its extensive implementation, it has
become the de facto standard. SNMPv2 1vas developed to make it independent of the OSL standard, as well as
adding more features. SNMPv2 bas only panlally overcome some oftbe limitations o fSNMP. The fmal version of
SNMPv2 was re.leased without ooe of its major enhancements on its security feantre due to strong differences in
opinion. SNMPv3 addresses the security feature.

4.3. In ternet Organ.izntion.s nod Stand;lrds

4.3. L. Orgaui7Jltions

We mentioned in the previous section that tbe LAB recommended the development of SNMP. The LAB was
founded in 1983 informally by researchers working on TCPIIP networks. Its name. was formally changed from the
Internet Advisory Board to the Internet Architecture Board in 1989 and was designated with the responsibility to
manage two task forces-the Internet Bngineeri11g Task Foree (IETF) and the lnteroet Research Task Foree
(IRTF).

The l.RTF is tasked to consider long-term research problem.~ in the Internet. ll creates focll~ed, long-term, and small
resem:ch groups working on iopics relnled to Internet protocols, applications, arcbitectru-e, and teohno logy.

Wilh the growth ofthe Internet, the 1ETF organization bas grown to be the protocol en~ineering. development, and
standnrdi7.ation arm of the LAB.
The Internet Net world.nfonnatlon Center (InterN!C) is an organization tbatmaintalns several archives tbat co main
documents related to the lntemel and the IETF activit.ies. They include among other documents, Request fur
Comments document (RFC), Standard RFC (STD), and For Your InfOrmation RFC (FYI). The latter two are
subseries ofRFCs (more about these in the next se<."lion).

The lnte.rnet Assigned Numbers Authority (lANA) is the central ·coordinator fur the assignment of unique
parameter values for Internet protoools. lt is the clearinghouse to ass.i.gn and coordinate use of numerous Internet
protocol par:uncters. The Internet. protocol suite contains numerous parameters, such as Internet addresses, domain
names, autonomous system nu.mbers (used in sbme routing protocols), protocol numbers, port numbers, MIB
object identifiers (including private enterprise numbers), and many others. The common use oflnternet protocols
by the Internet community requires that loose values be assigned uniquely. It is the task of lANA lo make those
unique assignments as requested and to maintain a registry of currently assigned values.

~.3.2. Internet Documen t~

Originally, RFC was just what the name implies-Request for Comments. Early RFCs were messages between
ARPANET architects about how to resolve certain problems. Over the years, RFC has become more fOrmaL ll had
reached the point that they were being cited as standards, even when they were not. To help clear up some
confusion, there are now two special subseries within too RFCs: FYis and STDs. The "For Your lnfurmation" RFC
subseries was created to document overviews and topics that are introductol)'. Frequently, FYis are created by
woups within the rETF User Services Area. The STD RFC subseries was created to identify those RFCs that do in
fact specify Internet standards. Every RFC, including FYis and STDs, has an RFC number by which they are
indexed and can be retrieved. FYls and STDs have FYI numbers and SID numbers. respectively, in addition to
RFC numbers. This makes it easier fur a new Internet user, for example, to find all of the helpful, infurmational
documents by looking fur the FYis among aU the RFCs. If an FYI or SID is revised, its.RFC number will change,
but its FYI or SID number will remain con stan! for ease of reference.

RFC documents are available in public libraries and can be accessed via tbe lnternel. Some sources that are in i!Je
public domain to access RFC and other Internet documents are:

£tp :/ /ftp . int ernic . ne t /rfc

ftp : //nic .mil / rfc
ft:p .ni c •.it
htt p : //nic.lnt ernic . net/

A novice to SNMP management eould easily be confused as to which RFC do<:ument rerers to what, namely, SMI,
MIB, and SNMP, etc. It is confusing becmtse ·the management field and associated documents are continuously
el•olving. Figure 4.4 portrays a higb-levc I view of various document paths and documents that are relevant to
SNMPvl and SNMPv2. Documents Msociaied with SNMPv3 will be described in Chapter 7. li is not intended to
be a. complete lis~ but to identify major core docwnents. There are three series ofRFC a.nd STD documems. They
arc: SMI, MIB, and SNMP Protocol. Thcte are three standard documents, STD 15, 16, and 17 d181 have been
approved by tbe lETF. STD 15/RFC 1157 defines the SNMP protocol. RFCs 1905, on protocol operations, and
1906, on transpon mappings, ore expanded updates of RFC 1157. These have been updated to RFC 1448 and RFC
1449 and subsequently, with the evolution of SNMPv3. to RFC 3416 and RFC 3417, respectively. In Figure 4.4,
RfCs in the back of the cascades are earlier ve.rsions of the draft that have become obsolcte. For example, RFC
1448 bas been replaced by RFC 1905.

Flgut•t 4.4, SNMP Do<wntul Evohniou

Structure of Management Information (SMI) forms the contents of RFC 1155, shown in Figure 4.4. A more
concise version of SMJ is given in RFC 1212 and is a supplement to RFC 1155. They both comprise STD 16
document. RFC 1155 did not address trap events, which is covered in RFC 1215.

SMI v2 is nex-t in the evolution ofSMI specifications, which are covered as STD 58 with the 'three documents RFC
2578- RFC 2580 describing SMlv2 daia definition language. teKtuaJ conventions, and conformance, respectively.

MlB has gone through a few iterations. RFC 1213/S1D 17 is the version that is currently in use. It is backward
compatible with Mm I specified in RFC 1156, which is obsolete now. Legacy systems that have implemented MLB
I can continue to be used with MIB II implementation.

SNMP protocol has gone through modification and is part ofSNMPv2. RFC 1907 is an early version ofMm 11 fOr
SNMPv2 and the .latest versi.on is RFC 34J8, which h.as gone through only minor changes from RFC 1907.

4.4. S.N.l\tP Model

We described an example of a managed networ-k in Section 4.1. We saw that numerous management functions
were accomplished in that cXllmple. We will now address how this is done in SNMP management An NMS
acquires a new .network element through a management agent or monitors lhe ones it has acquired. 11tere is a
relatioiiShip betwee.n manager and agent. Since one manager is responsible for mMaging the designated .functions
of many agents. it is hierarchicaJ in structure. The infrastructure oft.he manager-agent and the SNMP architecture
that it is based on fOrm the organization modeL

Information is transmitted and is received by boih the manager and the agent. For·example, when a new network
elemem with a built-in management agent is added to the netwodc, the discovery prooess in the network manager
broadcasts queries and receives positive response from the added element The information must he interpreted
both semantically and synta.ctically by the agent and the manager. We covered the syntax, ASN.l , in Section 3.T.
Definition ofsemanlic.s and synlllX form lhe basis of the information model. We present a detailed definition of a
managed object, rules fOr !he SMl. and a virtual information database, MJB, which groups managed objects and
provideJ> a relational framework.
Communication between the manager and agents has to happen be!Ore information can be exchanged. The TCPIIP
protocol suite is used for the transport me<: han ism. SNMP is defined for the application layer protocol and wi II be
presented in Chapter 5.

Functions and services ore not explicitly addressed in SNMP management. Security .management is covered in the
administration model as pan ofcommunication. Services are covered as pan ofSNMP operations.

lbe organization mode~ which has gone through an evolutionary process, is described in ·the next section.

4.5. Orga nization Model

The initial organization model of SNMP management is a sjmple two-tier model. It consists of a network agent
process, which resides in the managed object, and. a network manager process. which resides in the NMS and
manages the managed object. This is shown in Figure 4.S(n). Both the manager and the agem are software
modules. The agent responds to any mrutagement system thn.t communicates with it using SNMP. Thus, muhiple
managers can interact with one agent liS shown in Figure 4.5(b)

Fi~urt 4 -~· Two-TitrOrganiz:lllon Mod•l

SNMP
MAnllgor
I
SNMPAgent Noiwo!k Agorrt

Networ!l NatWUik
Etomonl £1e11'1eht
(b) Muttopla Managers-One A:lant Model

We can question the need of multiple managers in a system when il is ew.-y to monitor aU objects in a network with
standard messages. However, to configure a system in detail, more intimate know ledge oftl~e object is needed, and
hence an NMS provided by the same vendor would have more capabilities than another vendor's NMS. Thus, it is
common practice to use an NMS to monitor a net work of multiple vendor products, and several vendors' NMSs to
configure respectiv.e network elements. .Funher, during limit tracking, a vendor's NMS can probe in more depth the
source of milure-even to the level of identification of a component on a printed circuit board

1n two-tier models, the network manager receives raw data from agents and processes them. It is sometimes
beneficial for the network manager to obtain pre-processed data. For example. we may want to look at traffic
statistics, such as input and output packets per seoond, at an intermce on a node as a function oftime. Altemnrively,
we may want to get the temporal data of data tmffr: in a LAN. Instead of the network manager continuously
monit.oriog events and calculal iog the information-for example, data rate-an internll!diate agenl called Remote
Monitoring (RMON) is inserted between the managed object and the network manager. This introduces a three-tier
architecture as shown in Figure 4.6. The network manager recei.ves data from managed objects, as well as from t.be
RMON agent nboui the managed objects. The RMON function, implemented in a distributed filshion on the
network, has greatly increaSed the centralized management of·networks.

Flgurt 4.6. 'fhrtt-Titr0rgan17.otlon !\todd

A pure SNMP management system consists of SNMP agents and SNMP managers. However, an SNMP manager
can manage a network. element; which does not have an SNMP agent. Figure 4. 7 shows the organizatiooal model
for this case. This applicatK>n oaours in many situations, such as legacy systems mafll!gement; te lecommunications
management network, managing wireless networks, etc. lo aU tbese cases, tbey are part of an overaJI network that
have to be managed on an integrated basis. As an example in a legacy case, we may want to manage outside plant
and customer premises equipment fOr a Hybrid Fiber Coax (HFC) access system in broadband services to home.
Tbere are amplifiers on tbe outside cable plant, which do not have SNMP agents bllilt in tbem. The outside cable
plant uses some c~~;isting cable technology and bas monitoring tools bu ilt into it, as for example transponders that
m~ure various amplifier parameters. Information from the amplifiers could be transmitted to a central (head end)
location using telemetry fucilities. We can have a proxy server at the central location that converts datn into n set
that is SNMP compatible and communicntes with the SNMP manager.

An SNMP management system can behave as an agent as well as a manager. Tills is similar to client~rver
architecture, where a host can function as botJ1 a server and a client (see Figure 1.8). In Figure 4.6, RMON, while
collecting data .from network. objects. perlbrms some functions (network moniloring) of a oetwor.k manager.
However, pre-processed data by RMON may be re<)uested by the network manager or sent unsolicired by RMON
to the network manager to integrate with the rest of the network data 11nd to display it to the user. ln the ]utter
situation, RMON acts as a network ngenL Another example of a system acting ns both an agent nod a manager is
when two NMSs managing two autonomous networks exchange information with each other when the networks
are connected via a. gateway. This model is presented i.o Figure 4.8 and is appllcable to
t\\O relecommunicc8lioo
service providers managing ·their respective wide area networks. To provide end-to-end service to customers,
service providers may n.eed to exchange mnnage.ment information between them.

Flgurt 4.8. NMS BehO\•htg II! • M•n•e•r ond •n Agent

SNMP
Man..ger
SNMP
~ I· ·I SNMP
Agent
SNMP
Manager

t t
SNMP Agent SNMPAgeol

Network Nei\Mtrk
Element Element

4.6. System 0 \•ervicw

Now that we have learned the re.lafunsbip between tbe network (management) agent and manager and the different
ways they can be configured, let us consider SNMP management from a system poior of view. We have opted to
do this prior to discussing detail~ ofthe other three model'f--information, communicarjon, and functional, because
it wouk! help us to understand them better ifwe have the big picture first.

Figure 4.9 shows SNMP netwo rk management architecture. It portrays the data path between "the manager
application process and the agent application process via the four tmnsport function protocols-UDP, IP, Data
Link Control (DLC), and Physical (PHY). The three application layers above the transport Ioyer are integrated in
the SNMP process.

Figurr 4.9. SNMP Network Mllu~tgementArchitrctnre

 SNMP Manage· SN MP A,gent

~
.. .&mfPt.lo""!l"' SNMP~nt
,llopffcat.on J ApplcabM

§
l ..
a:
if ~
... l
~
i
a:
t
1-
i
I I
....
;
=
!
!
:c
§
!
--
~ l iS
~
~
;i ?;

~
~
i
SNMP SttMP

UOP
--- LOP

IP IP

Dl.C Cl.C

PHY PHY

As we stated in Chapter I, the.!ru.e rnet is only conte.rned with the TCPIIP swte of protocols and does not address
layers above or below it. Thus, layers I (PHY) and 2 (DLC) in the transport layers can be anytlling of users '
choice. In practice, S'NMP interfacies to the TCP/lP with UDP as lhe trnosport layer protocol.

RFC 1157 describes SNMP system architecture. It defmes SNMP " by which managemeru information for a
nenvork element may be inspected or altered by logica lly remote users." T\vO companion RFCs are RFC 1155,
which de.s(:ribes the s tructure and identification of management information, and RFC 1156, which addresses the
information base that is required for management.

lu lhe name implies, SNMP protocol has been lntentiooally designed to be simple and versatile; lhls surely has
been accomplished as indicated by its success. Communicntion of management information among management
entities is realized through exohange ofjust five. protocol messages. Three ofthese {get-request, get-next-request,
and set-request) are initiated by t.he manager application process. llle other two messages, get-response and trap,
are generated by the agent process. Message generation is called an evenL In the SNMP management scheme, the
manager monitors the network by polling lhe agents as to their status and characteristics. However, efficiency is
increased by agel.ltS generating unsolicited alarm messages. i.e., traps. We wiU summarize lhe messages here and
describe structures associated with their Packet Data Units (PDUs) later. RFC 1157 defines the original
specifications.

The get-request message is generated by the management process requesting ihe value of an object. The value o f
an object is a scalar variable. Sysiem group parameters in Figure 4.2 are single-instance values and are obtained
using the get-request message.

The get-next-request, or simply called get-next, is very similar to get-request. lo many situations, an object may
have multiple values because of multiple instances of the o bject. For eXlUDple, we saw in Figure 4.3 that an
interface could have muluple addresses associated with a given row. Another example is the routing table of a
router, wblch bas multiple values (instances) for each object. In such sirustions, get-next-request obtains the value
of the next insLanceofthe object.

The set-request is genemted by the management process to i:nitia!i1l: or reset the value of an object variable. The
configuration parameters in Figure 4.2 that are settable can be set using llle set-request message.

llte get-response message i.s generated by an agent process. It is generated only on receipt of a get-request, get-
next-request, or set.-request message from a management process. The get-response process involves filling the
value of t he requested object with any success or error message associated with the response.

The other message that the agent generates is tmp. A tmp is an unsolicited message genemted by au agent process
without any message or event arriving from the manager process. II occurs when ~ observes the occurrence of a
preset parameter in the agent module. For example. a node can send traps when an interface link goes up or down.
Or, if a network object has a threshold value set for a parameter, such as the •=~mum number of packets queued
up, a tmp could be generated and transmiued by the agent application whenever the t.hres.hold Is crossed in eitber
direction.

The SNMP manager, which resides in the NMS, bas a database thrit poUs managed objects for management daia. It
contains two sets of dat.~-one on inforllliltion about the objects, MIB, and a second on tbe values oftbe objects.
These two are often confused with each other. MlB is a.virtual data (information) base and is static. In fact. it needs
to be there wben an NMS discovers a new object in the network. It is compiled ln the manager during
Implementation. [f inforllliltion about the managed object is not in the manager, It could still detect the object but
would mark it as unidentiftable. This is b<.'Cause the <llicovery process involves a broadcast PING oommand by the
NM S and responses to it from network components. Thus, a newly added net work component would respond if it
has a TCP/IP stack that normally bas a built-in ICMP. However; the response contains only the IP address. MIB
needs to be implemented in both the manager and the agent to acquire the rest of the information, such as the
system group infurmation shown in Figure 42.

Tbe second database is dynamic and contains measured values associated with the ol)ject. This is a true database.
While· MIB has n formali;red struot·ure, the database containing actual values can be implemented using any
dat.abase at:ebiteoture chosen by the implementers.

It is won·h noting in Figure 4.9 that the SNMP manager has a database, which is the physical database, and the
SNMP agent does oot bave a physical database. However, both baveMIBs, which are compiled into tbesoftware
IDOdule and are not shown in the figure.

-t7. lnform ntiOn Mollet

The information model deals wiih SMJ and MIB, which are discussed in the foUowing subsections.

-1.7. 1. Int roduction

Figure 4.9 shows the in/Ormation exchange between the agent and the manager. In a managed network, there are
many managers and agenLs. Far information to be exchanged intelligently between manager and agent processes,
tltere has to be common understanding on both the syntax and semant·ics. The syntax used to describe lllilnagement
infbrmatio.n is ASN. l and a general introduction to it was given in Chapter 3. In this section, we will address
SNMP-specific syntax and semantics of management information.

We discussed the types of messages in tltc previous section and will discuss more in Chapter 5 when we consider
the communication model. In this section we will address the specification and organizational aspects of managed
objects. This is called the Structure of Management Information, SMI, and is defined in RFC 1155. Specifications
of mannged objects iUJd the grouping of; and relationship between, managed objects are addressed in the MIB
(RFC 1213].

There are generic objects that are defined by IETF and can be managed by any SNMP~mpatible NMS. Objects
that are defined by private vendors, iflhey conform to SMJ defined by RFC 1155 nnd MIB specified by 'R fC 12.13,
can also be managed by SNMP-oompatible NMSs. There are other RFCs tl111t address specialized network objects,
such ll'l FDDI [RFC 1285], OSPF [RFC 1253], ATM [RFC 1695], etc. Private vendor objects are specified in
private MJ.Bs provided by vendors for their specific products.

~.7.2. Structu r e of Mam•gement lnfom.:llion

A managed object can be considered to be composed of an object type and an object instnnce, as shown in Figure
4.10. SMJ is concerned only wit.h the object type nnd not the object Instance. Thill is, the object inslllnce is not
defined by SMI. For example, Figures 4.2(a) and (b) present data on two 3Com hubs. They are both identical hubs,
except for a minor software release difference. The object types associated with both hubs are represented by d1e
identical object ID. lso.org.dod.intemet.private.enterprises.43.1.8.5. Hub I with an IP address 172.16.46.2 is an
instanceofthe object

Figur• 4. tO, ManR~rd Objrcc: Tyt>• a nd ln$1an<r

Object
I I
Object
l)pe
I
I ObJect
tnsoancol
I
Name:
08JECT
Syntax: Enoocl111!l:
tO ENTIRE!\
ASN. l BER

figure 4.11 sbows the situation where there are muJtjp(e instance;; of an object type. In figures 4.2(a) and (b), hub
1 with an IP address 172.16.46.2 nnd hub 2 with an IP address 172.16.46.3 are two instances of the object.

Figure 4. tt . ~1anogrd Obj•<t: Typ• with l\lutliplt lnstanres

Name:
Sy·nux:
OBJECT
ASNl
IO£NTIFIER
A managed objet1 need not be just a network element. it could be MY object. For example, the Internet as an
orgM~iz.ation has ao object name. "internet," wit:b OBJECT JOENTIFIER 1.3.6.1. Of course, there can only be one
instance of itt Thus, a managed object is only ·a means of identifying an object, whether it is physical or abstract.

The object type, which is a data. type, has a .name, a syntax, and an encoding scheme as discussed in Section 3.7.
The name is represented uniquely by a descriptor and a.n object i.dentifier. The s~ of an object type is defined
using the abstract data structure ASN.I. Bas.icencoding ntles (BER) have been adopted as the encoding scheme for
transrer of data types between agent and manager processes, as weU as bet.ween manager processes. We will next
discuss each of these for SNMP-managed objects in detail.

Names. Every object type., i.e .• every name, is uniquely identified by a DESCRIPTOR and an associated OBJECT
IDENTIFJER. DESCRIPTOR and OB.JECf IDENTIFIER arc in uppercase s.inoe they are ASN. I keywords. The
DESCRIPTOR defining the name is mnemonic and is all in k>wercase letters-at least it begins with lowercase
letters, as we just described the Internet object as " internet." Since it is mnemonic and should be easily readable,
uppercase. letters ClUJ be used as long as they are not the beginning letter. For example. the objectJP address table is
defined as ipAddrTable. OBJECT IDENTIFIER is a unique name and number in the Management information
Tree (MI1), as we discussed in Section 3.4.1. We will henceforth use the term Managemenr tnformarlon Base
(WB) for the Internet MIT. Thus, the Internet MIB bas its OB.JECf IDEN11FIER 1.3.6.1. as shown in Figure 3.5.
It can also be defined in a hybrid mode, for example,

in t erne t OBJ~Cl' IDENTm ER : : • ( iso org (3 ) dod(6) ~ I.

Jnformation inside the curly brackets can be represented in various ways. This is shown in Figure 4.12. We can use
any combination of the unique name and the unique node number on the management tree.

Flgurt 4.t 2. OUT<rt nC Furrnais of Otclaration of OBJECT IDENTIFJER

lntomot OBJECT IDENTIFIER · " ( lso(1 ) orp(3) d«<C6) 1~tomot( 1 ) )

lntomot OBJECT IDENTIF 'ER ~: ( 1 3 6 1 )
Internet OBJECT IDEIITt<IER ;. • ( o>o "'11 dod inl<l•'hOI)
Internet OBJECT IDENTIAER :=< ( ISO 019 00<1(6) lntemot(1) )
Internet OBJECT IDENTIFIER :;: ( bo( 1) org(3) 6 1 }

Any object in the Internet MlB will start with the prefix 1.3.6.1 or imemet. For example. there are four objects
under the Internet object. These fOur objects arc defined as:

directory OBJECT IDENTIFIER : : • (internet 1)

mqmt OBJECT IDENTI FIER : :- {in ternet 2 I
ex p erimen t~l OBJECT IDE:I'lTib'IER : := {in tamet 31
private Q;;JECT .IDENTIFt.ER : : - linh xnet 4)

The first line in this example states that the object. directory, is defined as the fJISt node under the object internet.
The four subnodes under the "i nternet" node nre shown in Figure 4.13. We will discuss objects in the Mffi tree in
the next section.

Figure ~.t3 . Subnodt.! undtr t nttrnd Nod• in SNMP••I

The directol)( I) node is reserved fOr future use of OSI Directory in the lnteroet The mgmt(2) node is used to
identifY aU !E1F recommended and JAB-approved subnodes and objects. As of now the only node connected
directly to {intemet 2} is mib-2. As we said earlier, MJB-2 is a superset of MlB-1 , and hence mib·2 L~ the only
node under {mgmt} as shown below:

mib- 2 OBJECT IDE: NTI f.'IER : :• (mqmt 1 }

The experimenta1(3) node· was created to define objects under IETF experiments. For example, if lANA has
approved a number 5 for an experimenw~. we would use the OBJECT IDENTIFIER {experimental 5}.

The last node is priv ate(4). This is a heavily used node. Commercial vendors can acquire a number under
enterprises(! ), which is under the privaie(4) node.. Thus, we have

ent erprises OBJECT IDENTIFIER :: • (private 1}

or

en te:-prises OBJECT IDENTIFIER : : • (l 3 6 l 4 ll

Figure 4.14 shows an example of fOur commercial vendors-Cisco, HP. 3Com, and Cableiron who are registered
as nodes 9, II , 43 , and 52, respectively, under enterprises( I). Nod es under any of these nodes are entirely (eft to
l be discretion of the vendors.

l'igu•·• 4.14. PrlvPie Sublr<< for Co nm~tt•tial Ve ndor~

Syntax. ASN.I syntax tl111t w~ introduced in Section 3.7 is used to define the structure of object types, Nor all
constructs of ASN.I are used in TCPIIP-based SNMP management. Figure 4.15 shows the TCPIIP-bnsed ASN.I
data type. It is very similar to Figure 3.15, but only bas three categories u.n der structure.

f!lgur•·I.IS. SNMPASN.I Oata 'l'yJI<

=I 1 [...._ ,.,.,
_ ...__.

The three structural types shown in Figure 4.15 are simple. constructor, and defined types, ~ defined in RFC 1155.
Other common terms used for these are primitive (or atomic), structured, and application type.s, respectively. as
shown in Fig!Jrc 3.9. The tagged type is not explicilly used in TCPIIP maoagement, although the IMPLICIT and
EXTERNAL keywords are utilized for derived application data types.
SNMI' ASN.I dalll types are listed in Table 4.1. All data types except SEQUENCE and SEQUENCE OF are called
base types.

Tabl e 4.1. S N~fP-bostdASN.I OalllTyflt Siructurt

Strutture Dat~Type· Comments

Primitive types INTEGER Subtype INTEGER (nl.. nN)

Special case: Enumerated INTEGER type

OCTET STRING 8-blt bytes bl nary and teX\Ual data

Subtypes can be specified by either range orflxed

OBJECT IDENTIFIER 0bject position In MIB

NUll Placeholder

Defined types NetworkAddress Not used

I pAd dress Dotted declmaiiP address

Counter Wrap-around, non-negative integer, monotonically Increasing, max 2'.32 -1

Gauge Capped, non-negative Integer, Increase or decrease

nmelrcks Non-negative lntej!er In hundredths of second units

Opaque Application-wide arbitrary ASN.l syntax, double-wrapped OCTET STRING

Constructor types SEQUENCE SEQUENCE OF list maker Table maker

Primitive or simple types are atomic in nature and are: INTEGER, OCTET STRING, OBJECT IDENTIFIER, and
NULL. 11tese are also referred to as oon-aggregate types .

.INTEGER has numerous variations based on the sign, length, range. and enumeration. Tbe reader is rererred to
Perkins and McGinnis [1997) for a delllil.ed presentation on tbe subject. Wben the integer value is restricted by a
range, it is called a subtype, as presented in the comments colum.n ofTable 4. 1, as INTEGER (nl .. nN).

The data type ENUMERATED was specified in Section 3.6.2 as a special case ofiNTEGER data type. [n SNMP
management, it is specified as INTEGER data type with bbeled INTEGER values. The fOllowing elmlllple of
error-status in GetResponse associated wilb GetRequest-PDU illustrates the use of it. Each enumerated INTEGER
has a name associated W"ith it:

error- status LNT~GER

noError{O )
tooBig{l )
genEr r {S)
 a ut bor izationError(16)

Any non-zero value indicates tbe type of error enc01mtered by the agent in responding to a manager's message. As
a convention, the value 0 is oot pennitted in the response message. Thus, a.noError message ls filled wit:h NULL.

The OCTET STRING dat.a type is used to specify either binary or textual information that is 8 bits long. Just as in
INTEGER daUI. type, a subtype in OCTET STRING can be specified. ln filet, the sub~ value can either be
ranged, fixed, or u choice berwcen them. Some examples oflhe subtype a.re:

OCTt:;r STRI~ {SIZE 0 •. 255 )

OCTE:T STRING {Sl'Zfl 8)
OCTET STRTNG (SIZE ~ I 8 )
OCTET STRING {SIZE 0 .. 255 I 8)

The combinaticm keyword OBJECT IDENTIFIER, as we dlsoussed befure, is the object position in the Mill. The
fuurth primitive type listed in Table 4.1 is NULL and i.s also a keyword. SNMPvl keywords are listed in Table 4.2.

Tablt 4.2. SNMPvl Ktywonh

ACCESS

BEGIN

CHOICE

Counter

DEFINrrtONS

DEFVAl

DESCRIPTION

END

ENTERPRISE

FROM

Gauge

IDENTIFIER

IMPOR15

INDEX
TRblt 4.2. SN~1Pvl Ktywortls
ACCESS

INTEGER

lpAddress

NetworkAddress

OBJECT

OBJECT-1YPE

OCTET

OF

Opaque

REFERENCE

SEQUENCE

SIZE

STATUS

STRING

SYNTAX

TRAP-lYPE

TimeTicks

VARIABLES

The second category of da111 types shown in Figure 4.15 and Table 4.1 consists of defmed types. These are
application-specific data types, and are also SNMP-based types. They are defmed using primitive types. The
primitive types used are NetworkAddress (not used in SNMP management), lpAddress, Counter, (iauge, and
TimeTicks. The base type, Opaque. is U1lld to specifY octets of binary information. It is intended for adding new
base types to extend SNMP SMI. Other application-wide data lypes can be constructed as long as they are
IMPLICITly defined using these application data lypes.

NetwockAddress is a choice of the address of the protocol family. For us, it is the TCP/IP-base l,ntemet fiunily,
which uses the base type lpAddress.
lpAddr•ess is the conventional liJUr groupsofdoHed decimal ootationof1Pv4; for example, 190.146.252.255. 1be
32-bit string is designated as OCTET STRING of length 4 in network byt.e order.

CC!un ter is an application-wide dat.a type and is a ooo-negaiive integer. It can only increase in va.lue up to a
maximum of212- l (4,294,967.195) and then wraps around starting from 0. The counter type is useful fur defining
values of dat;ltypes that continl!liUy increase, such as input pncke.ts received on an iorerface or otdput packet errors
on an interface.

The data type Gaug_e is al5o a non-negative integer, but it:s value can move either up or down. It peg~ at its
maximum value of2'2-l (4,294,967,295), Gauge is used for data types whose value increa;;es or decreases, such as
the number of interfaces that are active in a router or hub.

TimeT icks is a ·non-negative integer and measures time in ttnits of hundredths of a second. Its value indicates in
hundredths of a second the number of unit.~ oftime between the current instant and the time it was initialized to 0.
The maximum value is zl2- l (4,294,967,295). The system up time in Figure 4.2 is an example of this.

Opaque is an appUcation-wide data type that suppons the capability to pass arbitrary ASN. I synta"' It is used io
create more data types based on previo usly defined data 1ypes. This is extensively used in private vendors defining
new data types in their products. When il is encoded, it is double wrapped, meaning the TLV (lag, length, and
value) for the new definition is wrapped a.round the TLV oftbe previously defined rype. Its size is undetined in
SNMPv J, which causes some problem in its implementation. It is limited in SNMPv2.

The Opaque data type can he defined both IMPLICITly and EXPLICITly. By use of EXTERNAL lype. encoding
other than ASN. I may be used in opaquely encoded data.

Tbe third and last type of structure shown in Figure 4. 15 is constructor or stntctured !ype. SEQUENCE and
SEQUENCE OF arc the only two constructor data lypC$ in Table 4. I that are not base types. They are used to build
lists and tables. Note that the constructs SBT and SET OF, which arc in ASN.l, are oot included in the SNMP-
based management syntaX. SEQUENCE is used to build a list and SEQUENCE OF is used to build a wble. We can
conceptualize ·the list as values in a row of a table.

The syntax for list is

SEQIJENCE t <t ypel> , < t ype2> , ,,, , <t ypeN>

wbe.re each type is one of ASN. I primitive types.

The syntax.fortabie ls

SEQUENCE Oli' <entry>

where <entry> is a list constructor.

lilustrailins of building Jist and table are shown in Figures 4. 16(a) and (b). Figure 4.16(a) shows the object
ipAddrBntry as an entry that is created fro rn a list of objects. The Ust of o~je<:ts in Figure 4. 16{a) is I through 5 in
the table . They are all basic types and each row of an object has the object name, OBJECT IDENTIFIER and
ObjectS yrrta"' For e.'Olmple, object I on row I is the lP address defmed as ipAdEnlAddr. It bas an OBJECT
IDENTIFIER {ipAddrEntry I} and synta.x lpAddress. Note thai there are two data types (ObjectSynlax) in the
table, ll8mely lpAddrcss and INTEGER. Thus, dala types CliO be mLxed in building a list. However, they are all
basic data type.s and not constntetor types.
Figurt 4.t6. Esamj>l< ufBillldiog a Lisl aud a T•blt fur • MallGg•d Object

Ob!e<:t OBJECT IDElmAER ObjoetSyntax

I lpMEnlAddr (lpAddiElllry I} lpN:Idru s
2 lpAdEn~flndOJC [lpAddrEntry 2) INTEGER
3 IPAl!EntNetl.lask (IJ)AcCUEnlry 3} lpAddross
lpJ\dEnl!lca~IAddr [lpAc!drEntry 4} INTEGER
"
5 IPAQEniReeJmMuS!te fopAddrEntry S} INTEGER
8 ~II)' flpACdrT~ 1) SEQUENCE

Ust lpAdd!Enlly .•
SEQUENCE
lpAd£lliA<Ich I~
lpA!IEn ~flndBx INTEGER
lpMEniNet~ta•k lpAddtess
lpA:ll!n II!Qo)IA<Jdr INTeGeR
lp.Adl:niReasmM;IXSWI INTEGER (0 .655351
)

(e) Managed Object lpAddrEntry as a Ust

OOJECT IDEHTIFlER

[ TB!II&: lpA<klrTabie ""

SEQUENCE OF lpAdd•Erwy )
(b) Managed Object lpAddrTable as a Table

The sixth object in the table is the object lpAddrEntry and is made up of the list of the first five objects.
Construction for that is a S.EQUENCE datn lype structure as shown. In Figure 4. 16(a). the· object
ipAdEntReasmMa.xSize has the S)nta.x INTEOER(0..65535), which denotes that it is a subtype and the integer can
ta.ke on values in the r:angc from 0 10 65535.

Figure 4.16(b) shows the seventh object, ipAddrTable. It is node 20 under ip node and has a SEQUENCE OF
construct. The ipAddrTable table is made up ofinstanoes of ipAdd.-Enuy object.

Encoding. SNMPv I has adopted BER with its TLV for enooding infonnation to be transmitted bet"'oeen agent and
manager prooesses. We covered this in Section 3.8 and iUustrated a few ASN.I datn lypes. SNMP data types and
tags are listed In Table 4.3. Encoding rules f.or various types follow.

Tobl• 4.l. SNMP Dal o Ty1><> and Togs

TYpe Tag

OBJECf IDENTIFIER UNtVERSAL6

SEQUENCE UNIVERSAL16

lpAddress APPUCA110N 0
Tablt 4.3. SN~1P D•lo T)'llfS and Ta~

Type Tag

Counter APPLICATION 1

Gauge APPliCATION 2

TimeTicks APPliCATION 3

Opaque APPLICATION 4

OBJECT IDEN1l fliER is encoded with each subidentifier value encoded as an octet and concatenated in the same
order as in the object identifier. Since a su bidentifier could be longer than an octet length, the most significant bit
(811 bit) is set to 0, lfthu subidentifier is only one o<.1et long. The 81' bit is set to l fOr the value that requires moJe
than one octet and indicates more octet(s) to follow. An exception to the rule of one or more octets fOr each
subidentifier is Lhe specification of the fll'St two s.ubideotifiers. For exiiiDple, iso( l ) and smndard(3) { l 3}, are
coded as 43 in Lhe first octet ofLhe value. As an illustration, let us consider the object identifier in/ermil { l 3 6 l }.
The first octet ofthe TLV is the UNIVERSAL 6 tag, and the second octet defines the length of·the value, which
consistsof threeoctets(43, 6, and l). T hus, the encoded format is:

00000 llO 00000011 00 l 01011 00000110 0000000 l

IP Address is encoded as straight octet strings. Counter, Gauge, and TimeTicks are coded as integers. Opaque is
OCTET STRING type.

4.7.3. i" l amlged Objects

In Chapter 3 we briefly looked at the. perspective of a managed object in an SNMP management model and
compared it to theOSl model. We will now specifY in detail the SNMP daLa type format that would serve the basis
fOr definin,g managed objects. We will address llll!nnged objects in the M)B in Section 4. 7.4.

Structure of Managed Objects. Managed object, as we saw in Section 3.4.2, bas five parameters. T hey are textual
name, syntax, definition, access. and status as defined in RFC 1155. For example, sysDescr is a data type in the
MlB that describes a system. Specifications for the object that describes a system are given in Figure 4. 17.

Figun 4.17. S1ttcification.s Jt>r Sys-ttrn De:SrriiJtion

~
S'f$0e$Cr. (system 11
SyniJ!x· Olsp1ay5lnno (SIZE {0 255))
Oofi~itoon; · A lcx~lllowlj)tcon oflho e~tbty Th1f volue
sl'ould lndudo 111e full name and ~aralon
ldonijfa.Uon ollho cy41om'e hord.,oro t)'PO,
scflwaro operatng tyS~am, aad netwo<lllng
software Ills mondalDry that this conlllln only
p<\nl<oblo ASCII chonte:lora..•
Accass: read-only
Stall.is: m!lndatory
As we notice in Figure 4. 17, the textual oome fur no object type is mnemonic and is defined as OBJECT
DESCRIPTOR. It $ unique and is made up of a printable string beginning with a lowercase teller, sysDescr, in our
example. OBJECT DESCRIPTOR defines only ihe object type, which is a data type. We will hencefurth use the
tenn objec/ rype and not data type when referring to a managed object. OBJECT DESCRIPTOR does not specify
instances of a. managed object. Thus, it describes whaJ rype of object i1 is and not the occurrence or instantiation of
ii, as we pointed out in Section 4.7.2. In Figures 4.2(a) and (b), the system description for the two hubs is 3Com
LinkBuilder FMS with an appropriate software version. They both could be of the same software version and
hence could be identical. Identification of eaob instance is left to the specific protO<:ol that is used. and is not part of
the specifiCations of either SMI or MIB. Thus, instl!llces of the two hubs in Figures 4.2(a) and (b) nre identified
with their respective IP addresses, 172.16.46.2 and 172.16.46.3.

Associated with each OBJECT DESCRIPTOR is an OBJECT IDENTlFIER. which is the unique position it
occupies in the MJB. ln Figure 4.17, sysDescr is defined.by OBJECT CDENTfFIER {system I}.

Syni3X is the ASN.l definition oft he object type. The syntax of sysDescr is OCfET STRING.

A definition is an accepted textual deseription of the object type. H is a basis for the common language or
semantics to be used by all vendors.lt is intended to avoid confusion in the excbange oLinfonnation between the
managed object and the management system, as well as between various NMSs.

Access is the speciflc8tion fOr the privilege associated with accessing tbe information. It is one of read-<~nly. read-
write, write-only, or not:aocessible. The first two choices are obvious and the third choice, not-accessible, is
applicable, fur example, in specifying a table. We access the values of the entries in the table and .not the table
it.scl£ and hence it is declared. not-accessible. The access for sysDescr is read-only. Us value is defmed by the
system vendor during the manufa.cturing process.

Status specifies whether the maooged object is current or obsolete. A managed obj ect. once defined, can only be
made obsolete and not removed or deleted. Ifit is current, the implementation of it is specified as either mandatory
or optional. Thus, the three choices for status are mandatory, optional, and obsoleie. The status for sysDescr is
mandatory.

Related objects can be grouped to furm an aggregate object type. In this case the objects that make up the
aggregate object type are called subordinate object types. llte subordinate object rype could either be si.mple
(primitive type) or an aggregate type. However, ii should eventuaUy be made up of simple object typeS.

Maeros fur Maooged Objects. In orderio encode the above infOrmation on a managed object to be processed by
machines, it has to be defined in a furmalized manner. Tit is is done using macros. Figure 4.18(a) shows a macro
whe.re an object type is represented in a furmal way [RFC 1155]. A macro always starts with tbe name of tbe
lype-in this case, OBJECT-TYPE-foUowed by the keyword MACRO. and then the definition symbol. The right
side ofthe macro definition always starts with BEGIN and ends with END.

Flgurt -'. t8. Seolar OBJECT-TYP E Macro aud EsBmplt

 OBJECi ·TYPE ~-IACRO ="
BEGIN
TYPE NOTATION ;:="SYNTAX' TYPE (TYPE ObJW.SynJaX)
'ACCESS' Access
'STATUS" Slalus
VALUE NOTIITION ·~ vahJa (VALUE ObjedN~ma)

Access : : •read -onl( l " read-wnto'l ' Nrrle-only' I "not-accessible'

Status :C' · mandatory' l ' optionar 1•obsolelo'

ta)An OBJECT·TYPt: Macro lRFC 11551

sysOescr OBJECT -TYPE

SYNTAX DISplay Stling (SIZE tO .. Zli:S))
ACCESS rea:l-orly
STATUS mondatory
DESC RIPTION
'A la~tunl do~~Crlnt<ln d r11o ontlly Thl~ Villua fihould N!clu(je tho lull
nomo ~nd v011110rllderrtofiCIIl•or~ of tho &YJtem'a nardw~ro IVPQ.
aonware oporotlng syslem. onu notwor~mg scnware II IS
mandalory that lhls r.omaln only prlnlable ASCII cneraclolll. •
::= isysUlm , )
(b) A Scalar or Single fnstence Maao: sysDescr [RFC 1213)

The body o f the macro module consisiS of three pans : lype notation, v.alue notation, and supponing productions.
lYPB NOTATION defines tbe data types in the modtdeand VALUE NOTATION defmesthe name of the object.
Thus, in the example of Figuro 4.18. Ute notations SYNTAX, ACCESS, and STATUS define the data types Object
Syntax, Access. and Status. The notation fur value specifies the Object Name. Supporting productions in Fignre
4.18 define the allowed values for access and slalus. Access can only be one of any of tbe fuur options: read-only,
read-write, write-only, or nol-ucoessible. Allowed v.alues tor Slatus are mandatory, options\ or obsolete.

Figure 4.18(b) [RFC 1213] shows the application of the macro to a scalar, single-inS11lllce managed object,
sysDescr, which is one of !he oomponents of the system group in the MIB, as we sball See in Lbe next .sect ioo.lts
OBJECT IDENTIFlCATI.O.N is {system I}. DESCRIPTION defines the textual description of the object

Aggregate Object. An aggregate object is a group of related objects. Figure 4.19 shows an example of an aggregate
managed object, ipAddrTable, wh1ch we briefly considered as an example ofSI.ruct.ured data type in Figure 4.16.
This is the IP address1able that defines the [P address for each interface ofihe managed object Objects i through 5
represent simple data types tbat make up an enuy in a table. Tbe textual name of the. entry is ipAddrBotry. Titus,
obje<:t I with the OBJECT DESCRIPTOR, ipAdEnt.Addr, is the first element of the entry, ipAddrEntry. and is
given the unique OBJECT IDBNTIFICATION , {ipAddrEntry I }. This represents tbe· IP address and has lhe syntax
IpAddress, a key,vord listed in Table 4.2. The ae<:ess privilege to it is read-only and every managed object and
management 5Ystem is required 10 implement it.

Figure ~ -19. Sptdfltallons for on Aggrtgott ~hnogcd Objet!: l t)AddrTobl <

( OfJJECr 1

s~
Dotlft!Uoft
lfMEftiAdct
-.- I bAdci£nlrl 11
.The IP acclres3 10 """"'thiS 1<1tly I 11\lormaton
OCr1.an;$•

rC3d..,..'Y
mant.alorl

(~/2)

·The-....,..., _.......,.IO<nlfiN"'"
NTESER

n:ertoce ~-,. wrt•~ The

t>t•-......

- -·
~
ncarfoce ollwniEx
,.....,.,__ .......... by ... _ _ ol..

"1!8d-<>nly
S lat.• ........-.,

"'""'"' 1 r~enuy 31
t>l\dC<OU
-n., swoo fT1M1< .UOO>Iod .,dh"" I F ' - ol

-
sw...
lbt~ry ""'""""'"'lho""'•~i&oniP»I,...,.;n,
.t4 IN NM-~ 1141 ltiiO I ...... IIW hCI&I bU.t ..110 0 "
--oriy
--...y

---•)t
~~ ,....,.,.'Enlry4)
ll,._ rtm:GER
o.r.r- ·n..-oiii'O --~~~tiC .. 1\eiP
M'dlnQesouur-on~~~e
lk>Qocllll"""'*--OIIIWIIII . . I P - a l
. _1>'For~
.hl.-.ry __ -nl\elriOinll~
.. _ , . . _ _ _ . .

I Tha•'ll... .,...lobolh 11-. 011t.ocai...O""""""

----ll'f!lllltnlrlyootr.-
~lln\ttl. . . .

- oe.'ldo0111y

~IR ~ IICIMIItE'*Y 6 )
~J ~TEGERto e:l5)
l)eh!Jon "ThoiS<le~ lllt..,...IPO.....,._- llwefticy
,.. ..-rnn ~ IP ~~ogmen~eo

.,._-....')' (~T-1

Synlal< rpAocfrEtay : seoueHce 1

rpi\C-r I~
loAdEnllnrdex INTEGER
l:tAdEniNaO.ta"' li>Ad<lress.

---
toAcfEn1Bc:>o!A46< INT'EC£R
loAd&!!Rewnl-la>cSze INTEGER 10 &5535)
DeflloiiCfl .,,.ada~.,-10f01'110ih$nt)'t . IP

~ ncl..-.oft
c-. ~
Object 2 is ipAdEntlflndex and is the second subordinate object type of ipAddrEntry. It identifies the instance of
occurrence oft he entry in the table. It references the values ofother elements associated with tbe Interface tor that
enlry occurrence. Although a sing)(,} element is adequate to uniquely identifY the occurrence of an entry in this
table, we will see later that there could be more than one element needed .in other rnbles. The syruax of
lpAdEmlfindex is INTEGER, n primitive data type. Access and stams are read-only and mandarory.

Objects 3, 4, and 5, ipAdEntNetMask, ipAdEnt&:astAddr, and ipAdEntReasmMaxSize, respectively, specify ihe

sub net mask, broadcast address inlilrmation, and the size of the largest datagram. The definition li>r each describes
what tbe.objcct is.

Object 6 is the managed object, ipAddrEntry, which consists of the subordinate object types of I to 5 above. It
describes the complete set of information consisting of the five fields needed fur an entry in the IP inter.fuce
address table. The syntax !Or ipAddrBnLry is a SEQUENCE data type consisting of t.he fiVe data types. Each data
type is i(lentified with its OBJECT DESCRIPTOR and syn111x. Note that the access for ipAddrEntry is non-
accessible. ipAddrED1ry is itself a subordinate object1ype oflhe mannged object, ipAddrTable. It is the first (and
only) element of ipAddrTable and hi!$ the OBJECT IDENTIFICATION ( ipAddrTable I}.

ipAddrTable is the OBJECT DESCRIPTOR for the lP address table, wbich bas a unique place in the M1B tree with
the OBJECT IDENTIFrER {ip 20). We will see how the managed object ip group fits in the MIB tree in the neKt
section. The syntax ofipAddrTable is lhe structure SEQUENCE OF the data type ipAddrEntry. Again, the access
is ·not-accessible-.

As an example of the use oftbe above. specifications in a table, let liS consider the ful.lowing entry in an lP add.ress
table:

OBJECT 1 (ipMEntAddr J • ( int e r net "123. 45 . 2 . 1" . )

OBJECT 2 (ipAd~ntiflndexJ = ( " 1 " J
OBJECT 3 (i pJ\d.EntNett~as k )- (internet " 255 .2.55 . 255 . 0 "
OBJECT 4 tipAdEntBca s t:AddrJ - ( •o• 1
09JECT 5 (ipAdEntReasmMaxSize) • ( " 12000" )

The value of ipAdEntlflndex for this .entry in the IP address table is equal to .l, and the lP address defming ·this
interface· is 123.45.2.1 using the lnlemet·specific protoool. The value associated with network mask is
255.255.255.0, with ipAdEnt.BcastAddr 0, and with the maximum size of the packet 12,000.

Fig1-n-e 4.20 [RFC 12 13] presents the macro fur the IP address table, a multiple-instance presented in Figure 4.17.
The text following " - " are co mments and not encoded. The module starts at the highest level defining the
ipAddrTable, then follows up with ipAddrEntry and fmally defines the subordinate object types of ipAddrEntry.
Note that there is an additiona l c lause, INDEX, in the ipAddrEntry macro in Figure 4.20. Tb..ls uniquely identifies
the instantiation of the entl)' object type in the table. Tim;, ipAdEnlAddr object uniquely identifies the
instantiation. We will discuss th5 more in the nexl section on columnar objects.

fllgu.-. 4.20. Aggngatt Msnngtd Objtcl Macro: it>AddrTsblt IR•'C 115Sl

- lhEIP-Iable
- Tht IP odole5S ""*"""""""' 1h6 ent<y'$ f' od.l""""'19 onlonrotJon
'I>Add<Tiilll<! 01!./ECT-lYPE

.ACCESS 1101---
SYNW< SEOliENCE Of li>l\ddr&try
STATUS onandal""f
llE~tPllON
1"he able orad:lres$irlg llllor!r,al#l reeanlto d1G ..~. ll' aotte5SK-
=-I'P20J
ioM<lre•ttv OBJB;f-1YPI:
SYNW<~r1
ACCJiSSooO--
STATUS '""rmtc<y
IIESCRJP110N
'The addre5S01Q intannatJ:IO 10' one oith>i em!(• £P acilresses_•
INOE;( (~rl
~t !llAd<lrTablo 11

I!IAdOrt:nuy ~
s:EOUENCE{
tpAdErAAddr
lpAdct .....
q,AdEnlllfld. .
IHTEGER
ic>A:jEntJ; etl.bll(
lj>Add<e$$
loA:IEndlc:astAOclr
IHTEGER
!pAdEntlleo._'nMn<Strlo
1Ni£GER Q .65535))
!PMEnVocldt 08JECT•lYPE
SYNTM I:>Ad<tes
ACCESS O!lldo<ri{
STATUS ...ancUICtV
OE~JPllON
"Til<! P - •..•to......, lhl~ <~~IIY·• OCI4._kl0 iiiiOfmabOn-ns •
~ ( opAddlellll'fl I
lpii<IE;ntlrlrclox OBJECT lYPii
SYNTAX INTEGER
IICCOS I'Ndenly
STATUS~
QCI)CRJMlOH
"Thtinduv~wtldlllllq,.iyldtnlifleslhellltetiacell>whi<II0.4tllllylf~ The
- - od<tntll«< lly e ~ · - ol f>••-. • _,.
u- ..._,._ •• <~<>•t•lfed by
1he - •otuo o1 ftAidl1' •
•(lfAd<llfnll) 21
II:AdEniNtl- OIIJECT-TYPE
SVNTIVC~

IICC€SS -~
STATUSro~
Ol'SCRIPlJON
"1114ts.bnet~ilssCcle1ed w.Ot 11>e IP llddreaollh'$en~~y Tl'e vollleoCillemi)$Jt ia""
tP: ~wrM- al CDe MlWOtti; bb_&elto 1 Mel ar tho~~ Wk '13\ toO •
"""# (~11)31
IP"><<Et>lllcasiM:It OB.IECT·TYPE
SVNTIVC I'ITEGER
ACCfSS ..ad-'Y
STATUS mat!d•IOIY
!!ES'cRiPllON
·~oflleieast·59>ifcoontbillnlhEIP-ilddressusedfo<oendn9daawems
oothB (~flletfacea<SQCiJiadwilhll"eiPaddressof flcsetrtry Forexsmpl!!,..,.nlhelnlatnel
01llnlard •1-oneo ~ add..,.. is'"""'
lhE v<ll<., w\1 be 1 lha valle """""' 10 l:ofl>
lhe SJbne!Jand- t><oad:asaadd:e$ses used by 11>e entliV on fills (ICgieaD InterlaCe·
~ I Or.Add!Etnry <4 I

fJ;Ac!EniRaosmNaxSlre OBJECr.NPE
SVHlM l'fl'E.GER tO .65:»5}
ACCESS --only
SlA1US~
OES<:RIPllON
'ThemtollhtlmgestiPdalilv<ill'IIWhdtlhitot>lolfc:anre~from"''''"""~IP(qg.
meritod dolliQr.ltns-., lhillll~ ·
We have so far presented the SMI as it wa~ originally developed in RFC 1155. This helped us understand the two
aspects of an object module: specifications and formal structure. Obviously, there is duplication in this. It was
originally developed this way to e\<entually migmte to OSI specifications. However, with the reality that the OSI
Slandards were not implemented and SNMP standards had been deployed extensively, the specifications and
formal Sllllct:ure were onmbined into a. concise defmitJoo of object macro, described in RFC 12J2.1L is presem.ed in
Figure 4.21.

f!lgur• -1.21 . OBJECT·'I'V r£ Mo<ro: Conci<r Dtlinlliou !RJ."C 12tll

IMPORTS
Ob,eC1Name FROM RFC 1155-SMI
O•!IOiaySUing FROM RFC 1158-MIB
OBJECT·TYPE MACRO ·•
BEGIN
TYPE N011\TIO"' ..=
- mus1 QCiftlocm to RFC 116S's ObjectSyntu
"SV1'1TAX'1Ype (lYPE ~Syn~ax)
"ACCESS" AcceS$
' STATUS" SloiU#
OMCrPart
Refarf>alt
lndt>xPart
Oe1Va1Pan
VALUE NOTATION :;: valll! (VALUE ObjedName)
Access ::= "tead«~ly' l "read-Yonie" l "wwm-«fy"l'oot-accesslble'
S latUS ·= "manaaor(' J ' OI'VO!l"r 1 ·~· raeprec:a~.eo·
OemrPart ::e 'DESCRIPTION"""""' (descnpt:Dn CispiaySirng) I empty
RelerPan :"' "REFERENCE' va\re (raft>re<!Ce Oisj>:ayS.mg)l ~
lndexPM :-:"fNoex··r lroexTypes T 18'1lll(y
lnduTwes := IndexType llodelrTypes • • IndexType
lndaxType ..:-
-lf irldexcbjed, use SYNTAX
-value olllle mn.,_lden1
-OBJECT-TYPE iniOCaliOil
value (tnllexoo,ec;t OQjec!Name)
-olherwtS!! use named SMI type
- mU!I ca>form to ~yntu Mlow
I Oype lndexT)II>IIl
OcNa!Part ·•
· oa:VAl' •r ~~... (dofvot... ~tSynuu) "I 1O<rC>1Y
END
lndexSyntex •
CHO IC~(
number INTEGER (0 .MAX),
oli"''J OCTtT STRINO,
object
oooress OBJECT iDENTIFIER
NelWOI1<AO<Jr_ _
ipAddre$$ lpl\dlllest

Note that there is the definition of imports from other modules. Also, there are additional clauses, ReferPart;
lndexPart. and Detval, and their associated value definitions. The REFERENCE clause is a textual. reference to the
document from wluch the object is being mapped. The INDEX clause is the colu01nar object ide.ntifier. wb.icb as
we said, will be discussed in lhe next section under columnar objects. DBFV AL is the defuult value to the object. lf
applicable.

Aggregate Object as Columnar Object. The aggrega1e object that was discussed above bas been formally defined as
colunmar objects in RFC 1212. SNMP o~ations apply exdusivcly to scalar operutions. This mean~ that a single
scalar value is retrieved or edited on a managed object with nny one operation. However, managed objects do have
multiple instances within a system and need to be represented formally. An aggregate object type comprises one or
more subtypes; and each subtype could have muhiple instances, with a value associated with each instance.

It is convenient to conceptnally define a tabular structure fur objects that have multiple values, such as the IP
address table. Such tables can have any number of rows including none, widt eaoh row con(!lining one or more
scalar objects. This is shown in Figure 4.22(a). Table T contains subordinale object Entry E that is a row in the
table. Since llte table Is a SEQUENCE OF construction with entry E as compoiJents, there are multiple entries in
tbe table; i.e., there are multiple rows in the table. Entry E is a SEQUENCE construct consisti11g ot:subordioote
objans, columnar objects I through 5, in Figure 4.22(a).

Figure 4.ll.. Numborlng COU\'tUIIOn or. MAnAgtd Objrcl Tobit

TABLE
T

r E.t.2 [[ T E.2.2
:l r E.3.2
Il T£4.2
II TE.52

T.E.t.3
II T.E.2.3
:I T.E.3.3
II T.E.4.3
I T.E5.3

TE.1.4
II TE.2A
II T E.3.4
II T;E.4 4
I T E.5.4

(b) wmpio ofn >Cdumnar Q)jocl"'11h 4 ln:~lml<Os !,Rows)

Figure 4.22(b) shows a five-columnar object with four instances, i.e., rou.r rows. It is importani to note the
convent ion used in denoting each o bject in the rows. The columnar objects in each row are denoted by the
concatenation ofthe object identifier of the table, the entry, and then the object, and lastly by the row number. Note
thai the last two nu..mbers fire not like w.bat we would norma Uy think of as a row and colu..mn sequence in a matrix
representation. It is more like co.lumn and row designation. Thus, the th.ird occurrence (third row) of the fourth
colu.mruu- object (fourth column) is T.E.4.3. The value ror the row number is the value of the index oft he table. For
example, ipAdEnt:Addr, which is theiP address, is the index for the rP address table example shown in Figure4.20.
Hence, the va lue of ipAdEntAddr will dete.r mine the row oftl~e table.

Let us apply this conceptual table to the rP address table example we h.a ve been following. This is shown in .Figure
4.23. Figure 4.23 (n) presents the detail of the columnar object, ipAdEntBcastAddr, which is the fuu.rth columnar
object under lpAddrEntry, which is a subordinate object of ipAddrTable. The OBIECr IDENTIFIER of the
ipAddrTable in the MlB is 1.3.6. 1.2.1.420. The ipAddrEntry is node I under it ru1d ipAdEntBcastAddr is the
fOurth node under ipAddrEntry. T hus, the columnar object identifier of ipAdEntBcastAddr is
11.3.6.1.2.1.4.20. 1.4}.

Figurt <1.23. Mulliplt-l ustauctl\1au•g•d Objtcl: ipAddJ'Toblt

I!>Ad..-Ta~(1.3.6 12.1.4.20}
lpl.~d<Efl11'( 11)
IJ)IIdEnlllddr (1)
IPI\OEnlllhoo• (21
lpl\dEniNc 1Mn1~ (3)
lpAUEn!ll<asiA1Ur jl)
lpAdEntR•asm~lll<Slze (5)

Columnarobjed 10 al ipAdcn!B<;os!AddriO (L3.6.1.2.M.20.1.4);

i>o ~dod lnte.'!lel mgmr mib ip lpl\:ldrToble l)MdrEnuy lpii:!EntBcasil\ddr

1 ' (; ! 2 t .o4 20 I A.

Row l p,AdEoiA<Idr ii>ACIEnllllrd~~ IP/I<IEntNetMool< IPAI!El>t5east tpA<!EntRe.•mt.l~•

Mur Si<C
1 123.46.~.1 1 255.255 255.0 0 12000
2 113.46.3 -~ ) 25$..25500 1 12000
3 165.8.!.25 2 2liUS525M 0 10000
4 9.96.8.U8 ~ 2S5 255255 0 0 15000

lb) Objecllnsu n<:Mof illAddrTable C1.3.B.1.2.1 .4.201

ColumoarCbiect l'lowtln (b) Dbj6Ct ldanufief

,.,....En!Ada
13 6. t 2. 1.•.20.1. 1 l (1.3.8. 1 2 I 4 20 1 1 123 •5.3 .•)
fl'AdE<JIIIncm
'3.:6.1,2. , ,... 20 12 ~ (1 3.0. 1 .2 . 1.-4.2~ 1.:!.11l!i 0.9.2!i}
ipb,dErJBca;tAdcr
1.3.8. 1.2.1.<.20.1.4 1 (1.3 e 1.2.1 4.2o 1 4.123.<5 2.11
lpACJEntR.eas.J11f!.~lCSI:te

136.12.1•.20 1.5 ~ (1 3..6.1.2 14.2!) 1.5.9 96.3 131!.\

[C) Objec1 10 fot Speo;r,. tnstooc:<!$

Figure 4.23(b) shows the tabular presentation of an JP address ~able. The table shows four rows and six columns.
Each of the four rows in the £P address table indicates a set of values assooiated with each instance of ifAddrEntry
in ·the table.

The first column in Figure 4.23(b) is the row number, which is added to the other five co lumns (co lumn 2 through
6) thar represent the five columnar objects of the IP address tabl.e. We have added the first column of the ·row
number fur e<~sy explanation only; it is not part of the managed. objects. The first columnar object ipAdEntAddr is
in bold lerters to indicate that it is the index fur the table. As each row in an aggregate object table is uniquely
identiticd by the INDEX clause of the OBJECT-TYPE macro, each row in our example is uniquely identified by
indexing the value of ipAdEntAddr. The second row is the co lumnar object ipAdEntlflndex. Note that
ipAdEntlflndex, which is the same as the itNumber. of the lnterface.s group, is not an index, but just an object
assoc iated with each row of the table. The last three columns in Figure 4.23(b) represent the columnar o bjects
ipAdEniNetMosk, ipAdEntBcastAddr, and ipAdEntReasmMaxSize.

Figure 4.23(c) shows the representation of the object identifier associated with each instance. T here are four
instances illustrated in the figure, The first column is the columnar object identifier, the second column is the row
number shown in Figure 4.23(b), and the last column is the object identifier for the instance of the columnar o bject.
Let us first look at the first row of Figure 4.23(c). We want to represent the object identifier associated with the
co lumnar o bject idAdBntAddr for the specific occurrence presented in the second row of Figure 4.23(b). The
object identifier ipAdEntAddr in the first row ofl'igure4.23(c) is its columnar o bject identifier 1.3.6.1.2. 1.4.20.1.1.
It is suffixed with the value of !.he table index field ipAdEntAddr 123.45.3.4. The resultant object identifier
1.3.6. 1.2.1.4.20. 1.1.123.45.3.4 is shown in the first row of"the last column of Figure 4.23(c).

The second entry in Figure 4.23(c) illustrates the object identifier 1.3.6. 1.2.1.4.20.1.2.165.8.9.25 for the columii1lr
object ipAdEntlflndex for the insl3nce indicated in the third row of Figure 4.23(b). The third and fourth entries in
Figure 4.23(c) illustrate the object identifier values of ipAdEntBcastAddr and ipAdEntRe<~smMaxSiz.e for rows I
and 4 of Figure 4.23(b), respectively.

The fOrmalized definitions ofSMJ as presented in STD 16/RFC 1155 are shown in Figure 4.i4.1n add.ition to the
definition of the object type macro , it also specifies the exports of names and object types, as well as the Internet
MJB, which is addressed in the next section.

Frgu o•t -'.14. SMI Ptfinlt.k>ou )RFC LIS.~)

RFC115S-sMI DEFINITIONS ~;s BEGIN
EXPORTS - EVERYTliiNG
Internet, dir@CtOfY, ITIO,L tt)q)eritnantat p""ate, e.nt.ertmses.
OBJECT-TYPE, Obje<>Nama. ObjeC!Synlox. SimpleSyn!ox,
Appllcatlof'JS.yntaiC;, Net.NQr$C;.\ckhM.s, lpAdd-ress.. Counter: G.a.a.t;e,
TiiT>!tTicl<s, Opaqce,
- lhe path to !he root
blla!nel OeJECTU)ENtlFIER .. ;( isoorg(3) d0l(5 ) I)
d1ractory OBJECT IDENilFIER ··a { ontornot 1 )
mgml OBJECT IDENTIFIER =( intomel2 I
C)(OCrirDcht.at OBJECT IOENTiriER :;- ( ln~mot 3)
pmate OBJECT IDENTIFIER ::• { tnteme14 }
enlefpn>es OBJECT IDENTIFIER ;-• { prlTote 1 I
- dettniJOn ot ob)!lCII)'JJM
OB.IECT·TYPt=lllACRO .~
BEGIN
TYPE NOTATION • • "SYNTI\X" IYI"' ('TYPE OI>JoctSynte.Q
·Access' ~ss
' S IAlUI;' SUlWS
VALUE NOTATiON cs v•lue (VALIJE Obfoc1Norra)
Access •• 'll!lld·onJy" I "!ud-write") 'Wrt~"I"1>0I·accessibla'
6 \nlua ;:• · -m"ndato;y' l 'oplion.nr 1• o~loto'"
END
- names ol Objeel$1n t~& MIB
OojecllNanle .~
OBJECT IDENTIFIER
- syolllx ol ollJoc1S 1n the MIB
Ob)O«!Syn!3X ·-.
CHOICE{
llmplo
SiMp~Syntflio( l

- Noto 1~11 otmple SEQUENCEs aro not dfootly montoonod ~ere 1o k(lql l~illll'
11~1<1 (I t provont mlsuoo) fiow~var, applia!Uan-w\do typot, which a1o IMPliC.
lrlv encodod tlll)plo SEOUENCEt. may Opi>OOt In Ul~ fOllowing CHOICE
oppiiCQt)on·mdo
Applle:$t.on~yn uu

SlmploSynthX •
CHOICE (
nurnb<lr
INTEGER
1\nng
OC1'1::TGmtNO
objecl
OBJ ECT IOENllFIER.
empty
1\'I.ILL

Applica!lo~Synutx :s
CI<OICE (
address
Netwo'I<Addt......
counter
Coonler~

9•"9•
Gauge.
bells
lime11d<S,
arbitrary
Opaque
- Chk<tr appUooJiOn•wkht types. as tkor era dQfl~ . ..,1-11 bo o6dod htto.
)
- e~pllcai.,..Nide type>
4. 7.4. M:~nagc mmt of lnfonnatiun :Bast

As stated. in Section 4. 7. I. M!B-11 specified in RFC 1213 is the current standard, STD .17. It is a superset of M!B-1
or simply MIB, as it was tben addressed in RFC 1156. We will present here MIB-II information. Both MIB-1 and
MIB-U can be implemented in SNMPvl . MIB is organized such that lmplementnlion can be done on an as-needed
basis. The entire MIB does not have to be implemented in either the manager o r the agentprocess.

Let us remember that MIB is a virtual information store (base). Managed objects are accessed via this virtual
lnfonnation base. Objecl~ In tbe MIB are defmed using ASN.I. In the previous section, we discussed the SMl,
which defines the mechanism fur describing these objects. 1lte definition consists of three components: name
(OBJECT DESCRIPTOR), syntax {ASN.I), and encoding (BBR).

Objects defined in MIB-ll have tbe OBJECT IDENTIFIER prefu::

mib-2 OBJECT I DENTIFIER : : • (mqmt 1)

MIB-11 has an additional anribure to tbe sratus of a mnn.~ged object. The o~ow tc.rm is "deprecated.". This term
mandates tbe implementation of tbe object in the current ver.s ion of MIB-!1, but is most likely to be removed in
future versions. For example, lllTnble is deprecated in MIB-11.

Object Groups. Objects thai are rc.lated nrc grouped into object groups. Notice that this grouping is different from
tbe grouping of object type.s to construct an aggregate object type. Object groups fooilitate logical assignment of
object identifiers. One of the criteria for choosing objects to be included in smndards is that it is essential filr either
fault or configuration management. Thus, if a group is implemented in a system by a vendor, all the component:s
are implemented, i.e., status is mandatory for all its component.~. FiJr example. if the External Gateway Protocol
(BOP) is implement.ed in a system, then n.ll EOP group objects are mandatory to be present.

The MJB module structure consi.sts of the module name, imports from other modules, and definitions ofthe current
module-. The· basic ASN. I stmcture is shown in figure 4.25.

Figurt 4.25. M IB Modult S tructur<

<modur. ru~mo > DEAN tnONS ;:. BEGIN

<;mpons>

ENJ

There fire II groups defined in MIB-ll. The tree structure is shown in Figure 4.26, and Table 4.4 presents the
name, objec1 identification (OIO), aod a. brief description of ea.clt group. It can be observed that these groups are
nodes under the MIB object mib-2 whose OBJECT IDENTIFIER is 1.3.6.1.2.1.

Figure -1.26. l ulem<l ~UB-11 Croup

Tabl• 4.4. ~fiB· II GrtiUI»
Group 010 Description (Brief)

system mib-2 1 System description and administrative Information

Interfaces mlb-2 2 Interfaces of the entity and associated Information

at mib-23 Address translation between IP and physical address

lp mlb-24 Information on IP protocol

temp mlb-25 Information on lCMP protocol

tcp mlb-26 Information on TCP protocol

udp mlb-2 7 Information on lJOP protocol

egp mib-2 8 Information on EGP protocol

cmot mfb-29 Placeholder for OSI protocol

transmission mlb-2 10 Placeholder for t ransmission Information

TRbl• 4.4, M IB·U Groull'J

Group OlD Description (Briel)

snmp mib·211 Information on SNMP protocol

The· System group contnins objects describing system administralbn. Tb.e interfaces group defmes interfaces of tb.e
network component and network parameters associated with each of those interfitces. The· Address translation
group is a cross-reference table between the IP address and lhe physical address.lP, JCMP, TCP, UDP, and EGP
groups are the grouping of objects assoc iated with the respe~:c.ive protocol of the system. The group, CMOT, is a
placeholder for future use of the OSI pmtoco ~ CMJP over TCPIIP. The Transmission group was created as a
placeholder lilr network transmissioD-rclaled parameters and was a placeholder in RFC 1213. Numerous
transmission systems and objects have been developed under this group since then. SNMP group is the
communication protocol group asso<:iated with SNMP management. We will now learn more about some ofthese
groups. It should be noted lhac !here are more groups defmed under the internet node, which we will address in
Chapter 5.

The following sections describe details of each group except for CMOT, transmission, and SNMP. The CMOT
group is a placeholder and is not yel dctined. l11e Transmission group is based on the transmission llll:dia
underlying each incerfnce ofthc system; the corresponding portion oft he Transmission group is mandatory fbr thai
system. The SNMP group will be addressed in Chapter S as part of the communication model.

Although there are many more groups in MIB-0 , details on only the generic groups direcUy rel.ated io physical
propen·ies of basic network elements (System and lntermces) and the managed objects associated wiih Internet
protocols (IP, TCP, and ODP) are presented here. They are intended to familiarize lhe reader quickly with how to
read and interpret RFCs specifying MIBs. lt is strongly recommended tlurt you refer to the RFC for detailed
specifications on each group and understand the structure or each MIB group.

Some a amples associated with managed objects .in the group arc presented along with a description of the group
in order to appreciate the signifiean.ce of each M18. In Chapter 9 we will learn to use the SNMP command using
SNMP tools and retrieve the values as.'IOCiated with managed objects.

System Group. The System group is the basic group in the internet scandard MIB. lts elements are probably the
most accessed managed objects. After an NMS discovers all the components in a network or newly added
components in the network, it has to obtain information on lhe system it discovered, such as system name. object
ID, etc. The NMS will initiate the get-request command on ·lhe objects in ·this group lilr this purpose. Data on the
systems shown in Figure 4.2 were obtained by the NMS using tbls group. The group also has administrative
information, such as contact person and. physicall~ation that helps a network manager.

lmplementntion of the System group is mandatory for all systems in both the agent and the manager.lt consists of
seven entities, which are presented in Figure 4.27 and Table 4.5. The vendor oft he equipment programs lhe system
description (sysDescr) and OBJECT IDENTIFIER (sysObjiD) during manufitcturing. System up time is filled in
hundredths of a second dynamically during operation. Network management systems usually conven !his into a
readable format of days, hours, and minutes in their pre.sentatioo, a.s shown in Figure 4.2. Ale hough system services
(sysServices) object is mandatory to be implemented, most NMSs do not show ihe information automatically.

Figu•·• ~27. Sysc..m Gr11up

Entity OlD Description (Brief)

sysDescr system 1 Textual description

sysObjectiD system 2 OBJECT IDENTIFIER of the entity

sysUpTime system 3 Time (In hundredths ofa second si·nce last ·reset)

sySContact system4 Contact person for the·noM

sysName system S Administrative name of the system

syslocatlon system 6 Physlcallocatlonofthe node

sysServices system 7 Value designating the layerservlces provided by the entity

loterfooes Group. The lntermces group contains managed objects associated with the interfooes of a system. If
there is more than one interface in the system, the group describes the parameters sssociated with each intermce.
For example, if an Biber net bridge has severaJ net work Interface cards, the group would cover iofurmatio n
associated with each interface. However, the Interfaces MID contains only generic parameters. In the Ethemel
example, there is more infOrmation associated with the Bthernet LAN, which is addressed in the Mill
specifications of the particular medilDn, as in Defin~ ions of Managed Objects fur the Ethernet-like I merfooe types
[RFC 2358]. An NMS would combine information obtained from various groups In presenting comprehensive data
to the user.

The lnterfaces group specifies tbe number of Interfaces in a network component and managed objects associated
wilh each inlerfu.ce. lmplemeoUition of lnterfa.ces group is mandatory for all systems. II consists of two nodes as
shown in Figure 4.28 and Table 4.6. The number of interfaces of the entity is defined by ifNumber, and the
iofurmation related to each inrerlilce is defmed in the lnterfaces 1able, iffable.
Figurt 4.28. htlerfa<e.s Grou11

~
LJU

Legend: lNOEX io bold

Table 4.6. lnter(••u Croup

Entity OlD Descrfptfon (Brfef)

lfNumber Interfaces 1 Total number of network Interfaces fn the system

ffTable Interfaces 2 Ust of entries describing information on each Interface ofthe system

ifEntry ifTable 1 An Interface entry containing objects at the subnetwork layer for a particular Interface

iflndex ffEntry 1 A unique Integer value for each Interface

lfDescr ifEntry 2 Textual data on product name and verslcm

lfType ifEntry 3 Type of interface layer bel ow the network l ayer defined as an enumerated Integer

lfMtu ifEntry4 Largest size of the datagram for the Interface

lfSpeed ifEntry 5 Current or nominal data rate for the Interface In bps
Tablt 4.6. lncuf>t<t5 Grourl

Entity OlD Description (Brief)

lfPhysAddress ifEntry 6 lnterfare's address at the protocol layer Immediatel y below the network layer

ifAdminStatus lfEntry 7 Desired status of the Interface: up, down, or testing

ifOperStatus ifEntry 8 Current operational status of the Interface

iflastchange ifEntry 9 Value ofsysUpTime atthe current operatiOnal status

iflnOctets ifEntry 10 Total number of input octets receive<!

iflnUcastPkts ifEntry 11 Number of subnetwork unicastpackets delivered to a higher-layer protocol

iflnNUcas!Pkts ifEntry 12 Number of nort-unicast packets deli vered to a higher- layer protocol

iflnOiscards i fEntry13 Number of inbound packets discarded irrespective of error status

iflnErrors lfEntry 14 Number of Inbound packets with errors

lflnUnknownProtos lfEntry 15 Number of unsupported protocol packets discarded

ifO utOctets lfEntry 16 Number of octets transmltted out ofthe Interface·

ifOutUcastPkts lfEntry 17 Total number ofunlcast packets that higher-level layer requested to be transmitted

ifOu!N UcastPkts lfEntry 18 Total number of non-unlcast paokets that higher-level layer requeste<l t\l be transmltte<l

ifOutOlscrds lfEntry 19 Number of outbound packets dlscarde<llrrespectlve of error stattJS

ifOutErrors lfEntry 20 Numb;er otoutbound pa.ckets that could not be transmitted beca.use of errors

ifOutQI.en lfEntry 21 le11gth of the output queue in packets

ifSpecific lfEntry 22 Reference to MIB definitions specific to the particular media used to realize the Interface

Each interfuce in the lnterfuces table can be visualized as being attached to eitber a subnetwork or a system. The
term subnetwork is not to be confused with the term subnet, w!Ucb refurs to an addressi11g pllrtilioning scheme in
the Internet suite of protocols. The index for the table is just one entity, specified by iflndex, as shown below in the
definition of the itEntry module under iffable.

!!Ent ry OSJeCT - rY ~ E
S'iNTl\X if'Entry
ACCESS not- accessible
STATOS manda t ory
DESCRIPTION
 " An interface e n tl:y containing o bjects at the s ubn.e twoJ:k layer and below for a
par ticular i nt er face."
INDEX {if Ind ex l
; ;- ( if T ab~ e 1}

The index is also shown in bold leitl:rs in the figure and the table.

The e ntity iiType describes the type· of daUJ link layer directly below the network la,yer. It is detined as an
enumerated integer. Examples of these are: ethemet...:smacd(7). iw88025-tokenRing(9). See RFC 1213 for the
specified type of standard interfilces.

The administrative and operational status that is indicated by object idemificrs 7 and 8 should agree with each other
when the system in\erfuce is functioning os administered.

Object identifiers 11-15 rc.fur to the measurements (with counter syntax) on inbound traffic and object identifiers
16--21 to mcasuremems on outbound tra ffic.

An example of use of l.nterfaces M1B would be to measure the incoming and the outgoing traffic rate o n a given
interface of an Etbemet hub. We can specify a port on an Ethernet net""rk interface card by the value ofillndex
and query (get-request) ihe number of input unicast packeis (iflnUcasiPkts) and Ihe· number o f output unicast
packets (i.fOutUcasi.Pids) every second. Remember thai we get the reading of two counters, which are incremented
with every packet coming in or going out of the p011 from the manage1nent agent associated with the port. We
would then take the difference in the consecutive counter reading to derive the packet rate oftraffic with time.

Interface Sublayers. One of the strengths of an lP network layer protocol is that. it is designed to run over any
network interface. lP considers any and all protocols it runs over as a single "netwo rk interface" layer. The
Interfaces group defines a generic set of managed objects such that any network imerfuce can be managed in an
interfilce-independent manner through these managed objects. The Interfaces group provides the means fOr
additional managed objects specific t·o particular types of network interface (e.g., a specific medium such as
Ethernet or Time Division Multiplex (TOM) c hannels) to be defined as extensions to ihe rnterfaces group for
media-specific l!lrul3gemenl. Since the slandardlzation of MIB-U, ma.ny suob media-specific MlB modules bave
been defmed. Concurrently, the Interfaces group bas evolved 10 accommodate the additional managed o bjects thai
need to be specified in a data link layer (DLL)-Layer 2.

DLL can 'be visualized, in general, os comprising several s ublayers. These can either be horizontally stacked or
vertically sliced (or " stacked"), as shown in Figures 4.29(a) and (b), respectively. An ex.ample oft he (ormer is an
interface with PPP running o ver a High data rate Digital Subscriber Line (HDLC) link, which uses an RS232-Iike
connector. An example oflhe latter is a cable a~ss link witb a do,llnstremn channel and several upstream
channelIs.

Flgurt .u9. l ulert"ace Subbtytr~

 Networi< lay~

Interlace Stblayer 1

Interlace Stblayer 2

ln~ce Soblayor 3

(a ) lntorfO<:<> Stackod loyoro

I -; I
I iI
I~I
I .E~ I

(b) lntO<faee Multplexe<llayers

Since the simplJstic model of a single conceptual row in r.he iffable In the lmerfaces group, an additional MIB
group, ifMJB (mib-2 31) was created. This is not shown in Figure 4 .26, which is the original MIB-11 Group. It is
shown in Figure 430. The first· subnode of lfMIB is i:IMIBObjects. There are othe.r subnodos unde-r lJMIB and the.
reader is referred to [RFC 2863] for details. Under the subnode. ifMIDObjects (ifMID I), the-re are three rabies
ifXTable (ifMlBObjec-ts 1), ifStackTable (l!MIBObjects 2), and ifRcvAddressTable (i!MlBObjecis 4). Including
the iffabie (interfaces 2), there are lilur generic Interfaces group tables under the two MIBs, interfaces and i.fMIB,
which we should be concerned wah in defin.ing managed objects in the DLL .layer. In addition to this, there are
devic~>ospecific interface MIBs. such as Ethemet-like managed objects (trnnsmiss'ion 7) that we would discuss
under each subject as we deal with them. It is worr.h noting that specifications for lJMIB have gone through a series
ofdocumentation-RFC 1229, RFC 1573, RFC 2233, and RFC :2863-cacb obsolescing the previous version.

fllgu.-. 4.30. lnttrfoct< Groups

 IIRcvAddressTable (4)

ifXTable contains objects !hat have been added to the lnt.erface MIB group as a resull of the Interface evolution
effort, or replacements for objects of the original (MIB-IT) iiTable tbat were deprecated because the semantics of
the said objects have signifi.Clllltly changed. It is an augmentation of iiTable. Flow two tables are augmented in SMI
to appear as a single table is described in Chapter 6 under SNMP2.

ifStackTable contains objects tbat define relationships among sublayersofan interface. Each sublayer is defmed as
an iffype and is represented by a conceptual row in the iffable. Because oftbe addition of such conceptual rows,
the value of iflndex is no longer canst mined. In other words, it can be stated that the index of a conceptual row no
longer has to be less than or equal to !he value of iflndex. The· upper layer in !he ifStackTable, ifStnckHigherl.ayer,
is the sublayer above the sublayer under consideration and carries the· value of the iflndex of that sublayer. If there
is no imerface sublayer above, i.e., it interfaces directly with !he network layer, then the iflndex value is zero.
Similarly, ifStaokLowerLayer is the lower interface sublayer, it has a corresponding i.flndex value ofthat row. ff it
interfaces directly with the physical medium, its value is zero.

ifRcvAddrcssTablecontains objects that are used to define media-level addresses, which !his interface will receive,
such as a port ID. This table is a generic table.

Address Translation Group. The Address Translation group consists of a table !hat converts NetworkAddress to a
physical or subnetwork address for all interfuces of the system. For example. in Ethernet the tmnslation table is
ARP cacbe. Since in MIB-U each protocol group contains its own translation table, this is not .needed and hence its
status is deprecated. It is mandatory to be implemented to be bnckward co mpatib.le with MIB-1.

fp Group. The Internet is based on fP protocol as the networking protocol This group has infom1atlon on various
parameters of the protocol. It all;o has a table that replaces the Address Tmnslation table. Routers in the network
periodically execute tbe rout.ing algorithm and update its routing table, wbich are detined as managed objects in
this group. We will discuss the contents uf this group in detail now.

1'be IP group defmes all the parnmeters needed for the node to bandle a network layer lP protocol either as a host
or as a router; implementation is mandatory. Figure 4.31 and Table 4. 7 present !he troe structure and deta.ils of the
entities, respectively. The group contains three wbles, 1P addtess wble,IP routing table. and [p Address T moslation
table.

Flgure .a.3 I. TP Crnu1)

L------1 lpOu!NoRo•loa ( I :I) 1----'

Table 4. 7. II' Group

Entity OlD Description (Brief)

ipforwarding ip 1 Node acting as a gateway or not

ipDefaultlTL ip 2 Time-to-live field of the IP header

iplnReceives ip 3 Total number of input datagramsreceived from interfaces, including those in error

lplnHdrErrors lp4 Number of dat~rams discarded due to header errors

iplnAddrErrors lp 5 Number of datagrams discarded due to address errors

lpforwOatagrams lp6 Number of Input datagrarns attempted to forward to the destination; successfully forwarded
datagrams for £ource routing

lplnUnknownProtos lp 7 Number of locally addressed datagrams received successfully but discarded due to unsupported
protocol
TRbl• 4.7. tP Go·our>

Entity OlD Desaiptlon (Brief)

lplnDiscards lp 8 Number of Input datagrams discarded with no problems (e.g. back of buffer space)

I plnOellvers tp 9 Total number of Input datagrams successfully delivered to IP user protocols

lpOutRequests ip Total number of IP datagrams that local IP user protocols suppli ed to IP

10

lpOutol.scard.s lp Number of no-error IP datagrams discarded with no problems (e.g. lack of buffer space)
u

I pOutNoRoutes ip Number of IP datagrams discarded because no route could be found to transmit them to their
12 de.stlnatlon

lpReasmTimeOut ip Ma~lmurn number of seconds that received fragments are held while they are awaiting
13 reassembly

lpReasmReqds lp Number of IP datagrams recei ved needing reassembly

14

lpReasmOKs lp Number of succes$full y reassembled datagrams

15

I pReasm Falls ip Number offallures detected by the IP reassembly algori thm (not discarded fragments)
16

lpFragOKs lp Number of successfully fragmented datagrams

17

lpFr agFails ip Number of IP datagram s not fragm ented due to "Don't Fragment Flag• set
18

tpFragCreates lp Number of datagram fragments generated as a result of fragmentation

19

lpAdddrTable ip Table of !Pad dresses

20

lpRouteTable tp IP routing table containing an entry

21

lpNetToMediaTable ip IP Address Translation table mapping IP addresses 1D physical addresses

22

lpRoutlngDiscards lp Number of routing entries discarded even though they were valid
23
We can use the lP Mm lo acquire any information associated with the lP layer. For exampl e, to Jearn the value of
the managed object, ipForward lng will indicate whether the node Is acting as ju.~t a router or a gateway between
two autonomous networks. We can measure IP datagrams received that are in eiTor, such as those wiih w rong
addresses (iplnAddrErrors).

The three tables belonging to the IP group are shown in Figure 4.32 (IP Address Table), Figure 4.33 (IP Routing
Table), and Figure 4.34 (fP Address Translation Table). Table 4.8 shows the entity ~able for the IP address tnble.
The illdex for the table, ipAdEntAddr, ls shown in bold letters.

Figurr 4.32. fP AddrrssTIIblt

opAddrfable
(lp 20)

Flgur•'i.33. JP Roodiug Tablr

Figurr-1.34. fP AddrrssTran.slaliou Tablt

 lpNetTOMe<llaPnysAG<ltoss (2) lpNetToMe<lliNl!lAddntss (3)

Tobit 4.8.1P Add.n!SS Tabl e

Entity OlD Description (,Brief)

lpAddrTable lp20 Tabl e of IP addresses

lpAddrEntry lpAddrTable 1 Ooe of the entries in the IP address !ilble

lpAdEntAddr lpAddrEntry 1 The IP address to which this entry's addressing Information pertains

lpAdEntlflndex lpAddrEntry 2 Index valve of the entry, same·as lftndex

lpAdEntNetMask lpAddrEntry 3 Subnet mask for the IP address of the entry

lpAdEntBc.astAddr lpAddrEntry4 Broadcast address indicator bit

lpAdEntReasmMa.xSize lpAddrEntry 5 Largest IP datagram that can be reassembled on this Interface

In Figure 4.23(b), we illu~ated an example of fuur instantiations (rows) associated with the 1P address table. T he
1P address table MIB shown in Figure 4.32 and Table· 4.8 is used to retrieve data from the router. It cxmld be
retr£vcd using get-request or get-next-requ(!st commands.

The IP muting table· is shown in Figure 4.33 and Table 4.9.lt contains an e ntry for each rome presently known to
the entity. Multiple route.s, up to five, to a. single destinat.loo can appear in the table, but access to such mulliple
entries is dependent o n the table-access mechanis m defined by the network management protocol. Routes are
indicated by. the entilles, ipRouteMetricN, where N is any integer from I to ·5. An entry 0.0.0.0 in ipRouteDest is
considered a default route. 'Tlte index. fbr the table is ipRo uteDest. As in llle !P address t.a.ble, the ipRoutciflnde~
has llle same value as llle iflndex o f llle InterfaCes t.able.

T able 4.9. IP Routin g T able

Entity OlD Desalptlon (Brief)

lpRouteTable lp21 tP routi~ table

Tablo 4.9.1P Rou1iog Tablt
Entity OlD Description (Brief)

lpRouteEntry lpRouteTable 1 Route to a particul ar des11nation

lpRouteDest lpRouteEntry 1 Destination IP address ofthls route

lpRoutelflndex lpRouteEntry 2 Index of Interface, same aslfln~x

lpRouteMetrlcl lpRoute Entry 3 Primary routing metric for this route

ipRouteMetrla lpRouteEntry 4 An alternative routing metric for this route

ipRouteMetrid ipRouteEntry S An al ternative routing metric for this route

ipRouteMetri~ ipRouteEntry 6 An alternative routing metric for this route

ipRouteNe>(!Hop ipRouteEntrv 7 IP address ofthe next hop

lpRouteType lpRouteEntry 8 Type of route

ipRouteProto lpRouteEntry 9 Routlrll! mechanism by which this route was l earned

lpRouteAge ipRouteEntry Number of seconds since routin,g was iast updated

10

ipRouteMask lpRouteEntry Mask to be logically ANDed with the destination address before companng with the
11 ipRouteDestfield

ipRouteMetricS ipRouteEntry An alternative metric for this route

12

ipRoutelnfo lpRouteEntry Reference to MIB definition speclflc to the routln,g protocol

13

Figure 4.34 and Table 4. 10 show the IP Address Translatio n table- It contains cross-references between I P
addresses and physical addresses, sucb as MAC address of Ethernet interface cards. ln some siruations, such as
DDN-X.25 where this relationship is algoril.hmic, this table L~ nol needed and hence luis zero entries. Indices for
!his table COO$isl of two e ntities, ipNetToMedialflndex and ipNetToMedinNelAddress. Again, the
lpNetToMedialftndex bas the same v.alueas iflnde·x. in the Interfaces group.

Tablt4.1 0. I P Addrt.ss T ranslation Tal~t

Entity 010 Desc:riptlon (Brief)

lpNetToMedlaTable ip22 Table mapping IP addresses to ph~ical addresses

TRblt 4.IO. lP AddrtSS TrAnslation Tobit

Entity OlD Desaiption (Brief)

lpNetToMedl aEntry lpNetToMedlaTable 1 IP address to physical address for the particul ar Interface

lpNetToM edialflndex lpNetToM edlaEntry 1 Interfaces on which this entry's equivalence Is effective; sam e as lflnde.x

lpNetToMedlaPhysAddress lpNetToMedlaEntry 2 Media-dependent physical address

lpNetToMedi aNetAddress (pNetToMediaEntry 3 IP address

lpNetToMedlaType lpNetToMedlaEntry 4 Type of mapping; validates with lpNetToMedlaType object

Baker [RFC 1354) has proposed on improved implementation of the IP routing table, called the IP Forwarding
Tab.le shown as an MIB tree in Figure 4.35 and rbe a.ssociatcd table in Tab.le 4.11. Tbe routing table that was
originally proposed in RFC 1213 is inconsistent with SNMP protoool in that no specific policy was defined to
choose the path among multiple choioes In ihe IP route mble. RFC 1354 has fixed lhlB deficiency. Besides, it has
added nex1 hop autonomous syslem number. nsefulro the administrarors of regional nelworks.

Figure 4.35. I P FOtWArdlng Tobit

Tobit 4.11 . IP I'OIWArdlng TAb If

Entity OlD Description (Brief)

ipForward ip24 Contains information on IP forward! ng tabl e; deprecates IP routing table

Tablo 4.ll.lP Forwardin.g TAblr
Entity 010 Description (Brief)

lpForwardN umber ipForward 1 Number of entries in the IP forward table

ipForwardTabie· ipForward 2 Routing tabie·ofthls enttty

ipForwardEntry lpForwardTable 1 A particular route to a particular destination under a particular policy

ipforwardOest lpForwardEntry 1 Oesti nation IP 'oute of this address

lpForwardMask lpForwardEntry 2 Mask to be loslc.aliy ANO.ed with the destination address before comparing wth
the lpRouteDest fleld

ipForwardPollcy lpForwardEntry 3 Set of conditions tnat selects one multipath rot~te

ipForwardNextHop lpForwardEntry4 Address ofthe next system

ipforwardlflndex lpforwardEntry S iflndex value of the Interface

ipforwardType lpForwardEntry 6 Type of route: remote, ~ocal, invalid, or otherwlse; enumerated Integer syntax

ipforwardProto lpforwardEntry 7 Routing mechanism by whi~h this route was learned

lpForwardAge lpforwardEntry 8 Number of seconds since routing was. last updated

lpforwardlnfo lpforwardEntry9 Reference to MIBdefinl:t lonspedflc to the routing protocol

lpForwardNextHopAS lpForwardEntry Autonomous system number of Next Hop

10

lpForwardMetrlcl lpForwardEntry Primary routing metrl c for this route

11

ipforwardMetricl lpForwardEntry An alternative routing metrlcfor this route

12

lpForwardMetric3 lpForwardEntry An alternative routing metric for this route

13

lpForwardMetrlc4 lpForwardEntry An alternative routing metric for this route

14

lpForwardMetrlcS lpForwardEntry An alternative routing metric for thi s route

lS
The entity ipForwnrdPolicy defmes the general set of conditio ns thm would cause the selection of one muJtipatb
route over others. Se.lections of path can be done by the protocol. If it· is not done by the protoool, it ls tbeo
specified by the IP Type-of-Service (fOS) Field, which is a part of the IP type of service field. See Baker [RFC
1354] for more details.

ICMP Group. We used the ICMP to do some of the networking exercises in Chapter I. It is part ofihe TCP/lP suite
of protocols. All parameters associated with ICMP protocol are covered. in this group.

As mentioned in Section 4.2, !CMP is a precu[sor of SNMP and npar1 of the TCP/lP suite. It ls included In MJB.. I
and MIB-11 and implementation is mandatory. 1l1e ICMP group oontains statistics on ICMP oontrol mes.;ages of
ICMP and is presented in Figure4.36 and Table 4. 12. The syntax of all entitieJ> is read-only counter. For elqlmple,
statistics on the number of ping requests (icmp echo request) se.ot might be obtained from tb.e eotmter reading of
icmpOutEchoes.

Figut.. 4.36. ICMI' Group

TRbl• 4. tl. ICMP Groutl

Entity OlD Description (Brief)

lcmptnMsgs lcmp 1 Total number of ICMP messases received by the entity lndudll'lfllcmplnErrors

Iem plnErrors icmp 2 Number of messages received by the entity with ICMP-speciflc errors

icmplnDestUnreachs icmp 3 Number of ICMP Destination Unreachable messages received

icmplnTimeExals icmp 4 Number ofiCMPTime Exceeded messases rea.ived

icm plnParmProbs icmp 5 Number of ICMP Parameter Problem messases rece lved

icmptnSrcQuenches icmp 6 Number of ICMP Source Quench messages received

Tablt 4.12. I CMP Croup

Entity OlD Description (Brief)

icmplnRedirecls i cmp 7 Number ofiCMP Redirect messages received

icmplnEchos icmp 8 NumberofiCMP Echo (request) messages received

kmp lnEchoReps lcmp 9 Number of ICMP Echo Reply messages received

lcmpln1i mestamps i cmp 10 Number of ICMP 1i mestamp (request) messages received

icmplnTimestampReps icmp 11 Number of ICMP Timestamp Reply messages received

icmplnAddrMasks icmp 12 Number of ICMP Address Mask Request messages received

icmplnAddrMaskReps icmp 13 Number of ICMP Address Mask Reply messages received

icmpOutMsgs lcrnp 14 Total number ofiCMP messages attempted to be sent by this enUty

lcmpOutErrors i crnp 15 Number of good ICMP messages not sent, does not Include the ones with errors

lcmpOutDestUnreachs lonp 16 Number of ICMp Destination Unreachable messages sent

lcmpOutTimeEl<cds lcmp17 Number of ICMP lime Exceeded messages sent

lcmpOutParmProbs lcmp18 Number of ICMP Parameter Problem messages sent

lcmpOutSn:Quenchs lcmp19 Number of ICM P Source Quench messages sent

lcmpOutRedlrects lcmp20 Number of ICMP Redirect messages.sent

lcmpOutEchos lcmp21 Numb:er of ICM P Echo (request) messages sent

lcmpOutEchoReps lcmp22 Number of ICM P Echo Reply messages sent

lonp0ut11mestam ps lcmp23 NumberofiCMP11mestamp (request) messages sent

lcmpOutTimestampReps icmp24 Number of ICM P 11mestamp Reply messages sent

ltmpOutAddrMasks lcmp 25 Number ofiCMPAddress Mask Request messages rent

icmpOutAddrMaskReps icmp 26 Number of ICMP Address Mask Reply messages sent

TCP Group. The transpon layer of the l,nten~et defines Transmission Control Protocol (TCP) fOr a connection-
oriemed circuit and User Datagram Protocol (UDP) for a connectlooless circuit. We will describe the TCP group in
this section and UDP in the next subsection.

The TCP group contains entities that are associated with tbe connection-oriented TCP. They are present only as
long as the particular connection persists. It is mandatory to implement this group. The entities rue shown in Figure
4.37 and Table 4.13. It contains one table, the TCP connection table. which is presented in Figure 4.38 and Table
4.14. The table eo11y has four indices to uniquely define it io the table. They are: tcpConnLocaiAddress,
t.cpConoLocaiPor~ tcpConnRemAddrcss, and tcpCollllRemPort and are identified in boldfaee. One may obtain all
TCP aeli ve sessions from this table with addresses and ports of local and remote entities.

Figurr -1.37. TCI' Grout>

Table 4.1 J. TCP Grout>

Entity OlD Description (Brief)

tq~RtoAigorlthm tcpl n meout algortthm for retransmission of octets

tcpRtoMin tcp2 Ml nlmum value for timeout In milliseconds for retransm l.ssion

tc.pRtoMax tcp3 Maximum value for timeout in milliseconds retransmission

tc.pMaxConJl tcp4 Maxi mum number ofTCP conJlections

tcpActlveOpeJlS tcp5 Number of active connections made CLOSED to SYN-SENT state

tcpPasslveOpens tcp6 Number of passive connections made LISTEN to SYN·RCVD state

tcpAttem ptFalls tcp 7 Number of failed attempts to make connection

tcpEstabResets tcp8 Number of resets done to either CLOSED or LISTEN state

Tablt 4.13. TCP Grourl
Entity 010 Description (Brief)

tcpCurrEstab tcp 9 Number of connections for which the current state Is either ESTABUSHED or CLOSED· WAIT

tcplnSegs tcp 10 Total numberofsegmentsr~el v~ Including with errors

tcpOutSegs tcp 11 Total number of segments sent excludl~ retransmission

tcpRetransSegs tcp 12 Total number of segments retransmitted

tcpConnTable tcp 13 TCO connection table

tcplnErrs tcp 14 Total number of segments received in error

tcpOutRsts tcp lS Numberofsegmentsentcontaining RSTflag

Agurt 4.38. T CP Conntclion Tobl<

tCI)ConnTable
(top 13)

Tablt 4.14. TCP C ~nntdion Tabl<

Entity 010 Description (Brief)

tcpConnTable tcpU TCO connection table

tcpconnEntry TcpConnTable 1 Information about a partlo:ularTCP connection

tcpConnState TcpConnEntry 1 Stille of the TCP connection

tcpConnlocaiAddress TcpConnEntry 2 !Dcai iP address

tcpConnloc:aiPort TcpConnEntry 3 !Deal port number

TAble 4. 14. TC P Connection Tobit

Entity OlD Description (Brief}

tcpConnRemAddress TcpConnEntry 4 Remote IP address

tcpConnRemPort TcpConnEntry 5 Remote port number

UDP Group. The UDP group oontahJS infOrmation associated with the connectionless transport protocol. Its
implemenllltion is mandatory. Figure 439 and Table 4.15 present the UDP group tree structure 11nd entities,
respectively. The group contains a UDP lislener mble, shown as part of Figure 4.39 and Table 4. 15. The table
contnins information about the entity's UDP end-points on which a local application is currently accepting
datagr:ams. Indices for tbe mble entry are udpLoea iAddress and tKipLoeaiPon, and are indicated in bold letters.

l'igu•·• 4.39. liDP Cruup

Table4.15. UDPGrnup
Entity OlD Description (Brief)

udplnDatagrams udp 1 Total number of damgramsnallvered to the users

udpNoPorts udp 2 Total number of received datagrams for which there is no application

udplnErrors udp3 Number of received datagrams with errors

udpOutDatagrams udp4 Total number of datagrams sent

udpTable udpS UDP listener table

udpEntry udpTable 1 Information about a particular connection or UDP listener

Tablt 4.15. UDP Cn>llfl
Entity OlD Description (Brief)

udplocaiAddress udpEntry 1 locaiiP address

udplocaiPort udpEntry 2 local UDP port

Summnry

We have learned the basic functions of SNMP management in this chapter. Advnnoed function~ are covered in the
next chapter. The subject mnner included in this chapter has been approved as a standard by IETF aod
implemented by most vendors.

We briefly learned the historical developmentofSNMP staoda.rds and documents. They grew more out of practical
necessity than the need fo.r setting st;lndards. The lntemet Engineering Task Force is the standards organi1Jltion and
RFG, STD, andFYlare IETF documenls on standards development.

SNMP management is organized as two-tier management, in which a mllllllger process and an agent process
communicate with each other. The agent process resides in the 11etwork element. The manager process is buik in
lletwork management stations. The agent process does not perfOrm any analysis, which is done in the manager. 11te
two-tier stnrcture can be extended to three-tier by saodwiching a proxy agent, or RMON, between the manager and
the agent.

All mMagement opernLions are done using five messages in SNMPvl. which is the current standard. They are get-
request, get-next, set-request, get-response. and trap. The first three are sent from the manager to the agent, and the
last two are sent by the agent to lbe manager.

Messages are exchanged according to specifications defined in the Stnrcture ofManagement lnfurmalion (SMI ). It
is composed of name, syntax, aod enCI)ding rules. Tbe name is a unique name for the managed object and no
associated unique object identifier. The syntax uses Abstract Syntax Notation I (ASN.I) language. Encoding is
done using basic encoding nrles (BER).

Objects or eollties can be composed of other scalar objects. Mult4>1e instances of a managed object. such as the rP
address table, are handled by defining tables and columnar objects in the table. Managed objects are organized in a
virtual database, called the Management Information Base (MIS). It is distinct from the management database thai
contains values for managed objects. Managed objects are grouped in the MIB occording to their function. MIB-11,
which is a superset ofMm-1. consists of II groups. Several groups have s ince been added to the MIB, although
they have not been approved as a standard.

Exe rcises

1. Refer to Figure 4.3 to answer the foil owl~ questions:

a.. What are the classes of networks shown in Figure 4.3(a)?

b. Explain the function of a network mask.
c. In Figure 4.3(c), network addresses 172.16x.O are subnets derived from the network address
172.160.0. Explain .bow IP address bits are split between subnet and host addresses.
2. Access Simple Gateway Monitoring Protocol (SGMP) RFC 1028 on the Internet. Describe the·four message types
defined In the document. (You do not nave to present the str&.~ctl.lre of the message.)

3. Present OBJECT IDENTIFIER for the object sun. products In two different formats, one In all mnemonic and the
other In all numertc.

4. Represent the objects as ORJECT IDENTIFIERs starting from the root for the three network components In figure
4.2.

a. Hub in Figure 4.2{a) in hybrid format

b. Hub in Figure 4.2(b) in numer-ic rormat
c. Router in Figure 4.2(c) in hybrid rormat

s. Encode IP Address 10.2030.40 In TLV formaL

6. Refer to RFC 1213 for the foll owing exercise:

a. Write the ASN.I speci.fications fOr sysServices.

b. J]lustrotc the specifications with values for a bridge.
c. lUustrote the specifications with values for a router.

7. Write the object DESCRIPTOR and synt.ax of the foll owing SNMP martaged entitles:

a. IP address 125.52.66.24
b. A row in the lnterfaces table (the row specificat·ions only, not the objects in the row)
c. MAC address of an interfucc card

8. In Exercise 4 of Chapter 1, you measured the percent packet loss using Ping tool, which depends on tne ICMP
group. Name the MIB objects that are used In the procedure and present the macros for the OBJECT TYPE.

9. Explain how you would determine whether a device is acting as a host cir as a router uslnganSNMP command.

10. Refer to the IP Address Translation table shown In Figure 4.34 and Table 4.10, as well as the numbering
convention shown In Flgure4.22 to answer the following questions:

a. List t.he columnar objects under ipNetToMed.iiEntry.

b. Draw an object instance table for ipNetToMediaTable as in Figure 4.23(b) without the row
column. Fill three rows of data using MJB specifiCations.
c. Redraw the table in (b), now filling each cell in the table with an object instance identifier. Use N
= 1.3.6.1.2.1.4.22.1 tor ipNeiToMediaEntry in the table.

11. You own a specialty company, ABC (Atl anta Braves Company), whl,n sell s hats and jackets. You obtained an
OBJECT IDENTIFIER 5000 under enterprises node from lANA. You have two branch loe<~dons. Each has an
Inventory system that can be accessed by the tP address; wnlcn have the following ORJECT DESCRIPTORS:

br a nch.l - 100. 100 . 100 . 15

 b ra ncll2 - 100 . tOO . 1 00 . 16

Each branch has two types of produc1s whose irwen tory are

ha:t s
j a.o ket s

HaiS are all ofthe same si2e and the inventory is a scalar value, batQunntlty.

JackeiS come in different sizes and the inventory is maintained in a table, jacket'rable, whose columnar
objects are

jacketsize \index )
j acket Quantity

Create a MlB module for your company. Tire ohjeclive is to find the inventory o f any specific product
while sitting in your office as presidem of the company.

a. Dmw a MIB subtree.

b. Write a MIS module.

12. A network manager dlscovetS th<rt a network romponent Is performing poorl y and Issues an order t\l the
technician to replace it. Which MIB group contalrt$ this Information for the technician to find out the physl~l
loe<~tion of the w mponent?

13. How would you use one of the standard MIB objects to determine· which one of the stations in a IAN Is
functioning as a bridge to the external network?

14. TCP Is a connection-oriented protocol and UOP Is a ronnectionless protorol. Identify differences in the two MIBs
that exemplify this difference.

15. What OBJECT TYPE would you use to Identify the address of the neighboring gateway from your local gateway?

16. rr
An m anager gets complaints from users that there Is excessive delay In response aver the Ethernet IAN. The
manager suspectS that the cause of the p'oblem Is excessive collisions on the IAN. She gathe•s statistics on
collisions using the dot3StatsTable and localizes the pr obl em to a single faulty network Interface card. Explain
how she loc;,rllzed the probl em. You may use RFC 2358 t o answer t hi s exerr.ise.

17. FDDi ls heavily used as a backbone network Ina corporate com plex.

a. Draw a MlB tree for FOOl MJB. Limit your tree to the top five groups.
b. Develop a three-column table presenting entity, OID, and brief descriptions of tJre groups and
tables under each group.

18. Two new managed objects, ifNam e and lfAII as were Introduced In lfM lB m odule. Explain the purpose· of these
 r>ew managed objects In r>etwork management and give an eKample for each case.

19. Il lustrate (a) the PPP <Wer HDCL and (b) the cable aa:ess link with one downstream and two upstream cllallnels
using the Interface subfayers shown In Figure 4.29.

5. SNMPv l Network Management: Communjcation and FunctionaJ

Models

Objectives
Communication model: AdmlnisiTOtive and messages
Administrative structure
o Community-based model
o Access policy
o MIBview
MessagePDU
SNMP protoool specifications
SNMP operations
SNMPMIB
SNMP functional model

We have covered the organization and infOrmation models ofSNMPvl in the previous chapter. In thL~ chapter we
will address the SNMPv I communication and functional models. Although SNMPvl does not rormally define the
functional mode~ applications are buih in the community·based access po.licy of the SNMP administrative model

5.1 . SNM P Com mun ication Model

The SNMPv I communication model def'mes specifications of four aspe<;IS of SNMP communication: archite<;ture,
admlnisiTOtive model that defmes data aocess policy, SNMP protoco~ and SNMP MIB. Security in SNMP is
managed by defining community, and only members belonging to the same community can communicate with
each other. A manager can belong to multiple communities and can thus manage multiple domains. SNMP
protocol. specifications and me.ssages are presented. SNMP·entitie·s are grouped into an SNMP M!B modul.e.

5.1.1. SNM I> Arcbii~'Ciure

The SNMP arcbilectural model consisiS o f a collection of network management Slat ions and network clements or
objects. Net'Mlrk elements have management agents buih in them, if they are managed elements. The SNMP
communications protocol is used to communicate· iorormaHJD between network management stations and
management agents in the elemenl~.

There are three goals of the architecture in the original spe<;ifieatK>ns of SNMP [RPC I 157]. First, it should
minimize the number and co mple!Uty of management functions realized by the muna&remenl agent. Secondly, it
should be flexible· for future expansion (addltioo of oew aspects of operation and management). Lastly, the
architecture should be independent ofarchi1eeture and mechanisms of particular hosts and gateways.
Only non-aggregate objeciS are communicated using SNMP. The aggregate objects are communicated as instances
of the object. This has been enhan.ced in SNMPv2, as we. shall see in the nexl chapter. Consistent with the rest of
SNM'P standards, ASN. I transfer syntax and BER encoding scheme are used for data transfer SNMJ>.

SNMP monitors lhc netwock with the five messages shown in Figure 4.9; and we discussed them in Section 4.6:
They comprise three basic messages; set, get, and trap. ln!Qnnation aboutlhe network is primarily obtained by the
management stations polling the agent~. The get-request and get-next-request messages are generated by the
manager to retrieve data from network eleme.nts using associated management agents. The set-request is used to
initialize· and edit net\vork clemeru parameters. The gel-response-request is the response froru lbc agent to get nnd
set messages from the manager. The number of unsolicited messages in the fonn of traps is limited to make the
arcbitecture simple and to minimize traffic.

There are three types of traps-generic-trap, specific-trap, a.nd time-stamp.• which are application speci.fic. The
generic-trap type consists of coldS tan, warmStan, liokDown, linkUp, authenticationFallure, egpNeighborLoss, and
enterpriseSpeci.fic. The specific-trap is a specific code and is generated even when an emerpriscSpeci.fic tmp is not
presem. An example of this would be to gather statistics whenever a particular event occurs, such as usc by a
particular group. The time-stamp trap is the time elapsed between the last initialization or re-initiali:mtion of the
element and the generation of the trap.

SNMP me.ssages are exchanged using a coonectionless UDP transport. protocol in order to be consiste.nt with
simplicity of the model, as well as to reduce traffic. However. the mechanisms of SNMP are suitable for a variety
of protocols.

5..1.2. Adminlst nu ive Model

Although the topic of administrative models should normaUy be discussed as part. of security nod privacy under the
functional mode~ at this point it helps to understand the administrative relationship among entities that participate
in the communication protocol in SNMJ>. Hence, we will discuss it now.

In RFC .1.157 the entities residing in management stations and networlt elements are calJed SNMP applicatio n
entities. Peer processes, which implement· SNMP, and thus support. SNMP application entities, are tenned protocol
entities. We will soon discuss protocol entities in detail. First. let us look at the application entities.

We will refur to the application entity residing in the roanagement station as the SNMP manager, and the
application entity in the element as the SNM'P agent The pairing of lhe two entities is called.an SNMP community.
The SNMP community name, called tbe community, is specified by a string of octets. Multiple pait:S can belong to
the same community. Figure 5.1 shows multiple SNMP managers communicating with a single SNMP agent.
While an SNMP manager is monitoring traffic on an element, another manager may be configuring some
administrative infonnation on it. A third mnoager can be monitoring it to perform so.me statistical s tudy. We also
have the analogous s.ituatioo where a manager communicates with multiple agents.

Figurt S.t. SNMP Community

With one-to-many, many-to-one, and many-to-many communication links between managers and agents, a basic
authenti:ation scheme and an access policy have been specified in SNMP. Figure 5.1 shows the authentication
scheme, which is a filler module in the manager and the agent The s implest form of authentication is the common
community name between tbe two application entities. Encryption would be a h.igher level of autbenticalion in
which case both the sou~e and the receiver know the common encryption and decryption aJgoritluns.

The SNMP authorization is implemented as part of managed object MfB specifications. We discussed MlB
specilications for mnnaged objects in Chapter 4, and will discuss MIB specificailins fur SNMP protocol in Section
5.1.4. A network element comprises many managed objects-both standard and private. However, a management
agent may be permitted. to view only a subset of the network element' s managed objects. This is caUed the
community MIB view. In Figure 5.2 the SNMP agent has a MIB view ofobjecrs 2, 3, and 4, although there may be
other objects asSociated with a network element In addition to tJIC MIB view, each commun ity name is also
assigned an SNMP access mode, either R6AD-ONL Y or READ-WRJTE, as shown in Figure 5.2. A pairing of
SNMP MIB views with an SNMP access code is called a community profile.

Flaur e 5.2. SNMP Communlly Profile

=
SNW'Agent

~~ I 1 ~Mi' Ac<assMooe
t t t t
no~ll* «YCk)CCy ............~y I ,_.0
Objoct I Objod2 ~, I at~·

A community profde in combination with the access mode of a managed object detennines the operation that can
be performed on ti!C object by an agent For example, in Figure 5.2. an SNMP agent with READ- WRJTE SNMP
access mode. can perfurm all operations-get, set, and trap-en objecrs 2, 3, and 4. On the other hand, if the SNMP
agent has READ-ONLY access mode privilege, it can only perform get and trap operations on objects 2, 3, and 4.
Object I has a "not-,accessible" access mode and hence no operation can be performed on it.

Tbere ore fuur access modes shown in Figure 5.2. 1ltey ·are not-accessible, read-{)nly, write-only, and read-write.
The tables are examples of no-acoess mode. One can only access scalar objecl~ associated with the entitles under
tbe table. Most objects availab le for the public community are read-only, such as the interface statistics and the IP
table in a router. These are the get and trap operations. Jf the access mode is defined as read-write, that operand is
available for all three operations of get, set, and trap. An example of read-write access is sysContact in the system
group. 1lte write-only access mode Is used to set the operand value of a get Mm object by the network manager,
for example sysDescr in the system group. This Is done in network management systems as Implementation-
specific.

We can now define an SNMP access policy in SNMP management. A pairing of an SNMP community with an
SNMP community profile is defined as an SNMP access policy. This defines lhe administrative model ofSNMP
managemenL Figure 5.3 shows an example of three network management systems in three network operation
centers (NOC) having different access to different community domains. Agents I and 2 belong to Community I.
However, they do have two different community profiles, community profile,s I and 2. Manager I, which is part of
Community I, can communicate with both Agents I and 2. However, it cannot communicate with Agents 3 and 4
belonging to Community 2. Manager 2 has nccess to them as it also belongs to Community 2. Agent 3 has
community profile 3 and Ageot4 bas community profile 4. Manager 3 has access to both Community I and 2 and
hence can communicate with alithe agents. We can picture an enterprise network management fitting this scenario.
If a corporution has two operations in two cities, Manager I in NOC I and Manager 2 in NOC 2 are responsible for
managing their re·spective domains. A top view of the overaU operations can be viewed and managed by NOC 3 in
the headquarters operation.

flgur t S.J. SNMP Acct"' Polity

A practical application of tbe SNMP access policy can be envisioned in an enterprise management system of a
corporation with l~e.,dquarters in New York and domains or network sires in New York and San Francisco. Let
Manager I and Communily 1 be associated with San Francisco, and Manager 2 and Community 2 with New York.
Let Manager 3 be the overalluetwork management system, the·Manager of Managers (MoM). Manager I manages
Agents I and 2 assooiated with network elements in San Fmncisoo. Manager 2 manages the New York network
domain. Manager I does not have the view of New York and Manager 2 cannot perform operations on network
elements belonging to the San Francisco domain. Manager 3 bas both community names defined in its profile and
hence bas the view of the total e.nterprise network in New York and San Francisco.

The SNMP access policy bas far-reaching consequences beyond that of servicing a TCPIIP-based l:nternet SNMP
community. It can be extended to managing non-SNMP communit.y using the SNMP proxy access policy. The
SNMP agent associated with the proxy policy is called a proxy agent or commercially, a proxy server. The proxy
agent monitors a non-SNMP community with non-SNMP agents and then converts objects and data io SNMP-
compalible objects and data to reed 10 an SNMP manager.

Figure 5.4 shows an illustmiion of SNMP and non-SNMP oommunities being managed by an SNMP mnnager. A
practi:al example of this would ben network of LAN and WAN. LAN could be a TCPIIP network with SNMP
ageoiS. WAN could be an X.25 nel\vork, whlc.b is not an fntemet model, but can be managed by a proxy agent and
integrated into the overall management system.

Flgul'f .S.4. SN Ml' Pmxy Atcts..~ Polk!)1

5..1.3. SNMP l' rotocol Spcci!iClltions

Peer processes, which implement SNMP, and thus support SNMP application entities, are 'termed protocol entities.
Communication among protocol entities is accomplished using messages encapsulated in a UDP datagram. An
SNMP message consists of a version identifier, an SNMP communi1y name, and a protocol data unit (PDU). Figure
5.5 shows the encapsulated SNMP message. The verllion and community names are added to the datn PDU and
along with tbe application header is passed on to tbe iransport layer as SNMP PDU. The UDP header is added at
'the transport layer, which then fOrms the transport PDU for the network layer. The addition ofthe IP header to the
Transport PDU fOrms the Network PDU fur the data. link layer (DLC) . The network or DLC header is !!dded before
the frame is transmitted on to the physical medium.

Figure S.S. Encllt>SUIAted SNMP Mr.ssog~

DalaPOU

Applcatoon POU

TI8!\SpOfl POU
Aflplieallon PDU

1 ~1
Data llr* POU Ntr.o.o<kPOU

An SNMP protocol entity is received on port 161 on the hoste.xcept fur trap, which is received on port 162. The
maximum length of the protocol in SNMPv I is 484 byles (1,472 byles now in prnctice).lt is mandatory that all five
PbUs be supported in all implementations: Get.Request-PDU, GetNextRequest-PbU, GetResponse-PDU,
SetRequest-PDU, and Trnp-PDU. One of these five data PDUs is the data PDU that we start with at the top in
Figure5.5. RFC 1157-SNMP Macro defmition is given In Figure 5.6.
Fi~urt ~.6. RFC U!i7..SNi\11' Ml\<ro

RFC1151 SNMP DEFINITIONS :• BEGIN

IMPORTS
OJjeetName, Oll)ijCtSyntax, NetworKAadrass. tpAOoress. nmencks
FROM RFC1155 -SMI
- top-tevol message
Me~>sage ::=
SEQUENCE {
vo(lllon - YOrcion
INTEGER ( -1 lorlhis RFC
vers1on.1 (0)
).
communily - communtty name
OCTET STRING,
dOlO - o.g .. PDIJo lf·trlviol
Am ·- eutl1onllcatlon Is being used
l
- protocol data un.ts
POUs ::=
CHOICF (
get-request
gct-noxt•rcqucsl GotRoquoo~POU,
get-response GetNexiReques~PDU.
set-request GeiResponse-POU,
trap SotRoquoot POU.
l Trap-POU
- lhe Individual PDUs and commonly used data types Will be defined later
END

Basic operations of the protocol entity involve the following steps as a guide to implemen(ation [RFC 1157). The
protocol entity that generates the message constructs lhe appropriate data POU as an ASN.I object. It then passes
the ASN.I object. along with a communicy name and the transport addresses of itself and the destinatio.n (e.g.,
123.234.245.156: 161) 'lo the authentication scheme. The authentication scheme returns another ASN.I object
(possibly encrypted). The protocol entity now cort'ltructs the message to be transmitted with lhe version number,
community name, and the new ASN.I object, then serializes it using lhe BER ntles, and transmits it.

The reverse process goes on at the receiver. The message is dlscarded if an error is encountered in any of lhe steps.
A trap may be generated incase ofautbenticatioo failure. On successful receiptoflbe message, a rerum message is
generated, if the origina.l message is a get-request.

A managed object is a scalar variable and is simply called a variable. Associated with lhe variable is its value. The
pairing of the variable and value is called variable binding or VarBind. The data POU in the message contains a
VarBind pair. For efficiency sake, a lb't ofVarBind pairs can be sent in a message. The ASN.I construct for get
and set cypc of messages is shown in Figure 5.7 and a conceptual presentation in Figura 5.8. The VarBindList
contains n instances ofVad3ind (pairs).

Flgurr 5.7. Grt and Stt TyJ~< POl! ASN.t Construct tRFC ttS1)
 - requestfresponse ln formallon

Requestld ::=
INTEGER

EnorStatus ::=
INTEGER{
noError(O)
tooB/g(1)
noSuchNamo{2)
bad value(3}
r-ead0nly(4)
gooErr(5)

Errodndex : :
INTEGER

- variable bindings

VatBind :;=
SEQUENCE !
name ObjeclName
vatue ObjectSyntax

VarBfndUsl ::=
SEQUENCE OF
VatBind

Figurt ~ 8. Gel ond S tt Ty110 POlls

The PDU lype for the five messages are application daljllypes, which are defined in RPC I 157 as:

get-request [0]

get-next-request (lj

set-request [2]

get-response [3]

trap (4]
1n Pigure 5.8 RequestiD is used to track a message with the eoxpected response or for loss of a message (remember
UDP 6 unreliable). Loss-of-message detection is implementat'ion specific, such as t·ime out if no response is
reoeived for a request within a given time.. A non-:a:ro ErrorSiatus is used to indicate tbat an error occurred. 1lte
convention is not to use 0 if no error is detected. Errorlndex is used to provide additional information on tbe error
status. The value is filled with NULL in those cases whe.re il is not applicable, such as in get-request data PDU.
Otherwise, il is filled \viLh the varBind numbenvhere the error occurred; for example, I ifihe error occurred in the
first varBind, 5 if the fifth varBiod bad an error-and so on.

Figure 5.9 shows lbe strueutre fOr a trap PDU. which contains n VarBinds, i.e., n managed objects. The enterprise
[RFC 1155] and agent-address pertain to the system generating the Lrnp. Tile generic-trap consists of seven types as
listed in Table 5. L Tile integer in parenthesis associated with each name indicates tile enumerated JNTEGER. Tile
specific-trap is a trap that is not covered by the enterpri.seSpeoific trap. Time-stamp indicates the elapsed time sin.ce
last re-initialimtion.

Fi~urt ~ .9. Trftt> PDll

T•blt S.t. Cmtri< T rops

Generic-Trap Type Desaiption (Brief)

coldStart(O) Serldlng protocol entity Is relnltlaii~ing Itself; agent configuration or protocol entity
Implementation mav be altered

warmStart(l) Sending protocol entity is relnitlaltzfng Itself; aget~t conflguratlon or protocol entlty
Implementation not altered

Hn~Down(2) Failure of one of the·cornmunlcatlon llnl!:s

llnkUp(3) One oft he links has come up

authentfcatfonFallure(4) Authet~tlcatlon failure

egpNelghborloss(S) loss of EGP neighbor

enterpriseSpedflc(6) Enterprise-specific trap

S..l A. SNMP Operations

SNMP operations comprise get and set messages from tbe manager to the agent. and get and trap messages from
the agent t·o the manager. We will now look at these operatio.os in detail in this section.

GetRequest PDU Operation. Figure 5.10 shows a sequence <Jf operations in retri.eving the values of objects in a
System group. It stans with tbe get-request opellllion using a Get Request PDU from a. manager process to an agen1
process Md tbe get-response from the agenl with a Get.Response PDU. TI1e message from lhe manager starts from
the left side and ends 81 the agent process on the right side of the figure. The message from the 8gem process sl.arts
on the r ighr side of the figure and ends at the manager process on lhe left side of the figure. The sequence of
directed messages moves with lime as we move down the figure. Messages depicted represent ihe values of ihe
seven objects in the System group.

Figul"t 5. t0. Gtt· Rtque<l Oprratlon for Sysrrm Gr oup

.... f..,.OOOU Oo _ . ,
II)<OwluO)

I.....,..., Ill _
~-~·~~lr,alOI~)

l>roUoT"""ewl~~~ II>)"IUp._O) -

I•)'ICou:t,.. I
.,_.,.~ -

~·)"IN_q _
,........... 0· t«l1
~,..,.._ ...o,_
~----· ...................,
...,.___..., -~·~o> -

The manager process starts the sequence in Figure 5.10 with a Ge!R.equest PDU for the object sysDescr. The agent
process returns a GelResponse PDU with 8 value "SunOS." The manager then sends 8 request for sysObjectlD and
receives the value "E: hp." The C~~change of messages goes on until the value of 72 ror the last object in the group
sysServices is received.

GetNextRequest PDU Operation. A get-next-request operation is very slmilar to get-request, except ihat ihe
requested record is ihe next one to t he OBJECT IDENllFl ER specified in the request. Figure 5.11 s hows the
operations associated with retrieving data for the System group by ihe manager process using ihe get-next-request.
The fJrst message is a GelReqllest PDU for sysDescr with the response returning the value ''SunOS." The manager
prooess then issues a GetNex1Request PDU with the OBJECT IDENTIFIER sysDesor. The agent processes the
name of the next OBJECT IDENTIFIER sysObjecliD and iJS value ';E: hp." The sequence 1em1ina1es when ihe-
manager issues a get-next-request for ihe object identifier next to sysServices, aod the agcn1 process returns the
erTOr message " noSuchName:"

Figur t S. ll. Gn -Nui-R<qut51 Optrttlioo for • Sysrtm Group

 -c.~...... ~o~:OS;t•.,.
c.u..,

-GeR-
- GetRespons (SY-"ObJectiD:I):.enuup(

,.,.v,T.....o.m7349530
- G<>~e l•r•Cooml:LO= ••1
I

""
"'l<l~i'IJ-o- ·no:l"l ~
- Gc!R.._.. (6)1S\OCO>OO.Oo' 1 ~·
- G<lR..)IO<UIO(SysSoMcoos.o-12)
Gel
~~~(NSwr::tNA.,._)

The System group example we just looked at is a simple ease where all the objcets are singlt>volued sca.lar objects.
Let us now consider a more complex soenario of a MlB that confllins both scalar and aggregate objeciS. A
generalized case of a conceptual MIB comprising three sca.lar objects and a table is shown in Figure 5.12. llle f"u-st
two objects A and B are single- valued sea Jar objects. They are followed by an aggregate object represented by the
tableT with an entry E and two rows ofthree columnar objects, T.E.I.I. through T.E.3.2. The MIB group ends
wiih n scalar object Z.

flgurt S.J l. MJB fur 0 J>tr•1ion E~An!Jll.. lu l'lgurr• S.t J ond S.t~

Figure ·s. IJ shows the use of nine get-requeS1 messages to retrieve the nine objects. The left side of the figure
shows the sequential operation for getting the MIB shown on tbe right ~ide of the· figure. The MIB shown is the
same as in Figure 5.12, now drawn to rollow the sequence of operations. We observe a few hidden assumptions in
retrieving the data using the get-request operations. First, we need to know all the elements in the MIB iocluding
the number of columns and rows in the table. Seoond, we traversed the MIB from top to bottom, which is really
from right to left in the MIB tree Slructure. Third, we retrieved the data in the table by traversing all the instances
of a columnar object. The number of iostances or rows in a table could be dynamic and is not always known to the
management process. Thus, if lhe manager had issued a request fOr the object T.E.I.3 after acquiring T.E.1.2, il
would ha.ve received an error message from the agent process. This is when get-oext-reqliCSt is very useful.
However, we need to have a convention on the defini!kln of what lhe nexi object in a Ml 8 tree is, especially on the
table representing an aggregate· objecl. l:n SNMP, objects are retrieved using lexicographic convention. We will
flrst exp lain wbat this convenJion is berore using the get-next-request operation to retrieve the same MIB group
data. ·

Figurt S. t3. Gtt-Rtquesl Opt,. lion for a ~UJl in Fignrt S.tl

I
-o.>ll'-(1>,1

~-Ill)
"-•Uo>
t· -
tTE.Il ~
=
~~."T£-12)
t l LIIJ
_,T.I.lll -

( T£.2.11 -...J
- -ITE.21)

~-I TE.2.2)
( li.2.21 ::;1
-
- --(TE-32
(TE-3.1)
I rE.l-11: - i
-(T.E.Hl-.:1
;o_,_ t?l =::l
- Reopoos.fZ)

The increasing order ofcmity used in SNMP opemtions is in lexicogmphic order. Let us understand lexicogmphic
order by cons.idering a simple set of integers shown in Table 5.2. The left side· is a sequence of numerically
increasing integer numbers, and lbe right sX!e is lexicographically increasing order for this sequence. We notice
that in the lexicographic order, we start with the lowest ioteger in the leftmost character, which in our case is I.
Before increasing the order in the first position, we select the lowest integer in the second position from tbe left,
wbicb is II. There are two numbers (1118 nod 115) that sron with II. We anchor at II ror thef"nttwo positions
and then move on to select the lowest digh in the thi.rd positkln, which is Ill . We then move to the· founh positioo
and obtain 1118 as the second number. Now. return to the third position and retrieve 115 as 'the third number.
Having exhausted Is (ones) in positions two to four, select 2 for the second position. and retrieve 126 as tbe ne.xt
number. We continue this process until we reach 9.

Tabt• 5.2. L<xkogrnphic-Onler fllu.m btr &\'anttlt<

Numerical Order lexkographlc Order

1 1

2 1118

3 115

9 126
Tabl< 5.1. Ltxitogror>hk.Qrdtr N~tmlltr E>~unr>lt

Numerical Order lexicographic Order

15 15

22 2

34 22

115 250

126 2509

250 3

321 321

1118 34

2509 9

We will now apply r.be ICllicographic sequence to ordering o bject idemificrs in a MIB. Lnstead of each character
being treated as n literal. we treat each node position as a literal and fullow the same rules. An example iJiustrating
this is given in Tab.l e 5.3. The MIB associated with this example is sbown in Figure 5.l4.lt can be noticed that the
lexit:ogrnphicaJiy increasing order of node traces the traversal oft he tree starting from the leftmost node I. We
traverSe down the path all 1he way to the left:mo&1 leaf 1. 1.5, keeping to the right wbenever n fork is eo¢ounte.red.
We then move up Lbe tree and rake a rigbl on tlu: first fOrk. This leads us to !he leaf node 1.1.18. Thus, !he rule at a
furked node is to always keep to the ri_ght while traversing down and while going up. Thus, we are always keeping
to the right if you imagine ourselves walking along the tree path and looking in the fOrward direction. We tum
around when we re«ch a leaf.

Tabl• 5.3. Mm Ex•mplt for Ltliro2r•r>bk Ord•rln~

1

1.1

1.15

1.1.18

1.2

1.2.6

2
TRblt 5.3. MIB E:uunr>le for Luicogn~pltl• O>'<ltrb>g

2.2

2.10

2.10.9

3.4

3.21

Figu>.. 5. 14. MIB Exllmple for Lulcogrnph ic Ordrring

Returning to &et-next-request opcmtion, the &et-response message contains the value of the neKt le:Ocographic
object value in eacb VarBind. lf the request VarBind con~;~ ins a scalar, non-tabular object, tbe response contains
tile next scalar, non-tabular value, or the fli'St columnar object value of a table, if it is the next lexicographic entity.
Figure 5.15 shows the principle of operation of the functioning of get-next-request and response. We use ·tbe same
MIB view tba1 we hod in Figure 5.12 using get-requesl operntion. The manager process starts the operation wilb a
get-request message for object A and receives lhe response with the value of A filled in. Subsequent requests from
the manager are get-neXI-request type with the objea lD oftllC ju~ received or~es. Responses received are the next
object fD witb its value. Operations continue until Z is received. The subsequem request rece.ives a response with
an error message "noSuebName."

Figu>.. 5. 15, Gei-Nut-Requul Opemtion for • MIB in f'igurr ~.12

 I -- --..:.._-,Cto!Nt<tll4oll"'t ! tl
•l<-(no:!<I<II1Hon,.l - -- - ---l

There are several advantages in using get-next-request. First, we do not need to know the, obje<:t identifier of the
next entity. Knowing the current OBJECT IDENTIFIER, we can retrieve the next one. Next, in the case of an
aggregate object, the number of rows is dynamically changing. Thus, we do not know bow many rows exist in the
table. The get-next-request resolves this problem.

There is also aoother advantage of the get-next-request. We can use this to build a MIB tree by repeating the
request from any node to any node. Thls is called MIB walk, and is used by a MID browser in NMS
implemcntation.

Figure 5.16 shows a faster method to retrie.ve an aggregate obje<:t. lt shows an Address Translation table with a
matrix of three columnar objects, atlfindex, atPhysAddress, and aiNet.Address. The obje<:ts atlflndex and
aiNelAddress are the indices that uniquely identify a row. There arc three rows in the table. If we use the get-next-
request operation shown in figure 5. 15, it would take us ten message exchanges. The VarBindList comprises two
Var.Bind name-value pairs, sysUpTime and atPbysAddress, suffixed with the vaJue,s o( atill.ndex and
alNeLAddress. lnstead of issuing ten get-next-requests with a s.ingle VarBind in the message, the manager generates
fuur GetNextRequest PDUs with a list of two VarBind fields. Although the Address Translation table is relatively
stable, in general, a table is dynamic. and hence the Lime-stamp is requested by including sysUpTime.

flgurt 5.16. G<tNextRtqutsl E~an>J>k with tudi«S

 I.,.__.-

I
~~Tr-(•.,tJlllltf')
~s··nt
I
ln this method, the manager bas to know the columnar objects of the mble. The first query message. retrieves the
indices automatically. For the Address Tmnslatioo table, the atlflndex and atNetAddress are indices. This is shown
in the request and response message O!Ds. The flfSt get-nel<l-request message does not contain any operand value.
The neld ihree contain the value returned by ihe response. The fourth and ltlst get-ne·l<l-requ.est brings ihe object,
ipForwarding, which is llle f~rst element in the IP group, which is the next group in internet MIB. This is because
all table entries in the Address Table have bee.n retrieved. It is up to the malll!ger process to recognize this and
terminate the process. lf the table contained more rolumns, the Vru-BindList could be expanded 11nd values fOr all
the objects in the neld row obtained with eacb request.

There are more details to this PDU operation and. the reader is rererred to the rererences Perkins and McGinnis
[1997], RFC [1905], and Stallings [1998).

SNMP PDU Format E.xamples. We will now look at lllePDU for llle System group example shown in Figure 5.10
us.ing a sniffer tool. Sni trer is a management tool lllatcan capture packet.~ going across a !ransmiss ion medium. We
have used this tool to "sni£1'' some SNMP messages to display how messages actuaHy look. We are presenting a
series of messages that qtterya system for its system group d31a (Figure 5.17). This corresponds to the data shown
in Figure 5.1 0. We ihen set the missing values for a couple of entities in the group (Figures 5.18 and 5.19) and
finally reexamine lllem (Figure 5.20).

Figut.. S. t7. Snifftr Dot• or Got Mus•gtS ( ln<Ontplt!t Dam ill Agt11tj
 13:55:47.445936 noc3.blc.gatech,e(lu.164 > noct.btc.gate<:h edu.snmp:
Community= public
GelReques\(111)
Recues! ID = 1
sys!em.sysDescr.O
system.sysObjecliD o
syolem.llysUpTime.O
system.sysContact.O
syslem.sysName.O
syllltlm.sr-rLocaUon,O
system.sysServtces.O

13:55.47.455936 noc1 btc.gatech,edu.s.nmp > noc3.btc.gatech.edu.l64:

Community c ~ubl lc;
GotResponse(172l
Request 10 1 =
system.sysOescr.u =
· sunos ncc1 :>.:>.'1Generto_103640-o.e suMu"
sygtem sysObj<>etiO 0 = E·hp 23 10 1.2
syslem.sysUpTime.O = 247349530
systcm.sysContaCI.O ,. -
oystorn.oysNomo.O• •noo1 •
syslem.syslo<:atlon.O=
system.sy$Sen;lces.O = 72

Frgurt ~ .18. Snlmr Oaco ofS tc-Rrqui:sc and .Rrsponst ror Syscrcn Co11la<l

t3:5'6:24.89t369 nocl.bJc.9atoeh. I!GJ. I~ > roc1.btc.gacech.odu.snmp.

Communny e netman
$Q!R&qO. .t(41)
RequeSIIO= 2
syscem sysConcacc.O ='"Brlnoon Rnodes

13:56.24.894369 noe1.bl~toch odu.snmp > noel.btc.gatech.edu 164,

communKy • netman
GetResPOtue(41 1
RequeaiD•2
fiystetn.sysConcaa..o ~ -&an0on Rr-·

Figure 5. 17( a) shows a GetRequest message for the system group values going fro m the manager,
noc3.gatech.btc.gatech.edu (noc3, fur short), to the agent, nocLbtc.gatech.edu (nod , fur short). The fJrst line
shows tbat it was sent at 13:55:47 from port 164 of noel to srunp port ofooc3. Tbe tool tbat was used bas actually
translated the conventional port number 161 to snmp. The community name is public and lhe Get Request message
is Ill bytes in length. The SNMP version number is not tilled in. l11e seven object IDs from system.~-ysDescr.O to
system.sysServices.O aU end with zero to indicate tbal they are single-~aJued scalar objects. The agent, noel . sends
a GetResponse message of 172 bytes with values filled in fur all seven objects. 11te Get.Response message is
shown in Figure 5.17(b). Notice tbat the values filr sysContact and sysLocation in GetResponse are blank as they
have not been entered in lhe agent.lo addition, lhe request number identified in lhe GetResponse PDU is the same
as lhe one in lhe GetRequcst PDU.

Flgul'f 5.19. Sniffer DAta of Stt·Rtque-st. and Responsr for Sy.sttm Loc:Atinn

13:56~7.874245 noo3.tliC.gatoeh.e<lu 164 > noc1 txc.gatech.edu.snmp:

Co mmuroity = netmaro
SetHoq...,.,t(37)
Request tO= 3
system.s)'Slocation.Oe 'BTC NM Lab'

13.56:27.884244 noc:1.btc.gatocl't.edu.anmp > noc3.btc.galech.edu.164'

C<lmmuntry =netman
GetRe:sponse(37)
Request 10 = 3
systemsyslocation.O" "BTC NM Lab'

Flaure 5.20. Snlffu 0 111• of Grt Mrssag .. (Com1>lrtr O.ca In A~tnl)

14 03:l6.71l8270 n()(3.btc.gatocn.O<fu 164 > 00(1 .btc.goll)Ch.e<tu 5nmp:

Canmunny ., pl.<blio
Ge1Request(111)
Request LD = 4
sy>temsysOescr.O
system.sysObjetUD.O
systems ysUpllnie.D
system$ysContoct.O
system.sysName.O
system.syslocallon.O
system.sysServi:!"'.O

14 03:36.798269 noo1 .bte.gate<:h.odu,,nmp > noe3 ~lc.got och 0<11.164

Community =public
GeiRO>Jil011>0( 196)
Reques110=4
syJtcrru;ysl)i!w.O " ·sunOS noel 5.5.1 Ge~oric_103840 .{)8 Wl'l'W.
")'Jicn"•ysObJo~tiD.O • E:hp.2.3.10 1.2
systemsysUpnme.O" 24'7:.\95453
sysacrnsysContac:l.O = ' Brandon Rhodes·
sy.a.l.oem..~ysNnma.O • "noo1"
sysaem.syslocation .o = "BTC NM Lab·
syl(em.sysServices.O = 72

Figure ·s . 18 shows ihe ~of the SetRequeS1 message lo write lhe sysContact name in noe l whose value is
"Brandon Rhodes.'' Notice lhat the communil)l name is changed to netman. The community ofoetman has lhe
access privilege to write in noc I. and the objrot, system.sysConta.ct, hos the read-write access for the netman
community. The agent, noo I, makes the change and sends a GetResponse message back to noc3 . Figure 5.19
shows a similar set of messages ror sctling the emily sysLocatlon with the value "BTC~ Lab."

Figures 5.20(a) and (b) are a repetition of Figure 5.14 of the GetRe.questand GetResponse messages. We now see
!he completed version of !he system group dam.

5.1.5. SNMP MlB G1·oup

Figure 5.2 1 shows t he MlB tree ror !he SNMP group, and Table 5.4 gives the description ofihe entities. Note that
OlD 7 and OID 23 are not used. The number of tr80SIIctions in tbe description column in the Ulble indicates ins and
OUI.S of the SNMP protocol entity. AU entities exoept snmpEoableAmhenTmps have the syntax, Counter. The
implementation of the SNMP group is mandatory-obv.iouslyl

Flgw·• 5.21. SNMP Grout>

Tabl• S.4. SNMP Group

Entity OlD Description (Brief)

snmplnPkts snmp (1) Total number of messages delivered from transport service

snmpOutPkts snmp (2) Total number of messages delivered to transport service

snmplnBadVerslons snmp (3) Total number of messages from transport service that are of unsupported version

snmplnBadCommunltyNames snmp (4) Total number of messages from transport service that are of unknown
oomm unity name

snmplnBadCommunityUses snmp (5) Total number of messages from transport service, not allowed operation by the
sendlngc<>mmunlty
TRblt SA. SN~1P Go·our>
Entity OlD Description (Brief}

snmplnASNParseErrs snmp (6) Total number of ASN.1 and BER errors

snmp (7) Not used

snmplnTooBigs snmp (8) Total numberofmessages from transport service that nave ' tooBig' errors

snmplnNoSuchNames snmp (9) Total numberofml!$<18es from transport service that nave ' noSuchName' errors

snmplnBadValues snmp Total number of messages from transport service that nave ' badValue' errors
(10)

snmplnReadOnlys snmp Total number of messages from transport service that nave ' read Only' errors
(11)

snmplnGenErrs snmp Total number of messi!l!es from transport service that nave 'genErr' errors
(12)

snmplnTotallleqVars snmp Total number of succe.ssful Get-Request and Get-Next messages received
(13)

snmplnTotaiSetVars snmp Total number of objects successfully al tered by Set-Request messi!l!es received
(14)

snmplnGetRequests snmp Total number of Get-Request PDUs accepted and processed

(15)

snmplnGetNexts snmp Total numberofGet-Next PDUs accepted and processed

(16)

snmplnSetRequests snmp Total number ofSet-Request PDUs accepted and processed

(17)

snmplnGetResponses snmp Total number of Get-Response PDUs accepted and processed

(18)

snmplnTraps snmp Total numberofTrap PDUs accepted and processed

(19)

snmpOutTooBigs snmp Total number ofSNMP PDUsgenerated forwhlcherror-status is 'tooBig'

(20)

snmpOutNoSuchNames snmp Total number ofSNMP PDU.s generated for which error-status is ' noSuchName'
(21)
Table 5.4. SN~1P Go·our>

Entity OlD ~criptlon (Brief)

snmp0U1BadValues snmp Total number of SNMP PO Us generated for which error-status is 'badValue'
(22)

sn mp Not used
(23)

snmpOU1GenErrs snmp Total number of SNMP PO Us generated for whloh error-status ls 'genErr'
(24)

snmpOU1GetRequestS snmp Tot;!l number of SNMP G.et-Requesti>OUsgenerated

(25)

snmpOu!GetNexts snmp Total number of SNMP Get-Next POUs generated

(26)

snmp0u1SetRequests snmp Total number of SNMP Set-Request POUs generated

(27)

snmp0U1GetResponses snmp Total number of SNMP Get-Response PO Us generated

(28)

snmpOutTraps snmp Tolal number of SNMP Trap POUs generated

(29)

snmpEnableAuthenTraps snmp Override option to generate aU1bentl<atlon failure traps

(30)

5.2 F un ctio n n l Model

There fire no formal specifications of functions in SNMPvl management. Application functions are limited, in
general, to network management in SNMP and not to the services provided by the network.

There are five areas of functions (configuration, fault, perfOrmance, security, and ~unting) addressed by theOSJ
mode. Some configuration functions, as well as security and privacy-related issues, were addressed as part ofthe
SNMP protocol ·entity specifications in the previous section. For example, the override function of traps is one of
the objects in the SNMP group, which has the access privilege of read and write and bence can be set remotely.
Security functions are built in as part of lbe implementation of lbe protocol entity. Community specifications and
authentication scheme partially address these rcquircment.s.

The write access to managed objects is limited to implementation in most cases. Thus, configuration maJl!lgement
in general is addressed by the specific netwo(k manage.m ent system or by lbe use of console or telnet to s..'l
configurable parameters. We saw the use of lbe configuration management function in the examples shown in
Figures 5.18 and 5.19.
Fault maongeme01 is addressed by error co1mters built into the agents. They can be read by the SNMP manager and
processed. Traps are usefUl to monitor netw.:>rk elements and interfaces go.lng up and down.

PerfOrmance counters are par1 of the SNMP agent MIB. It is the function of the SNMP manager to do performance
analysis. For example, counter readings can be taken at. two instances of ·time and the data mle calculated. The
intermediate manager/agent, such ~ RMON, can perform such statistical functions, !IS we will see io lhe next
chapter.

1'he administrative model in protocol entity specifications addresses seclirity function in basic SNMP.

The accounting function is not addressed by the SNMP model.

Summ;try

All management opc.rations are done using five messages in SNMPvl. They are get-request, get-next-request, set-
request, get-response, and trap. The first 'three-are sent from the manager to the agent and the last two are sent by
the agent to the manager.

The SNMP communication model deals with the administrative structure and the five SNMP mcs.sage PDUs. llte
administrative model defines the community within which messages can be exchanged. It alw defines ·the acooss
policy as to who bus access privilege to what duta. The five protocol entities are defined in ASN .I format and
macros. We teamed SNMP opermions by tracing messages exchanged between manager and agent processes. We
then looked inside PDU formats for various messages to learn the data fonnall!·.

There is no formal specification fur the functional model in SNMP management. However, management functions
are accomplished by built-ill schemes and managed objects. The administrative model in SNMP and tl!e operations
using managed objects are·employed to accomplish variolL~ funct.i.ons.

Ex.erci.~es

1. lhr~ m.anaged hubs wl\h lnlerf~ce ld 11-13 (fourth decimal position value) In subnetwork 200.100.100.1 are
being monitored by a network management system (NMS) for mean time between failures using \he SysUp1ime
in system {internet. mgmtmib·2.system} group. The NMS periodically issues the command get-re<(uest object-
lnstanre rommunil:y OBJECT IDENTIFIER All the operands In the three set of re<(uests that the NMS sends out
Use "public" for the mmmunltyvarlable.

2. You are assigned the task of writing specifications for configuring SN MP managers and agents for a corporate
network to Implement the access policy. The policy defines a community profile for all managed network
romponents where a public group (comm·uruty name public) can only look at the System group, a privileged
group (rommunlty name privileged) that can look at all the MtB objects, and an exclusive group (community
name exclusive) th;tt can do a n!ad·wrlte on all allowed components. Present a figure (similar, but not Identical,
to the flow chart shown in Figure 5.2) showing the paths from the SNMP man~ers to managed objeru of a
network component.

3. All In the data In the trap PDU format shown In Figure 5.9 for a message sent by the hub shown In Figure 4.2(a)
one second after It l$ reset following a I allure. Treat the t;rap as generic and leave \he speclflc trap field blank.
The onlyvarBind thatthe trap sends lssysUpTime. (Refer to RFC 1157 and RFC 1215.)

4. AnSNMP manager sends a request message toanSNMP agent re<(uesting sysUpTime at 8:00A.M. Fllll nthe data
for the fields of an SNMP PDU shown In Agure S.S. Please use "SNMP" for the application header, enumerated
 INTEGER 0 for version-1, and "public" for community name.

5. In Exerctse 4, If tile SNMP manager sent tile request at 8110 A.M. -and the SNMP agent was reset at mldnlgnt
after afaflure, fill in tile fields for tile SNMP PDU on the response received.

6. An SNMP manager sends a request for tne values of tile sysUpnme In the System group and If Type in tile
Interfaces group for lfN umber value of 3. Wrtte lhe PO Us with tile fields filled In for

a. the get-reques1 PDU, and

b. the get-response PDU wilh ooSuci\Name error message for ifrypc

7. Tile following data response Information is received by tile manager lor a get-request with a varBindUst.
Compose

a. !he get-request PDU, and

b. the get-response PDU

Objeet Value

Error Status Too big

Error lnc!ex udplnErrors

udplnDatagrams 500,000

udpNoPorts 1,000

udplnErrors 5000

udpOutDatagrams 300,000

8. Draw lhe message sequence diagram si.mllar to the one shown in Figure5.10for the hub example given in Figure
4.2(a). Assume tnat a separate get-request message is sent for each data value.

9. Repeat Exerdse 7 with a VarBfndUst. Use thefor~t of Figure 5.16.

10. For tile UDP Group MIB shown in Figure 439, assume 1hattilere are three rows for tile columnar objects In tile
udpTable. Write the OBJECT IDENTIFIER for all the objects In lexicographic o'der.

11. Draw tile message sequence diagram for the following lpNetToMedlaTable retrieving -all the values of objects In
each row with Single get-ne>rt·request commands, similar to lhe one shown In Figure 5.16. The Indices are
lpNetToMedlalflndex and ipNetToMedlaNetAddress.lgnore obtaining sysUpnrne.

lpNetToMedla lflndex lpNetToMedlaPhys Address lpNetToMedlaNet Address lpNetTo MedlaType

 25 OOOOOC392084 192.68.252.15 4

16 OOOOOC3920AF 172.16.49.1 4

9 OOOOOC3920A6 172.1655.1 4

2 OOOOOC39209D 172.16.56.1 4

12. Compose data frames for SNMP PO Us for the example shown In Figure 5.16 for the following two.cases:

a. 1l1e first GeiNextRequest (~sUpTime, at.PhysAddress) and the GctResponse.

b. The second GeiNextRequest and GetResponse with values obtained in (a).

13. A data analyzer tool Is used to look at a frame of data traversing a LAN. It Is from the station noc3 In response to
a request from noel. Use the following system status to answer this question.

Versi on = 0
Communi t y ~ netma n

Object Value Units

Request 10 100

Error Status Too big udplnErrors too high

Error Index udplnErrors

sysUplime 1, 000,000 hundredths ofa seamd

udplnDatagrams 500,000 datagrams.

udpNoPortS 1,000 datagrams

udplnErrors 5000 datagrams

udpOutDatagrams 300,000 dataigrams

Compose the expected da111 &ames for SNMP PDtJ types. Your frames should l.ook l1ke the ones shown
in Figure 5.17.

a. Get Request from the manager 10 the managed object.

b. Get Response from lhe managed object to lhe manager.
7. Identify the authoritative and non•authorltative entities in Figure 7.20.

8. Define the configuration parameters for a notlflcallon generator to send traps to two network management
systems noel and noc2 by fi lli ng In the objects In the snmpTargetAddressTable, snmpTargetTable, and
snmpNotlfyTable. Specifications for the two targets are given below. You may use the Appendix of RFC 2273 as a
gul de to answer this exercise.

noel noc2

messageProcesslngModel SNMPv3 SNMPv3

securltyModel 3 (USM) 3(USM)

seculrtyName "'noel.~~ "'noc:2'""

snmpTargetParamsName "NOAuthNoPrlv-noc1" "NOAuthN oPrlv-nocl"

secu rltyleve I noAuthNoProv(1) authPrlv(3)

transportDom al n snmpUDPDomaln snmpUDPDom9ln

transportAddress 128.64.32.16:162 128.64.32.8:162

tag list "groupl" "group2"

9. Access RFC 2274 and tist and define the primitives provided by the authentication module at the sending and
receiving security subsystems. Describe the services provided by the primitives.

10. Access RFC 2274 and list and define prtmitlves provided by the privacy module at the sending and receiving
security subsystems. Describe the services.provided by the primitives.

11. SpecifY the fam ily name, the family subtree, the family mask, and the family type In vacmVIewTreeFam lyTable
for ah agentto present a view of:

a.. tbe complete lP group

b. IP address table ( ipAddrTable)
c. tbe row in the lP address table correspooding 10 tbe IP address 172.46.62. 1

12. Wrtte the vacmVlewTceeFamllyTable for the three rows th~t present the system group In the IP address table for
the row with IP address 172.46.62.1 without the ipAdEntReasmMaxSize.

8. SNMP Management: RMON

Objectives
• Remote net\mrk monito ring, RMON
RMON I: Monitoring Ethernet LAN and token-ring LAN
RMON2: Monitoring upper protocol layers
• Generates and sends sLalistics clo.se to subnetworks to central NMS
RMON MISs fur RMON group objects

The success of SNMP management resulted in the prevalence of managed network compo nents in the computer
network. SNMPv I set the fuundation for monitoring a network remot.e ly from a centraUzed .network operations
center (NOC) and performing fa1~t and configuration management. However; the extent to which network
performance could be managed was limited The characterization oft he performance ot a computer network is
statistical in nature. This led to the logical ste p of measuring ihe statistics of important pammeters in the network
from the NOC and the development of remote monitoring (RMON) spec ifications.

8.1. W hut is Remote Monitoring?

We saw e xamples of SNMP messages going across the network between a manager and an agent in Section 5.1.4.
We did this using a tool that ··~niffs'' eve.ry packet thai i-1 going aero~ a local area network (LAN), opens it. and
analyzes it. It is a passive operation and does nothing to the packets, which continue ttl proceed to their
destinations. 1l1Js is called monitoring or probing the network and the device that does the function is called the
netwo rk monitor or tlte probe. Let us distinguish between the two components of a probe: ( I) physical object that is
connected to the transmission medium and (2) processor, which analy zes the datn. 1f both are at the s ame place
geogr<~phically, it· is a local probe, which is how sniffers used to function. We will discuss this further in Chapter 9,
when we consider management systems and tools.

The m onitored information gathered and analyzed locaUy ca.n be transmitted to a remote network management
station. In such a case, remotely monitoring the network using a probe is referred to as remote network monitoring
or RMON . Figure 8. 1 shows a fiber-distributed data interfuce (FODI) backbone network with a local Ethernet
LAN. lltere are two remote· LANs, one a token-ring LAN and another, an FOOl LAN, cormec ted to ihe backbone·
network. The network manage ment system (NMS) is on the l.o cal Ethernet LAN. There is either an Ethernet probe
or an RMON on the Ethernet LAN monitoring tbe local LAN. The FODr backbone is monitored by an FOOl probe
via the bridge and Ethernet LAN. A toke!l-'ri.ng probe monitors the token-ring LAN. lt communicates with the
NMS via routers and tbe wide nrea network (WAN) (shown by lhe IJghtening bolt symbol of the
telecommunications link). The remote FOOl is monitored by the built-in probe an the router. The FDD! probe
communic11tes with tbe NMS via the WAN. All fuur probes that monitor the fuur LANs rutd communicate with tbe
NMS u.re RMON devices.

l'igur·• 8.t . Nrework Connguruciou wilh RMONs

The use of RMON devices has several advantages. First; each RMON device monitors the local network segment
and does the necessary analyses. Ll relays the necessary information in both solicited and unsolicited filshion to the
~S. For example, RMON cou.ld be loc41lly polling network e.lements in a segmcni. 1f It detects an abnormal
condition, such as heavy packet loss or excessive collisions, it would send an alarm. Because the polling is local,
the information is more reliable. This example of local monitoring and reporting to a remote NMS significantly
reduces SNMP tra.ffic in the network. This is especially true for the segment in which the NMS resides, as all the
monitoring traffic would otherwise converge there.

The following case history illustrates another advantage. RMON reduces the necessity of agents in the network to
be visible at all times to the NMS. One of the NMSs would frequently indicate that one of the hubs would show
failure, but the !tub recovered itself without any intervention. The perfonnance study of the hub that the LAN was
pan of indicated that the LAN would frequently become overloaded with heavy traffic, and would have a
significant packet loss. That included the ICMP packets tb.at the NMS was using to poll the hub. The NMS was set
to indicate a node failure if three sucoessive ICMP packets did not receive responses. Increasing the number of
packets needed to indicate a failure stopped the failure indication. This demonstrates the third advantage.

There are more chances that the monitoring packets, such as ICMP pings, may get lost in long-distance
communication, especially under heavy traffic conditions. This may wrongly be interpreted by the NMS as the
managed object being down. RMON ping; locally and hence has less chance oflosing packets, thus Increasing the
reliability of monit.oriog.

Another oovantage of local monitoring using RMON is thut individual segments can be monitored on a more
continuous basis. This provides better statistics and greater ability for control. Thus, a tauU could be diagnosed
quicker by the RMON and reported to the NMS. In some situations, a failure could even be prevented by proa.ctive
management.

The overall benefits of implcme.nting RM.ON tecltnology in a network are higher network availability for users and
greater productivity for administrators. A study report [CISCO/RMON] indicates increased productivity of several
times for network administrators using RMON in il~eir network.

8.2. RMON SMI anti MIB

Por a network configuration system. like the one shown in Figure 8.1, to work suocessfuUy, several conditions
need to be met. Network components are made by different vendors. Even the RMON devices may be from
different vendors. Thus, just as in the communication of network management infOrmation, standards need to be
established for commo.n syntax and semantics lOr the use of RMON devices. The syntax used is ASN.I. The
RMON structure of management info[lll8tion is similar to SMiv2 in defining object types. The Remote Net1\0rk
Monitoring Managemenrlnformation Base (RMON MlB) defining RMON groups liaJ; been developed and defined
in three stages. The original RMON MIB, now referred to 3S RMONl was developed fur Ethernet LAN in
November 1991 RFC 1271, but was made obsolete in 1995 RFC 1757. Token-ring extensions to RMON I were
developed in September 1993 fRFC 1513). The use of RMON I for remote monitoring was found to be extremely
beneficial. However, il addressed parameters at the OS! layer 2 level only. Hence, RMON2 [RFC 2021] was
developed and released in January 1997, which addressed the parameters associated with OSI layers 3 through 7.

The RMON group is node 16 under MIB-11 ( mib-2 16), as shown in Figure 6.36. All the groups under the RMON
group are sbown in Figure 8.2. It consists of nine Ethernet RMON I groups (noon I to rmoo 9), one t.oken-riog
extension group to RMONI (rmon 10). and nine RMON2 groups(nnon 11-20) for tlte higher layers.

Figur• 8.1. RMON Croup

t
RM<lHI"'*'-'

.RMONI is covered in Section 8.3 and RMON2 in Section 8.4. We will discuss the applications ofRMON in Part
m when we discuss applicatioos, systems,andtoo1s.
8.J.RMONI

RMONI is covered by RFC 1757 for Ethernet LAN and RFC 1513. There are two data types introduced as textual
conventions, nnd ten MlB groups ( noon I to rmon I 0), as shown in Figure 8.2.

8.3.1. RMON I Textual Conventions

Two new data types thm are defined in RMONI textual conventions are OwnerString and BntryStatus. Both these
data lYJles are eKtremely useful in the operation of RMON devices. RMON devices are used by maoagemen1
systems to measure and produce stati.stics on network elements. We will soon see !hat. this involves setting up
tables that control parameters to be monitored. Typically, there is more than one management system in the
network, which could have permission to crente, use, and delete control parameters in a table. Or, a human network
mnnage.r i.n charge of network operations does such function s. For !his purpose, the owner identification is made
part oftbe control table defined by the OwnerString data lype. The BntryStatus is used to resolve conflicts between
management systems in manipulating control tables.

The OwnerString is specified in the NVf ASCll cbarr~eter set specified by DisplayString. The information content
of OwnerS!ring conlllins in.furmation about the owner: lP address, management slation nnme, network manager's
name, location. or telephone number. If the agent itself is the owner, as for example in the addition of an interface
card, the OwnerString is set to "monitor."

1n order to understand the data 1ype, BntryStatus, we need to understand the concept of creation and deletion of
rows in tables, which was discussed in Section 6.4. 7. For a table to be shared by multiple users, a columnar object
EntryStatus, similar to RowSmtus i.n SNMPv2, is added to the lllble that contains information on the status of the
row. The EntryStatliS data lype can exist in one of four states: (I) valid, (2) createRequest, (3) undciCreation, and
(4) invalid. l 'he four states ofEntryStatus arc shown in Table- 8.1 . Under the valid srate condition, the instantiation
or row of the Lable is operational and is probably measuring the number of input octets in tbe JF group on an
interface. Any mllllagement system, which is authenticated to· use the RMON device, may use this row ofdalll. Of
course, if the owner of the row decides to make it invalid, other systems lose the data. The invalid state is the way
to deleiea row. Based on implementntion, the row may he immediately deleted and the resource claimed, or it may
be done in a batch mode late.r. Iflhe desired row of information does not already exist, the ma.nagement system can
create a row. The EntryStaiUs is then set to oreateRequest. 1lte process of Cl'e8tion may involve more than one
exchange of PDUs between the manager and the agent. t n such a situation, the state of the Entl)iStruus is set to
undcrCreation so that others won't use it. Aller the creation process is complete, it is set to the valid state.

Tabt~S.I. EntryStatus.Tutuat Convention

State Enumeration Description

valid 1 Row exists and Is 11ctlve. It is fully configured and operational

createRequest 2 Create a new row by creating this object

underCreation Row is not fully active

Invalid 4 Delete the row bydlsasscdatlng the mapping of this entry

8.3.2.RMONl Groups and Functions

RMON in general, and RMON I specifically, performs numerous functions at the data liok layer. Figure 8.3 shows
a pictorial representation of RMON I groups and functions. The data-gathering module;;, which are LAN probes,
gather data from the remotely monitored network comprising Ethernet and token-ring LANs. The data can serve as
inputs to five sets of functions. Three of those comprise monitoring of traffic statistics. The host and conversation
statistics group deals with traffic data associated with the hosts, ranking of traffic ror the top N hosts, and
conversation between hosts. The group of statistical data associated wiili Ethernet LAN, namely Ethernet statistics
and Ethernet history statist·ics, is addressed by the groups and functions in the Etbemet statistics box. The history
control table controls the data to be g;ubered from various networks. lt is also used by the token-ring statistics
modules in the token-ring statistics box. Outputs of various modules are analyzed and presented in tabular and
gmphical forms Ill the user by the network manager in 1be NMS.

Figu•·• 8.3. RMONt Groups oud Fuu<lions

The filter group is a cascade of two filters. The packet filter filters incoming packets by perfurming a Boolean
and/or XOR wiH1 a mask specified. This could be quite complex. The filtered packet stream is considered a
channel. We can make further selections based on the channel mask. The filtered outputs may genemte either
alarms or evenls. These are reported to the network manager. The output of the data g&he.rer could also genemte an
alarm directly.

The output of the filter group could be stored in the packet capture module for filrther analysis by the network
manager. This could be associllted with a special study of the traffic pattern or troubleshooting of an abnormality in
tJIC network.

The above functions associated with the various groups are accomplished us ing teo groups associated with the
RMONI MIB, as sbown in Table 8.2. The firsi nine groups are applicable to common dam and to Ethernet LAN,
and the tenth group extends it to token-ring LAN. Most of the groups have one or more tables. The groups liiJI into
three categories. The largest category is the statistics-gathering groups. These are the Statistics groups, the History
groups, the Host group, the Host Top N group, and the Matrix group. The seonnd category deals with the network
event reponing functions. lllese are the Alarm group and the Evenl group. The third cmegory deals with filtering
the input packets according io selec1ed criteria and capturing the data if desired for further analysis. These are the
Filter group and the Packe.f Capture group. We will consider RMON I groups and the token-ring extension to
RMON I in Sections 8.3.4 and 8.3.5, respectively.

Table 8.2. RMONt M ID Grou1>< oud Tab Its

Group 010 Function Tables
Tabl t 8.2. Rli10NI MIB Go'OUf>S nnd TAbi<S

Groop OlD Function Tab~

Statistics rmon 1 Provides link-level statistics -etherStatsTable

-ether5tats2Table

History rmon 2 Coll&ts periodic statistical data and stores for later retrie.val -hlstoryControffable

-etherHistoryTable

-hlstoryControi2Table

-etherHistory2Table

Alarm rmon 3 Generates events when the data sample gathered crosses pre- -alarmTable
estabnshed threshol cis

Host rmon 4 Gathers statistical data on hosts - hostControffable

- hostTable

-host1i meTable

- hostControi2Table

Host Top N rmon 5 Computes the top N hosts on the respective categories of surtlstics -
gathered hostTopNcontroiTable

Matrix rmon 6 Gathers statistics on traffit between palrs.of hosts -matrixControiTable

-matrlxSDTable

- matrlxDSTable

-matrh<Controi2Table

Alter rmon 7 Performslllterfunctiohthatenables capture·of desired parameters - fllterTable

-channeffable

- fllter2Tabfe·

-channei2Table

Packet rmon 8 Provides packet capture capabll ity to gather packets after they flow -buffercontroiTable
TRblt 8.2. RMONI Mffi GrOllllS and Tab los

Group 010 Function Tables

capture through a channel

~pture8uffer'Table

Event rmon9 Control s the generation of events and notiflcatlons -eventTable

Token ring Rmon See Table 8.3 See Table 8.3

10

In Table 8.2, we notice in 1be Tables colunu1 that some of the groups have tables with "2" as part of the name; for
example, etherStats2Tnble in the Statistics group. These are additional tables created during RMON2 specifications
development and are enhancements to RMONI. Hence, 1hey are included here as part o f RMONI. The
enhancements 10 RMONI include the standard La<rtCreateTime te~tual convention fOr all control tables and
Time-Filter textual convention that provides capability for the filter to handle rows to be used for the index to a
table. The LastCreateTime enhancement belps keep track of data with tbe changes in control. Tbe. TimeFilter
enables an application to download o nly those rows that ohang!ld since a particular time. 1l1e agent returns a value
only if ibe time mark is less t.ban the last update time.

As an example, .let us consider a fooTable with two rows and three columnar objects, fooTimeMark (with
TimeFilter as the data !ype), foolndex. and fooonums. The indices defining a row are fuoTimeMnrk and foolndex.
Let the TimeFilrer index start at 0, ibe last· update of fooCounter in row #I occur at time 3, and its value is 5.
Assume 1he update to .r ow #2 occUI'red Ill time 5 and tbe value was updated to 9. This scenario would yield the
following inst11nce offooCounts io the fooTable:

fooCount s . O. l 5
fooCounts . 0 . 2 9
fooCount s . l . l 5
foocounts . 1 . 2 9
fooCoun t s . 2 .1 5
fooCouots. l . 2 9
fooCoun t s . 3 .1 5
fooCount s.3.2 9
fooCounts . L 2 9 {Note that row U does not exist for times 4 ilf\d S since the l ast
update
occurred at timema r k 3 . )
fooCoun t s.5.2 9
(Both rows U and 12 do no t exist for timemark g reater than 5 . )

8.3.3. J{el.atiorL~hip Between Control and Data Tables

Observing the Tables column in Table 8.2, you will notice several of the groups have a datil 1able and a control
table. T he datil table contains rows (instances) of data. The control table· defines the instances ofthe datr rows in
'I he data mble and is seunble to gnther and s tore different instances of data. The relationship between tbe control
table and ibe daia table is illustrated in a generic manner in Figure 8.4. The vahre ofihe datalndex in ihe data table
is the same as the value ofcontronndex in I he comrol table.

Figure 8.4. Rtlotlonsblp Btrwttn Control and O•u• T ables

 iKlloltiJII "*-"
~I'Mf\ta11'tltO!Oi«W
Vii!Jt Clf dft!hOOJ •~me n hwl.ltot ClO!IiUtnckt

Let us understrutd how the dat!l tllble and the control t!lble work together using the matrix group in Table 82. We
can ro llect data based on source and destination addresses appearing in the packets on a given interface using the
matrixSDTable (matrix SQurce-<lestination table). The control index is rut integer uniquely identifying the row in
the control table·. II would have a va.Jue of I for the iirst intrice of a managed entity. llte value of the columnar
objecl, controlDatllSource, idenJifJe.s the source of the data that is being collected.ln our example, if the interface
#1 belongs to the imerfaces group, then controlDataSourcc is iflndex.l.

The controJTableSize identifies entries associated with this data source. In our matrix source-<lestinatim table
example, tllis would be the sourc&-destination pair in each row ofUIC table.

The controiOwner columnar object is the entity or person who created the entry. The entity could be either the
ngent or NMS, or a manngement person. The contro IStat·us is one· of the· em·ries listed in Table 8. I. The
controiOther could he any other object.

To uniquely identifY a conceptual row in the data table, we may need to specify more indi.ces th110 the dat;Undex.
This is indicated as dataAddllndex in Figure 8.4. In our matrix source-<lestination example, additional indices are
source and destination address objects. The dataOthcr in the data table indicates data being collected, such as the
number of packet~.

8.3.4.1tMONJ Common and Ethernet G roup~

We. have so fur covered the global picture of RMON I Ethernet MIB and how data and control tables are related to
each other. Let us now address the nine RMON I commo o and Ethernet groups.

Stal'istics Group. llte statistics group contains stntist·ics measured by the probe tOr each monltored Ethernet
interface on a device. The etherStatsTable in tbis group has an entry for each interfilce. Data include statistics on
packet types, sin:, and errors. ll also provides capability to gather statistics on the collision of the Eihemet
segment. The number of collisions is a best estimate, as the numbe.r o(collisions detected depends on where the
pro be is placed on the segment.

lbe statistics group is used to measure live statistics on nodes and segments. Commercial NMSs include features
such as dynamic presentation of various trafflc patterns. 1he number of MlB collisions could also be used for
alarm generation when it exceeds a set high threshold value.
History Group. The history group consists of two s.ubgroups: the history control group and the history (data) group.
The history control group controls the periodic st3listl.cal sampling of data fro m various types of networks. The
control table stores configuration entrie.~ comprising interface, polling period, and other parameters. InfOrmation is
stored in a media-specific table, the history table, which contains o.ne entry for each specific sample.. A short"tenn
and a long-term imef\•al , such as 30-second and 30-rninute intervals. rnay he specified to obtain two diflcrent
sllltistics. The dat;l objecis defined 11re dropped events, numbe.r of octell!· and packets, diffl:rent type of ·errors,
fragments, collisions, and utilization.

The history group is extremely useful in tracking the overall trend in the volumeoftraflic. Since historical data are
accumulated at the data link layer, they include traffic caused by aU higher-layer protocols. Short-!erm history
statistics can also be used to troubleshoot net work performance problems. For example, in one study of traffic
pattern that the author participated in. short-term history statistics revealed that a significant volume of
"transparent" data was contributed by servers in the network, which were functioning as " mirrors"' for a public
news service on ihe Internet. Although the service \vas considered to be desirable, since il was gcoemted and
consumed externally, it behaved sornewltattraospareotly with regard to the local network traffic.

Alarm Group. The alarm group periodically takes statistical samples on specified variables in the prohe and
compares them with the pre-configured threshold stored in the probe. Whenever the monitored variable crosses the
threshold. an event is generated. To avoid excessive generation of events on the threshold border, rising and falling
thresholds are specified. This works in the following manner. Suppose an alarm event is generated w.ben the
variable crosses the faUlng threshold while going down in value. Another.event would be generated only after the
value crosses the rising threshold at lea~t once.

The group contains an alarm table that has a list of entries defining the alarm parameters. The colmnnar objectS
alarm Variable and alarmlnterval are used to select the variable and the sampling interval. The sampling type is
either tbe absolute or delta value.. In the former, the abso ktte value of the variable at the end.of the previous period
is stored as an alarm value. In the· latter type, the absolute value at the end at a period is subtracted from the
beginning of the period and tbe computed value is stored. These values are compared with the rising and falliog
thresholds to generate alarms.

An e.xample of an absolute value would be a new interface card on test fbr infant mortality. The threshold of the
sum ofoutgoing and incoming packets could be set to I gigaoctecl~ and tbe RMON would generate an alarm/event
when the threshold is reached. An example of delta type is threshold set to 10,000 packets in a 10-second interval
for excessive packet loss.

Host Group. The host group cootains information about the basts on the network. It compiles the list of hosts by
looking at the good packets traversing the network and extracting the source and destination MAC addresses. It
maintains statiStics on these hosts. There are three tables in the group: hostControlTable, hostTable, and
hostTimeTable. The hostControlTable controls the interfuceson which data gaUtering is done. The other two tables
depend on this infOrmation. The hostTable contain5 statistics about the host. The bostTimeTable contains the same
data as the host table, but is stored in the time order in which the host entry was discovered. This belps in the .filst
discovery of new hosts in the system. Tbe entries in the two data tables are synchronized with respect to the host in
the hostControlTable. We can obmin statistics on a.host using 1his MIB.

Host Top N Group. The host top N group performs a report-generation function ror ranking the top N hosts in the
category of the selected statistics. For example, we can rank-<:>rder the top ten hosts with maximum outgoing
1mffic. The HostTopNControlTable ls used to initiate generation of such a report.

As an elQl.mp le of the rypc ofda.ta that can be acquired using an RMON probe, Figure 8.5 shows a chart derived
using an RMON probe for the output octets of the top ten hosts in a network. The names of the hosts have been
changed to generic host numbers for security reasons.

Flgurt 8.5. Hosffot>-10 Output O<lrls

 H0<1TopN

HO!I!I

H0o12

HOI!I3

HOlt~

HOIU

H01t6

HOII I

HOII6

H"'*9

lloJI10 .,.
ICO :roo 300 •oo
Gign Oote!1

Matrix Group. The matrix group stores statistics on the oonversation between pairs of hosts. An entry is created lbr
each conversation that the probe detects. There are three table.s in the group. ThematrixControLTabl.e controls the
information to be gathered. The mntrixSDTable keeps track of the source to destination com<ersations; aod the
matrixDSTable keeps data based on destination to source traffic. We can obtain a graph similar to Figure 8.5 fur
the oonversation pairs in both directions using this group.

Filter Group. The filter group is used to filter packets to be captured based on logical expressions. The stream of
data based on a logical expression is called a "channel.'' The group contains a fiker table and a channel table. 1loe
filter table allows packets to be filtered with an arbitrary filter expression, a set of filters associated with each
channel Each fi.ker is defined by a row in the filter table. A channel may be associated with several rows. Por eacb
channel, the input packet is validated against each filter associated with that·channel aod is accepted if il passes any
of the tests. A row in the channel table of the filter group includes ·the interface 1D (same as iflndex) with which the
chatlllel is associated, along with acceptance criteria. The combination oftbe filter aod channel filtering provides
enormous flexibilit.y to select packets to be captured.

Packet Capture Group. The packet capture group is a post-filrer group. lt captures packets from each channel based
on the filter criteria of packet and channel filters in tbeftlter group. The cb.annel fihcr criteria !Or acceptance oftbe
filter group output are comrolled by the bufferControiTable and the captw-ed channel data in the
captureBufferTable. Each packet captured ls stored in the buffer as an inslan¢e.

Event Group. The event group controls the generation and notification of events. Both the rising alarm and the
falling alarm can be specified in the eventTable nssoc.iated with the group. Besides the transmittal ofevenis, a log
is maintained in the system.

8.3.5. RMON Token-lUng·Extension Croups

As we mentioned earlier, token-ring RMON MlB is an extension to RMONI MIB and is specified in RFC 1513.
Table 8.3 p(esents the token-ring MIB groups and tllbles. There are eight groups, each with a data table and two
with controlmbles.

Tobit 8.3. RMON Tok•n-Ring MIB Groups~~~~ To bits

Token Ring Group Function Tables

Statisti cs Current utilization and error statistics of MAC layer tokenRingMIStatsTabl e

tokenRingMIStats2Table

Promiscuous statistics Current utilization and error statistics of promiscuous data tokenRingPStatsTable

tokenRingPStats2Table

ll,lA£-Iayer history Historical utilization and errorstatlstics of MAC layer tokenRlngMI.HistoryTabl e

Promiscuous hls.tory Historical utflizat!on and error statistics of promiscuous data tokenRingPHistorVTable

Ring station Stlrtlonstatlstlcs rlngStat!onControrTable

rlngStationTabl e

rlng5tationControi2Table

Ring station order Order of the stations rlngStationOrderTable

Ring station configuration Active configuration of ring stations rlngStationConflgControiTable

ringStationConflgTable

Source-routing Uti lizat.i on statistics of source routing Information sourceRoutlngStatsTable

sourceRoutlngStats2Table

There are two token-ring sllltistics groups, one at the MAC layer (token-ring statistics group) and a second on
packels collected promiscuously (lokeo-ring promiscuous statistics group). They both conmln statistics on ring
utilization and ring error statiStics. The MAC-layer statistics group collects dat;l on token-ring parameters such as
Ioken packets, errors in packets, bursts, polling, etc . The promiscuous statistics group addreJ>ses statistics on the
numbe.r of packets of various sizes and the type of packets as to data-multicast or broadcast. There arc two
corresponding history stacistics groups~urrcnt and promiscuou.~. Each oft he four statistics groups has one data
table assoeiated wiih it.

There are three groups associated wil:b the stations oo the ring. The ring station group provides sll!Listlcs oo each
statim being monitored on the ring ahng wilb its status. The data are stored in lhe ringStationTable. The rings and
parameters to be monilored are co.ntrolled by. the ringStationControiTable. The ring smtion OJ'der group provides
the order of the· station on the monitored rings and has only a data table. The ring station configuration group
manages the swtlons oo lhe ring.

The last group in ihe ring groups is ihesource-rouiing group. It is used to gniher statistics on routing in.fbrmuion in
a pure souree-routing environment. ·

8.4. RMON2

RMON l deal! primarily with dat!l associated with the OSJ dnlll link layer. The success and popularity of RMON l
led ·to the development of RMON2. RMON2 [RFC 2021] extends the monitoring capabWty to the upper layers,
from the network layer to the application layer. The term application level is used in ihe SNMP RMON concept to
describe a class of protocols, and not strictly ihe osr layer 7 protocol. The error smristics in any layer include all
errors below the layer, down I'D the network layer. For example, the network layer errors do not include data link
layer errors, but the transpon· layer errors inOlude the network layer errors.

Several oftl~e groups and functions in RMON2 at higher layers are similar·to ·that of the dalalink layer in RMONI.
We will discuss ihe groups and their similarity here. We wIll cover in detail bow protocol analyzer systems
incorporate the higher-layer data gnthered using RMON2 in Chapter 9 on NMSs and tools.

8.4.1. RMON2 Managemen t l nfomuuion Base

The arcbitcdure of RMON2 is the same as RMON I. RMON2 MID is arranged into ten groups. Table 8.4 shows
ihe RMON2 MlB groups and lables. We have already discussed eohnncements· to RMONI MIB in the previous
section.

Table 8.4. RMON2 MtB Groups •nd TBbles

Group 010 Function Tables

Protocol dl rectory rmon 11 Inventory of protocols protocoiDirTable

Protocol distribution rrnon 12 Relative statistics on octets and packets protocoiDistComroiTable

protocoiDlstStatsTable

Address map rmon 13 MAC address to network address on the interfaces addressMapControiTable

addressMapTable

Network-layer host rmon 14 Traffic dm from and to each oost nlHostControiTable

nlHostTable

Network· layer matrix rmon 15 Traffic data from each pal r of hosts nlMBtrixControiTable

nlMatriXSDTable

nlMatrixDSTabl e
TRblt 8-'. RMON2 Mm GroullS a11d Tab los

Group OlD Function Tables

nlMatrixTopNControiTable

nlMatrixTopNTable

Application-layer nost rmon 16 Traffic da13 by protoc<>lfrom and to each host alHostTabie

Application-layer matrix rmon 17 Traffic data by p<otocol between pairs of hosts alMatrixSDTable

a1Matrfx05Table

alMat rixTopNControiTable

alMatrlxTopNTabie

User history collection rmon 18 User-sped fled historical data on aJ.arms and statistics usrHistoryq,ntroiTabl e

usrHistoryOb)ectTable

usrHistoryTable

Probe config.u ratlon rmon 19 Configuration of probe parameters serlaiConfigTable

netConflgTabl e

trapDestTabie

serlaiConnectionTable

RMON conformance rmon 20 RMON2 MIB compliances and compliance groups See Section 8.4.2

The prot(X)O( directory s.roup is an inventory of 1he protO(ols that the probe can monilor. The capability o f U1e
probe can be allcred by reconfiguring lhe proloc.oiDirTable. The prOt(X)O(S range from the data link conll'Ollayer to
1he app1icadon layer. This is identified by the columnar o bjecl on the unique prolocol ID. Each. protocol is furtber
subdivided based on paramelers, such as frag ments. The protocol identifier 11nd protocol parameters are used 11s
indices fur the rows of the table.. There is one entry in the table for each protocol. The protocols thai can be used
with the protocol directory have been defined in RFC 2 074.

The protocol distribution group provides infurmatio n on the relative traffic of different prolocols e ither in octets or
packets. It collects ve.ry basi c statistics that would. help a NMS manage bandwidth allocation utiliz.ed by different
protocols. The protocoiDistConll'OITable is configured according ttl the data to be collected and
protocoiDistStatsTable stores the data collecu:d. Eaeh row in the protocolDist StatsTable is indexed by the
protocolDistControllndes. in the protocoiDistControJTable and protocoiD.irLocaHndeK in the protooolDirTable.
The data table stores the packel nod octet cmmts.
The address map group is similar to tbe address translation wble bindmg tbe MAC address to lhe network address
on each interface. It has two lables for com·rolnnd data.

The nerwork-layer host group measures traffic sent from and to each network address representing ench host
discovered 'by tbe probe·, as tbe host group in RMON I does. ·

The network-layer matrix group provides informal ion on the conversalion between pairs of hosts in both directions.
It is very similar to the matrix tables in RMON I. The group also ranks the top N conversations. It bas two contra I
tables and tbree data tables.

The application layer functions are grouped into two groups, the application-layer host group and the application-
layer matrix group. They both calculate iraffic by protocol units and use their respective control Ulbles in the
networ.k-loyer host group and the network-layer matrix group. The application-layermatrix group can also generate
a report of the top N prutocol conversations.

Alallll Wld history group information have been combined into the user history collection group in RMON2. This
fuoction, nonnally done by NMSs. can be off-loaded to RMON. Lt has t\\'\J control tables and ooe data table. Data
objects are coHected in bucket groups. Each bucket group pertains to a MIB object, and the elements in the. group
are the instances of the MIB object. Users can specify the dam to be collected 'by entering data into
usrAistoi)ControiTa'ble, wbicb will then be assembled with rows of instances in the usrAistoryObjectTable. Each
row in the former specifies tbe number of buckets to be allocated for each object, and the latter contains rows of
instances of the MIB object. The data nre stored in userHistorifable. There could be one or more inslrulces of
userHistorifable associated with each usrHistoryObje<.'tTable.

The probe configuration group provxtecs the facility to configure the probe. The data can be accessed using a
modem connection. The pertinent data are stored in the serialConfigTable and serialConnectionTable. The
nelConfigTable contains the· network configuration parameters, 8Dd the trapDestTabJe. defines the destination
addresses fur the traps.

8.4.2. RMON2 Confomtance Spccifieations

Confurrnance specifications were not specified in RMON I. They have been added in RMON2. As shown in Figure
8.6; the RMON2 confollllWJCe group consists of two subgroups, llllon2MIBCompliances and llllOn2MIBGroups.
The compliance requirements are separated into basic .RMON2 MIB compliance and appliauion layer RMON2
MlB compliance.. Each compliance module defines the mandatory and optional groups. Vendors are required to
implement the mandatory groups fur compliance; optional groups may be used by vendors to specify additional
capabilities.

flgurt 8.6. RMONl Cunformon<'< Gruup

Tbere are 13 groups in nnon2MIBGroups. They are listed in Table 8.5 along with the manda10ry (M) and optional
(0) requirements for tbe basic- and application-level coofonnance 10 RMON2. llte rmonlEnhancementGroup is
mandatory for systems thai implement RMON I with RMON2. Notice that probeConfigur81ionGroup is a basic
group and hence marked as mandatory, even though it is oot specified as such in RFC 2021 definitions. The
rmonJ BribancemenlGroup is mandatory for implemcnmt ion of RMON I. l 'he rmon IEUu.'rnei'BnhancementGroup
and rmoniTokenRingEnhancementGroup a4d enhanceme.nts to RMONI ibat belp management stations. The
enhancements include filter enlry, which provides variable-length offsets into packets and the addition of more
statistical parameters.

Tablt 8.5. RMONl Grour>< Rnd Comr>liRnc••

Object Group RMON2 M l.B RMON2 M IB Application Layer Compliance

protocoiDirectoryGroup M M

protocoiOistnbutionGroup M M

addr~MapGroup M M

nlHostGroup M M

nlMatrixGroup M M

alHos~oup N/A M

alMatrlxGroup N/A M

usrHistoryGroup M M

probelnformatlonGroup M M

probeConfiguratlonGroup Ml'J M'''

rmonlEnnancementGroup oPJ oJ'I

rmonlEtnernetEnnancemnetGroup 0 0

rmonlTokenRingEnhancementGroup 0 0

l'l One oftbe basic groups in RMON2 and hence is mandatory.

ftl Mandatory for systems implementing RMON I.

8.5. ATM Rcmot~ Monitoring

We will be learning management of ATM in Chapter 9. However, there is a similarity in the use of remote probes
for RMON on ao ATM network. We will address the commonality aod differences here. You may skip this .section
now, if you so choose, aod rerum to it after you have studied A TM management.

We have thus far learned about RMON aod its advamages for gathering statistics on Ethernet aod token-ring
LANs. RMON I denlt with the 4ata link layer and RMON2 with higher-levellnyers. IETF RMON MJBs have been
extended to pe.rfonn traffic monitoring aod analysis for ATM networks (see af-nm-test-0080.000 in Table 9.3).
Figure 8.7 shows an RMON MIB framework fur tbe extensi>ns, as portrayed by the ATM Forum. Switch
~'Xt.ensions for RMON and ATM RMON define RMON objects at the "base" layer, wruch is the ATM sublayer
level. ATM protocol IDs for RMON2 deime additional objects needed ru the higher-level layers [RPC 2074].

Figun8.7. RMON MIB Fr amrwork

,~
~ llP'fi.JI,... PIU-'1
~IAOIH
t"'C2021,2'J~
. NI!WOik lAytr G"-~~J Rf.OON·2
dltlonttoiU'CrouJ

-t-
Ethrnl!l
RM()I>I
!RFC1l'ti7)

-
IETF MI8o
~-
Tol<on•R,.g
~MON
IRI'e t ~W
"DU:sl)· '-t1Y..t

-L-
I
Swll<lt
E.&:lltMOI'lt
wRt.o.'\N
._____ 0
A1,'1(1:1~ MI6t

There arc .several differences between RMON of Eth.ernet aod token ring and monitoring of ATM devices.
Extending RMON to ATM requires design changes and new functionality. Particular attention needs to be paid to
U1e fullowing issues: high speed. cell vs. frames. aod connection-oriented nature of ATM. At I he data link sublayer,
ATM RMON measures cells instead of packets or frames, and provides cell-based per-host and per-convc~tion
tmffic statistics. The high-speed nature of ATM imposes a severe set of requiremems in ATM RMON
implementation. At the application layer, RMON provides basic statistics for each monitored cell stream, for each
ATM host, and fur conversation between pair-wise hosts. Ct also provides capability fur flexible configuration
mecbllllisms suited to U1e connection-oriented nature of ATM.

There are four different collection perspectives that are possible for ATM RMON. as shown in Figure 8.8. Figure
8.8(n) is a stand-alone probe attached to a single port of a switch. ATM traffic is copied somehow to the RMON
probe. Figure 8.8(b) is an embedded probe within a switch, but with no access to the switch fabric. Again, ATM
tral'lk is somehow copied to 1he RMON probe. Figure 8.8(c) is an embedded probe with ac.cess to the switch
fabric. However, this type of probe measures traffic al the cell header level only. Figure 8.8(d) is a stand-alone
probe, tapping a network-to-network ioter.fuce between rwo switcbes. ATM traffic in both directions is monitored
directly without switcb intervenl ion. Wben RMON instrumentation is either embedded into tbe switch fa brio (c) or
placed between two switches as in (d), no modification of tbe circuit is needed. In (a) and (b), circuit. steering is
needed m copy the cells onto the probe. TIIC two-way arrows in the figures indicate two half-duplex circuits Lhal
carry lbe steered traffic.

fllgu,.. 8.8. ATM l'mbr Location

 ti
,.,-.... - ... er... lb! .......... """"'..., Copy

The ATM RMON MJB is under theexjXlrimental node of the lETF lnternetMJB and is shown in Figure 8.9. The
functions of the groups and the lables in each group are given in Table 8.6. The MIB co mains four groups:
ponSele<:t, atmSI8ts, atmHost, and atmMalrix.

Flguo·t 8.9. ATI\1 RMON Mlll

Tabl< 8.6. A1111 RII10N 11118 Grouf>S ood Tablts

Group OlD Function Tables

por!Select atmRmonMIBObjects 1 Port selection poriSeiGrpTable

Tablt 8.6. ATI\1 RMON MID Groups ond To bits

Groop OlD Function Tables

portSeiTabie

atmStats <ltmRmonMlBObjecrs 2 Basic statistics atmStatsControiTable

atmSt<ltsTabl e

atmHost atrnRmonMIBObjects 3 ATM per-host atmHostControiTable

statistics atmHostTable

atmMatrix atmRmonMIBObjects 4 ATM per-circuit atmMatrixControiTable

statistics atmMatrlxSDTable

atmMatrlxOSTable

atmMatrixTopNControiTable

atmMatrixTopNTable

The portSelect group !!ddresses port selection. rt is used to define rhe ports io be monitored in a particular statistics,
host, or matrb< collection. It conmins two tables. 11te portSeiGrpTable controls the set-up of ports and ATM
connection selection crileri.a used on behalf of any collection associaJed with entries in Lhls table, such as
aunHostTnble. The ponSeiTable is Lhen used to control the set-up of selection criteria for a single ATM port.

The atmStats group col lecLS basic statistics. rt counts rhe total amounr of traffic on behalf of one or more
ponSelectGroups. Titcre are two tables in Lhis group: atmStatsControiTable and atmStaiSTable.

lbe atmHost group coUecLS per-host statistics. It counts the amount of lraffic sent on behalf of encb ATM llddress
discovered by the probe, according to associarod portSolectGroup criteria. It contains a daLa table and a control
Lable.

The atmMatrix group collects per-circuit statistics and reports the top N circuit traffic. It gathers traffic data on a
pair-wise source-destinatk>n address, accordiJtg to portSelectGroup cri1cria, in bolh directions. It conlllins three
data lable.s and two control tables. The ntmMatrili:ControiTable is used to define the source-to-destinaLion
(aunMiltrixSDTable) and destination-to-source (aunMiiLrixDSTable) lraffic. The atmMatrixTopNControlTable and
atrnMatrixTopNTable are used to nnal)7.e and present the top N traffic c;31Tiers.

8.6. A Case Sfud y onlntenef Tl'llffie Using RM'ON

A study was undertllken fOr planning purposes to gather statistics on the [memet growth at the Georgia LnSLilule of
Technology. The rechn.ical objectives of lite study included traffic growth and 1rend and 1raffic pattern. The latter
was based on (I) weekly nod monthly patterns, (2) diurnal patterns. (3) distribution of trnffic by users, packet size,
aod protocol, aod (4) souroe oftmffic based o.n source-destinat ion data.

The network comprised multip le domains of Ethernet and FDDI LANs. The network comple x was ·connected to
the lnternet via a high-speed gateway. Data were gathered by me<~surements made on various domains
individually, as well as on the gateway.

Various tools were used to gather datn, including RMON statistics. t-lewlett-Packard' s NetmelrLx Protocol
Analyzer was U1lld for Ethernet LANs. The statistics were gathered using the host top N and history groups to
select the lop gener:ators oftrnffic O\<er the period The matrLx group was used to measure incoming and outgoing
traffic. The filter nod packet capture groups were beneficial in analyzing the type of traffic based on the application
level protocol, such as HITP, NNTP, etc.

.Besides the commercjaJ tools, specjaJ tools were developed for lite study. for example, the commercial probes
were not filst enough to measure the packets Ira versing an fDDl ring. Hence, a promiscuous mode of couming the
packets (function of a prohe) was developed to measure traffic on the gllleway. We wlll learn more about
m3.llllgement tools and their use in management applications in Chapter 9. However, the case study described here
is intended to illustrate the importance of gathering sllll.istics and the U1ll of RMON for that purpose.

A partial summary of the results follows. lbe names ln the results have been changed to protect the privacy and
securit.y of the institution.

Resu lts

I. Growth Rate: lnier.net traffic grew at a significant rate from February to June at a monthly rate of9% to
18%.

February to March 12%

March to Apri l 996

April to May 18%

2.
3. Note: There was a sudden drop in June due to end of spring quarter aod lhe beginning of summer quarter.
4. Traffic Pan em:
o Monthly/Weekly: The only discernibl e variation was lower traffic over weekends.
o Daily: '))3 ofthe top 5% peak.~ occurred in the afternoon.
o Users:

Top six domain of users (96%) are

Domalnl 20%

Domaln 2

(25%)
Subdomain I
 Domain 1 20%

(3%)
Subdomain2

Domaln3 34%
Domaln4 7%
DomainS 3%

Domaln6 2%

Top three hosts .sending or receiving daia were:

Newsgroups

Mbone

Linux. host

What we have learned:

I. The three top groups of users contributing to 84% of 1he l,ntemet traffic are students (surprise!), Newsgroup
services, and Do rna in I.
2. The growth mte oft ntemet use during the study period in the spring quan·er was 500/o.

Su mm11ry
In this chapter we discussed the enhancement to SNMP management by Lhe introduction of remote monitoring,
R.MON. Remote monitoring is monitoring the network using remotely positioned probes in various segments in the
network. RMONI was initially defined for data link level parameters of Ethernet LAN. rt was !hen extended to
token-ring LAN. RMON2 development fu.llowed to monitor and produce stlllistics for parameters associa.ted wilb
the upper layers, from the network to the application level. We will pursue the use of RMON in managing
networks from a pmctical point of view in Part ill of !his book.

Exe rcises

1. An NMS connected to a 10-Mbps Ethernet LAN Is monitoring a network comprising routers, hubs, and
woricstatlons. There are 10,000 nodes In the network to monitor. It sends an SNMP query to each station once a
minute and receives a response when the stations are up. Assume that an average frame size Is 1,000 bytes long
for get·requestand response messages.

a. What is the maxi mum traffic load on the LAN that has the NMS?
b. Assume that the Ethernet LAN operates at a1118x.imum efficiency of40% throughput, what. is the
overhead (SNMP packetslt·otal packets) due to network monitoring?

2. In Exercise 1, assume that the network comprises ten s.ubnetworks, an RMON monitoring each subnet.

a. Design a heartbeat monitoring system, using RMONs, that indicates lililures to tlie NMS within a
minute of a failure.