Part II: SNMP and Network Management

Part ll, comprising C hapters 3-9, is devoted to unders tanding the principles o f net work and syste m
management. Chapters 3- 7 discuss the management of a TCPIIP netwock using Simple Net\~ork
Ma.nagement System (SNM i>) versions I, 2, !!lid 3. Remote monitoring. wh.ich is also part of SNMP
management, is discussed in Chapter 8.

In Chapter 3, tec lmical fOundations on standards, models, and language. which are needed ro build
network management based on various standards, are introduced Net\\Wk management standards
dtat are currently used are SNMP (lntemet), CMlP (OSI). TMN. IEEE, and Web-based
Management. Of these. SNMP is the most widely deployed management system due to its truly
simple architecture and implementation. An overview o f models and concepts of network
management is covered. Specif'.:atlons of most pro tocols are done us ing ASN. I syntax, which is
discussed insomedetaiL

There are three versions of SNMP-based protocols tbal manage TCPIIP networks. SNMPvl is
covered in Chapters 4 and 5. Chapter 4 is devoted to the organizatlon and information models of
SNMP in network management. System architecture and SNMP m essages are presented. The
structure of manageme_nt information (SMn is presented using ASN.I s ynt;lx. The definition o f
SNMP objects and their organization in the structure of management information base (MJB) are
described. Chapter 5 covers SNMP communication protocoL Message data structures are presented
along with the message prot.o co l operalions and SNMP MlB.

Learning Chapters 4 and 5 would help the reader to understand the basic principles behind SNMP
network management. Case ltistories and practical elalmples pmtctuate the presentation. When the
book is used as a textbook for a course, this should provide adequate- background fur the student to
select a project for the cou[se if the course includes a project as part of its requirements. 1 strongly
recommeod it-especially for an undergraduate course. A list of projec~ which have been used in
senior undergradunt.e and graduate classes, is present.ed in Appendix B.

Chapter 6 addresses SNMPv2. SNMPv2 adds several sigoificanl enhancements to SNMPv'l,

inc lnding efficient transferring of bulk data between systems. O ne of the intended major
·enbance_ments, namely security consideratioos, was postponed from SNMPv2 to SNMPv3. In
Chapter 7, we cover security and privacy, as well as generalized SNMP architecture and
a pplications, which are part of SNMPv3 specifications.

The SNMP mrinagemenl system is based on polling. Re mote monitoring of network components
using probes and sending only relevant data to the network management system is dte goal of
RMON discussed in Chapter 8.

Chapter 9 is devoted to networking rools. management tools, nod management systems. You will learn
some baslc networking tools that are part of the operating system, wbicb would be of immense help in day-
tQ-day use and operations of the network. SNMP command tools are convenient tools that can be used for
network management even without having a network management system. We bave earlier learned the
immense benefits of MlBs in octwotk management. Hence, MIBs bave to be designed well, which is
covered in MTB e ngineering. The d esign of the network management system for varioll~ veltical net\vork
applications, as well as tor performing various functio·ns, is covered in detail. After learning "these tools, we
will cover network management systems ranging from low-end to hig!Hnd solutions. We will dwell in
more detail on the mid-range enterprise network management systems \vith example.~ of commercial
systems tbat are in w ifespread use.
3. Basic Foundations: Standards, Models, and Language

Objectives
Standards, models, and language needed for network management
Network models
o OS!
o lnternet
o TMN
olEBE 802
o Web based
Management communication protocols
o SNMP
o CMIP
o XML
o CORBA
ASN.I language
o Syntax
o Macro
Basic encoding rule
Management application functions

In Pan· r we bad an overview of networking and management of network and systems. We learned about network
technology and components that need to be managed. There are several management standards and models in
existence for managing networks, systems, and services. We can understand and appreciate them better by f:irst
looking at dte commonality among them, and then the differences that distinguish dtem. These goals form the
objectives of this chapter.

We will consider the foundations that are needed to build v81ious network management mode.ls and protocol~. We
wlU survey the network management standards and present the genera I architecture of the network management
models in Section 3.1 .

The International Standards Organization (ISO) has defined a geoerali.md model that addresse.s all aspects of
network management. We will oover the three models of the archiiecture in Sections 3.3 througlt 3.5, wh:ich deal
with org~U~imtion, infOrmation, and communication. Then we willle81n the basics of the formal language, ASN.I,
and the data stnacture that is used for maJiagernent systems t.o store management infom1ation and communicate
with each other in Sections 3.6 through 3.8.

Allrhe above three models are designed fur management applications lo manage networks, systems, and services.
The fourth mode~ fwtctional model, addresses these in Sectk>n 3 .9. The applicatk>ns fall into the categories of
fault, configuratio11, performaR«e, se~urity, a.nd accounting.

ln a global perspective, three areas of network need managing. They are network, systems, and services; inter-layer
protocols; and intra-layer protocols. In this book our focus wi Ube on network and system managemem aspects. We
define network managemem as mnnagemenl of1he network comprising nodes and links, and system management
as managing system resources, such as centml processor usage, disk usage, and application processes. Service
management deals with services provided by orgllnizalions to customers. Service management is an extension of
network and systems.
The two leading models of network management fire lhe lntemet model and lhe Open System i nterconnection
(OSij model. The lnt.emet model is lhe most widely used for network management.. It is a. simple scalar model an.d
hence easy to implement. The OSI model, which is object oriented, is more complex and harder to implemenr.
However, w~.h the maiured Sl8le of object-oriented techoology. and the convergence of data and
telecommunications technologies, object-oriented implementation of network maoagemc01 has come into vogue.
We will address thi s in Chapter 16. A highe.r-l.evel management network called the Telecommunications
Management Network (TMN) is alsc based on the OSJ model. It ·addresses all levels of management including
service and business aspects. We wiU study TMN in Cbapter 10.

ln t.his book we will be concerned primarily with lhe study of Internet-based SNMP model. Tbe OSI model is
discussed in Appendix A

3.1. NeiworkM;magc mcnt Standards

There are several network management standards that are in use today.

Table 3.1 lt;t.s four standards, along with a fifth class based on emerging technologies, and their salient points. 1lte
first four are the OS! model, the Internet model, TMN, and IEEE LAN/MAN. A detailed treatment of the various
standards can be fuund in [Black, 1995]. The first category in Table 3.1. Open System Interconnection (OST)
management standard, is the standard adopted by the [otemational Standards Organizalion (ISO). Tb.e OSl
management protocol standard is Common Management Information Protocol (CMIP). The OS! management
protocol bas builL-in services, Common Management lnfurmat.ion Service (CMIS), which specify the basic services
needed to perform the various functions. lt is the most comprehensive set of specificat.ions and addtesses all seven
layers. OSI specificat ions are structured and deal with all seven layers of the OSI Reference Model. The
specifications are object oriented and hence managed objects are based on object c lasses and inheritance rules.
Besides specifYing the management protocols, CMlP/CMIS also address network management applications. Some
oft he major drawbacks of the OSI management standard were that it was complex and that the CMIP stack was
large. Allhougb these fire oo longer impediments to lhe implementation of the CMJP/CMlS network management,
SNMP is the protocol tbat .is extensively deployed.

Tobit J.t. Network ManRgernent Stondords

Standard Salient Points

OSI/CMIP lntematioual standard (ISO'OSO

Management of data communications ·network-LAN and WAN
Deals with all seven layers
Most complete
Object oriented
Well structured and layered
Consumes large resource in implementation

SNMP/Internet Industry standard (lETF)

Originally intended fur management of I ntemet components, currently adopted filr
WAN and telecommunication systems
Easy to implement
7 Most widely implemented

TMN lntemational stllndard (ITU-T)

Management of teleco mmunications network
Based on OSf network management framework
TAble 3.1. Network MAnAgtmtnl Standllrds

Standard Salient Points

Addresses both netwotk and administrative aspects of management

eTOM industry standard tbr bus.iness processes for implementing TMN using NGOSS
framework

IEEE IEEE standards adopted internationally

Addresses LAN 8J)d MAN management
Adopts OS! standlll'ds significantly
Deals with first two layers ofOSI RM

Emerging Wei>-B85Cd. Enterprise Management ( WBEM)

Technologies Java Management Extension QMX)
XML-based Network Managemeor·
CORBA- based Nelwork Management

ln contrast to the CMIP protoco~ the Simple Network Management Protocol (SNMP) presented in Table 3. 1 is
truly simple as its name indicates. 11 started as ao industry standard and has since become very much like standard
specifications of a standards organization. The lnten~et Eng.ineeriog Task Force (lETF) is responsible for all
Internet specificatiQns including network management. The managed objects are defined as scalar objoots in
SNMP. It was primarily intended to manage Internet components, but is now used to manage WAN and
teleco mmunications sySiems, It is easy to implement !!lid is the most widely implemented network management
system today. We will discuss SNMP manage ment in more detail in this book.

The third category in Table 3. I, TMN, is designed to manage the telecommunications network and is oriented
ioward the need;; of telecommunications service providers. TMN is ITU-T (International Teleco mmunications
U nion-Telecommunicatio ns) stllndard a nd is based on OSI CMIP/CMIS s pecifications. lMN extends tbc concept
of management beyond managing nctwor.ks and network components. Its specifications address se.rv.i cc and
business considerations (M3000). Chapter JO is devoted to the discussion ofTMN.

Erihaoced Telecommunications Operations Map (eTOM) is a guidebook for business processes in the
telecommunicat ions industry. lt is an extension ofTMN. It is being developed by TeleManagement Forum (TM
Forum) as component of NGOSS (New Generation OSS) [Reil Uy and Creaner, 2005]. The main difference
between the TMN and eTOM approaches is that the fonncr has been developed starting from networks and
netwo rk equipment (bottom up), while eTOM is a top-down approach. The eTOM framewo rk has bee n
incorporated within tbe TMN tramework as a set of standards (M.3050.lC).

Tbe IEEE sUUJdards for Local Area Network (LAN) and Metropolitan Area Network (MAN) specifications shown
in Table 3. 1 are only conoemed with OS! layers I (physical) and 2 (data link) . Those s peciJications ore structured
s im!l.ar 1'0 OSI specifications. Botb OSI/CMIP and [ ntOOJet/SNMP protocols use IEEE standards for the lower
layers. 1l1e lEEE 802.l( series of specifications define the standards for the various physical media and data link
protocols. lEEE 802. I specifications present overview, architecture, and management. T he IEEE 802.2 standard
specifies the Logical Link Control (LLC) layer. As we saw in Chapter I (Figure 1.14), the LLC layer provides
tnulSparwcy off be various physical media and protocols to the network layer. Tbe others in series arc tor specific
media and protocols. For e l(Sffiple, 802.3 s pecif'JCations are fur Ethen~et LANs.
The last category in Table 3.1 addresses several emerging management technologies. One of them is based on
using Web technology. Web server for the management system and Web browsers for network management
stations. ln Web-based management, the organimtion model uses Web s~ver-Web browser architecture. Much of
the object-oriented technology, such as hypermedia server, CORBA-oriented transportation, and client- server
push-technology influence the Web-based management.

The Well-Based Enterprise Management (WBEM) standard is developed by the Desktop .Management Task Force
(DMTF). Lt is based on the Common loforOtalioo Model (CIM) data model transported using CIM Operations over
HTTP.

The Java Management Extension [JMX] is an open Java technolo.gy for management. It defines management
architecture, application programming interfaces (APls). aod managemc.ot servioes under a single umbrc.lla
specification. It was developed under Sun Microsystems's.JMAPI. (Java Management API) initiative.

X'ML is a meta-markup lan.guage standardized by the Worldwide Web Consortium (W3C) for document exchange
in the Web. XML-based network management is based on a network management method, which defines
management information by XML and the exchange of data for management in the form of an XML document,
and it uses an XML documeni-prowssing siandard method for proce-ssing duta.

Common Object Rcq\lest Broker Arcbitecmrc (CORBA)-based Network Management is an object-oriented client-
server model thut uses GORBA. The objects are defined usicng lnterfilce Description Language (IDL) and uses a
distributed managed objects nrchitecture.

With the Web-based management system, not only can object-oriented techno logy be implemented but also the
dedicated workstation constraint is removed by Lhe use of a Web browser. However, which object-oriented
teclmology should an IT manager choose? There is no clear-cui answer to this question, and different vendors huve
implemented NMSs using different technologies for different applications.

3.2. NctworkM.Il nagcment M.odcls

The OSI network model is an ISO standard and is most oomP'lete of all U~e models.lt is structured and it addresses
a.ll aspects of management. Figure 3.1 shows an OSl network management architectural model thut comprises fOur
models. They are the organization model. the information model. the communication model. and the functions I
model. Although, the above classification is based on the OSI architectuml model, and only parts of it are
applicable to other models, it he.lps us understand the holistic picture of different aspects of network management.

Agurt 3.1 . OSI Ntn.1ork M•nagtmtnl Modtl

The organization model describes the components of 11 network management system, their fuo~1.ions, and their
in.frastruot·ure. The organization model is defined in ISO 1004 0 OSI Systems Management Overview. It defines the
te.rms object. agent, and manager.
The OSI infonnation model deals with r.he structure and r.he organization ofmanagement information. lSO 10165
specifies the Structure of Management Information (SMI) a.nd the information da.tabase, management information
base {MJB). SMI describes how the management infOrmation is structured and MlB deals with the relationship and
storage of management information.

The third model in OSI management is the communication model There are three components· to this--
management application processe$ that function in the application layer, layer management between layers, and
layer operation. which is within r.he layer. We will focus on the application processes in tb.is book.

The functional model is the fourth component of OS! management, which deals with the user-oriented
requirements of network management. As memioned in Chapter I, there are fiVe functional application areas
defined in OSI, namely configmarion, fault, performance, security, and accounting. These are defmcd as system
management fmtctions in OS!.

As mentioned earlier, only OSI presents the most complete model for network management. while the others either
deal with only a subsel or are still in the process of development of standards. All bough a discussion of OSI
managemeDI is not pan of this book, it is briefly covered in Appendix A fur completeness of r.he subjecL OSl deals
with all seven networking layers. Besides, as we shall see in Chapter 10. it lends itself to addressing service and
business management that are more than just networking. 11tc second standard listed in Table 3.1 is SNMP/lntemet
standard. IETF does not define architecture for the SNMP manageme.nt model explicitly. However, it does exisl
implicitly. The organization. information. and communication models are similar to OS.I models. Tbe- SNMP
network managemeru model addresses the functional model in terms of operations, administration, and security.
SNMP-based management is widely used for campus-wide networks. akbougb enterprise--wide net\vorks are also
managed by using distributed configurations ofSNMP-based .network mrinagemenl systems (NMSs). SNMP-based
management systems, 1ools, and applications are addressed in Chapter 9. The third standard listed in Table 3.1 is
the TMN, which is based on the OS! model Thus, the four models apply to TMN. The focus of the TMN standard
is towards managing telecommunications networks. As mentioned earlier, it ex'tends the application functions of
OS! further into business and service considerations. Operations systems support service and business
management. Tbe fourth standard in Table 3.1 is the IEEE Standard on management and is dedicated to Ute
managemeDI of layers I and 2 of the OS! Reference Model.ll is applicable to LAN and MAN. LAN referS to local
area network and MAN (Metropolitan Area Network) refers to metropoli1an (intra..;:ity) network. 11 also addresses
standards on broadband network management, which is of greal relevance to the currenl technology. Broadband
management is covered in Part lV. Since it deals only with physical and da(a link layers, it is primarily concerned
with t.he communication modeL

In Web-based and object-oriented management, !he organization model uses Web server-Web browser
architecture. Much of the objecl-orienred technology, such as bypemiedia server, CORBA-orienled traosportatio.n,
and client-ser\'er push-technology are influencing Web-based management. Applicalions developed under Web-
based management could still fall under the OSI functiona I model. We will now look at each oft he models..

3.3. Organization Mode l

The organization model dc.scribes the components of network management and their rellllionships. Figure 3.2
shows a representation of a tWo-tier model. Network objects consist of network elements such as hosts, hubs,
bridges, routers, etc. They can be classified into managed and unmanaged objecls or elements. The managed
elements h.wc a management process running in them called an agent. The unmanaged elements do DOl have a
management process running in them. For eJUIOiple, one Cl!ll buy a managed or unmanaged hub. Obviously the
managed hub has management capability buill into it and hence is more expensiv.e r.han the unmanaged hub, which
does not have an ageD! running in it. The manager communicates with the ageD! in the managed element.

Figure 3.2. Two-Tltr Nth<o•·k Mauagtmtul Organizallon Mod <I

MOB Managf'm"ri Dnlabace
C:::J Agent Process

The manager manages !he managed element As shown in Figure 3.2, there is a dauibase in the manager, b1n not in
the agent The manager queries and receives management data from the agen.t, processe~ them. and ~tares them in
ils database. The agent can also selld a minimal w of alallll inf>rmation to the manager unsolicited.

Figure 3.3 presents a three-tier conftguration. The intermediate layer acts as both agent and manager. As manager,
it collects data from the network elements, processes them, and stores the results in .its database. As agent. it
transrnits information to the top-level manager. For example, an intermediate system is used for making statistical
measurements on a network and passes the infOrmation as needed t·o the top-level manager. Altematively, an
intermediate NMS could be at a ~site of a network aDd the information is passed on to a remote site.

Flgun 3.3. Thnt-Tirr N<lwork Maoa.gtrutol Organization Modtl

MOB MMDQemont Oalabas<!

C=:J ~nt Pmc:esa

Network domains can be managed mally; and a global view of the networks can be monitored by a manager of
managers (MoM), as sho"'" in Figure 3.4. Thi·s configuration uses nn enterpri·se NMS and is applicable to
organizations with sites distributed across cities. ll is also applicable to a configuration where vendor management
systems manage the domains of their respective components, and MoM manages the entire network.

fllgm-. 3.ol. Ntrwork Msnagemenr Organization Model with MoM

 h'<>M Manager of Maoagers
~·os: M.,_ment D<~tai>B$0
c:::::J Agent process

Netwockmanagement sys1ems can also be configured on a peer-to-peer relationship as shown in Figure 3.5. Iltis is
the dumbbell architecrure shown in figure 1.24. We can recognize the similariy between this and the client-server
architecrure where a bost serves as both a client and a server. An example of sucb a situation would be two network
service providers needing 10 exchange management infonnruion between them. From the user's point of view, the
infoonation traverses bolh networks and needs to be monitored end-to-end.

Figul't 3-~· Dual Rolr of Managtmtnt P1-ocess

Agent NMS Mf.lnagerNMS

ManagerNMS Agent NMS

In I he above discussion, we have used the term network management system (NMS) to mean a sys~em that runs a
management process, not jus1 a managed object. Thus, the agent and the manager devices are
defmed as agent
NMS and manager NMS, as shown in Figure3.4 and Figure 3.5.

3.4. Information Model

An infurmation ~model is concerned witb the structure and storage of information. Let us consider, for example,
how information is structured and stored in a library and is accessed by all. A book is uniquely identified by an
International Standard Book Number (ISBN). It is a ten-digit number identification that refers to a specific edition
of a specific book. For e-xample. ISBN 0-13-437708-7 refers to the boo.k "Understanding SNMP MlBs" by David
Perkins and Evan McGinnis. We can refer to a specific figure in Lhc book by idemil)'ing a chapter number and a
figure number; e.g., Fig. 3. 1 refers to figure I in Chapter 3. Thus, a hierarchy of designation {ISBN, Chapter,
Figure} uniquely identif'es the object, which is a figure in the book. "ISBN," "Chapter," and "Figure" define the
syntax of the three pieces of information associated with the figure; and the deftnition of their meaning in a
dictionary would be the semantics associated with them.
The representation of objects and infurmation that fire relevant to tbeir managemetll forms the management
infOrmation model. As discussed in Section 3.3, information on ne1work components is passed becween the agent
and management processes. 1lte infOrmation model specifies t he information base to describe managed objects and
the relationship between managed objects. The structure defining the syruax and semantics of management
information is spcctfied by Stn.cture of Management. lnfonnation (SMJ). 1lte ini>rmation base is called the
Management InfOrmation Base (MIB). The MJB is used by both age.nt and mnnageme.nt processes to store and
exchange management informution. Tbe MlB associated with an agent is called an agent MIB and the MIB
associated with a manager is designated as the manager MIB. The manager MID consists of information on all the
network components that it manages; whereas the MlB associated witlt an agent process ·needs to know only its
local information, its MlB view. For exrunple, a county may have many librflries. Each librury has an index of all
the books in that location-its MID view. However, theeenrral index at tbe coum:y's main library, which manages
all other libraries, h.as the index of all books in all the county's librari~global manager MlB view.

Figure 3.6 expands the net.,vork configuration that is shown in Figure 3.2 to include the MlB that is associated with
the manager. Thus, the manager has both the management database (MDB) and the MIB. It is important to
distinguish between the two. The MOB is a real database and contains tbe measured or adm.inistrotively configured
value of the elements of the network. On the other hand, the MIS is a virtual database and contains the infOrmation
necessary for processes to exchange infonnation among themselves.

Agut-. 3.6. Nrlwork Configuration wit h Dolo and lnfonn•rlon &••

MOB. Managanonl Oal.tbase

MIS: Manaoement lnlonnaiJon Base
c:=J Agent p , _

Let us illustrate the distinction between MlB and MOB by considering the scenario of adding a component to the
network. Assume that all the hubs in the network are made by a single vendor, say Cablctron. 1l1e manager in
Figure 3.6 has knowledge about the Cabletron hub and its associated parameters in its MIB: and the values
associated with the parameters with the hubs are in its MOB. For example, the number of ports in the hub is a
parameter associated with the hub (Mill infonnation); and if they are 12-port hubs, the values associated with the
number of ports ore 12 (MDB information). Suppose we now odd another Cabletron hub to the network. The
manager would discover the newly added hub during il$ next discovery pro<:ess, which could be just a broadcast
ping from the manager. The tJew hub is another instance of the hub with a new IP acklre..'>S, and its MlB infoi"IIUIIion
is already in the manager' s Mill. Its address and the number of pons associated with it are added to MOB by tbe
manager querying the agent.

Now, let us add a 3Com hub to the network. Let this be the first· time that a 3Com hub is ackled to the network. 1lte
toanager would recognize the addition of a new component to tbe network by the periodic broadcast ping oftbe
network by the manager. However, it wo1~d not know wbat component bas been added until the M1 B infurmmio n
on the 3Com hub Is added 10 the manager's MIB. This information is actually compiled in10 the manager's MIB
schema. After the infOrmation on the 3Com hub has been added to ·the manager's MJB, it can send queries to the
agent residing in the 3Com bub. It then retrieves the valu.es fur the type of hub, the number of ports. etc. and adds
tbem to its MDB.

The M1B that contains data on managed objects need not be limited to just physical elements. For example, in
network management, management information extends infurmation beyond that associated with the description of
network elements or objects. Here are S:Ome examples of infOrmation that can be stored in the MIB.

Network Elements: hubs, bridges, routers, transmission facil ities, etc.

Software Processes: programs, algorithms, protocol functions, databases, etc.

Administrative Information: contact person, account. number, etc.

In fact, any type of infOrmation oou.ld be included as an object in the MIB.

3.4. 1. M11n>•gement [nformlltion Tree

The managed objects are uniquely defined by a tree structu.re specified by the OSJ model and are used in the
Internet model Figure 3.7 shows the generic representation of the tree, defined as tbe Management Information
Tree (Mil). There is a root node and well-defined nodes underneath each node at different levels, designated ns
Level I, Leve12, etc. Ea.ch managed object occupies a node in the tree. In the OSI model, the managed objects arc
defined by a contaimnenl tree representing the MIT.

l'igu•·• 3.7. Ctntri< Rtlll"tstnlolion ofl ht MAnag<m<nclnfonnacion Tnt

Root

Lov<>f 1

Level 2

Level 3

Figu.re 3.8 shows the imernationaUy adopted OSI MIT. The root node does not have an expllcit designation. The
roo1 has three nodes in !he layer bencaH1 it-iso, ccin (itu).nnd iso-ccitt, (iso-itu). The iso defmes the Inccmational
Standards Organization and cciti, or itu, defines tbe lntemational Telecommunications Union (the old name· is
ccitt). The two standards organizations are on the first layer defining managing objects u.nder them. The joint iso-
itu node is for managemenl objects jointly defined by the two organizations. 'The nu.mber in each circle identifies
the designation of the object in each layer. Thus, iso is designated ns I, orgas 1.3, dod, Oepru:tment ofOefense, ~
1.3:6, and the internet~ 1.3.6.1. Alllnt.emet-managed objects w~l be thai nu.mber followed by more dots and
numbers. 11 is to be no1ed lhat the names of the nodes are all in lowercase lett.ers as a convention. which we will
formally defme in Seclio.n 3.6.

Flgurt 3.8. OSI Managtmtnl lnformaiion Trt'f

3.'1.2. Mnnugcd O bject Perspective

Ah.hough a managed object ·need not be a phys'ical object that can be seen, touched, or tell, it is convenienno use a
physical represenlaLion to understand lhe characleristics and operations associated wilh a managed object. Let us
consider an object, which is circular in shape. We can define the object in BngJisb langnage syntax as circle. To
associate a meaning with the object name, circle, we can use Webster' s dictionary definition " a plane figure
bounded by a sing le curved line every point of which is equally distant from the point at lhe center oftbe figure."
ln other words. the definition Is a textual description of lhe object. The object can be viewed and its parameters
changed by people who have access to it. The access privilege could be limited io just accessing it or performing
some action on it; fur exampl e, resetting a counter value to t\\Q. These are all defined as access attributes. If we
envision a scenario .in which the object is used by a nursery school to explain shapes to children. it should at least
have some basic shapes, such as a circle, a .square, etc. We can define the basic objects lhat are required of a group
(ofobjeds) as the swtus of tbe objed- wbetber ills mandatory or optional to bave (implement) that object. 11tis
attribute of the object is defined as the status of lhe object. There could be many types of objects in the nursery
school that are circular in s hape. There is a unique identification and name (objecl identifier and de:;c;rlptor)
associated with each of them, such as a ring, a donut, etc. There could be many instances of ring and donut; but we
are only addressing the types of object, not instances of'thcm here. We have thus defmed the five basic al'tributes of
a managed object type from the Internet perspective. They are name, defin itio n, syntax, access, and status,

A pictorial view of a circular object in the Internet is shown in Figure 3.9(a).

Figure 3.9. Omctt)lltat Vltws or M IUiaged Object

 Access:
ACcess
P<IVII(lge

<f 8 ~~
Syntn;
MOC!Ot of Ob)oct
OoOnllon:
s ..nRnlica-
Textual Oescrlpton
(a) lnlornol PG!11)0<llvu
NoUJia.Uone:
N<iiiiY~In
Atlrlbv.. Vobn

8
qBehaviGr

Allllbu!es: Altribulas:
Clrel4, Otmon~n EMipse. D•me.•slon

(b)OSI Perspecllw

A managed object in the lntemet is defined by five parameters [RFC t t 55). They are:

objectlde11tifwr and descriptor unique 10 and name for !he object

syntax
access tL'ied to model I he object
status
dcfmition access privilege to a managed object

implemenialion requiremenls

textual desert ptlon of the semantics of object type

A modification ofthis is specified in RFC 1212, as we shall see in the next chapter.
The Internet object model is a scalar model and is easy to understand, as seen above. In comrast, the OSl
perspective of a managed object is complell and bas a different set of characteristics. We will extend the above
aonlogy of the circular objed in a nursery to illustrnte an OS! persp«tive.

Figure 3.9(b) presents the conceptual OSI representation of the various characteristics of a managed object. As
mentioned earlier. OSl specifications are object oriented, and hence a managed object belongs to an object class.
The left side of Figure 3.9(b) presents the same circular object in the OSl model. The definition of an object in an
object-oriented perception would include both the s hape and values. Thus, the attribute of the object is a c ircle with
given dimensions. The attribute of an object defines the extemal perspective of the object. It undergoes an
operation "push." Push is not really an OSI operational entity, but is used be.re· to illustrate tbe concept. The
behavior oftl~e object is to change its shape or attribute from a circle to an ellipse. It then sends notifications to the
relevant community lnfurming of its change. Thus, the characteristics of an OSI managed object are:

object class managed object

attributes
operations attributes visible nt its boundary
behavior
·notifications operations that may be applied to it

behavior exhibited by it in response to an operation

notifications emitted by the·object

It is bard to compare the characteristics of a mru18ged object in the Internet and OSI models on a one-to-one bas.is,
as tbey are very much different. However. it can be observed in the conceptual models in Figure 3.9 that the OS!
characteristics-operations, behavior, and notification--are a part of the Internet co0110unications model.
Operation in tbe Internet is done by gel and sct commw1ds. Notification is done by respon.o;e and alarm messages.
The syntax characteristic ofLhe Internet is part ofOSI attributes. Tbe access characteristic ofLhe Internet is a part
of the security function in the OSI functional model The stntus characteristic of the lntemet is handled by
conformance as a part of application services in OSI. Further, in OSI we can create and delete objects, while these
concepts do not exist in the Internet. Objects in early SN MP management are aSSUmed to exist for management
purposes.

Figure 3.10 shows the comparison between Internet and OSJ specifications fur tbe object, packet counter. An
example of a pack·e t counter as a managed object in the Internet model Is given in Figure 3.10(a). The object t;.pe
(we will define object id later) is PktCounter. l11e syntax is Counte.r. Tbe access mode is read-only. The status
implementation is mandatory, which mandates that this obj~ must be implemented if the group it belongs to is
implemented. The description provides the semantics !bat the packet counter counts tbe number of packets.

filgun 3.10. P111:ktl Couulor as Au Exalllt>tt oro M•oaj<d Objtct

(a) Internet Perspective

Characterlstks Example

Object type PktCounter

~yntax P>unter

f'\ccess Read-only

~tatus Mandatory

Description P,unts number of packets

(b) OSl Perspective

haract.erlstics Example

p bject dass Packet Counter

f'\ttrlbutes ~h'lgle-valued

pperatlons ~et,set

Behavior Retrieves or resets values

Notifications ~erates notifications on new value

Too example oft he same counter as a managed object in the OSJ model is given In Figure 3.1 O(b). The counter is
defined as an object class, Packet Counter. It could be re lated to either a sui> or superclass. The attribute value is
single-valued. We can perfOrm get and set operatiolls on its attribute. Its behavior to a se1 ope~:~~tion would be to
reset the counter, or just retrieve data if the operation is get. llte new va lue is sent out as notificlllion.

3.5. Communication M'odcl

We have discussed in the previous section how infOrmation conient is defined (SMI) and stored (MIB). We will
now address the model associated with how the information is el(changed between systems. Management data arc
communicated between agent and manager processes, as well as between manager processes. Three a~pect.~ need to
be addressed in the communication of infOrmation between t.wo entities: Lrnnsport medium of message exchange
(transpon protocol), message rormat of communication (application protocol), and the actual message (commands
and responses). Let us illustrate tbis by an C)(Smpleof Azita buying a car from an automobile salesperson, Roberto.

AziLS could go l'O the automobile dealer and communicate in person 1vith Roberto. Alternatively, she could
communicate with Robeno via the Internet. ln the lbrmer, visual and audio media are tbe transport mechanisms,
and clectron:ic exchange is used in the latter. The communication at the appl.ication level could. be exchanged in
English, Spanish, or any other mutually understandable lnnguage between tbe two. This would be the application-
levetprotocol that is decided between Azita and Roberto. Finally, there are messages exchanged between Azila and
Roberto. Por exa mple, Azif;l could request what cars are available and Roberto would respond wiih the cars that
are in stock. Azita could then set a price range and Roberto responds with cars that match the price range. These
exchanged messages are the commands/requests/operations and rcsponseslnotitications. Tbey can be considered
services requested by Azita and provided by Roberto.

.Figure 3.11 presents the communication model The applications in the manager module initiate requests to tbe
agent in the lnt.emet model. It is pan of the operations in the OSI model. The agent executes the request on the
network element; ie., managed object, and return~ responses to the manager. TI1e trapS/notifications are tbe
unsolicited messages, suclus alarms, generated by the agent.

Flgurt 3.11. Management Communication Model

- 0p&IBII6M/ReqllliSIS_.

Figure 3.12 presents the communication protocol used to transfer infOrmation between managed object and
managing processes, as well as between mMagement processes. The OS! model uses CMfP along with CMIS. The
Internet uses SNMP for communication. The services are part of operations using requests, responses, and alarm
notificatioos.

Agut-e 3. I 2.. f\1Jm.agement Comm unicatinn Tro.nsftr J•roc·ocol.~

UOPrtP (lnt\ilnl!l)
OSI ':_owor~yor Proliles (OSI)

Phy.llcnl Mo<tluln

OST uses both connectioD-orierued and <:onnectionless protocols for rnmsportation. For exampl<; the TP4 transport
layer protocol r.iding on top of the .x.25 protocol could be used. lOr con.nectio~H>riented transporting Blld application
messages. TP4 over Conne<:t ionless Network Protocol is used lOr connectionless transportation. The Internet uses
connectionless UDP/fP protocol fOr transporting messages.

CMlP and SNMP specify the management communication protocols lOr OS! and lntemet management. CMIP is
addressed in Appe.ndix A. SNMP is extensively covered throughout the book.

The application processes invoke the management communication layer protocols. OST deals with messages in the
specification of managed objects. M!!llaged objects and their attributes could be m!!llipulated by ope~:~~t:ions. Basic
application scrvioe modules arc defined by CMIS.ln the Internet, operations are executed by SNMP messages.
3.6. Abstract Syntax Notation One: ASN.I

In both tJIC infOrmation model and the communication model, discussed in the previous sections, we have
addressed fimctions. In these models, SMI needs to be specified syntactically and semantically, which will be the
content of this sect ion.

It Is important for communication among systems that a formalized set of rule$ Is agreed upo n on the structure and
meaning oftbe language of communication, namely syntax and semantics of the language, There are numeroll~ sets
of application and 1ranspo11 protocols. Thus, it is beneficial to choose a synlllctical fOrmat for the language thal
specifies the management protocol in the application layer, wblch is transparent to the rest of the protocol layers.
One such fOrmat is an old and well-proven formal, Abstract Syntax Notation One, ASN.I. We will introduce
ASN.I here to the e.xtent needed to understand iiS use in n.etwork management.. The reader is refen'ed to other
references [Cassel and Austing, 1996; Larmoutb, 1997; Stallings, 1998) for greater depth on the subject.

ASN.I is more than just syntax. It is a fom1BIIanguage developed.jointly by CCJTr (now ITU-T) and ISO for use
with application layers for data transfer between systems. It is also applicable within the >)'Stem fur clea:rly
separating the abstract syntax and the transfer synta.-. at the presentation layer. We define the abstract. syntax as tbe
set of rules used to specifY data types and structures ror the storage of infOrmation. T he transfer syntax represents
the set of rules for communicating information between systems. Thus, the abstract syntax would be applicable to
the information model discussed in Section 3.4 and the trans.k.r syntax to the communication model discussed in
Section 3.5. The abstract syntax can be used W"ith any presentation syntax, the latter depending on the medium of
presentation. The ab~'tmct syntax i n ASN.l makes it independent of: tbe lower-layer protocols.1SO 8824/X.208
standards specifY ASN.l. The algorithm to convert Lhe textual ASN.l syntax to machine-readable code is defmed
in ISO 8825/X.209 standards. It is called Basic Encoding Rules (BER).

3.6.1. Tcm1inology. s,•mbol~, nod Conventions

ASN.I syntax is based on the Bacl"lls system and uses the fOrmal syntax language and grammar of Bac.lms-Nauer
form (BNF), which hoks like:

<name> : : = <defini t ion>

where the not'Btion "<entity>" denotes an "entity" and. the symbol " ::=" represents "defined as."

Let us illusrrate the Backll~ system by developing a simple arithmetic expression <SAE> [Maurer, 1977]:

We can define an entity <digit> as

<digit> : : • 0 I 1 1 2 1 3 1 4 s I 6 I 7 1 a I 9

wbere tbe symbol"'!" represent " or.'" We can also define an operation entity <op> as

<op> : : • + I - I x I I

The definitions on the right side are called primitives. Using these primitives, we can construct more entities- Thus,
an entity number can be constructed from the primitive, <digit>

<number> : : • « iiQ"it > I <digit><numbe r>

For example. the number 9 is tbe digit 9; the number 19 is the concatenation of the digit I iUJd the number 9; and
the number 219 is the concatenation ofdigit2 with the number 19.

We can now construct a simple arithmetic expression <SAE> from the primitives and the construct <number?>.
Thus,

<SAE> : := <number> I <$AE> I <SAE><op><SJ\E>

The IOrmat of each line is defined as a production or assignment.

Let us consider an example with the ti::>llowing two assignments:

<BooleanType> ; ; ~ BOOLEAN
<Booleanvalue> : :- TRUE I li'l\LSE

The expression on the left side specifies the name of the type and the right side is the definition or value of the
type. Thus, BooleanType is defined as BOOLEAN and BooleanValue is defined as either TRUE or FALSE. The
above exrunple illustrates tbe two basic parnmeters associated with an entity, namely, data type and \•alue. The frrst
line is called dalll type assignment and it defines the name of the entity; and the second line, value assignmeni,
specifies the assigned value to the data type. Thus. in the above example the entity BOOLEAN can have assigned
values ofTRUE or FALSE. Entities tbat are aU in capitallerters, such as TRUE and FALSE. are called keywords.

A group of assignments makes up an ASN.I module. For example, a name consists of first, middle, and IIIst names,
and they can be specified as:

pe~son - name ~erson-Name :: =

I
first. "John "',
middle " I" ,
last " Snith "
I

Here person-name, beginning with lowercase letters, is the name of the data type. Pe.rson-Name is a module and
begins with capital le11ers. lbe module comprises three assignments, whose 011mes are first, middl.e, and last with
values "John," "!," and ''Smith.''

Figure 3.13 and Figure 3.14 show two examples of ASN.I data type definition [Larmouth, 1997]. They are L\VO
ASN.I modules defining data types pcrsonneiRecord and trade-Message. Because they are modules, they start with
capital letters. PersoonelRecord describes the personnel recor.cJ of an employee in a global corporation. The Trade-
Message is a module specifying a list of invoices defming customer 11ame, part numbers, quantity, charge. and
security authentication.

Fi~urtJ.tl. ASN.t Dnt.O TY!>< Dtlinltlon Enmpl< I

 PersonnelRecord ::= SET
{ Name,
tttfe GraplucStnng.
divislo~ CHOICE
marketing (OJ SEQUENCE
{Sector.
Country}.
researth (1 J CHOICE
{pr<>:luel·based (OJ NULL.
baSIC [1) NULL}.
produdlon (21 SEQUENCE
{Product · lmo,
Country )
etc:.

Figul't3. 14. ASN. I Data 'l'ypo Otfinitlon Epmpltl

Trade·MI!ssage ::=SEQUENCE
{Invoice -oo INTEGER
name GraphlcSI"ng,
detalls SEUUE.NCt: or-
SEQUENCE
{pM·nO INTEGER
quantity INTEGER},
ci'largo REAL,
aulhMtlc::~tor Se01~rlty -TYf"!)

Secuflly -Type ::= SET

{

Note that in the examples of Figure 3. 13 and Figure 3.14, the data types are built-up from primitive data types:
INTEGER, REAL. NUJ..,L. and GraphicString. GraphicString is one of several Chnracter.String type primitives.
These examples present three kinds of data types, which are built using three construction mechanisms:

alteroativee: CHOICE
list: SET and SEQUENCE
~epet,lHon : SET OF and SEQ0£1-lCE OE"

These constructs are used to buiid structured data types. Just as we SfiW in the <SAE> example earlier, all data
types are buill from the ground up using primitive (also called atomic) entities. ASN.I definition allows both
backward and forward references, 8S well as in-line definition. For iosumce, in Figure 3.13 the dam types Name,
Sector, Country, 111Jd Product-Line are defmed externally .either before or after the. module defming
PersonneiRecord. The data type whose name is title is defined in-line as Lhe data type GraphicString. U could have
been defined as data type Tille lis follows:

t itle Tit le: : • GraphioStdng

Let us analyze the three construe~ 1ypes. ln PersonnelRecord, the person works in one of the three divisions--
marketing, researcll, or production. This is buiU using CHOICE construction. Not.ice that in each of those divisioo_s,
research could be either product-based or basic.

The consrructs SET and SEQUENCE are list 'buiklers. The PersonnelRecord module is a set of da111 types, Name,
GmpbicSiring. Sector, Country, etc., which are all different dat11 lypes. Since they are differe.nt and each is
uniquely associated with a name, they can be encoded and transmitted in any order. For example. they could be
arranged in any of the foUowiog orders:

"Smi t h"' , "Manag er", ( " ~r th '", "Chil e " }

"Manager", ''' Sm.lth", (''Nor t h ", "Chile"}
("Nor t h ", "Chlle ") , '' Manage r ~", "sntith"
etc .

Notice that "North" and "Chile" are always in the same order. This is because it is a list built with SEQUENCE
construction. and the order in the list should be maintained.

The third type of construction is the repetitive types SET OF and SEQUENCE OF. ln tbe example on
1'mdeMessage in Figure J. 14, the SEQUENCE OF coo.wuction is shown. The "de111ils" in the invoice are a
repetition of dal1l consisting of the ordered IL<;t (SEQUENCE construct) of part number and quantity in each
invoice. The repel it ive rec-ords themselves are ordered in a SEQUENCE OF c-onstruction. This means that the data
will be transmiited in the order in which tbey are entered. The encoding scheme will preserve that order while
transmitting the data from one process to another. For example, if data are entered for details in Figure 3.14 as a
sequence {part•no, quantity} in the order {I. 5}. {60, 3). {120, 40}, they will be transmitted in that order by the
sending process. Ifthey had been a SET OF construct instead of a SEQUENCE OF construct for details in Figure
3 . 14, the order is irrelevant. The order in this case for the e;xample could be encoded and transmitted by the sending
process as any of the combinations, II, 5}, {60, 3}, {120. 40}; or {60, 3}, {I, 5}, [120, 40}; or { 120, 40}, {1 , 5},
(60. 3 }; etc. witho1rt relevance to the order.

The NULL data type used in Figure 3.13. PersonneiRecord, is a placeholder. No value needs to be associated with
il except indicating that such a data type exists.

We observe in the PersonoeiRecord example in Figure 3.13 that some assignments have int.egers in square
brackets. For instance,

(p~oduc t-based [ OJ troLL,

basic [1) NULL }

These are called tags.1lle definition of a 111g is introduced in ASN.I to uniquely identiJY a dat11type and will be
discussed in detail later.

We have used several symbols and primitive data.types including keywords in the preceding examples. A complete
Ust of ASN.I symbols is shown in Table 3.2.

'TnbloJ.l. ASN. t Symbols

Symbol Meaning

::: Deflned as or assignment

Or, alternatives, options of a list

TRblt 3.2. ASN.I Symbols

Symbol Meaning

Signed number

Following the·symbol are comments

{) Start and end ofa list

('] Start and end ofa tag

() Start and end of a subtype

Range

Table 3.3 lists some of the frequently used ASN. l keywords. 111e reader is directed to the rereren<:e [Perkins and
McG innis, 1997] for a more complete list.

Table J.l . ASN.I Keywords

Keyword Brief Description

BEGIN Start of an ASN.l module

CHOICE list of alternatives

DEFINITIONS Definition of a data type or managed object

END End of an ASN.l module

EXPORTS Data types that can be exported to other modules

IDENllFIER A sequence of non-negative·numbers

IMPORTS Data types defined In external modules

INTEGER Any negative or non-negative number

NUll A placeholder

OBJECT Used with IDENTIFIER to uniquely Identify an object

OCTET Unbounded 8· blt bytes (octets) of binary data

OF UsedwlthSETandSEQUENCE
TabltJ.J. ASN. I Keywords
Keyword Brief Description

SEQUENCE Ordered list maker

SEQUENCE OF Ordered arrayofrepetltivediJta

SET Unordered list maker

SET OF Unordered list of repetitive data

STRING Used wit h OCTET for denotlne a string of octets

As we said earlier, we can group assignments that are related to each other; this group is cal led a module. A funnnl
definition of a module is as follows:

<mo~>le name> DE FINITIONS :: • BEGI N

<name> :: ~ <definition>
<name> : : • <defini lion>
END

For example, a MID definition module will look like:

RFC1213-MIB DEFINITIONS : :• BEG IN

END

The terms DEFINITIONS, BEGIN, and END arc primitives and are called keywo rds in ASN. I. They are built-in
expressions and have special meaning. The DEFINITIONS indicate that the named module, RFC 1213-MID, is
being defined. The body ofa module ahvays slarts with BEGIN and ends wiih END. Grouping assignmenrs Into
modules has the greal advantage that modules can be impo ned into and exponed from other modules. Thus, they
are reusable.

We notice In the examples described SQ far in this section that we have used both lowercase and uppercase letters.
There are ASN.I conventions to designllle the data. These are shown in Table 3.4.

Tabld.4. ASN .II>ula Trr>< Convtonkons

Data Types Convention E>eample

Object name Initial lowercase letter sysOescr, ethe.rStatspkts

Applicat ion data type Initial uppercase letter Counter. lpAddress

Module Initial uppercase·tett.er PersonneiRecord

TAble 3.4. ASN.I D•IATy~ Conventions

Data TYpes Convention Example

Macro, MIB module All uppercase letters RMON- MIB

Keywords All uppercase letters INTEGER, BEGIN

3.6.2. Objects a nd Oa111 Types

We will now use ASN.I notation to define lhe various dnta types and apply Lhem to dcscn'be objeelll in the context
of SMI and MIB.

We observed in Section 3.6.1 that the darn type could be eilher a simple type (also called primitive, atomic, or
basic), or it could be ~tnc~'lured. In acklirion, we tlllked aboul tag designaLion, which uniquely identif1es lhe datn
type irrespective of the syntnx version. In general, dnta types are defined based on structure and tag. The structure
is subdivided into four cntegories. The tag is subdivided into class and tag number. This is shown in Figure 3. 15.
An object can be lnliquely defined by its tag, orunely class and tag number. For exchange of informatbn between
systems, lhe structure informatbn is alw included.

Figut.. 3. 15. ASN.I Dam Typr Slnt<lurt ond T og

The four caregories of data type structure, sho\Vn in Figure 3.15 are. s'imple type. structured type, tagged 1ype, and
other type.

A simp.le type is one fur which the values are specified directly. For example, we can define a page of a book as
PageNumber of simple 1ype, which can take on any integer value. INTEGER is a simple type. 1lcus,

PaqeNumber : :- ! NTEGER

Similarly, we can define the chapter number ofthe book as

Cttapt erl.'wnber : : • !.NTEGER

Values ror PageNumber can be specified as I, 2, 3.... and for ChapterNumber as l, 2, 3, ...

A datalype is defined as a structured l}lJC when it contains other types. Types that are within a structured lype are
called component types. In the a·bove example. a page number of a book oould be defined as a structured type by a
SEQUENCE construction of CbaprerNumber and PageNumber component data types, Let us call it
BookPngeNumber.
BookPageNumber : :• SEQUENCE
(C~pterNumber , Sepa r ator, Pag e~berl

wbere Separator is a data type with value"-." BookPageNumber is 11 structured type. Values.for BookPngeNumber
would then be like 1-1,2-3, or 6-25.

We can define all the pages of the book as a coUection of individual pages. If we want to define them in a
sequential order from the first page of the first chapter to the last page of the last chapter, we would use a
SEQUENCE OF construction. Let us caD il BookPages.

Boo kl?ages : : • SBQUENCE Oli' ( Bool<J;>ageNumberl

We could defme the same in an altcmative manner ns

Boo kl?ages :: = SEI,lOENCE OF

(
SEQUENCE
(ChapterNumber, Sep arator , PaqeNumberl
I

The above two defin~ions have identical meaning. Values for BookPages would tben be 1-1, 1-2, 1-3, ...• 2-1, 2 -2,
2-3".. The ordering of the values is by the order in which the data are specified and oot by sorting of the
component data types in the structured construct.

The pages of a book could also be specified as a collection of individual pages in random order. The stroomred
type for BookPages would ·then be constructed with the SET OF data type construct:

BookPages :: • SET OF
l
SEQUENCE
(ChapterNumber, Separator , PaqeNumberl
I

Note tbat we could not have used a SET OF construct for BookPageNumber as the order of the chapter number,
separator, and page number is important to keep. However, we could have used the· SET construct to defme
BookPages as

Boo ~..l1 age$ : := SET (ChapterNumbe.r, S.eparator , PageNuml)erl

and assigned values 1-2, 2-3, 1-1, ... in a·mndom order. The order of the. \'8lues in the transmissionofdata between
the sender and the receiver is unimponant. Thus, SET is distinguished from SEQUENCE in two respects. First, the
data types should all be distinct; and second, the order of values in SET is of no consequence, whereas it is critical
in a SEQUENCE constmcl. It is also worth noting that the compone.nf duta types in a SEQUENCE constmct need
not be distinct since the order is preserved.

Tagged type is a type derived. from another type and is given a new tag id. Although a data type bas a unique tag
associated with it, a tag data type is defined to distinguish types wit bin an application. For instance, in Figure 3.14
although "invoice-no" is an INTEGER type, which we will soon Jearn as a universal class with a tag number [ 1]. it
coukl have 'been assigned a local lag id. This is sometimes done to improve the efficiency of encoding.

The fourth and last catego(y of structure is other type, which is a data type lltat is ool pro-defined.lt is chosen from
CHOICE and ANY types, wh1ch are contained in other types. Type CHOICE defines the selection of one value
.from a specified Ust of distinct types.1'hus.ln Figure 3.13, "research'' uses a CHOI CE construct to select one of
the two akematives between "produt1-based," and "~ic.'' We can represent them with specific values instead of
NULL. as fullows:

resea rch Research : : • CHOICE

(
product - based ProductType ,
basic VisibleString
I
P:roduc t Type : := 1/isib!eString

Type ANY is always supplemented with any valid ASN. l type defined in another module. We have given two
represenllltklns for Research, the one above and the other in Figure 3.13. We coukl give a definition of these rwo
options by defining Research as follows:

Rese arch : : • CHOICE

r
p roduc t -basad ANY,
BASIC ANY
I

This definition using ANY specifies lhattbe "product-based" entity could be eil her n "NULL or a ProductType da.ta
type, and similarly "basic" could be either VisibleString or NULL.

Figure 3.15 shows two perspectives of data type-stmcture and tag. Tile structure that we hove so fur described
addresses how the data type is constmcted. On the other hand, tag uniquely identifies the data type. II is required
for enooding the data types for comnwnication. Every data type except CHOlCE and ANY has a tag associated
with it. Tag bas two componems-class and tag number. There are four classes of tag. They are: Universal,
Application. Context-specific, and Private; and each data type belonging to each class is assigned a unique number.

The universal class is the most commonly used class, and the ASN. I liSI of universal class assignments is given in
Tab.le 3.5. A core set of assignments is used in aU applications. Data types bebnging to tbe tmivcrsal class are
application-independenL It Is similar to the use of a gbbal variable in a software program, and is applicable
anywhere in a program. lt need not be defined repeatedly in the subroutines of the program. BOOLEAN nod
1N1'EGER are examples of a universal class, whose rug numbers are [I] and [2], respectively.

Tobit J.~ Univtrsul Class Tog ASslgn1nt.nl'l

Tag Type Name Set of Values

Tablt 3.5. Urtivtrul Class Tag ;\.SSfgmueucs
Tag TYpe Name Set of Values

Universal 1 BOOLEAN TRUE or FALSE

Universal 2 INTEGER 0, Posltlve·and negative numbers

Unlversal 3 BIT STRING A string of binary digits or null set

Unlve•sal4 OCTET STRING A string of Octets or null set

UniversalS NULL Null, single-valued

Universal 6 OBJECT IDENTIFIER Set of values assodated wlth the object

Universal 7 Object description Human readable text describing the object

Universal S EXTERNAL The type is extemal to the standard

Universal 9 REAL Real numbers, expressed in scientific notation Mantissa x Base.,..,• .,,

Unlversal lO ENUMERATED Specified list of Integers

llniversal l l ENCRYPTED Encrypted Inform atlon

Universal 12- Reserved for future use

15

Untversall6 SEQUENCE and SEQUENCE Ordered list of types

OF

Universal 17 SET and SET OF Unordered list of types

Unlversal 18 NumerlcStrlng Digits o-9, space

Untversal19 Prl ntableStrl ng Prl ntable characters

Universal 20 TeletexString Character set specified by CCITT Recommendation T.61

Universal 21 VideoteXStrlng Character set specified by CCITT Recommendation T.lOOandT.lOl

Universal 22 JASStrlng International Alphabet 5, which is equivalent to ASCII

Universal 23 UTcnme nme format YYMMDDHHMM[SS](Iocal t im e differential from universal

standard time]
TAble 3.5. tlrtl\•tffitl ClASS TogASsignn>eliiS

Tag 'TYPe Name Set of Values

Universal 24 GeneraUzedTlme llme format YYYYMMDDHHMM[SS][Iocal time differential from universal

standard time)

Unlversal 25 GraphicStrlng Graphic character set specified by ISO 8824

Unlversal 26 VislbleStrlng Character set speGlfled by ISO 646, equivalent to ASCII

Unlversal 27 GeneralString General character strl ng

Universal 28 CharacterStrl ng Character set

Universal 2!1- Reserved for future use

Tags belonging to the application class are specific to applications. EKamples of application-specific tag oumber.s
are used in examples in Figure 3.13. A universal class tag number can be overridden with an application-specific
tag number. T)ipes in two differem applications can have the same application-specific tag, but carry two different
meanings.

Application-specific assignments are cl.assified as such. For instance, in the above example ofBookPageNumber, if
we II.Ssign Pageld, CbapterNumber, PageNumber, and lbe tugs APPLICATION I, 2, and 3, respectively, tbe
assignment will read

Pageld : := [l\PPLIC!\'l'ION 1) SI!!OOEIICE

[APFLICl\TION 21 Chap terNumber ,
[ ~PPL IC ~TION 3] PageNumber}

Wben defining large modules, the structure can become large. We ca.n introduce descript ive names and comments
on tbe structure for easy reading. Let us expand the above example as follows:

Pageid : :• [APPLICATION 11 SEOCEIICE (

chapter- number [ ~PPLICATIO N 21 CbapterNumber ,
page-number [APPLICATION 3j PagaNumberl
- page numbers are grouped by chapt.er numbers

Tbe descriptive words "chapter munber" and ''page number" do not affect the result when encoding this structure.
oeitber do tbe commen1S folk>wing the "- ''.

In the previous example. both PageNumber and ChapterNumber have INTEGER values. IN110GER can be
classified as either UNIVERSAL 2 or APPLICATION 3. This could be encoded either way. The efficiency of
encoding can be improved if we bad added tb.e data designation lMPLlCIT as below:

PageNumber : '= [~.PPI, IC AT!ON 3j I MPUCIT I NTEGeR

Such an expression tOrces tbe encoding to follow the local tag assignment.
The context-specific type, a subset of an application, is limited to that application. Thus, in Example 1 of Figure
r
3.13, research bas a tag 1] associated with the application of PersonneiRecord and under that application, research
has two context-specific lags [OJ and [1) for product-based and basic.

The private ~· is used extensively by vendors of network products. A vendor is assigned a node on the MIT, and
all br:anches and leaves under that node will be a~igned a private da111 type by the vendor.

Before leaving the subject of tags, it is worth noting a special c:ase of data type INTEGER. lt is no
ENUMERATED type nnd is similar to INTEGER. For example, we can define the colors of the rainbow as
ENUMERATED type integers.

RainbowCo~ors : : • ENUMERATED
I
violet (0)
indigo ( 1 )
blue {2)
green 13)
yello" (4)
orange (5)
red (6)

In this case, when a value of 5 is designated fur the object type RainbowColors, it is implied that it is orange.
RalnbowColors could take on only the seven integer values defined.

An example for the ENUMERATED lype for INTEGER from SNMP MID, which we will cover in Chapter 5,
error status in a get·respome message is:

ErrorStatus : :-
INTEGER)
NOErrOr(O)
tooBig (1 )
noSuobl>lame 12)
badValues t3)
rea<Klnly 14)
genErr (5 )
)
A subtype data t ype is derived ~rom a pa ren t type. For example, in th!l PageNumber examp,Le,
i f "" limit the mximum page number to 2SS ( based on 2'), the.n the assignment would <ead
PageNumber : : • Int eger {0 .. 255)

The parenthesis indicating that it is a subtype expression (see Table 3.2), where the integer range is from 0 to 255.

Let us conclude this section with a rca.l-life example in network management of a data type, which is the address
translation table in SNMP lP MIB. An entry in tbe wble is of data type lpNetMedlaEntry, wh.ich is a sequence o f
fuur mnnnged objects with associated data types as shown below. Each of the fi:>ur objects slllrts with a lowercase
letter, and the assooiated data type with either a capital leiter or is a11 capital letters.

I pNetMediaEntry :: •SEQUENCE I
J.pNe tToMedia! flndex INTEGE:R
i pNe t ToMedia Physl\ddress PhyaAddress
i pNetToMedlaNetAddress I pAddresa
ipNetToMediaType INTEGER!
3.6.3. Ob,j cct arne

In a MIB, there is an identifier for eacb occurrence of an object. In the ASN.l notation, it is the OBJECT
IDENTIFIER. The object identifier lOr the.Internet shown in Figure 3.8 is
i.n l:ernet OBJECT IDENl'IFlER ::o (iso(l) org{3) dod{6 ) internet(l))

Thus. the object identifier for the internet has the value 1.3.6.1 , which we discussed in Section 3.5. 1. The MIT
shown in Figure 3.8 bllS been extended to include tbe clllSs privote type in the MIB and is shown in Figure 3.16.
T hus. the object identifier for private enterprise 1BM 5 1.3.6.1.4.1.2.

· ·igur< 3. t6. IBM "'•• Ex•mt>k: ofil Prlv01c CI~J in MIT

3.6.4. An Example o f Ust• of ASN.1 from ISO 8824

Figure 3.17 shows the ASN. I structure for a pe.rsonnel record. Part (a) shows the informal description, part (b)
shows the ASN.l description of the record, and part (c) shows the description of the record value. There are several
salient points to note in this example. First, there are no simple t::rpes in this example such as the page number
defu:ted in Sootion3.6.3. Tite data aype, Name, does not have an associated object name, although we could defme
one. for example, personnel-name. to such a case, the second IJne in Figure 3. 17(b) would read

personnel- name Name

Frgu o•t 3.17. I SO 88241b•mt>l t Qf U ~t of ASN.l

N3mo: Jcton P Smlh

litto. O~color
Empklyeo Number 51
DQW oi H116: 17 S&pluoiiUt!l 1971
Name of Spouao; MaryTSmih
Numoor of Chlo:rron 2
Child lnfonn~tion
Name Ralph f Smith
Da1o of Blnh 11 No"ember 1957
Child lnform<>tion
Name Susan B Jones
Dale of Bin~ 17 July 1959
(a) lnlormal desafptlon of personnel record

PersooneiRecord ::=(APPLICATION OJ IMPliCIT SET {

NCJtne.
tiUe {OJViSible Siting,
numbQr EmployooNumb«.
daeOIHine 111 Dale.
nomcOfSi>(>UlSo f2J NAmo,
Q>iltlren (3]1MPLICIT SEQUENCE OF Ch!'dlnformatlon DE.FAULT { } )
CIIIIOIMormhiiOII ..• SET (
Name,
oall!Ottlil1n [OJ Dale J
Name ::= )APPliCATION 1) IMPLICIT SEQUENCE (
glvonName Vlsi ~l eSirln g.
lnillal VIGlbleString,
famllyName VlslbleSII'Ino)
EmployeeNumber : a (}\PPLICAflON 2) IMPLICIT INTEGER

Date :• [APPLICATION 3) IMPLICIT VlslbloSirlng - YYYYMMDO

(b) ASN.1 de.Crlpliool of Clio rocood •lfo.lc1uro

(givanNamo 'Jotvf, Initial T. famllyNana "Smll~"},

l1ue "0il1lCIOI'
number '51'
dateOfHire "19710917"
nemaOfSI)CIOSe {olvoanName ' Ma,y'. lnlllafl"'. fnmilyNAme "Smilfl').
Q>lldron
{l (9lvonNomo 'Rolph'. lnlllol ' T", fomllyNomo 'SmPh1,
daloOfBilth ' 19H11 t 11,
{ (giV'O~Namo •s u,..,n·. initial ·.a·. fom,lyName · Jones")
date01Bil1h "1959071T}ll
{c) ASN.1 deS<lrlpUon of a rocord Vlllue

PersonneJRecord is a structured dnta type, SET with the bas.ic component types Name, E.mployeeNumber, Dare.
Name (namcOfSpousc). and Childlnformation. Childfnformation itself is a smactured data type. a SET consisting
ofName and Date as component types. A third structured data type that we notice Is SEQUENCE fur the dam type
Name with Vi.slbleString as the oomponent types.
The SEQUENCE type is used fur Name and the SEQUENCE OF type is used for children, wh.ich contains
component type SEQUENCE. Thus, the ftrst occurrence ofName in PersonneiRccord is a SEQUENCE construct,
and the same construct is embedded in children, which is a SEQUENCE OF construct. Thus, we see a nested
stnrct ure in this e.xrunple..

The structure fur PersonneiRecord is a structured type and it could have bee.n defined without the data designation
LMPUCIT as well as the local tag [APPUCATION 0]. However, as mentioned in Section 3.6.2, the k>caltag type
bas been used ro improve the efficiency of coding. Fun·her use of the IMPLICIT designation makes the coding
more e fficient in that il will be encoded with the [APPUCATION 2] tag and not the UNIVERSAL tag, wllich is
also applica'ble. [n this situation, it would not be encoded as UNIVERSAL type 1..

3.7. Encoding Sc·ructure

The ASN. I syntax conlllining the management information is encoded using the BER defined for the transfer
syntax. The ASCII teKt data are converted to b.it-oriented data. We will describe one specific encoding structure,
called lL V. denoting Type, Length, and Value components of the structure. This is sbown in Figure 3.18. The fuU
record consists oHype, lengtl~ and value.

F·lgurt 3.18. TLV Eucodiug Structurr

Lnngth

---------- --- - .... __ __

Valuo
J
fag Humber
(Hih bits)

The type has tbree subcomponents-class, P/C, and tag number. P/C specifies whether the si.nacture is primitive,
i.e., a simple type or a construct, an~hing other than a simple type. It is encoded as a 1-byte (an octet) field. The
two most significant bits (t' and 8 bit) specifying the class are coded as per values defined in Table J .6. The
value of P/C is 0 for Primitive and I for Constnrct. The lowest 5 bits ( 1- 5) designate the tag value in binary. For
example, rNTEGER, from Table 3.5, bek>ngs to a universal class with a tag value of2 and is a primitive data type.
1-;!ence, the type iS 000000 10.

Tablr 3.6. Valur ofClas.< in Tyt>t

Class B'"Blt 7v. Bit

Universal 0 0

Application 0

Context-spedflc 1 0

Private 1 1
The length specifies the length of the. value field in the number of octets. The length is defined as a series of octets.
It is either one octet (short) or more than one octet (long). The most significant bit (8 11 bir) is set to 0 for a. shor1
length with the low 7 bit~ indicating the length of the value. lf the value field is longer than 127 (maximum
specified by 7 bits). then the long form is used tor length. 1l1e s"' bit of the first octet is marked as I and the rest of
the seven bits oftl~e first. octet indicate how many octets follow to specify the length. For example, a value length
ofl28 would looldike

10000001 10000000

The value field is encoded based on the dar.a·type. lt is a multiple number of octets. The simplest data type value to
encode is an OCTET STRING. An octet string of ' OC I B' B (the string is designated with apostrophes on both sides
and an 8 denoting hexadeoimal .notation) would look like

00001100 00011011

The complete TLV for the string of octets 'OCI B' H is made up from universal (00) Primitive (0) data type of a tag
value of 4 wiU1 a one-octet length field to indicate that there are two octets of value field. rt is

00000100 00000010 00001100 00011011

The integer value is encoded using a twos-complement form. For a positive value, the actual value is the binary
represeOilltion with the most significant always being 0 to indicate a positive sign. IT the integer exceeds 127, an
additional octet of Os is prefixed. Thus, a value of 255 is written as 00000000 11111111 , with the leading 0
indicating the positive sign bit. For a negativ.e integer, the absolute value of the integer is written in a binary fOrm.
The leading sign bit. should be 0 to indicate the positive sign. lnvert alllbe ls to Os and all the Os to 1s. Then add I
to the inver1ed binary digits. The leading sign bit will autamatically become I, indicating a negative integer. For
example, a - 5 will start as 0000010 I. lnverting the bits and adding I, it becomes Ill J I 01 I. Refer to Perkins and
McGinnis [1997.) for the encoding of other values,

J.8. Macros
The data types and values that we have so fur discussed use ASN.I notation of syntax directly and explicitly.
ASN.l language permits extension of this capability to define new data types and values by defining ASN.l
macros. The ASN. I macros also facilirate grouping of instances of a.n object or concisely defining various
characteristi:s assoeiat~-d with an object.

The. structure of a macro takes the fOrm shown in Figure 3. 19.

Flgu r• J .t9. Slructun of an ASN. t Macro

<macroname> MAC~O ."

BEGIN
TYPE NOTATION ::" qynwxOfNewType>
VALUE NOTATION ::= <syntDxOIN9wValuo>
<auxtflatyASstgnments>
ENO
As can be observed from Table 3.4, lhe keyword for a macro is all in capital letters. 'TYPE NOTATION defines the
syntax of the new types and VALUE NOTATION defines the syntax of-the new values. The auxiliary assignments
define and describe any new "types identified.

The OBJECT-IDENTITY macro is used to define information about an OBJECT IDENTlFIER assignment. Figure
3.20 shows an example from RFC 2578 ofcrea1ing an l.nlemet object using an OBJECT-IDENTITY macro. The
two syntactical expressions STATUS and DESCRlPllON are mandatory and the type Refer Part is optional. The
value in VALUE NOTATION defines the object identifier.

Figure 3. 20. OBJECT-IDENTITY Macro )RFC t9021

OBJECT-ID.ENTITY MACRO
BEGIN
TYPE NOTATION ::-
"STATUS' Status
"DESCRIPTION"Text
RererPart
VALUE NOTATION ··=
valuetVALUE OBJECT IDENT1FIER)
Slatus ::=·current' I "deprecated"l"obsole!e"
RaferPart ::= "REFERENCE" Text I empty
Text ::= ·value (IASSiring)'
END

As an example of the usage of the OBJECT-IDENTITY macro, let us consider a regislration authority that registers
all computer science courses that are offered in the Co liege of Computing. Suppose we want to formally register
the network management course cs8113 under the object descriptor esc lasses as lhe 501h suboode. We can specifY
an ASN.I OHJECT-IDENTI'TY macro shown in Figure 3.21. The object ide-ntifier cs8113 bas a value (csclasses
I} .lts si.atus is current and has a description explaining the course of.kring.

Figu•·• 3.2t. E»tmplt for OBJ EC'r-ID ENTITV M»<ro

<:s8113 OBJECT-IDENTITY
STATUS -~
DESCRIPTION Agradualo-levolnetwork mnnagomont C:OUJSO
offe111d INery I<!II by Conege of Compotllll) In
Geotll•a lr~SIIluto ofT~y ·
::: (esctasses 50)

3.9. F unctionul Model

The functional model component of an OSJ model addresses user-oriented applications. llu~y are formally
specified in the OSl model and are shown in Figure 3..22. The model consists of five models: coof~guratioo
management, fmtlt management, performance maoogement, security management, and accounting ma:nagement.
Pan ill of the "book is devoted to the application aspectS ofnehvo[k. management.
Fi~urt 3.22. Ndwork Monagomtnl Fundional Mod•l

Conf~gurntion management addresses the setting and changing of configurations of networks and network
components. Re levant management information is embedded. in managed objeciS, such as switches, hubs, bridges,
and roulec;. Configuration management involves setting up tbese paramele11i. For example, alarm thresholds could
be set to generate alarms when packet loss exceeds a defmed value. information on the object name and contact
pec;on to be contacted when the· component fails could he entered in the management agent. The configuration data
are gillhercd automalically by, and are stored in, the NMS a1 the network operations cemer (NOC). NMS displays
in real-time the configura! ion oft he network and its status.

Fauk management involves detection and isolation of the problem causing the fai lure in the network. An NMS
constantly monitors and displays in real-time major and milor alarms based on 1he severity of fililures. Restoration
of service is done as soon as possible and il could involve reconfigurat·ion of the network, which is part of
configuration manage.ment. In several failure situations, the network could do this au(omatically. Tb.is network
fea1:ure is called self-beallng. ln other situalions, restoration of service does not in.clude .fLxing the cause of t:he
problem. A trouble ticket is generated and followed up for resolution of the problem using a trouble ticket
administration system.

This is dte trouble ticket administrruion of faull management and is used to track problem~ in the network. All
problems-including non-problems-are to be tracked until rcso lved. Period.ic analysis of the data, which are
maintained in a database, is done to establish patterns of t:he problems fur fullow-up nctioa There are trouble·
tracking systems to automate the 1rncking oft roubles from !he automatic generotion of"n trouble ticket by an NMS
to the resolution of the problem.

Performance management is concerned with the performance behavior of the network. The status of the network is
displayed by a network-monitoring system that mel!sures the traffic and performance statistics on the network.
Network statistics include data on traffic volume, network availability, and network delay. Traffic data can be
captured based on the traffic vo iUJnein various segments of the network. Data need to be gathered by the NOC and
updaled inn timely fashion in order to administer pcrformanc.e management. Any configuration changes needed to
relieve temporary congestion in traffic are made by tbe NOC. Permanent relief is engineered by the addition of
equipment and facilities as well as policy changes. Performance-monitoring tools can gather statistics of all
protocol layers. We can analyze the various application-oriented tra ffic such as Web traffic, Internet mai~ file
transrers, etc. The st;ltistics on applications could be used (o make policy decisions on m!IJlaging the applications.
Performance data on nvailabiiJiy and delay are useful for tuning tbe network to increase tbe reliabilily and to
improve its response time.

Securitymanagement covers a broad range ofsecurity aspects. It involves physically securing the network, access
to the network resources, and secured communication over the network. A securily database is established and
maintained by the NOC for access to the network and network informal ion. Any unauthorized access lo 1he
network resources generates an alarm on the NMS at the· NOC. Firewalls are implemented to protect corporate
nel\voiks and nel\vork resources fro m being accessed by unauthor.ized personnel and programs. including virus
programs. Secured oommunieation is concerned with the Ulmpering of information as it traverses the network. The
content of the information should neither be accessed nor altered by unauthorized personnel. Cryptography plays a
vital part in security management.
Accounting management administers cost allocation of the usage of network. Metrics are established to measure
the usage of resources and services provided. Traffic dow gathered by performance management serve a.s input to
this process.

Another dimension of npplication mrinagemenl is concerned with service and business management, which we
discuss in Chapter 7. Service and business management is directed to,vard service providers, in order fi>r them to
accomplish customer satisfaction and to ensure the profJtability of business. T he traffic statistics, trouble ticket
adm.inistratkln data. and accounting management results are inputs to service and busine ss management.

S ummary

The foundations of standards, models, and language needed to delve into the study of·network management have
been addressed in this cllapter. These are the four network management models-OSl, Internet,
Telccommunicat ions Network Management, and 1EEE 802--and a 6.flh emerging o ne using Web techno logy.

The OS! management model categorizes the four functions ofuetwork management into !bur models. They are
configuration, information, commun:icalion, nod application functions. Each of these bas been addressed In detail.
Some parts oft he OS! model are appiicablei.o the other three management models.

The o rganization model describes the management process in the network element, coiled the agem process, and
the management process in the manager. We presented the two-tier and three-tier architectural models and the
relationship between them.

The lnformnlion model addresses the SMI that enables processes running in different components in the network to
exchange management data. We defined the management object for both OS! and Jnternet/SNMP management
models.

1'be two primary communications protocols are CMIP in OSl nod SNMP in the Internet.

We discussed the syntactical format, Abstract Syntax Notation One, and how it is applied to defining managed
o bjects. We presented the terminology, symbols, and conventions used in ASN.l , and then defined the various
categories and structure of data lypes. We defmed Lhe managed objects in OSl and SNMP/lntemel management
models in adequate detail so that we sbouJd be prepared to study SNMP management in the next 1'\\u chapters. We
briefly covered how ASN.I is nppljed io specifying the management information tree and MIB by giving some
specific examples.

The text-oriented ASN.I specifications need to be eneoded for transmission of dam between systems. We
discussed the most w~ely adopted encoding scheme, the Basic Encoding Rules.

We defined the extension to ASN.I In defining an ASN.I macro and presented an example from the SNMP
management model used to create a new object

The application functions are subdivided into five categories of management config uration, fault, performance,
security, and accounting. We have addressed each function briefly In thL~chapter.

Exercises

1. What are the standards used for the various layers In an Ethernet-based network that is managed by the Internet
management protocol? Assume that Ethernet runs on 10 Mbps on an unshielded twisted pair cable.
2. Consider a network of muttivendor network components. Hubs are made by Cabl etron and are managed by
Cabletron's Spectrum Nfv1S (network management .system). Routers are made by Cisco and are managed by
CiscoWorks NMS. Tile entire network. i s managed by general-purpose NM S such as HP OpenVIew Network Node
Manager. Draw a two-tier management network t hat performs conf~guratlon and fault management Explain the
rational e for your configura~on.

3. Redraw the management network configuration of Exercise 2 as a three-tier configuration. What are the
requirements on the three-tier network management system?

4. Explain succ.lnctly the difference between the database of a network manageme.nt system and Its MIB. How do
you Implement each In a network management system?

s. You have been assigned the responsibili ty of addine a new vendor's components with Its own network
management syst.em to an existing network managed by a network management system. ldentlfy the three sets
of functions that you need to do to ful fill your task.

6. Write an ASN.l module that specifies DaysOfWeek as SEQUENCE type with each day of the week (dayl, day2, •.•)
as the type VisibleStrlng. Write the ASN.l description

a. for the structure and

b. for I he value

7. Repeat Exercise 6 defining DaysOIWeek as an ENUMERATED data type, with values from 0 to 6.

8. The foUowlne Is the InfOrmal record structure of my home address:

Name Manl M . Subramanian

Address 1652 Harts Mill Road

City Adanta

State GA

Zip Code 30319

Write for your record:

a. the infurmal record structure

b. ASJil.l description of the record structure
c. lhe record value for your home address

9. Given the definition

olass : : • SET t