Network Management Principles and Practice - 2nd Edition (2010)_2.pdf

Network
Management
Principles and Practice
Mani Subramanian
Get~'!ia lns1iMe ojTWrt!o/Qgy
Jndiall hmit~~~e q]Thdtnoloo Madras
~lo SoftwarePrlYale Umittd
With conbibudon.rfrom
11molhyA. GoOAIYea
IN/Jan /nsliruu ofTechMiogy Madras
N.UsbaRanl
NMSWol-lu Software Private Umit~d

--
Network Management:
Principles and Practice
By: Manl Subramanian; Tlmothy A. Gonsalves; N. Usha Rani
Publisher: Pearson Education India
Pub. Date: 2010
Print ISBN-10: 81-3172-759-9
Print ISBN-13: 978-8-131-72759-1
e-book ISBN- 10: 81-3174-208-3
e-book ISBN-13: 978-8-131-74208-2
Pages in Print Edition: 726

Table of Contents
Copyright
Endorsements
Preface
About the Author
Plitt J: Background
Oiapt« 1. Data Communications and Networl< ManagementOverview
Section 1.1. Analogy cl Telephone Network Management
Section 1.2. Data (Computer) and Telea>mmunicatlon Network
Section 1.3. Distributed CCmputing Environment
Section 1.4. TCP/IP-Based Networks: Internet and Intranet
Section 1.5. Communication Protocols and Standards
Section 1.6. Networks, Systems, and Services
Section 1.7. case Histories on Network, System, ard Servics Management
Section 1.8. Challenges of IT Managers
Section 1.9. Network Management: Goals, Organization, and Functions
Section 1.10. Network ManagementArchitecture and Organization
Section 1.11. Network Management Perspectives
Section 1.1.2. NMS Platform
Section 1.13. CUrrent Status and Future cl Network Mana{jement
Summary
Exercises
Chapter 2. Review of Information Nelwor1< and Technology
Section 2.1. Network Topology
Section 2.2. Local Area Networks
Section 2.3. Network Node Components
Section 2.4. Wide Area Networks
Section 2.5. Transmission Technology

Section 2.6. Integrated Services: ISDN, Frame Relay, and Broadband
Summary
Exerdses
Part II: SNMP and.-rk 14anagement
Chapter 3. Basic Foundations: Sblndards, Models, and Language
Section 3.1. Network Management Standards
Section 3.2. Network Management Models
Section 3.3. Organization Model
Section 3.4. Information Model
Section 3.5. Communication Model
Section 3.6. Abstract Syntax Notation One: ASN.l
Section 3.7. Encoding Structure
Section 3.8. Maaos
Section 3.9. Functi9nal Model
Summary
Exerdses
Clutpter4. SNI4Pv1 Network Management Organization and information 14odels
Section 4.1. Managed Network: Case Histories and Examples
Section 4.2. History of SNMP Management
Section 4.3. Internet Organizations and Standards
Section 4.4. SNMP Model
Section 4.5. Organization Model
Section 4.6. System Overview
Section 4.7. Information Model
Summary
Exerdses

01apter 5. SNMPvl Net-rk Management: comm..,icatlonand F..,ctional Models
Section 5.1. SNMP Communication Model
Section 5.2 Fund:ionall'tldel
Summary
EXercises
chapter 6. 5NMP Management: SNMPY2
5ectlon 6.1. MajorChanges in SNMPv2
5ectlon 6.2. SN.
MPv2 System Architecture
Section 6.3. SNMPv2 Struci)Jre of Management Information
Section 6.4. SNMv2 Management Information Base
Section 6.5. SNMPv2 Prot:oa>l
5ectlon 6.6. COmpatibility with SNMPv1
Summary
EXercises
01apter 7. 5NMP Management: SNMPvl
Section 7.1. SNMPv3 Key Features
Section 7.2. SNMPv3 Documentation Architecture
Section 7.3. Architecture
5ectlon 7.4. SNMPv3 Applications
5ectlon 7.5. SNMPv3 Management Information Base
Section 7.6. Security
5ectlon 7.7. SNMPv3 User-Based Security Model
Section 7.8, Acai!ss Control
Summary
Exercises
01apter 8. 5NMP "!1111agoment: RMON

section 8.1. What is Remote Monitoring?
section 8.2. RMON SMI and MIB
section 8.3. RMON1
section 8.4. RMON2
section 8.5. An-1 Remote Monitoring
section 8.6. A Case Sttdy on Internet TralfiC USing RMON
Results
Summary
Exercises
Chllpter t . Network Manogement TooII, s,.tom., and Engineering
section 9.1. System Utilities for Management
section 9.2. Network Statistics Measurement Systems
section 9.3. MIBEngineering
section 9.4. NMS Design
section 9.5. Network Management Systems
Summary
Exercises
Part W: TMN and Appllcatlortt Management
section 10.1. Wl'rf n-1N?
section 10.2. Operations Systems
section 10.3. n-1N Conce~Xual Model
Section 10.4. n-1N Standards
Section 10.5. n-1N Architecture
section 10.6. n-1N Management Service Architecture
section 10.7. n-1N Integrated View

Sedlon 10.8. 'TMN Implementation
Summary
Exercises
Chapter 11. Networlc ManagementAppllcatloni
Sedlon lLl. Configuration Management
Sedlon 11.2. Fault Management
Sedlon 11.3. Performance Management
Sedlon 11.4. Event Correlation Techniques
Sedlon 11.5. SeOJrity Management
Sedlon 11.6. Accounting Management
Section 11.7. Re~X~rt Management
Sedlon 11.8. Policy-Based Management
Sedlon 11.9. Service Level Management
Summary
Exercises
PartIV: Broadband Networl< Management
Chapter 12. Broadband NetworkManagement: WAN
Sedlon 12.1. Broadtend Network and Servk:es
Section 12.2. A'TM Technology
Section 12.3. A'TM Network Management
Section 12.4. MPLS Network Technology
Sedlon U.S. MPLS OAM Management
Sedlon U.6. Optical and MAN Feeder Networks
Summary
Exercises
Chapter 13. Broadband Networj< Management Wired and Optical AcC<!IS Networks

section 13.1. Broadband Access Network
section 13.2. Broadband Access Technology
section 13.3. cable Modem Techrology
section 13.4. cable lv.:CI!SS Network Management
section 13.5. DOCSIS Standards
section 13.6. DSL kress Netwai<
Section 13.7. Asymmetric Dgtal Subscriber Une
Section 13.B. ADSL Management
Section 13.9. ADSL2, ADSL2+, and VDSL2
section 13.10. Passive O~ical Network
section 13.11. PON Management
Summary
Exercises
Section 14.1. Basic Prindlies
section 14.2. Fixed Broadband Wireless Access Networks
section 14.3. Mot:XIe Wireless Networks
section 14.4. Satellite Networks
Summary
Exercises
section 15.1. Home Networking Technologies
section 15.2. Wired Home Distribution Network
section 15.3. Ethernet: Management
section 15.4. Wireless Home Distribution Networks
section 15.5. IEEE B02.11/WIFI Network
section 15.6. IEEE 802.11 Network Management

Sunrnary
EXercises
Chaptar 16. AdVI-d MlnlgiiiMntTopics
Section 16.1. Introduction
section 16.2. Early Web-Based Development
Section 16.3. CORBA·Based NM Technology
Section 16.4. XML·Based NM Technology
Section 16.5. COmparison of Management Technologies
section 16.6. Recent NM·Related Standards
Summary
Exercise
Aj>pendbt A. 051 Networlc ond System M1n1goment
Section A.l. OSI Management St!ndards
Section A.2. System Overview
Section A.3. Organization Model
section A.4. Information Model
Section A.S. COmmunication Model
Section A.6. Application Functions Management
Sunrnary
Aj>pendbt e. ProjeCt 91ggostlont
Section 8.1. Project Struct~.re and Evaluation
Section 8.2. Projects
Aj>pendl~ C. LaborlltofY Tuto~el
5ectlon C.l. Network Basic Tools Lab

Section C.2. SNMP Tools lab
Section C.3. SNI'F AJ)Pications
Appendlx D.Sp•ud Spec:tnlm Tedlnology: OFOM
5edion 0.1. FourierTransformation
Trademarks
Acronyms
Glossary
References
Index

Copyright
Copyright C 2010 Manl Subramanian
This edilion is published by arrongemeot with P~'MSOn Education, lnc. aodDorling Kindersley Publishing lnc.
This book is sold subject to the condition thatit shall not, by way oftrade or otherwise, be lent, resold hired out, or
othimvise circulated without the publisher's prior written consent in any form ofbinding or cover other than that in
which it is pubtisbed and withoul a similar condition including litis condition being imposed on the subsequent
purchaser and without limiting tbe rights under copyright reserved above, no pan of this publication may be
reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by BOY means (eleoironic,
mechanlcal, pho10copying, recording or otherwise), wilhoul the prior written permission of both the copyright
owner and tbe aboVC>-mentioned publisher ofthis book.
First Impression
Publlshed by Dorllng Kindersley (lndia) Pvt Ltd, licensees ofPearson Education in South Asia.
Head Office: 7th Floor, Knowledge Boulevard, A-8(A). Sector-62, Noidn 201 309, lndia.
Registered Office: 14 Local Shopping Centre, Panchsheel Park, New Delhi II 0 017, India.
Typeset in 10.5/125Times New Roman by Sigllia Business Process, Chennai.
Printed in India
Dedication
In loving memory ofAppa Mahadevan Amma Kalyani
Affectionatelydedicated to R1rth,.Rnvi, and Mcern Subramanian fur sustained support and persistent
patience
With deep appreciation to Stimulating Students Who led me to leoro by teaching

Endorsements
•t have ~n using the first edition since 21Xl3 as core management principles-and practical topics discussed therein made It
an e>ctremely useful reference even for practitioners. I am happy to note that the second edition Is making the contents of
the·te>Ctbook even more appli!<!ble In the current technoi C~~Ical context by Incorporating management of Optical & MPLS
networks widely deployed In the telecommunications network. discussing broadband wireless ne~orks management that
are now ubiquitous and the evolution of standards and t.echnoiOI!ies governing the actual implementation ofthe NMS Itself.
The addition of discussions around Cygnet NMS to Illustrate the NMS architecture concepts and Implementation
considerations are quite useful. 1 am sure·the· book will serve· the needs of both students In academics as well as the
telecom and networking professionals.•
-Nagarajan, Sankor
Head, NMS R&D Services, Tech Mahindra, Chennai, India
"Many congrnl ulations! It is a wonderful book wiU1 lots ofminute details on Network Management
ram sure it will be a ready handbook for the student/professional communities.
My sincere thanks for your time and effortin bringing out the second edition ofthe textbook."
- Seetharaman, V.
Head, ITMC & Cable NOC, Bharti Airtel Limited, Chennni, India
"Prolessor Subramanian has a remarkable ability to set oomplex network engineering and associated
network maJiagement problems in context with well-written explanations and real-work! examples
1hat deal with 1he varied demand~ placed on converging telecommunications networks and the
design and operation ofthe underpinning management systems and protocols.
This book will be extremely useful resource for graduate· and postgraduate students on CSIEE
courses including those studying in their first year ofPhD in Telecommunications Engineering, as it
provides a fantastic coverage ofa wide ra11ge of fundamental network management issues. I fur one
will be using it for my graduat.e students."
-Parr, Gerrard
School of Computing and Information Engineering, University of Ulster, Coleraine campus,
Londonderry, Ireland
"Dr. Subramanian's Network Management Principles and Practice provides the most thorough
treatment of network management. io date. There is no fluff in this book. rt ·is for tl!C serious,
interesr.ed reader. rt proceeds from the ground up. startlng with common network managemeru
protocols and coot!nuing to cover telecommunications management and broadband network
management, focusing o n WANs, optical networks, wireless networks, and home networks. Each
chapter builds nicely upon previous chapters so that there is a logical delivery of infom1ation.
Chapter 9, "Network Management Tools, Systems, a.nd Engineering" is a very useful, practical
chapter. rt provides Lhe reader with the know-how to perfOrm hands-on network management with
various management tools. Chapter l0 covers the classic model of tl!C Telecommunications
Management Network, indispensoble for understanding network management. C hapter II covers
other important aspects of network management, including fimll management, performance
management, security management, policy-based management, and service level management.
Further, C hapter II includes a section on event correlation methods, typically notfound in book~ on
network management, and this is refreshing. These two chapters provide a soUd foundation for
understanding the management ofWANs, optical networks, wireless networks, and home networks
in lhe subsequent chapters. Chapter 16 covers forward-looking topics in network management,

including web-based enterplise management and XML-based management approaches. Titere are
appendices on Project Suggestions and Laboratory Tutorials that render the book quite well·suitcd
fur use in a course on network management. All in all, Dr. Subramanian's book provides a serious,
first-rule trealment ofthe subject."
-Lundy Lewis
Department Chair & Professor. Southern New Hampshire University. Manchester, USA
"This book fills a loog-siandiog need. While there is an abundance of courses and textbooks that
deal with typical topics in networking, there is a lack of such books for Network Management.
Often, concepts and technologies related to Network Management are relegated to the last few
chapters. This book brings out the fuct that there is a wealth ofdetail in this area, which is important
fur practitiooers as well as students.
This book give·s comprehensive details of aU aspects ofnetwork management, in different types of
contemporary networks. Reading it would save .practitioners considerable time and effort, which
they might otherwise put into reading diverse onllne sources. This book also provides the syllabus
structure required fur a fitll-fledged course.on Networking Management. It would be appropriate for
students at the wtdergraduate as well as postgraduate levels."
-Sridhar lyer
Indian institute ofTechnology Bombay. Mumba India
"It is a very comprehensive book on Network Management Systems addressing the needs of
academia, industry both.R&D and Operations. Coming from a person who has worked on all these
functions in telecoms, the good thing about the second edition is the coverage of various
technologies like Wireless, broadband, home networking nod the challenges these technologies pose
to ihe NMS."
-Chalapathi Rao
Vice President & Head Global Delivery, Tata Communications Transformation Services Ltd.,
Chenoa~ Iodin
"Mani Subramanian's book has been of great help in our undergraduate Network Management
course.
Tite book provides both a top-down view on Network Management approaches and a boHom-up
view of the managemeru information available in almost any kind of network technology and
environments. ln particular, it offers quick and visna Iorientatio.n in the jungle of Mills available in
all kinds ofequipment.
The new edition kept the spiril oft·he first edition, but enhanced it significanllywith new and helpful
visualisalions, examples and contempomry management scenarios.
The presentation is interspersed with the author's long-standing experience with Network
Management and its tools, which beIps lhe reader to gain a deC~> understanding of the reasoning
'behind NetworkManagement models, protocols, services nod tools."
- Markus Fiedler
Blekinge lnstituteofTechnology, Karlskrooa, Sweden
"This edition takes offfrom the previous one with a renewed perspective on network management,
incorporating relevant developments over the pas! decade. The ueatment ofthe topic beginning with

a problem statement sels the scene for a detalled coverage on network management systems and
their asscx:iated protcx:ols. Mapping of TMN and eTOM gives a we.U-rouoded view of both the
technical and business process aspects of network management for the telecom operator. Real
industry examples provide. the much-needed meeting ground of theory and practical
implementations. Or. Subramanian's experience with the implemeolalion of network management
in major telcos lends authenticity to the treatment of this interesting sU:bjecL To summarize, the
book would be va.luable to students and professiooa.ls alike."
-Aiyappao Pillai
Head, CNMS, Tata CommunicailinsLtd., Mumbai, lodia

Preface
Network-centric World 1
1nd Role of Network Management
The world in the information era has become network-centric. Daily life, both personal and institutional, is
network-centric. Century-old telephone technology has brought us today to llte converged telccommunicatiom and
data communications technology eni. We are linke-d to and i:nterfitce with the globally ''flat-world" viae-lifeline.
The information era has buib a world of information networks and systems that we need to operate, administer,
maiotain, and provision onan on-going basis. That is our cballenge.
Areas of management ofnetworks, systems, and appiJcations in data and telecommunication services are not only
the responsibility oftelecommunications and networking industries and standards bodies but also of the academic
world. Snadents gradualing from technical Colleges nod universities are eltpected to be prepared to use a network
and also to design and to manage one. The eltisting procedure to design and.test some key networks is heuristic.
Personnel with e1tperience, nod sometimes without, design networks and test ·them in live situations. A corporation
hardly functions today without the deployment of locaJ area. networks (LANs) in their networking environment.
The majority of homes in developed 118tions have a home network distributing voice, video, and data information.
With the prolifernLing use ofthe internet and Web technology, Lhe subject ofnetworking nod network managemenl
has become part of the academic curriculum. This tClttbook. introduced ten years ago, has been part of this
evolution. This newedition brings newtechnologies and services to undergraduateand graduate classrooms in the
broad arena ofwhat is known as network management.
Justificntioo for a Textbook on Network Management
Over a decade ago when I sLnrted teaching a course on network management, there was a need for a textbook that
satisfied quarter/semester requirements. The adoption ofthis book bycoUeges and universities across the world has
partially fiU.ed lltal void. Just as networking education has been brought from the graduate to the undergraduate
level. thiseditim ofthe textbook has been upgraded so that early parts ofthe book can be used at the junior and the
senior undergraduate level and tarter parts at lhe graduate level. It alJJO addresses lhe audience of self.learners who
want to get into or gain knowledge ofnetwork management.
Once again, a note abotrt the title of this book: As noied in the earlier edition, the title does not truly reflect Lhe
contents of the book because we want to keep it succinct. The book covers management principles, practices, and
teclmologies fur managing networks. systems, appllcations, and services. The book is designed to be self-
conLnined, so that the student does not have to traverse in ond out ofthis book' s domain. An atte.mpt has been made
to strike the right balance between theoretical background and practical aspects of networking. The treatment of
practical aspects includes some real-world examples and "war stories." lf"a picture is worth a thousand words,"
this book oomains. about a million. Just as a programming course requires hands-o.n programming exercises, so
does a. network management course. So we have added laboratocy tutorials to the nppeodix, which supplement
classroom teaching.
A major addition to the book is the eXpanded treatment ofbroadbaod network management. It covers "triple play"
services of voice, video, and daLn communications. It spiUlS the netwOrk over the segments ofwide area network
(WAN), access networks to home, and home distribution networks includingLANs. Multimedia communications
is covered from the aspects ofwired transmission media ofcable. digital subscriber line, and optical fiber as well
as tilted and mobile wireless.
This book exposes the student tocurrentnetwork management technology. At the completion ofa course using this
book, the student could either enter the industry with adequate networking knowledge or graduate scboolto pursue
further research and specialization.

About t.be Contents
The book is divided into four part$. Part I deals with baekground material on networking and net,vorking
technologies. Pan naddresses network management archirecltlre$ and protocols. l11e fOcus is on SNMP and lP
network management. Pan ill extends network management to tbe management of telecommunications, which
includes networks, systems, opemHJDs and business services, and management applicaHJDs. The lasi, and final,
Pan IV concludes with the management ofbroadband networks and the latest trends in management technology.
Pan Lconsists ofChapters I and 2. Chapter I presents an overview of networking nod network management.lt is
intended not only as a. background and top-down information, but also as a motivation for the student. Chapter 2
reviews networking technology with a slant on management aspects. The course, fur which this textbook is
intended, assumes thlll the student bas basic knowle<lge of data communications and networking. However, we
review them briefly in Chapters I and 2. lt is extromely difficult to cover much more than the basics of protocols,
algoridmts, and procedures of transport protocol layers 2, 3, and 4, as well as basic ruditne.nts of components of
LAN and WAN networks in such a cour.se. Not much techno logy can be covere<l, and network rnanagement
depends strongly on managing oerwork components that are based on an ever-evolving technology, hence the
presence ofChapter 2. It can be either skipped or covered in parts by ihe·instructor. Relevantsections could also be
used when dealing with subjects in Pans 11, IlL nod rv. However, it would be useful as reference material for non-
classroom learners who want an introduction to networking and network management.
Chapters 3 dtmugh 9 fonn Pan 11. Basic foundations ot models that are needed to build various network
management architectures and protoools are covere<l. OSI-b115ed network management is rarely used. but has some
strong fundamental concepts. For completeness of the subject, it is included in Appendix A. SNMP-based
protocols that manage TCP/lP networks are covered in Chapters 4 through 8. Chapters 4 and 5 are devoted to
learning the concepts and use of SNMP (version I) in network management. Chapters 6 and 7 deal with the
additional specifications defined in versioos 2 and 3. Chapter 8 extends network management using remote
monitoring capabilities. Chapter 9 discusses networking and network management tools. The architecture and
features ofsome ofthe widely used network and systemmanagement systems are also covered.
Network management is more than just managing the network infra.;tructure. Pan Ill addre$ses this trom the
service, business, and applications points of view. Chapter 10 extends the management area to cover broader
aspects of networ.k management &om managing oetwor.k elements and networks to service and business
management as addressed in Telecommunications Management Network (TMN) standards. The knowledge
acquired onmana&rement tools and systems, as weU as on principles in Panll, .
is applied to practical applications i.n
managing iilult. configuration, performance, security, and acoounti.ng, which fOrms the contents ofChapter II.
The demarcation of telecommunications and data communications is becoming increasingly fuzzy in broadband
communications. ln Pan IV, tbe broadband network is segmented into WAN, access network, and home
distribution network. Cbapter 1
2 deals with WAN.lP teclmology bas been extensively dealt with in Parts f and IT.
The management of ATM network, MPLS network, and optical SONET/SDHIDWDM network management is
covered in Chapter 12. Chapter 13 addresses wired broadband access networks in bringing services .from core
WAN to home. Management of cable, DSL. and PON are the three technologies Lhat we cover. Pixed and mobile
wireless access network mnoogement form the subject matter ofChapter 14. Having brought voice, video, and data
ofbroadband service to home, it needs to be distributed inside customer premises and managed. This is the topic of
discussion In ChapUT 15.
The impact of emerging technologies in a We!>-based and object-oriented management system is me future of
management techno logy, which is addressed in Chapter 16.
Suggestions furCourse Syllabus
Pans I and IT along with tbe Laboratory Tutorials in Appendix C form a unit for undergraduate courses. Pans ID
and IV are suitable for gmduate-level oourses with senior-level students admitted with Lhe consent ofthe instructor.

The complete contents of the book are more than can be covered in a quarler or !!Yeo a semes1er course. The
instructor may do a "mi.x and match" between chapters to sui1· fecal needs if SNMP basics and some of the
broadband network management are to be covered in one seme,~ter. Independent of the choice, a project to
aocompaoy the course is recommended, and suggestions are given in Appendix B.
For a dedicated course on network management, U1ere are seve~:~~ I choices. If the focus is on SNMP managemeni,
then Chapters 6 through 8 covering SNMPv2. SNMPv3, and RMON, respectively, can be used. That can be
followed with network management tools and systems (Chapter 9) and applications (Chapter II).
Iftelecommunications is·emphasizcd (this is more likely in computer engineering sthools), !hen it would be good
to include Telecommunications MlUlagement Network (ChaptQr I0).
Ifbroadband services are taught at the schoo~ then Part IV (Chapters 12- 16) could be included.
Finally, ifthe school has a research program on network management, il is suggested that in addition to the special
areas ofinterest, management applicutions in Chapter .II be dealt with in depth. ln addilien, adequate treatment of
Advanced Management Topics (Cbapter 16) is strongly suggested.
To the JnMructor
This 1
extbook is designed as a dual-level book. It can be used for undergraduate courses at the junior or the senior
level or for graduate-level courses. H assumes that the student bas t.akeo a prerequisite course in either data or
telecommunication network or has equivale.nt knowledge. Howeve.r, the book does review networking from a
management focus prior to de-.tling direc1ly with the main subject ofnetwork management.
With the prolific growth of networking, nel:vork management is expected to become part of the academic
curriculum, and. this book will be useftl fur both Computer Science and Electrical and Computer Engineering
schools that specialize in networking.
Online Supplements: Solutions to exercises are available to instructors from the Pearson representative. Visual aids
in the format of PowerPoint sfides fur instructors and students are available to all from the Pearson website that
would facilitate leachiQg and note-taking in 1hc class.
The book could also be used as a reference material ifyou are leaching a Continuing Education course on network
management. lloe PowerPoint slides will come in handy as classroom aids. l have found that students like to take
borne koowledge in the !Orm of a book in addition to the srudetn manua.l. The author welcomes suggestions and
material to be added and may be reached at manims@ieee.org.
To the Student
Although the book is written as a textbook to be adopted for n course, additimal information is provkled in the
book !bat would serve as a reference book for students after graduation. For example, basic information is provided
along with references to serve as a springboard to access additional in-depth details on any specialized
management topic.
The book is also geared toward self-motivated. engineers in the industry who are eager to learn network
management. lfthe engineer bas access to network resources, many ofthe bands-on exercises could be practiced.
At the minimum. it would provide enough tools and knowledge for tbe frustrated worker when he or she eaMoi
access the network resources and does not know why.
Grateiitl Acknowledgements

Tbe major impetus for tbe contents ofthis book bas come from students overtbe course offerings since 1996. lt bas
been reviewod a.t various levels and LO various depths by rnany students.
My thanks flow profusely to Profussor Timothy Gonsalves and Dr. Usha Rnni for making major contributions to
Chapters 9 and 16, respectively. We hove shared together teaching tbe Network Management course at Indian
Institute of Technology Madms, I thank Professor Gemrd Paar for moth•ating me to come out with a second
edition; and it is unfortunate that he coukl not participate as a contributing author due to other commitmen.ts. I owe
gratitude to several persons at NMSWorks who have helped in various ways in the preparation ofthe lllJllluscript
My special thanks to Binu Raghavan for generat.ing topological views of CygNet NMS that is customized for the
textbook presentation, to Madangopal and Adithyan for SOH exercises, and to Santosh Chaudbari for help with
network load statistics figures.
Many reviewers· comments and suggestions have contributed to the richnessofthe contents ofthe first edition that
.form U1e basis of this edition. 1 owe special gtutitude to Lundy Lewis, who bas made numerous and specific
suggestions for improvement in the ftrSt edition. TI1e results of .interviews described in Chapter I generated
positive feedback from reviewers and students; and I thank the fullowing at Georgia Tech .
fur consenting to be
interviewed: Cas D'Angelo, Ron Hutchln.s, Dave Miller, John Mize, and Jobn Mullin. Some of the case histories
were provkled by Rob Beverly, Ron Hutchins, and Dave Mlllcr. Brandon Rhodes and Oleg Kolesnikov provided
someinteresting practicalexercises to be included in the book.
My thanks go to Sojan Jose, Commissioning Editor, M. E. Sethurajan, Senior Production Editor, and Je1mifer
Samuel Sargunar, Associate Production Editor, of Pearson Education for their ever-willing cooperation in
successfully seeing this second edition through to complet.ion.
1 am indebted to the lndian Institute ofTe:chnology Madms fur providing time off fur me to corr~e out with the
second edition. r also want to tbank Professors Ashok Jhunjhunwala, Timothy Gonsalves, and Bhaskar
Ramamurthy of TeNeT Group for providing me with an environment to fulfill my desire of the long-needed
upgrade oftbe book.
My wife, Ruth, continued her contribming role to the book by inputting revisions, ncling as the local copy edi1or,
and beingproduction manager ofmanuscripts. Thank you again, Ruth.

About The Author
Mani Subramanian
Mani Subramanian is a Chair Professor at Indian {nstitute of Technology Madras where he teaches courses on
Network Management and Broadband Communication Systems. Be is also the Director ofNMSWorks Software
Solutions Private Ltd., Chennai. India. He initiated 11 ·network 1011nagement program at Georgia Institute of
Technology in 1996, wJ1ere he is presently on tile Adjunct Faculty. The first edition ofhis book, published in 2000,
is currently adopred ns a te:..tbook in over fifteen countries and translated into Chinese for Higher Education in
Chinn. For over 45 years, he has led research and development at several IT corporations including ~II
Laboratories, has been in the faculty at three tmivcrs.
ities, and bas founded network management companies in the
broadband arena. As an elected Director of the Network Management Forum, be was responsible for the fl'.st
release ofOSI NM specifications. Dr Subramanian received h.is Ph.D. fi:om Purdue University.

Part I: Background
Chapter I presents an overview of tel.ecommunicaiions, dala communlCIItions, and network
management. It is a broad review ofnetworking and network mamigement. It stru1s with an anabgy
of lite telephone network. Telephone network almost always works, and there are reasons tOr its
achieving quality and reliability. You will learn lite relationship between data communications and
telecommunications and b.ow the d.istinction between the two is slowly disappearing. The influence
of desktop computing sod distrlbuted computing environment based on client-server architecture
.bas revolutionized computer communlCIItion. The lnier.
net is a worldwide fabric and you willleam
to appreciate bow infOrmation travels across it around the globe. Basics ofcommunication protocols
and architecture are presenred along with various standard~. Select equivalent applications are used
as illustrations comparingthe Internet and OSI protocols.
Components ofnetwork llUIJl8gemeot are described and complemented by interviews witll network
managers, whose experiences emphasize the need .
fur network managemem and a network
operations renter. Network management is more than just managing networks. Network
management l$ presented from lite perspectives ofservice management, operatiorts support systems,
and business management. The platfOrm !Or a network management system is discussed based on
client-server architecture. Chapter I concludes with a note onfuture trends in network management
technology.
Chapter 2 !Oc:uses on netvork techoology. You may skip this chapter ifyou are familiar with the
practical aspects ofnetworking. Ifyou are knowledgeable on principles ofdata communication, this
chapter. will help you appreciate lite 1eclloological aspects of i1. You will learn how various
topologies are implemented in LAN and WAN networks. Basics of Ethernet, Token Ring, and
FOOl networks are described from a pmctical point ofview. Ofll"oe.se, Elhernet is the most widely
deployed LAN today. LAN evolution from basic Ethernet to Gigabit Ethernet. with half· and full·
duplex configurations is presented. Switched Ethernet adds capability to expand lite bandwidth and
the flexibility of LAN. Virtual LAN is implemented using a switched Ellternet bub accomplishing
flexibility in administmtion of workstations across mukiple LANs. You will learn the various
network components--hubs, bridges, routers, gateways, and protocol converters--that need to be
managed. A brief review of wide area networking and transmission technology is also presented.
Broadband technology is briefly described in Litis chapter. but a dem.iled discussion of it will be
done in Pan rv while addressing the managemem ofbroadband networks and services.

1. Data Communications and Network Management Overview
Objccth'es
Teleoommunications overview
Data oom.municalionsoverview
Evolution ofconverged networks
Desktop processors and LAN technology
Client-Server architec1ure in networking
Internet and intmnet
Nerwork communication protocols
OST and lntemet standards
Broadband networks and services
Need for network management and NMS
Operat·ions, Administmtion, Ma.inlenance, and Provisioning
Network management architecture and organization
Concep1 ofNetwork Operations Center
Perspeclivc.s ofnetwork managemenl
• Network ma11agemeli/ :r."-">tem
Look-ahead ofnetwork management technology
This chapter demonstrates the lleCessity of network system and service management in providing infurmation
technology (IT) services. The challenges thai IT managers face are pl:esented to motivate !he studenl to get excited
about n.etwork management. We start with the ltistory of computer oommunicatiotL walk you through some real-
world case histories, and then present an overview ofvarious aspecls ofnetwork management.
The telephone system is known to be very reliable and dependable, One can make a lelepbone call from anywhere
to anywhere at any time oft.be day and be reasonably sure that the connection will be made and the quality of
conneclion will be good. This is partly due lo the efficient management of the telephone network. Secrion 1.1
introduces the concept of managemem for the success of telephone nelwork by using Operation Support Systems
(OSSs).
Computer communication initially used the 'telephone networlt to carry digital data. There was a clear demarcation
between '!be tmditionalteleconummication network and computer communication network. The evolution ofearly
computer communication networks is dealtwith in Section 1.2.
Computer communicalion technology radically changed with the advent of desktop computing power and
distributed computing environments (DCEs) using local area netvorks (LAN) as described in Sec!ion 1.3. Global
communicalion using Internet became. a reality with the introduction of TCP/IP-based networks. Section 1.4
describes Internet and inlnlnel followed by a dlscussion in Section 1.5 on the importance of communication
pro!oonls and standards.
The nexi phase in the evolution ofIT was !he introduerion of broadband services. Voice, video, and data oould he
delivered on the same medium to homes. lltis has revolutionized the access network to horne and the distribution
network at customer premises. 11 has also iniliated impt"Ovemenl in the core wide area network (WAN). Section 1.6
addresses these issues.
Nelworking is full of "war stories" as experienced by IT managers. Sec!ions I.7 and 1.8 presenl case histories
experienced by IT managers and the challenges !hey face in today's computer and telecommunicalion

enviro.mnent. Interviews with them emphasize the impor11loce of network and system management tools. Section
1.9 describes network management that comprises operations, administration, maimenan.ce, aod provisioning.
Three groups perform these functions: Engineering, Operations, and Installation aod Maintenance (l&M). Section
I. 10 focuses on Network Management System (NMS) aod relationships between its various components. Besides
managing network components, application system resources also need to be managed. TWs is the subject of
Section 1.1 I.
Network. managemem tecbnology is still in an evolutionary mode as network and software technologies advance.
Section 1.12 bricily add.resses NMS platforms baSed on Microsoft. Windows and UNIX operating system. The
future direction~ of network management technology form the content ofSection L 13. As with all chapters in the
book. a sun:unary section and exercises conclude this chapter.
1.1. Analogy ofTclcphone Network Management
The need.for data or computer communication network management is best illustrated.by an analogy oftelephone
·network management. Tbe high degree of reliability of the telephone network is evidenced by the following
illustration. We can pick up a telephone, call anybody, anytime. anywhere in tl!e world, aod be·almost sure to be
connected to the destination. It is reliable and dependable; and the quality ru1d speed ofconnection are good. It is
reliable because it almost a!ways provides se.rvice of voice communication tbat we expect of it. It is dependable
because we can be fairly sure that il works when we need il. especially in an e.mergency situation. such as 911 calls
in 'the USA or military defense situations. The quality ofservice is generally good; and we can have a conversation
across !he world with the same clarity that we bave when we call our neighbor.
The pre~nt-dny telephone network is referred to as Public-Switched Telephone Network (PSTN). aod is probably
the best example of traffic engineering providing guaranteed Quality of Service. The reason .for such reliability,
dependability, and quality Is more than careful planning. design. aod implementation of a good telephone network
using good and reliable components. 'Tlte key is management aod operation of the oetwor.k. Much of the
management of the network is so well automated that it becomes part of the operation. Let us first look at the
telephone network architecture and then at some oflhe operations support systems tbat manage it. In the 1970s the
telecommunications industJy switched to digital services, which followed much the same pattern as voice services
and conceived a vision of end-to-end circuil-switc.hed services. known as the Broadband Integrated Services
DigitalNetwork(B-ISON).B-ISON is now being replaced by Internet and Broadband Service.
The ar.chitecntre ofa telephone network is hierarchical as shown in Figure 1.1[AT&T 1977]. There are five levels
of network switches and three types of trunks that connect these switches. A trunk is a logical link between two
switches and may traverse one or more physical links. The end office (Class 5), wh.ich is lowest in the hierarchy, ls
the local switching office. The customer's telephone or Private Branch Exchange (PBX) Is connected to the end
office via a dedicated link called " loop." The other fuur higher levels of switches (Class 4 through Class I) are
tandem or toll switches carrying toll (long-<listance) calls. Because of the advance in switching technology and
economy oftransmission, ctasse·s I through 4 have been merged into a single class rercrred to as Class 4. A direct
trunk connects two end offices, a toll-connecting trunk connects an end office to any toll office, and 11.toll(internal)
trunk connects any two toll offices.
Figure 1.1.Td•t•hou• Notwork Mod<l

End Cllfoee EndOfflc<>
Class5 SwiiCh Class 5 Switch
• t
6> 0
Voire Voice
To Oliler
Regional Centers
Sedional Cenlers
Primal)' Centers
ToUCenteB
EndOff.a;s
Primary Centers
Toft Centers
EndOiftee$
Cia$$ 4 Toll Polnls
EndOtr,._
Logond;
.... I..OQP
- Olrecl Trunk
- - Toii.COnnoc~ng Trunk
- Toii Trunk
From the lo<:al Class 5 office to the called party's Class 5 office, there are multiple routes. A circuit connection is
set. up either directly using a local trunk or via higher-level switches and routers. Primary and secondary routes are
alrea~y programmed into the switc.h. lftbe primary route Is broken or facilities over the primary route are filled to
capacity, an alternate route is automatically assigned. For e.xrunple, on Mother's Day, which is the busiest
telephone-troffic day ofthe year in theUnited States, a call io tbe neighboring town could trove! clear across the
country and. back iftb.at's the route where adequate bandwidth is available. Let us remember that there is a 3-hour
time difference·between the two coasts, and traffic in the West Coast starts 3 hours laterlhan the East Coast.
To ensure tbe quality of service in a telephone network, operations support systems are implemented. They
constantly monitor the various parometerll oftbe network. Forexa.mpte, to ensure that there is adequate band,vidLb
to carry the· troffic over the facilities, a troffic measurement system constantly measures iroffic over switch
appearances. The results are analyzed for facility-planning purposes. They also provide real-time input to a NMS
when there is excessive blocking (traffic over the capacity oft.he trunk group) in any link.
The qualily of the call, measured in terms of signal-t~no ise (SIN) rotio, is measured regularly by a trunk
maintenance. system. This system accesses all the trunks in an office during the night· and does a loo~back test to
the far end. lbe results are analyz.ed in the morning and corrective actions taken. For example, ifthe SIN ral.io ofa
trunk is below the ac.ceplaoce level, the trunk is nimovcd from service before the· customer experiel.lCes poor
performance.

Par a given region, there is a network operntions cemer (NOC) where the global s1atus of!he network is mo.nitored.
Traffic patterns are constant.ly observed and corrective operations are taken, ifneeded, in real time. The NOC is t:he
nerve center oftelephone network operations.
lt is worlh noting !hat the telephone .network is lll1IJI8ged from the users' perspective, and not nom that of the
system or the service provider, even though the objectives of both are the same. However, with emphasis on the
user's point ofv.iew, the fnt objective in operations is restoration ofservice and then the qualiiy and economy of
service. Thus, isolation ofthe problem and providing allelll8tive means of service, by either manual or automated
means, bocome more important !han fixing tbe problem.
To manage a network remotely, i.e., to monitor and control network componems from a central location. network
management functions need to he bui.lt into the components of the network as much as possible. In tbat sense,
network component designs should include network 01anagement functions as part of their requirements and
speci.fications.
The computer or da.ta communication network has no1m3tured to the same ell1em a.
s the telephone network. Data
communications technology is merging with telephone technology. Dala and modern telecommunication networks
are evolving into broadband communication networks and are more complicated 1han the plain old telephone.
service (POTS). Analog audio and video services are migrating to digillll services. The analog hierarchy of low-to-
high bandwidth signals is being mmsmitted across the globe using a Synchronous Digital Hierarchy (SOH) mode.
Network management and operations of lhese digital networks are continuously being developed as new
l.echnologies emerge. Furlher, the telephone industry all over the world had been monopolistic and 1hus singlt>
vendor oriented. This is no longer true. Digital-based computer communications started 8ll a private industry and iS
hence m1~tivendor oriented. Unfortunately, this bas produced enoanous problems 10 users because network
components supplied by different vendors do not always communicate with eacb other. The network or
information systems manager. who has the responsibility of keeping the service alive all the time, has been
confronted with resolving the issue as oow tecbnology and oow vendor products emanate. This situation has been
recognized by various industrial and standard groups and is being continuously addressed.
1.2. Da.hl (Computer) 110d T elecommunication Network
Network communications lechnology deals with the lheorY and application of electrical engiooering, computer
engineering. and computer science to aU types of communication over networks. It also addresses accessing of
daUlbases and applications remotely over LANs 8ll well as switched and private lines. A basic network can be
vJe,ved as interconnected nodes and links as shown in Figure 1.2. A link carries infurmalion from one node to
another that. is directly connected to it. A node behaves as an end (tenninating or originaling) node, or an
intennediate node. or both. If the node behaves as an end node, infonnation either originates or tenninates there.
An intermediate node redirects the informalion from one link to another. End-office nodes mentioned in Section
1.1 behave as end nodes. A node can drop and add infur01ation channels and til the same time switch infurmation
t·ransparently between two links. EaCh end node has aconnection to a user interface if1he infOrmation originates or
termina1es !here. Tlti.s interface could use My type of equipment-audio, video, or Data Tenninating Equipment
(DTB). A DTE is anyequipment I hat generates or accepts digital da1a.
Flgul't 1.2. LogicAl Nttwnrk Modtt

VIdeo
EN: End NOC!o
IN. lnlermodialo NIXIe Wo.rkslallon
Daia coo be trnnsmilled eiiher in an analog or digital formal. The analog da!a are sent eilher·as a baseband (e.g.,
voice data from !he switching office 10 !he customer premises) or on top of a carrie.
r (e.g., cable TV). Digital data
are eilher directly generated by the user equipmem (e.g., computer 1erminnl) or as analog data and are convened lo
digital data (e.g., Integrated Services Digital Network. (ISDN) connection to cus1omer premises). The ]utter
scenario of the ability to handle integrated digital and analog signals is beooming extremely importanl as in the
case of multimedia broadband services. Management considerations associated with them are alsO very
oballenging, as we will sec in Pan lV. Long.<fistance data transmission today is mos1ly digital due 10 its superior
prioe and performance.
Data ore sen! from the originating to the terminating node via a direct link. or via a tandem ofliok.s and intermediate
nodes. Dala can be transmiued in one of three modes: circuit switched, message switched, or packet switched. Ln
!he circuit-switched mode, a physical circuit is established between the originating and terminating ends befure the
data are transmitted. The circuit is released or "tom down" aftercompletion oftransmission.
ln message-switched and packet-switched modes, data are broken int·o packets and each packet is enveloped with
destination and originating addresSes. 1lte message-switched mode is used to send long messages) such as emall.
The packet-switched mode is used to transmit small packets used in applications such as intera~1ive
communication. Bridges and routers open each packet to find the destination addre$5 and switch the data to the
appropriate output links. The path between thetwo ends may change during the transmission ofa message because
each packel may take a differenl route. They are reassembled in I he right order at the receiving end. The main
difference between message and packet swilcb.ing is thm in the former, data are stored by !he system and then

retrieved by the user at a later time (e.g, email). l,o the packet-switched mode, packets fire fragmented and
reassembled in almost real t·ime. They are stored in the system only long enough to receive aU the packets in the
message. ln Europe, X.25 packet-switched network was ex-tensively used in Public-Switched Data Network
(PSDN).
Neh~rk communications are commonly classified as either data communications or telecommunications. This
classif
tcation is based on historical evolution. The te.lephone network, which came into existence first, was known
as a telecommunication network. It is a circuir-swilcbed network that is structured as a public network accessible
by any user. The telephone network represents a telecommunication net,vork. The org-anization that provides this
service iscalled a telecommunication service provider (e.g., AT&T, British Telecom, NTI, BSNL, etc.).
With the advent ofoomptrtcrs, the terminology data communication network carne into vogue. It is also sometimes
called computer communication network. The telecommun1catiorts infrastructure was, and is, still used for data
communications. Figure 1.3 shows an early configuration of terminal-to-host and host-to-host commuoicat.ions,
and how data and telecommunication networks interface w ilh each other. To interface, a terminal or host connected
to an end-office switch communicates with the host connected to another end-office switch by modems at each
end. Modems transfer information from digitallo analog ai the source (telephone nehvorks carried analog signals)
and back to digilal at the destinatk>n.
Figurt t.l.Anotog•nd Data Ttltrommunlu rlon Nttworks
Modem telecommunication networks mostly carry digital data. The nodes in Figure 1.4 are digital switches.
Analog signals from telephones are converted to digital signals either at the customer premises or the central office.
figure 1.4 shows a corporate or enterprise .environment in the stage of the .evolution of data a.nd telephone
communications. A number of telephones and computer terminals at various corporate sites are connected by
telecommunication network. Telephones are locally interconne<:ted to each other by a local switch, PBX, at the
customer premises, which interfaces digitally to the telephone .
network. The computer terminals arecoMected to a
communication controller, such as a djgital mutt iplexer, which provides a single interface to the telephone network.
Figurt 1..&.. Oiaie:al Data and Te:IKOIIHUWJication NttVOI'k s

With the advent of desktop computers and LAN, data communication was revolutionized. Desktop computers
could communicate with each other over the LAN. This led to a Distributed Computing Environment (DCE),
which is discussed in tbe next section.
1.3. DL
~ttibuted Computing E nviron ment
Figure 1.5 shows a LAN with hosts and workstations. Let us ob.serve that dtey are workstations with processing
power and not just dumb terminals as described in the previous section. Any workstation can communicate with
any host on the LAN. Therecan be a large oumber ofworkstatioDS and bosts depending on the type ofLAN.D1Es
connected to different LANs that are gcogrnpbically far apari can communicate via telecommunication net,vork,
either public or private switched. The system of links eotu1ecting remote LANs is called a WAN. A LAN is
physically connected to a WAN by a bridge or a router as shown in Figure I.S(b). We will discuss the types of
LANs and WANs in Chapter 2. .First, we want to bring out two important aspects ofDCE in this section.
Figurt t..5. DCE with L
~Ns IUid WANs

~ 1l g
~
w...- ._ W<NWon
0 I ElJiemot I
~
I
1i
w-..
-·
(•1-ondVI-ool-"CCOIAo'l
Q~
/ =
:=-'6
LANC
-%-- WNI
The first aspect is the question ofwhether the different plalforms and applications mooing on DCBs have the
ability to communicate with each other. In the early stage of communication network evolution, proprietary
interfaces between platforms and processeJ> were implememed by telecommunication service providers and
computer vendors to communicate autonomously within each of their networks. For example, Bell System, a
monopolistic telecommunlcatbn service provider, and IDM, the largest computer vendor, established transmission,
switching, and interface standards and manufuctured their own communications equipment to meet them. They
made significant contributions to the standards bodies to make such specifications the industry standards. For
customer premises equipment (CPE) interface, specifications are published for them to interlilce cleanly with the
network. For example, Bell System published specifications for Customer Service Unit (CSU) for customer
equipment to interface with the network. However, as the telecommunications industry rapidly grew, national and
intematb nal standards needed to be established for communication between equipment provided by various
vendors. Protocols and database st11ndards for handshaking and information exchan.ge are discussed in the
following sections. For now, we will assume that the different processors 1llld prooesses running on them collld
communicate with each other.
The second aspect of DCB is the ability of processors attached to LANs to do multiple functlons. They could
continue, as dumb terminals did, to request a bost to perfunn the functions and retmn the results. Alternatively,
they could request some special functions to be performed by a host-and it could be any processor in the
network-and receive the results. In this scenario, the processor that requests a service is called the client; and the
processor tbat provides the service is called the server. Such a configuration is termed a client- Saverenvironment.
Allhough the terminology of clieru and server is commonly associated with t.he processors, the more accurate

defnition shouk! be associated with the processes. Thus, the process that iniliates a transaction 1.0 run an
application in either a local or a remote processor is called the client. The application process that is invoked by a
client process is called ·the server. 1lte .serv-er returns the results to the client. Tbe application designed to take
advantage of such a capability in a network is called a clie.m- server architecture. With such an interpretation, the
e llen! and server processescan coexist in the same processor or in different processors.
We will now go into some detail on ·the salient characteristics and features ofclient-server architecture and models,
as they are very pertinent to nct~:>rk management applications and architecture. A simple client-server model is
shown in Figure 1.6. There is apt to be confusion between wh.ich is a client and which is a server in distributed
computing architedure. The 'best way to distinguish 'between the two is to remember that the client initiates the
request and the server responds.
Flgw·• 1.6. Simplt Clitni-Str'tr Modtl
Cllel'l
The client initiates a request to tbe server and waits. Tbe server executes tbe prooess to provide the requeSied
service and sends the resuk$ to the client. lt is worth noting that the client cannot initiate a process in thu server.
Thus. tbe process should have already been started in the server and be waiting for request.s to be processed.
A rea.l-world analogy to the clieot-server operation is a post offioe. The clerk behind the counter is ready and
waiting for a client. She is a server. When a customer walks in and initiates a transaction, for example, ordering
stamps, the clerk responds. The customer is the client. After the clerk gives me Sinmps to the customer, I.e., she has
delivered the resuks, the customer leaves and the cler.k, as a server, goes into a waiting modeuntil the next client
initiates a transaction.
As with any system, delays and breakdowns of COIIliDuoiCation need to be considered in this model The server
may be providing the service to many clients that are conncctoo to it on a LAN. as shown in Figure I.7(a). Eaeh
client's request is normally proces.~ed by the server according to the FrFO rule--f~rst in first out. This dei3y could
be min.im.ized, but not eliminated, by concun:eot processing ofrequests by the server. It is also possible that, due to
either the communication link or some other abnormal termination, the server may never return the result to th.c
client. The application on the client should be programmed to take care ofsllCh deficiencies in communication.
Fi~ur< 1.7. Clitni-Strvt r In Discrlbused Cumt>ulio.g.Environmeuc

.•
..
:...~
·..~,
' ··....
··•., ......~.~.
.~ ..··
...~. ............__,.,..
··..................________,
_
........-.....--~ - ~
........- ····
..· ...
i
'.... ·.
·..
...
g ...~....
.•' ,-
...
.......__.......... _.,.~·····
.........................
'
..f
Since the client and application are processes runnlng in nDCB, each oftbem can be designed to execute a specific
function efficiently. Further. each function may be under the jurisdiction of different departments in an
organization. An example ofthis is shown in Figure 1.7(b). joe.stooe@source.com (Joe Stone's user id) using a
client in a network sends a message to sally.jones@lest.com (Sally Jones' user id) on the network. The message
first goes to tbe mall server on the network. BefOre it can pro<:ess the request, the mall server needs to know the
network !!ddress ofsally.jones, which is dest.com. Therefore, it makes a requestto the domain name server (DNS)
on the network for routing information for the address ofdest.com. When it receives that information, it sends out
joe.stone' s message via the bridge connected to the network. It then sends a message to joe.stone on the client
stating that the message has been sent (or not sent because the dest.com address does not exist in the DNS). In ·this
e-
xample, the mail se.rver behaves both as a server and as a client. The three processes in this scenario, namely the
client, lhc mail server, and the DNS, are considered cooperative computing processes and may be running in three
separate platfonns on remote LANs connected by a WA:N. Communication between these processes is called peer-
to-peer communication. We wi.ll soon learn bow network. management fits into such a model nod manages
components on lbe network. that perform cooperative computing using peer-to-peer communication. However,
befOre we pursue that.. let ns first look at a new dimension that the DCE has caused ·networking to mushroom
into-t:helntemet.

lA. TCP/JP-Based Networks: Internet and .Intranet
Transmission Control Prot.ocoVlmemCI Prot.ocol (TCPIIP) Js a suile of protocols that enable networks to be
interconnected. It forms the basic foundation ofthe Internet. Architecture and protocols are discussed in detail in
Section 1.5. We will brie·fly Mscribe tbe role TCP/IP plays in Internet. Nodes in the network route packets using
network protocol IP, a connectionless protocol. That means there is no guarantee that the packet will be delivered
to the destination node. However, end-to-end communication can be guaranteed by using the transport protoco~
TCP. Thus, ifa packet is lost by LP, the acknowledgement process ofTCP ensures successful retransmission ofthe
packet.
TCP/TP suite of protocols contains more than TCP and IP protocols. TCP is a connection-oriented protocol A
complement to TCP is User Dalagrnm Protocol (UDP)., which is a co.nnectionless protocol. Much oflntemet traffic
really uses UDPIIP due to the reliability ofdata transmission. For example, email and management messages are
carried by connectionless transmission.
lbe Internet is a network of networks. Just as we can communicate over the telecommunication ·network using the
telephone from anywhere to anywhere in the world today, we can now communicate worldwide over thecomputer
network via email. We looked at the example of Joe St.one sending a message to Sally Jones in the previous
section, Figure 1.7(b). Let us expand that example and visualize that Joe Stone, who is at the College ofComptrting
building of Georgia lnstintte ofTechnology, is sending an email to Sally Jones at her home in Australia. SaJiy is
connected to an Internet service provider, ostrich. com. Similar to a unique telephone number that each station has
in the telephone world, each person has a unique address in the computer communication netwOrk. Joe's email
address isjoe@cc.gatecb.edu and SaUy's address issally@ostrlcb.com.au.
Figure 1.8 shows an lnt.emet configuration fOr our scenario. Assume that Joe is at Workstation A on LAN A
sending the ernall to Sally at Workstation Z that is "telccormected" to her Internet service provider's email server
on LAN Z. Two serve.
rs shown on LA~ A are mail server and DNS. J't should be noted that the servers do not b.we
to be on the same LAN as the sender's LAN, as shown in Figure 1.8. The two servers cooperatively transmit the
email message to LANCon the computer network made up ofbridges and routers. lbe link between LAN A and
LAN C could bea WAN. tnfurmation is transported exclusively based on TCPITP-based protocols. We will explain
TCP/LP protocol in Section 1.5.2.
Flgurt t.8.1nttrnet Conllgurnclon

lnfonnation from LAN C progresses vill gateways and WANs to the computer communications network in
Australia, as shown in Pigure 1.8. The WAN network shown is composed of a ser.ies of networks, not all
necessarily using TCP/TP prot~ol Gateways between them serve as the interfaces between dissimilar and
independent autonomous networks and perfurm many functions including protocol COilversions. Autnnomous
networks have liitle knowledge ofeach other's aitrlbutes, configumlions, and addresses and yet communication is
automatically taken care ofey a bierarcbyoflnternet servers along the path.
Joe's email message finally reaches the email server on LAN Z in Australia and is stored there until Sally retrieves
it via her Internet link with an Internet service provider's server. ln fact, email messages are trMsmitie.d by a

"store-and-furward" scheme all along lhe path. 1n addition, the final sLage in the Lntemetlink uses a TCPIIP suite
ofprotocols.
Thus, viathe Interne!, any user can communicate with any other user in any pan of the world as IQng as both are
connected to n network that is pan of the lnternel. This .has aIso revolutionized the software user interfuce
providing capabilities li.ke web pages so that you can gather information about any1hing in the world instantly
through the 1nternet.
Another per.speclive ofthe Internet is to view it as a layered architecture, as shown in Figure 1.9. This architecture
shows the global Internet as concentric layers of workstations, LANs, and WANs interconnected by fubries of
Medium Access Controls (MACs), switches, and gateways. Workstations belong to the user plane, LANs to the
LAN plane. and WANs to the WAN plane. The interlilces are defined as the fabdcs. MAC fabric interfaces the
user plane t·o the LAN plane. LAN and WAN planes interface through switching fabric. WANs in tlte WAN plane
interface wii.h each other via the gateway fa'bric.
Flgun 1.9. loltrott Fobri< Mod<l
~~ GatowiiYIOb<icl
( ] SWitchlnolab<lc
MACiob1C
USER PLANE
The user's workstation intermces to a LAN via a MAC. which will beexplained in Chapter 2. LANs internee to a
WAN by a switching fabric of bridges, routers, and switches. Enoh WAN may be considered as an acrtooomotl~
network, and hence needs a gateway to communicate with another WAN. Gateway fllbric iotercOtmects different

WANs. Thus, a single lnternet plane at the core of the model multiplies into millions and mlllions of users at the
user plane, with virtuaiJy no limits in sight.
Communlcation between two users in the user plane, i.e., logical link connection on the user plane, takes the
following path. The physical path traverses the MAC fabric, the LAN plane, the switching fabric, the WAN plane,
and the gateway fabric to the core and then returns (o the user plane going through all the planes and interface
fabrics in reverse..
The huge success oflnternet teclmology has spawned Intranet h::chnology. The main distin~1ion between lhe two is
similarto that between public and private switched networks. An intranet is a private network and access to it is
controlled by the enterprise that owns it. whereas the Internetis public.
The impaot of ihe Internet in nelvorking is enormous. How do we manage the Inte.met? For example, ifan email
does not reach its destination, how do we detect where the communication broke down? How do we take
advan111ge of lnten-.et ·capabilities to impl.eme.nt network manage.ment? We have not yet defined network
management and how it fits into the client-server environment. However, before we define what network
management is, let us briefly look at the protocols and protocol architecture that enable successful communication
between different components on the network.
1.5. Commun.ic:ttion Protocols and Standar ds
Consider a fax machine and a modem bought from a local store successfully sending a fux to a modem and fax
machine anywhere in the wodd. even though each fax machineand attacl-.ed modem were manufuctured by local
vendors. Likewise, isn't it a technological miracle thattOJ computers located anywhere in the world can transmit
messages to each other as long as each is connected to the Internet? The key to the practical success of these and
other such teohnologies is the interoperability of ihe two end devices. More and more vendors in more and more.
countries have recognized that in this world of shrinking cyberspace and advancing modem communication
technology, interoperability is the key to the success oftheir business,
Universal interoperabllity is achieved when all participants agree to estllblish common operational procedures. In
communications lingo, commonal.lty can be interpreted as standards and procedures as protocols. Let us consider
the scenario ofJoe sending an email from Georgia Institute ofTechnology(GA Tech) in Atlanta to a colleague in a
Japanese Telecommunications Company (ITC) in Tokyo. Joe oomposes the message on his comprrter terminaland
sends it to llis colleague (yoho@jtc.com.jp). Joe's message with his user id (joe@cc.gatech.edu) and IP address
(169. I11.103.44) goes through several changes befure it is transmitted on tl-.e plrysical LAN medium at GA Tech.
The message goes to its College of Computing (cc)'s email server, which oblnins the IP address of the destination
and sends the message out on the Internet. The message traverses several nodes and links and arrives at the post
office box ofYoho's mail server at JTC. She establishes a session in her computer and gets the complete message
thai Joe transmitted. ln this seenario, Joe's message is wrapped with several layers of control information at
various times and is broken down into packet unitS and reassembled at the destination. AII these steps happen each
time without any loss or error in ihe message due to standard.ization and modular (layered) architecture of data
communication protocols. As we w Wsoon learn in this section, the popularity oflnternet as a peer-to-peer network
has been mnde possible by the peer-to-peer protocol TCP/IP suite.
Architecture can be defirled as ·modeling a system into functional components and the relationship among ihem.
Thus, communication architecture deseribc.s the functional components of oommunication network as well as the·
operational intcr:filce between dtem. Operational procedures-both intra· and iuter-modules--ere specified in te.rms
of protocols. Just as human communication is made mutually understandable by speaking a common language,
communication protocols are standardized for service interfaces from the perspectives ofboth a service provider
and a service user. If diffi:rent vendors implement the same standards in thei.r sy·stem components, then
communic11tion between iheir different components can be universal. Standa.rdization of protocols involves
agreement in the physical characteristics and operational procedures between communication equipment providing
similar functions. Thus. looking at our example, all fax machines are able to comrnunicale with eacb other because

all vendors bave implemented standards recommended by loternational Telecommun.ication Union-
Telecommunications Sec10r (ITU-T). Similarly, email exchange across !he world ls possible because most vendors
have adopted Intemet standard Simple MailTransport Pm10eol (SMTP) in ·!heirsoftware. However, there are email
software packages other than SMTP, and the user has to i.os.tall a gateway in those.systems to convert back and
filrlh between SMTP and the vendor-specific proprietary protocol For example, lBM Lotus uses oc:mail (now
defunct), and any network tl111t uses oc:mail bas to implement a gateway (o send an e.mail over the Internet. Note
·!hat there are different mail protocols (SMTP, !MAP, POP, etc.~ whlcb have different procedures. We will now
look atlhe details ofcommunication architecture.
1.5.1. Commm1ication A•·chitectures
Communication between users (human beings using a system) and applications (programs that run in a system)
occurs at various levels. They can communicate wah each olher at the application level, lhe highest level of
communication architecture. Alternatively, they can exchange Information at the lowest level, the physical
mediUl.D. Each system can be broadly subdivided into two sets of communication layers. The top set of layers
consists of application layers and the bottom ~1 tronsport layers. The users-nd users include application
program!O-interface with the application level layer, and the communication equipment interfaces with the
physical medium. The basic communication architecture 1$ s.hown in Flgure 1.10. In Figure 1.1O(a), the two end
systems associated with the two end nodes communicat.e dirCclty with eaob other. Direct communication occurs
between lhe corresponding cooperating layers of each system. Thus, lransport layers can exchange infonnatioo
with each other, and so can lhe application layers and the users.
SVaollnA
t•lOOiet CoMmunl<a!M BMw..,. EIC!Sy<l...,.
'"*"'-••)'11om
[ uwA J
}ljlpiOOim~--
Tr•lllpol1 la)'llt
lflnOI>GrlL"Y',.
- -
CGftWtc.Mwt
-
I Pllytlc:aii.IO<II'--1 I I Pl1l<oea1Moclillm
Sytto,.z
~001 l.t)U/1
T_Loy..
I

This can be illustrated w.itb a real-life example. A bearing-impaired pers~n, accompanied by an interpreter,
arteoded oneofmy classes. As llecmred, the interpreter t.ranslated to the student using sign .language. Ifthe student
had a que·stion, the interpreter translated the information &om sign language, orally to the da.~s and me. In this
llluslration, the bearing-impaired Sll1dent aod I are at the application layer. The interpreter di:l the protocol
conversion attheapplication layer level. 1lte transport layer is the aural aod vL~al media.
Figure I.J ()(b) shows the end systems communicating v.ia an intermediate system N, which enables the use of
different physical media for the two end systems. System N converts the transport layer information into the
appropriate protocols. Thus, system A could be on a copper wire LAN and system Z could be on a fiber optic
cable.
Var.
ious standard organizations propose, deliberate, and establish standards. One of the internationally re·nowned
standard organizatiolls is International Standards Organization (ISO). lSO has developed a highly modular, or
layered, architecture for communication protocols that is called the Open Systems Interconnection (OSI) Reference
Model, published as OSl RM-ISO 7498. This model was developed based on the premise abat the different layers
of protocol provide different services; and tbat each layer can communicate with only its own neighboring level.
Two systems can communicate on a peer-to-peer level, Lbat is. at the same level ofthe protocol. The OSl protocol
architecture with all seven layers is shown in Figure 1.11. Table 1.1 describes the salient features of, and services
provided by, each layer. Layers 1-4 are the transport system protocol layers and layers 5-7 aro application support
protocol layers.
Figurt 1.11. 051 Protocol Laytrs
t
l~7 Aj>f>li<ooon
layet& Pr~
"-5 ~"
~·
TIMspo<t
""""' -
~2 0."'-"'k
L#)'tlrl f'nyu:al
l
Tablt 1.1. OSI Lay•l"5 and Strvi<ts
Layer Layer Name· Salient Services Provided by the·Layer
No.
1 Physical -Transfersto and gathers from the physical medium raw bit data

Tablt 1.1.. OSI LAy<rs Rnd Strvkes
Layer Layer Name SalientServices Provided bythe layer
No.
2 Data nnk
3 Network
4 Transport
s Session
-llandles physical and electrical Interfaces to the transmission medlum
-Consists oftwo sublayers: logical link control (llC) and Media access control (MAC)
- llC: Formats the data togo on the medium; performs errorcontrol and flow control
-MAC: Controls data transfer to and from LAN; resolves conflicts with other data on LAN
Formsthe·swltchlng/routll'lg layer ofthe network
- Multlplexll'lg and de-multlplexll'lg of messages from applications
-Acts as a transparent layer to applications and thus isolates them from the transport system
layers
-Makes and breaks connections for connectlo,...oriented communications
-Data flow control In both directions
-Establishes and dears sessions for applications, and thus minimizes loss of data during large data
exchal'lge
6 Presentation - Provides a set of standard protocols so that the display would be transparent to syntax of the
application
-Data encryption and decryption
7 Application - Provides applcatlo,...speclfic protocols for each specific application and each specific transport
protocol system
OSI protocol architecture ITuly enables building systems with open interfuces so that networks using systems from
different vendors ore interoperable. Figure 1.12 expands the bas·ic communication architecture shown in Figure
I.I 0 to an OS! model figure 1.12(n) is a direct end-to-end communication model. The corresponding layers in the
two systems communicate with each other on a peer-to-peer protoool ioter.
l3ce associated with those layers. ln
Figure 1.12(b), the end systems communicate with each other by going ·through an intermediate node/system.
Agnln. notice that the physical media connected to the end systems could be different. The intermediate s}'stem is
involved only up to the first three layers in the process. Layers 4-7 are not involved in the intennediate system.
This is analogous to a mail container with letters enclosed in envelopes being transported from one 10wn to another
town anywhere in the world. It does not matter what .network ofintermediate cities (nodes) it goes through, or wbat
netwo(k of transportation media-surface, air, or water-it takes to get to the destination. The letter in the
envelope and contents of pa.ckages are untouched at the ITnnsfer points and are only handled by the sender and the
receiver; i.e., user applications.

Figurt I.U. OSI Communltullon Archlltc!lurr
EroS~Z
L
- -
~-
-
,..._.,_ ...~
- $o......
~-
_..._~fro~!_
T!a<UP!>'I
- ........,.
o-Ln< Datal lnlt
Pilylotol ~
I I
'*'"
I
~
-
-
r -
H-.rt<
DINII.iniL
~
I
The message in each layer is contained in message units called protoool data unit (PDU). h consists oftwo parts-
protocol control information (PCI) and user da.ta (UD). PCI contains header information about the layer. UD
contains the data ihat the layer, acting as a service provider, receives from or transmits10 the upper layer/service
user layer. The PDU communication model between two systems A and Z. including Lhe users at the top and IJ1e
u:ansmissioo medium at the bottom of the PDU layers, is shown io Figure 1.13. As you can see, the size of the
PDU increases as il goes tow81ds lower layers. If the size of the PDU exceeds the maximum size of any layer
specificauons, it. is the.n.fragmeote.d into multiple packets. Thus, a single application layer PDU could multiply into
several physical PDUs.
Figu•·e 1.13. PDU Communication Model between £nd Sy.s1ems

I lh«A
I u-z I
l t
Ai>!~ic:at.... Applicotlon
Prqwm1~ton Pleson"dtion
-·- - L. d-x==z:3: . _..,
'Tf1tniiW"1
- fr~tnftJOI1
- -
Nttwof~ -~·
..........
Dtlln Uno O<tto L~o~
-f>tol"lddi
""~
~
~
(D}POU Oo1a SL~ltil~
l.5.2.1>rotocol Layet'S :1nc.l Set·vices
We will OOv go into some detail re~ding services provided by the seven layers ofOSI protocols.
Layer I, physical layer, is responsible fur physically p.
lacing the electrical sigonl on the physical medium and
picking up the signal from it. It controls and manages the physical and electrical interfu.ce.s to the physical medium
including the connector or the transceiver. The physical medium could be copper in the form ofa twisted pair or
coaxial cable, optical fiber, or wireless media such as radio. microwave, or infi'ared. The signal could be either
analog ordigital. There are various protocol standards fur a physical-layer interface depending on the transmission
medium and the type of signal. The 1wo classes of standards have been established by ITU-T and Electronics
Industries Association (EIA).
Layer 2 is the data link control layer, or data link layer for short. Data communication between two DTEs is
comroUed and managed by this layer. Note tllat in contrast to a. byt<>oriented tronsmlssion across a computer bus,
the data communication is a serial-bit-<>riented stream. The data link layer needs to do basic functions: first
establish and cle.ar the link, and second tra.nsmit the datn. Be.sides these, it also does error control and data
compression. Flow control on data link layer is done on a bop-to-hop basis.
For point-to-point communication using a dedicated facility, like the loop link from a customer telephone to the
telephone compa.ny switching office, the data link control is simple and stril.iglltfurwa.rd to implement. However, if
the DTE is connected to a LAN, or which is shared tf811smission media and is accessed simultaneously by many
users, then the data link control beoomes more complex. In the case of point-to-multipoint tmnsmission, the he!KI
end controls the access oft.he medium. LAN is a distributed environment and tllus access control is di.stributed. ln
an OSI-layered model, the data link layer is divided into to,w sublayers-logical link control (LLC) and media
access control (MAC), as shown in Figure 1.14. The lower MAC layer controls the access and transmittal ofdata to
U1e pllysicallayer in an algorithmic manner. There are three basic types ofLANs. Ethernet LAN is n bus type a.nd
the media is accessed using a distributed probabilistic algorillun. Carrier Sensing Multiple Access with Collision
Detection (CSMAJCD). The second type ofLAN is a ring type U
1lld in token ring (fR) and Fiber Distributed Data
lnterface (FOOl). A deterministic token-passing algorithm is used in this case. The third type. ofLAN is deployed
In wireless medium and is referred to as wireless LAN or WLAN. The probabilistic algoritlun, Carrier Sensing
Multiple Access with Collision Avoidance (CSM.A/CA), is used to access the medium . Random-access protocol
will be covered in Chapter 2.
Figure t.l4.Subtoytr Srruc:turt of• OAt.• Link l'rotoc:ol la~'fr

Netwcrk
Logical Link Control
(LLC)
lled1um Ace<:>$ Control
(MAC)
F'llysloal
LLC performs link management and dara transfer. Link management includes formaning the data ro go on the
medium, pe.rrorming error contro~ and flow control. If there is security required, it could be included in the ILC
sublayer.
The network layer is the third layer in the OSI protocol stack. It controls and manages the switching fabric of tb.e
·network. It provides both connectionless network service (CLNS) and oonnection-oriented ·network service
(CONS). The former is used when lower layers are highly reliable, such as LANs and bridges, as weU as when
messages are short. CONS is the method fur transmitting long messages, such as file transfer. It is also used when
the transmission medium is not reliable. It subdivide.s the transpol1 PDUs into !Tames ofappropriate size based on
transmission parameters. The destinalbn address ofeach packet is read in both CLNS and CONS at the network
layer and routed 011 the appropriate link.
A router, or a routing bridge, at the nodes ofa network perforras the function ofrouting and switching data. Any
subnetwork oftl~e node is under thecontrol ofthat router. The subnetwork(s) can be anything &oma simple-single
segment LAN to complex subnetworks operating under a proprietary protocol. OSI architectural model handles
this by dividing the network layer into three sublayers as shown in Figure 1.15. The lop sublayer is the
Subnetwork-Independent Convergence Protocol (SNICP) layer Ibm interfaces to the transport layer. l 'he Internet
communicares between nodes using Internet address and SNICP. llte nodes in tum communicate with subnetworks
using the Subnetwork-Dependent Convergence Protocol (SNDCP), which depends on thesubnetwork protocol and
could be any proprietary protocol In such a situation, the SNDCP communicates with its data link layer via the
third network sublayer, the Subnetwork-Dependent. Access Protocol (SNDAP). This subnetwork arc.hitecture
isolates transpon and the above layers from the subnetwork dependencies. It also enables communication between
a DTE on dte lntemet and a DTE on a subnetwork node, as shown in Figure 1.16. Figure I. I6(a) depicts network
configuratbn in which DT£..A connected to end node A communicates with DTE-NI connected to subnetwork
Mde·Nl via ·the intermediate system gateway node N. Figure 1.16(b) describes the path ofcommunication through
different protocol layers from the originating end system to the terminating end system vta the intermediate node
gateway. The formats of the PDUs are identical in all three systems at SNICP layer levels and above. Access
networks having their own addressing scheme using Network Address Translator (NAl) or Dynamic Host
Configuration protocol (DHCP) can be implemented using tltis scheme.
flgurt l.t5. SublayuStruclurt or a i'lrtwork Protoool Laytr

Transport
SNICP
Networli SNDCP
SNOAP
Oatallnk
SNICP: SubnetWOtt-tndepend9nt Con~ergence Protocol
SNOCP: Subnetwork-Dependent Convergence Protocol
SNOAP; Sulrletwork-Oependent Adapler Protocol
Flgu•·• 1.16. Caccwoy Communlralion coPrivoct Subnecwork
A-lh! s!Mda-dNll!wcirl<
N· U1-N2-N3Sotlne!worUIOefNOde N
ll'iln~ r -
SNICP
I~
SNJCP
SNOOP SNDCP
SNJC
OP-SN
SNO~P SNDN' SNOA1'-S«
tataLmlti 1
- Dlll8Lnl< DO!> L111k·SI'l
1>11)"""" rn,.~<a~ oSN
PhyS)clll
J J 1
-
-
---1@
Trilf11!0f'll'1
SNIC?
SNOCP-sN
SNCAP·SN
t.la.Q LWI't•~
~
1
N9twuu; Meot.tm Sl.l1l00lwc:JIX Meaiul:n
(b) Pl'o4acol Olmml.,loa....,

The most used network protocol is tbe Internet Prorocol (IP) and has been PQpularized by the Internet. It is part of
the Internet suite of the TCP!IP and is a CLNS protocol. In OST terminology. It is called ISO-IP or ISO CLNP. A
connection-oriented OSI protocol is X.25 PLP, Packet Layer Protocol.
A popular scheme ofimplementing private subnetwork is to establish a network. with a private IP address, sucb as
1O.x.y.z. In this insrance, the gateway node, known asNAT, converts the global IP address to the local proprietary
IP address. fur example, LAN Z in Figure 1.8.
The transport layer is the fourth layer ofthe OSl protocol. It multiplexes the OD provided byapplication layerS and
passes packets to the network layer. Its se.rvicc is independent ofthe network on which the packets are transmitted.
The transPQrt layer can ag~~in be connectionless or connection oriented and is implemented in hoth Internet and
OS! protocols. As mentioned earlier, TCP is a component of the IP suite nod is conoection oriented. The
connect·ionless t·ransport protoool in a TCP/IP suite is called Lhe UDP. Plow control is also implemented in
tmnsport layers and functions as data rate manager between application programs and the network layer. ISO has
five transport layer specifications, TPO to TP4. TP4 is analogous to TCP.
Layers 5-7 arc application layer protocols. £xcepl in the OS! Reference Model, the tltree application layers are not
clearly separuted and independent. Let us look at each layer as ifthey were independent., like in the OSJ mode~ to
understand their specific fimctions and services provided. An application process commuolcates with flllother
application process during a seso;ion. The session layer services establish communication at the beginning of the
session. monitor, sync.hronill!, and error correct the information exchanged during the session. and then release the·
logical link at the end ofthe session. H is very strongly nilatcd to the presentation layer, which is the medium of
prese.:ttation ofthecontext ofthe mess.~ge to the user or application program. In that sense, the presentation layer is
a context-sensitive layer. ll can be interpreted as the common language and image that the users at hoth ends ofthe
system use and understand- shared semantics of the two end users. A common abstract syntax that is used for
semantics is Abstract Syntax Notlltion Number One (ASN.I). Although the primary function of the presentation
layer is the conve.rsion ofsyntax. data encryption and data oompression are also generally done in that layer.
The lop and the seventh protocol layer is the application layer. The application 'Process interfaces with the
application support processes tbat are provided by this layer. Uke the other two layers in the set ofapplication
layers (session and presenration), it is strongly coupled with the restofthe application layers. In the OS! Reference
Model, one can separate these processes &om the presenration and session layers, but in other models there is no
clear distinct·ion of the functions. Figure 1.17 presents a comparison of the models-OSI Reference Model and
Internet model.
Frguo
•r t.t7. Conoroartson qfOSI anollnltmtll'roloc:ot l,ayrr M<>oltl(

OSI INTERNET
Appllca~oo
Pro~rttnt.on
Appllcati.,.,.Spa:lfiCl
Prorocals
$<>10$000
TtlltllJIUO
fron!li>Ort ConOOCI...,.. I Conoll':lian·
le!!il: UOP orit~tlld. TCP
SNICP
N~l""'r~
N
o!WC!1(
SNOCP
I~
IP
SNOAP
Oatn ~Ink
Not S(lft(!~l>d
l't1)Sital
The Internet model does not specey the two lower layers although H
· is obvious Lhat !hey use distributed LAN and
WAN configurations. The tmnsport and network layers fotm the suite of TCPIIP protocols that we mentioned
earlier. Application layers arc combined into application-specific protocols.
Figure 1.18 shows a comparison offuur common applicat·ion-specific protocols in OST and Internet models. There
are more OSl applicalioo-specifie protocols, which we will not discuss here. All application-specific protocol
services in OS! are sandwiched between the user and pre-
sentation layers. In the lntemet mode~ drey are
sandwiched between the user and thetransport layer. The boxes on the right-hand side ofFigure 1.18 describe the
comparable scrvites offered in the two model'!. A user intedaces with a host as a remote terminal using Virtual
Te.
rmloal (VT) in the OS! model and TELNET in the Internet model. File transfi:rs are accomplished using File
Transfer Access and Management (FTAM) in !he OSl model and File Transfer Protocol (FTP) in the Internet. The
most common used mail service function in tbe Internet i<; Simple Mail Transfer Protocol (SMfP). A similar
protocol io the OS! model is the Message-Oriented Te-xt lnte.rchange Standard (M.OTIS). Network management is
accomplished using the Common Management InfOrmation Protocol (CMlP) in the OSr model and the Simple
Network MmuigemenL Protocol (SNM.P) in the Lntemel. We viii extensively discuss tbe details of SNMP in this
book. CMIP is briefly discussed in Appendix for completeness. However, it is imporUlnt to understand tbe overaii
picture of protocol layers and other application protocols to appreciate network management fimctions that are
accomplished using network management protocols.
flgur• 1.18. APt>Utailon-SI!OciRc: Protorols tn OSI and lnitn>tl Mod•IS

,.--1---:c'--,.,.--'--~
1.6. Network~, Systems, alitl SL•n•ices
~ ~
m - _J
{~I
( '::'I
We described a network comprising nodes and links in Section 1.2. The phys.ical embodiment ofa network·can be
deftned as a system. Thus, the nodes nod links are components of a network system. Just as a network can be
subdivided into subnetworks. a system comprises subsystems. A system or subsystem is made up of network
elements. Network elements can be either active or passive. Thull, a router is an octive network element, whereas a
splitter or a combiner !bat divides or combines signal energy is a passive element. A link could also be an active or
a passive component. 1n the case of an active transmission link, it can be subdivided into active nodes and passive
transmission media.
Servioes are fun~'lions ihat users derive out of networks and systems. Neiworks and systems exist to provide
service to the users. Service providers provide telecommuoicatlon services to subscribers and customers using
networks and systems.
J.(i.l . .Broutl blind Networks. Systems. 1
md Sl'n'ices
A broadband communication system can be defined as one that provides broadband service to homes and
enterprises. The common interpretation ofthis definition in practice·varies in different countries as weU as among
various service providers. ln the· most comprehensive defmition of !be term, we will define broadband
communication system as one that provides voice, video, and data services over the same medium to customer
premises. Broadband service comprising audio, video, and dara is also known as multimedia service.
Audio service includes telephone., telephone conference, and radio broadcast. Although the end terminals could be
either analog or digital devices, inrormation is carried digitally in the context of broadband service. A system
providing this service is tmly a real-lime information system.
Video service includes broadcast television, interactive television, video-oiHlemand, and video conference
services. Video service could be either real-time or quasi (near) real-time service. Once again, the presentation
could be on eitber analog or digital terminals.
Data service includes numerous applications, whi.ch can be classified into three categories: store-and-fofvard,
audio streaming, and video streaming. Some· examp.les of store-and-forward service are email. messaging, and
Web-based applications. Audio and video broadcast and streaming services mentioned above sucb as MPJ and
video-oiHlemand can in a sense be considered under this category. They are not sensitive to absolute delay time
'between the source and the destination, but are affected by delay variations orjitter.
Broadband services are provided using broadband nehvo(ks. There are nume.rous types ofnetworks to choose from
depending on what segment and what type of service one needs. It is like ordering ice cream in an ice-cream
pnrlor---ooneorcup, hard or soft; size smaJJ/mediwn/large. choice offlavor, choice oftopping, etc.

The Lhree segmenLsofbroadband network are WAN, broadband access network, and CPE nemmk.lobroadband
tenninology, the CPE network is also called home network when the customer premises is a residence. Network
segments and choices in various segments are shown in Figure 1.19.
Flgur • 1.19. Broadband NtlworkS.gmtnb and Ttcbnul~gltll
INIIIII
-··
llloliol:><l<
The WAN and access network interface with each other via !he edge rouLer. The demarcation point between the
access network and CPE network is shown as the residential gateway. Although 1his is the logical demarcation
point the physical de.marcation point between the access network oftbe service provider and the customer-owned
CPE, or home uetwork, could be different. As an example in the cable network, the demarcation point is called
Network illtcrfuce UnJL (NTU) or Network lnterfuce Device (NID) and is the physical termination of the cable
access network outside the house. Tbe residential gateway·may onnay not·exist, and ifit does, it is a part ofCPE
network.
1.6.2. Wide Area etwork<i
The four leadmg networks and protocols that are used in broadband WAN are Internet using Asynchronous
Transfer Mode (ATM), Synchronous Optical Network (SONB1), IP, and Multiprotoco.l Label Switching (MPLS)
network.
ATM. network: ATM network is ideally suited for WAN or core network. It has fast. layer 2 switches that can be
configured to func1ion in parallel and thus can process bigb data rate cell-oriented packets. l...alc:ncy can be set in
ATM. switches by setting priorities to tbe different services-real-time and non-real-tim~!Kling provided
Furthe-r. traffic·perfbrmance is iooreased by establishing Virtual Path-Virtual Circuit (VP- VC).
Four classes oftruflic have beeo defined in ATM. network to implemenL quality ofservice. COostaol bit rate (CBR).
real-time variable bit rate (VBR-R.T), oon-.real-time variable bit rate, (VBR-NR.T), and available blt rate (ABR) or

user bit rate (UBR). Transmission of voice is assigned CBR. An example ofVBR-NRT is transmission of stiU
images. Data 1raffic and store-and-forward traffic get the lowes! priority, ABR.
SONEf: An optical fibe.r medium can be used to carry multiplexed lower bandwidth signals implementing SDH.
This mode of transmission is known asSONET. The Oplicaltransmission network oontains regenerators, digital
cross·oonnect elements, and add-and-drop multiplexers (ADM). Modem optical networks use dense wavelength
division multip.lexers (OWDM) and very high bandwidth signa Is can be transmitted.through dtis optical network.
Internet: The lntemet backbone WAN using IP is highly matured. bas a full set of application·oriented li:atures,
and can interface with access and CPE network fn a more seamless manner. However, its main drawba.ck is that it
is difficult to meet qualit.y-Qf-service requirements needed for multimedia broadband service. Because of its
variable packet size. and packets choosing possible alternate padts between the source and the dcstin!llion, th.e
performance ofrouters and other transmission devices is not as efficient as in an ATM network.
Quality ofservice in IP-ori.ented WAN traffic is improved by implementing one oftwo different approaches. They
arc integrated service [RFC 2205] and differeotlated serv.
ice [RFC 2474]. Jn one form of implementation, lntserv
packets in dte·lntemct are classified into dtree classes: guaraateed, controUed or predictive, and best effort. Intserv
rese.rves bandwiddt from dte source to dte destination on a pe.r-flow basis fur a guaranteed class-of-service call or
session using reservation protoool, RSVP. Once the reserved path with dte necessary bandwiddt is established, dam
arc transmitted.The bandwidth is released after the calVsession is completed. lntse.rv is not an efficientscheme for
establishing quality ofservice in the backbone network as the.re is no guaran.tee that the resources will be available
wben needed. Furdter, the scheme does not scale weU.
In the diffi:rcntiated service, diffserv, packets belonging to the same class are grouped at each hop and then
prioritized. There are four classes and each class bas dtree subclasses for dropping packets-low, medium, and
bigb. The present tre.nd in providing quality of sc..Yvice ror backbone is to use diffe.reotiated service comple.mented
with some form ofreservation capabilities ofRSVP.
MPLS network: MPLS attempts to oombine the benefits of ATM quality ofservice with feature benefds ofthe IP-
based Internet. Conventional routers examine the packet headers and classify them into forwarding equivalence·
classes (FEC). They are then assigned the next hop.1n MPLS this is done once; possibly at tbe ingress router, and a
label is attached to it. At each router, only the label lookup is done for detem1ining the next bop. Label lookup can
also be done using a switch. A router that silpports MPLS is known as a Label SwitchingRouter (LSR). MPLS can
support nny network layer protoool. RFC 3031 describes MPLS nrchitecture fur an IP network layer protoool.
1.6.3. Broutlbund Access Networks
Figure 1.20 shows six types of broadband access networks dtatprovide broadbiiJld service to homes, Small Office
Home Office/Small and Medium Enlerprise (SOHO/SM£), and enterprises. The core network is ll'/ATM/MPLS
WAN. The l.ink from the head e.nd or dte edge router to business customers is shown as an optical earrier-n (OC-n)
link, afthough it could be any other transport scheme. Hybrid fiber coax (HFC) cable network and Digital
Subscriber Line (DSL) nelwodt are dte matured access networks. Fbted wireless is bei.ng offured as point-to-
multipoint service or meshed oetwork. W!Max, 10 metropolimn areas. Mobile wireless could be offered using
either 3G technology or wi~less !.,AN. The furmer has the limit<Ilion on data rat.e and the latter on range. Fiber
network as Passive Optical Network (PON) is still in an embryonic stage fur economic reasons.
Figuc
·• 1.20. BroiKlb•od A<tt5!l N<IWttrks

Cable Access Network has its head eod interfacing to t.he edge router. Analog and digital signals from various
service.s are multiplexed at the head end and are converted &om on electrical signal to optical wavelength signals.
The optical signal is then carried over fiber up to an intermediate point, optical node, where it is dow~Konverted to
radi:> frequency and transmitted the rest ofthe way to the cust"omer premises over two-wny coaxial cable, hence the
term hybrid fiber coax (HFC). At the customer premises, the TV analog signal is split from the digital data. The
latter is demodulated to a baseband digiml signal using a cable modem and is fed to the digiml devices, such as
computer and appliances.
Digital Subscriber Une access ·network uses a telephone line and can be deployed uSing different
implemcnmtioos, refe.
rred to as XDSL. Of tl~ese, Asymmetric DSL (ADSL) shown in Pigure 1.20 is the most
prevalent deployed all over the world. AUhough cable network is more commonly used in the United Smtes by a
ratio ofapprox.imately 2 'to I, the reverse is the case in the rest of the world. The technology uses the .existing
unshielded twisted-pair (UTP) wire that carries the analog voice to transmit data in addition to voice. The voice is
carried as an analog signal at the low end ofthe frequency spectrum (0-4 ld:lz) and the digital dam over the higher
band of1he spectrum. It is termed asymmetric as 1he downstream data rate (from the centraI office to customer
premises) is much higher than the upstream (1iom customer premises 10 the eent.ral office) data rare. The analog
voice and digital dam are separated at both e.nds of the aocess network using a fiker, and the digital dam are
modulated and demodulated at both ends using ADSL modems. Atlhe central office, voice circuit interfaces with
U1e central office~·witch and the digit.al daia with the edge router.
Wireless Access Networks: Figure 1.20 shows three types of wireless access networks. The terrestrial wireless
network, also known as fixed wireless, is a point-to-multipoint transmission. A base smtion with mullipleantellll8S
covers multiple sectors, each serving many subscribers. The two well-known deployed technologies are
Multichannel Muh:ipoint Distribution Service (MMDS) for rural areas and WiMax fur urban areas. Satellite
wireless syste.ms are primarily used for on~>,vny televisi:m broadcasting service. Mobile wireless has limited
bandwidth and is currently used In phones such as smart pbooes, providing bl:oadband service.
1.6.4. Homf/CJ>E etworks

CPE network in enlerprise environmem is eitber an IEEE 802.3-based Etbernel LAN or I:EEE 802.11 based
wireless LAN, also known as W!Fi, or a hybrid ofboth. Horne network provides the opportunity to uti.lize mulliple
technologies besides Etbernet LAN and WiFi. HomePNA is implemented using twisted-pair telephone cable
medium, HomePiug takes advantage of power line wiring in the house, and cable utilizes ahe aelevision coaxial
cable. FireWire is also a wired medium and is based on IEEE 1
394 protoco l to transmit high-speed digital dala
Universal Se.rial Bus (USB) is u$00 for low dalll rilte peripherals. Wireless home network technologies include
Blueaooth and ultra-wide band (UWB) personal area networks (PANs) fur short distances.
1.6.5. Quality ofSc!"icC in Broadb"Jul Systems
Quality ofservice CQuld be interpreted in toohnical terms in many different ways. However, from the users' point
of view, people are used to reliable, dependable, and good quality analog telephone and tcle,~sion sc.rvicc. They
expect the same quality of service when the telecommunication and cable services are extended to broadband
service that inchJdes voice, video, and data. Networking aeclmoiogy has to prioritize real-aime voice and video
traffic over store-and-forward data traffic, and provide the end-to-end quality of service. For real-time applications
of voice and video. the delay and jitter should be imperceptible. Service should be highly dependable (always
available) and reliable (quality is consistent). Monitoring and manag.
ing these parameters is achllllenge for network
management.
1.6.6. Security und Privacy in Broudbund Systems
With universal 10 and multiple service providers delivering multiple services on shared media to multiple
subsCribers, the security and privaey ofinformation becomes a primary concern. This is especially critical with e-
bu~iness over the Internet. Besides implementing security and privacy-authentication, authorization, and
encryption-of tbe· data and management infunnation, tbere has to be a cultural change in the perception of the
subsCribe.rs that the information link is secure.
1.7. C nse Hisfo-rics on Network, System, and Service M:1nagcment
Network Management is more than just managing the network. In standards bodies it i.s referred to as Operations,
Administration, Maintenance, and Provisioning (OAMP). Ofcourse, networking and network management existed
befOre network management became a formalized diScipline. Network management and its complemcnlllry
functions ofsystem ~management and application management are all means to tbe end ofservice ~management in
provi:ling the subscriber or customer quality ofservi.ce. As one IT manager commented, the configuration and use
ofa NMS formalizes what a network administrator would have otherwise.done. llte network administration "war
stories'' in the folJo,ving subsections illustrate thai network management (especially without proper tools) could
presenl a challenge to IT managers.
J.7.J. Case History 1: lJUr)Ort:wce of ToJ}Ology ("Case oftbe Footprint}
A saable corporate n~'lwork consisting ofseveral minicomputers arJd about 100 desktop workstations and personal
computers suddenly started "crashing" freque.ntly (a legacy network·ex.ample). How often have we heard 11 network
coming down without any apparent reason? Here is bow one· Vice President of l.nrormation Systems desc.ribes an
incident.
Partofthe network went down in the engineering area one morning. Since there were a whole series ofusers and at
that time we were not using a STAR ( hub) topology. but ratber the old-fashioned serial topology (wbere all the
users were daisy cbnined to the coax), we suspected a break in abe cbain, probably at a tr.ansceivcr lap. Lacking
sophisticated NMS tools, Infurmatk>n Systems persorutel started walking dte hallways asking the users Ifanyone
bad just been doing anything oul ofthe ordinary, which might have broken tbe chain and caused the problem.
The guys came back and reponed tbat no one hnd said abat they bad ''done anything." So I (VP) started back down
the halls with the guys and peeked into each office. Finally, I stopped and said "Let's look up in the ceiling bere."

Sure enou,gll, we found a transceiver that someone bad been fooling with and tbat was not properly connected,
which bad caused the break. Once connected, the network segment came bac.k up.
The guys asked "Why did you say- try here?" particularly since the engineer in tbat office claimed ignorance. I
calmly pointed to a dusty image of a sneaker footprint on the engineer's desk and the ceiling tile that was ajar
above the desk and said-"you need to use all the diagnostic tools at your disposal!"
1.7.2. Case Hi~tory 2: Centrally Managed Network lssuc.s
There are numerous war stories tbat we can describe relating to heavy load on a NMS managing the network and
network e.
lements. We will choose one tbat illustmtes several is.sues related to network design, configuration, and
maintenance. An integrated network management system (INMS) was integrating alarms from multiple element
managemenl systems (EMSs) in a service provider network. Each EMS manages a domain of network elemenlS
and passes the relevanl events to the INMS as sbown in Figure 1.21. The service provider is able to monitor in its
centrally located NOC faults occurring in itsglobal network. As simple as this sounds, its imple.ment;ltion could be
extremely complex. Let us consider a si,mple real-world situatioo in which a f'ew EMSs were integrated into an
INMS and the alarm occurrence time in the INMS was at variance with the individual EMSs.
Flgurt 1.2t. cas·t History 2: C<nlrolly Maoagtd Nthmrk lssu..
EMS EMS
Each EMS records and displays tbe receipt time of tbe alarm. The same is transmitted lo tbe INMS. lt was
observed tbat tbe indication ofibe time at wbicb the alarm occurred was significantly different in INMS from that
indicated in the EMSs thru were sending the alarms. The alarm occurrence time was ooosidembly delayed,
sometimes by hours, in INMS. Tite cjJaUenge in a centmlly managed .network is to find the root cause of the
problem. Is it network delay? Is the delay due to excessive number of events? Is it due to input/outpur (1/0)
limitation ofthe input port ofthe lNMS? ls it due to I/O output port ofEMS?ls it in the software ofeither EMS or
INMS or both? lH is in the INMS software, sbould the filtering of unnecessary events at the input take care ofthe
problem? The answers io most ofthese questions were affirmative for each. but to a varying degree In each case.
The predominant cause is the stress on NMSs, although it can be traced sometimes to network elements in the
various domains. Tmnsmis.sion ofunnecessary alarms also causes a stress on tbe network and networks have gone
down due to uncontrolled generations.ofnetwork management messages.

I.7.3. Transaction Delays in Client-Server Network
In cumru oational and global enterprise organizations, application servers serve thousands of clierus over
international nelwork.~. In a study ofbanking industry, lrnnsaction del11ys were measured and analyzed to determine
the root cause ofthe deilly as reported by tellers of bmnches. The propagation time of individual trnnsaclions was
monitored as they traversed through the LAN networks and servers of the branches, through the WAN, and
centra.lly processed by an application server. Some of the transactions were discovered to time>out due to long
tra.nsaction delays. Study results identified the source of lhe problem to be galeways and applications; and
appropriate actions were initiated to resolve the problem. This case illustrates the need tor management ofend-to-
end communication and the influence of network components, applications, and client-5erver arohitecture in a
network.
1.7.4. Service lmp:lct in End-to-End ScJVicc ofCustOmers
End-t<rend communication is further illustrated by the need to proactively identify the service of the customers
affected by a network element failure·. This is illustrated by the following case. Inan optical fiber transport network
using TDM SOH network element that carries thousands ofcbnnnels, Ihe failure of a single component affec1S
services of hundreds of customers. An end-to-end communication breakdown is to be lraced to the failure of a
single or multiple network elements by root cause anliJysis and dyii1U11ically determine all clients whose services
are impacted. The serv.
ice provider detects the problem even be!Ore cusfomer complaints nre received and in!Orms
the customers that the problem is already being addressed to restore service as soon as poss.ible.
l.7.5. Some Common 'etwori< l'roblcms
The most common and ser_
ious problems in .network ore connectivity failures and are.bandled under tbe category of
fault management. Fauk is genemlly interpreted as fuilures in accessing networks and systems by users, Network
failure is caused more often by a node failure than failure of passive links (except when it Is cut by construction
crew). Even node failures are more often limited to specific interface failures, When this happens. all downstream
systems from that interface are ioaccessible. Such tailures are associated with fuilure ofthe network interface card.
Node failures manifest as connectivity failures to the user. There are networking tools ava.ilable to the manager to
localize the fiml~ as weshall learn in Chapter9 on Network .Management Systems and Tools.
Another cause of nerwork conoect:ivity failure is procedum~ bul very common. Network connectivity Is based on
the IP address, which is a logical. address assigned by the network administrator. The lP address is uniquely
associated with a physical MAC address of the network component. However, mistakes are made in assigning
duplicate!P addresses, especially in an enterprise environment with mukiple system administrators,
A host or system interface problem in a shared medium can bring the entire segment down, sometimes
intermittently, as shown in Case History 1 abo<e. 1l1is could be a nightmare for the network manager to isolate
without causing lnlerruption in service. A network roaoager uses intuitive knowledge to look for patterns such as
change in configura.! ion, addition of new equipmentor facility, etc. in resolving such problems.
Intermittent problems could a.lso occur due 10 traffic overload causing packet loss. Sometimes the management
system may indicate fill lures, when in actuality data traffic is nowing normally. Perforroance mooitoring tool.s
coukl be useful in tra.cking such problems,
Power hits coukl reset network oomponent configuration, causing network ful.lure. The network has a permnnenl
configuration (default) and. a dynamic configuration (run-time). and. thus a power hit could chaoge the
configuration.
Finally, there is the non-problem, which really means that the cause of failure is a mystery. Tbere is nothing else
that a network manager could do except tum the sys!em offand then on. Bingo! The problem is resolved.

Perfonnance problem could also manifest as network delay and is more an annoyance to the network manager,
who needs to separate network delay from the application program or application processes de.lay. Then the
network manager ha~ to convinoe the user and then the person responsible fur the application to rectify the
situation.
With the ever-increasing size of the network and connectivity to the Internet, security violation in network
management is a frequently encountered. problem. This is more a policy problem than technical, which we will
address in Chapter ll when we discuss security management.
1.8. Challenges ofiT Managers
Managing a corporate network is becoming lutrder as it becomes larger and more complex. When we talk about
network management, il includes not only componeniS that transport information in Lbe network. bur also systems
that generate rraffie in tbe network. What use is a computer network if there are no systems in dte network to
provide service to users? The systems could be hosts, database servers, file servers. or mail servers. In the client-
server environment, network control is no longer centralized, but distributed. Computer and tek!communication
networks are merging fast Into converged nctvork with common modes and media of transportation and
distribution. As in the ca;;e ofbroadband networks, the IT-manager needs to maintain both types ofnetworks. Thus,
the data communications nutnager func.tions and telecommunication manager functions have been merged to I bat
of tbe IT manager. With t:be eKplosion of information storage and transfer in the modem information era,
management of information is also the responsibility oftlte· IT manager, with the title ofCIO, Chieflnformation
Officer. For example. the IT manager needs to worry in delall about who can access dte infurmation and what
inlbrmation they can access, i.e., authentication and authorization issues of security management. The corporate
network needs to be secured fi.)r privacy and content. using firewalls and encryption. Techno logy is moving so fast
and corporate growth is so enormous, that n CIO has to keep up with new technologies and the responsibility lilr
financial investment thal the corporation commitS to. This amount.s to millions ofdollars, and the success or failure
of making the right guess-not choic-.:ould make or break the CIO'sjob.Notice that dte word "guess'' was use.d
instead of"choice" deliberately because it is not always clear wb.iob oftbe options nre a dead end, a.nd hence need
to be avoided. Since they nre not obvious, the IT manager needs to make provisions for contingencies to change
direction when the IT industry does.
A good example of indeterminacy in the fast-moving tecbnology industry was competition between the two
technologies ofEthernet and ATM to desktop. ATM was pr<XIictcd to be tbe way to go a few years ago. However,
·this has not been the case because of tbe development of enhanced capability and speed of Ethernet. Anotber
current example related to this is tbe decision that one has to make in the adoption and deployment of WAN-
whether itshouk! belP, ATM, or MPLS.
Perspectives ofNetwork Managers ln order to appreciate challenges t:bntlT nutnagers face, several of them were
interviewed by the author. They face netVO(k administration and manageme.ot problems day in and day out. These
are the folks who carry a cell phone with them all the time since mostcorporate networks run 24/7-i.e,, available
24 hours 11 day 7 days a.week! The questions Uta! were posed, wiU1 n summary oft:be answers edited ror the current
SLatus of IT, follow. They are not an ellhaustive list of queSI·ions and answers, since thai would make the contents
of a separate book, but are<mly intended tc;> indicate the compleKity of managing a network and thus motivate a
student in networking. Notice that it is not just a technical function, as Case History I exemplifies. Also, e<en u.se
of t:be beSI NMS does not solve the problems associated with building and maintaining a network, but it is a
necessary tool. Thus. learning network management involves more than understanding netvork and network
management protocols. The author'·s recem.in-deptb study ofservice providers alsp raises similar comments.
General
People el<pect a network to function like a telephone network.

Reliability in a data network as in a telephone is unrealizable. The telephone network was monopolistic and
had expensive redundancy. llte data network is ad hoc, decenu:ali7..ed, has loosely specified interfaces, an.d
has dynamic routing. Thus, it is a lot more flexible thanthe telephone network though less reliable.
• Designing, deploying, and managing net~vorks that can handle reol-'iime and non-real-time dalll.
Integration ofmultivendor 811d multitecboologyequipment and their network management systems.
I. Wbat are your top challenging activities in managing the network?
o Rapid advance oftechnology
o Problem analysis-needs human intuition and skill besides scpbisticated management tools
o Anticipatecustomer demands
o Acquire and retain human resources
o Manage client~rver environment in converged networks
o Networking with eme.rging technology necessitates the need for continuing education
o Collaborative research between academic Institutions and industry
o Maintain reliability, that is, make changes, upgrades, etc. without disrupting the network and
impacting business
o Diagnose problems or outages in a non-disruptive maaner (without impacting other users on the
network)
o Bstimate the value of a technology transition. For example, should one transition over to
accommodate the increasing number of!P addresses with !Pv6 or oontinue with !Pv4 with Network
Address Translation (NAT) as a hierarchical addressing scheme?
2. Which elements of managing your network require most of your time? What percentage of time do you
spend on maintenance compared to growth?
o A 30-SO% growth, 20-70% maintenance b~o;ed on the organization.
o Configuring the management system itselflllkes most ofthe time.
o Expanding the network.
o Gathering and analyzing statistics for upper management review to conduct business.
3. How did you or would y.ou manage your network without an NMS?
o Reactively, .not proactively; firefighling
o Troubleshooting tools, e.g., sniffer, ping, etc.
o Home-grown systems using an open scurce, e.g., MultiRouterTraffic Grapher (MRTG)
o Rely onconsultant advice and technical informalion for growtb decisions
4. Do you need an NMS? Wby?
o Por proactive management ofnetwork
o Verify customer configuration
o Diagnose problems
o Provide statistics on performance
o Help remove bottlenecks
o NMS formalizes the manual practice of network management
o NMS products reflect the company's practice that develops them
o Tosee theirend in growth
5. What problems would you expect theNMS to resolve, and how?
o Bnhance customer satisfuction by meeting the Service Level Agreement (SLA)
o Save time and poople rescurce and thus cnbance productivity
o Turn-around shoner fur re,sclotioo ofproblems
o Gather statistics and predict trends for planning purposes
o Docurnent events
o Troubleshooting
o Remove constmints and bottlenecks
o FouJt isolation
o Expect the NMS ro do a root cause analysis and pinpoim failures
We will now briefly introduce the subject ofnetwork management funetionsand system in the following ;ections.

1.9. Network Management : Goals, Orga.nization, and Functions
Network Managemenl. can be defined as Operations, Administration. Maintenance. and Provisioning (OAMP) of
network and services. The Operations group is concerned with daily operations in providing network services. The
networkAdministration is concerned with establishing and administering overall goals, policies, and procedures of
network management. The Installation and Maintenance (l&M) group handles functions that include both
installation and repairs of lilcilities and equipment Provisioning involves network planning and circuit
provisioning, traditionally handled by the Engineering or Provisioning department. We will describe each of these
functions in this section. Although we continue to use the tenninology of network management. in r.he modern
enterprise environment this addresses all om and ITservices.
1.9.1. Goal ofNetwork Management
The goal ofnetwork management is to ensure Lhattbe user.> ofnetwork are provided IT services with a quality of
service that they expect. Toward meeting this goal, the management should establish a policy to either formally or
infOrmally contract an SLA with users.
From a business administration point of view, neh,wk management involves strategic and tactical planning of
engineering. operations, and maintenance of netv.'Ork and network services fur current and future needs at
mirtimum overaU cost. There needs to be a well-established interaction between the various groups performing
these functioos.
Figure 1.22 presents a to]Hiowo view ofnetwork management functions. lt comprises tltree major groups: (i)
network and service provisioning, (ii) network and service operations, and (iii) network r&M. It is worth
considering the different functions as belonging Ill specific administrative groups. alr.hough there arc other ways of
assigning responsibiliiies based on loenl organizational structure. Net~vork provisioning is the primary
responsibility of the Engineering group. The Customer Relaiions group deals with clients and subscribe.
rs in
providing services planned and designed by the Engineering group. Network l&M is the primary responsibility of
r.he Plant Facilities group. lnter:-dCtioos between the groups are shown in Figure 1.23. Nonnal daily operations are
the function oftbe Network Operations group, which controls and administers a NOC. This is the nerve center of
network management operations. The functions of NOC are primarily concerned with network operations; its
secondary responsibilities are network provisioning and network l&M. The associated service operations are
handled by a subscriber operation ceruer (SOC) and customer relations management (CRM). Our focus here is on
NOC.
Figurt L22. Nrtwork Manugrm<ul Functionlli Groupin~

Flgul'f 1.2.l Nttwork Man-agement Fw1etional Flow Char1
1.9.2. Network J>rovisioning
Network Provisioning consis1S ofnetwork planning and design and is the responsibility ofthe Engineeringgroup.
The Engineering group keeps track ofnew technologies and introduces them as needed. What is needed and when
it is needed are determined from analysis oftraffic and pedilrrnance data provided by the netwo.ck operations. New
or modifications to network provisioning may also be initiated by management decisions. Planning and efficienl
use ofequipmentcan be acbieved w.itb good inventory management ofcurrent and fitture modification~ ofnetwork
configuration by tbeNetwork Provisioning group.

Network management roots are helpful to the Engineering group in gathering statistics and studying 1reods in
traffic patterns fur planning purposes. Automated operat·ions systems help in the design ofcircuits and measuring
the performance tune-up.
1.9.3. Network Otwmtintli and 'OC
The functions of network operations listed in Figure 1.2'2 are administered by the NOC. They are concerned with
daily opemtions of the network and ·providing ·network servi.ces. lSO has defmed five OSI network management
applications, which are fault, configuration, performance, security, and account management. They are also
responsible for gathering statistics and ,generating reports for management, system support, and users. NMS and
tools are a necessity for NOC operations. They are U
$ld in various management applications described below.
Fauh Manageme.nt/Service Restomtion: Whenever there is a service failure, it is NOC's responsibility to restore
service as soon as possible. This involves detection and isolation ofthe problem caus.
ing the failure. and restoration
ofservice. In sever:al failure situations, the networlnvill do this automatically. This network feature is called self-
healing. In other situations, NMS C41n detect failure of components and indica.te with appropriate alarms.
Restoration of service does not include fL'Iing the cause oflbe problem. That responsibility usually rests with the
I&M group. A trouble ticket is generated and fOllowed up for resolution ofthe problem by the I&M group.
Trouble Ticket Administration: Trouble ticket administration is the administrative part off.~uh management and is
used to track problems in the network. All problems, including non-problems, are to be tracked until resolved.
Periodic.analysis ofthe datn, which are maintained in a database, is done to eslllbli.sh patterns of'the problems for
fOllow-up acl'ion. There are troubl(.}otracldng systems to automate the tracking of troubles from the automatic
,generation ofa trouble ticket by an NMS to the resolution ofthe problem.
Confrguration Mnnagement: There are three sets of configuration of the network. One is the static contiguratbn
and is the permanent configuration of the network. However, it is likely that the current running configuration,
which is the second, coukl be different from that of the pem1811ent conftguration. Static configuration is one that
tl1e network would bring up if it is started from an idle status. Tbe third corlfiguration is the planned configuration
of the future when the conftguration data wiU change as the network is changed. This information is useful for
planning and inventory management. The configuration data are automatically gathered as much as possible and
are storedby NMSs. NOC has a display that reflects the dynamic oonfiguratbn ofthe network. and its stows.
The statusofthe network is displayed bya NMS and indicatesany fitilure ofcomponents ofthe network, as well as
·the traffic pattern and performance. Any configuration changes needed to relieve temporary congestiln in traffic
are Olllde by NOC and are reflected in the dynamic display at NOC.
Performance Management: Data need to be gathered by NOC and kept updated in a timely fashion in order to
perform some of the above functilns, as well as tune the network. for optimum performance. This is part of
performance· management. Network SUllistics include data on traffic. network availability, aod network delay.
Traffic dam can be captured based on volume of traffic in various segments of the network. They can also be
obtained based on different applications such as Web traffic. email, and network news, or based an iriUlSport
protocols at various layers such as TCP. UDP. IP, rPX, Ethernet., TR, FDD[. etc. Traffic statistlcs are helpful in
detecting trends and planning future needs. Performance data on availability and delay are useful for tuning the
network to increase the reUability and to improve its response time.
Security Management can cover a very broad range ofsecurity. J't involves physically securing the network, as well
as access to the network by users. Access privilege to applicntbn software is not the responsibi lity ofNOC unless
·the application is.either owned or maintained by NOC. A security database is.established and maintained by NOC
for access to the· network and network information. There are other aspects of security management such as
firewall~ and cryptography, which viii be introduced later in Chapter II .

Accounting Management administers cost allocation of the usage of network. Metrics are established to measure
the usage ofresources and services provided.
Since the network consists ofcompo.nents manufactured by muliiple vendors, commonality in the definition and
relationship ofcomponent attributes is needed. This is defined by Management Information Base (MIB), which we
will discuss in Pan II. Some of the data acquisition has to be manual (because of leg~~cy systems), but most data
can and should be acquired in an automated mode. The SNMP is the most popular protocol to acquire· data
automatically using protocol- and perfurmance-analyl.ing tools.
As pan ofimplementing the above standards, we need to ensure that adequate reports are generated and distributed
to relevant personnel. There are, in general, three classes of reports: SYS!ems, management, and user. SySlem
reports are needed for network operations to track activities. Management reports go to the managers of network
management group to keep them infunned abonl the activilies and performance of NOC and the network. User
reports are distributed to users an a periodic basis or are available on-line to let ihem know the stains of network
performance.
J.9.4. etwori< ln.stallation 11.utl Maiuteuaoce
The Network l&M group takes care ofall activities oflll$tallation and mainie08Jice ofequipment and tnUJsmission
facilffies. 1ltis group is the service ann of the Engineering group for installation and fiXing troubles for network
operations. The group works closely with the Help Desk in responding to the problems reported from the field.
Having introduced what network management is from an operations, administration, maintenance, and planning
viewpoint. let us next oonsider the architecture and orgaitization ofan NMS.
1.10. Nclwork 1hnagcmcnl Archilcclu rc and Org11ni7.a1ion
We need to distinguish at the oUlset the difference between network management and network system and service
management. Remember tbat a user may not mnke that distinction when be or she cannot access an application on
a server from a client application in his or her workstation. This could beeither due to a problem in the application
progrnm in the server affecting one or mare clients or due to a.lrnnsport problem.from the client workstation to the
server platfonn. The fanner is a network system problem affecting tbe serviceofrered and ralls under the category
of network system and service management. The latter is a connectivity problem and falls under network
management. We can genernlicre system and service managemeni as the mnnab>emem of systems and system
resources in the network and services ofrered by the network. Network management is concerned with network
resources such as hubs, switches, bridges, routers, and gateways, and the connectivity among them via a network.
l t also addresses end-to-end connectivity between any two processors (not application processes) in the network.
As we saw in Section 1.1, a network consists ofnet'"r.k components and their interconnection. Each vendor, who
manufactures a n etwork component or a set of network components, is best qualified to develop an NMS to
manage that product or set of products. This involves getting data from each instance of tbat. component in the
network to one or more ·centralized locations and displaying their status on an NMS; for example, failure of a
bridge. This would set up an alarm in the NMS to alert operations personnel of the fai lure. This would enable
operations personnel to follow up on the problem and restore service·, even before the user calls in a complaint.
As mentioned above, e!ICh type of component is managed most efficiently by its respective management system.
There is need for an NMS to manage all the components tbat are connected to a netvork. Ag~~in, it is relatively
simple for a vendor to develop an NMS to manage a network comprising only their components. However, a user,
sucb as a g.lobal corporation. buys components from many different vendors, and the lnfonnalion systems manager
oftbe corporation bas the responsibility ofma inta.ining the network ofall vendor components. 1ltis mi~ht require
the installation of multiple NMSs fur an e nterprise or an NMS tbat can manage multiple vendor components ofa
network. Thus, common management system, as well as the integration ofdifferent management systens and the
interoperabilffy between them, has played a major role in the network management arena. Standards org~~niz:ations

and industrial commun.ities bave est'l!btished standards for this purpose, whiob are still eva lving. The two major
management staodards are the lnternet developed by the lntemet Engineering Task Force· (IETF) and OS!
developed by the ISO. We will look at the former in detail in this book. There are also standard~ that are developed
by industrial consortiums associated with specific technologies, such as DSL Forum and Cablel..abs.
Network management dumbbell arehitecture for interoperability is shown in Figure 1.24{a) where two vendor
systems A and B exchange common management messages. The messages consist of management infurmation
data (type, id, and status ofmanaged objects, etc.) and management controls (setting and changing configuration of
an object). The protocols and services associated with dumb beU architecture are presented in Figure 1.24(b).
Application servioes are the management-related applications Such as fault and configurailin management.
Managemem protocols are CMJP fur the OSl model and SNMP fur the Internet model Transport protocols ore the
first four OS! layers for the OS! model and TCP/lP over any ofthe frst two layers fur the l.nternet model
Figw·• t.24. Nttwork ~bnagtmtnt Dumbbtll Architrcturt
8 8
Figure 1.25 models a hierarehical configuration of two netmrk agents monitoring two sets of managed objects.
The agent could be an embedded agent in a network element or nn EMS communicating with agents embedded in
the network el.emeots. Ao NMS is at the top of the hierarchy. Each network agent monitors its respective objects.
Bither in response to a polled query from the NMS or triggered by a local alarm, the agent communicates to the
NMS the relevant data.
Frgurt 1.25. Nttwnrk Manogtlnrnt Comt>Onrnll!

Peer networks can communicate network management messages and controls betw~ each other, as shown in
Figure 1.26. An example where such a configuration could be implemented would be two NMSs associated with
two telecommunication networks belonging to two network servk:e providers; for example, an lnterexobange
cll!T.er and a local access provider. As the i wo NMSs communicate with each other, each NMS can superimpose
the data from the other and present an integrated pit1ure to the network administrator.
Figure 1.16. Ntlwork Mau•g<mtnl lultrot>•nlblllly
We want(o make one final note before we leave Utis section. Some ofthe issues associated with the management
of telecommunication network by the telecommunication service providers are unique and involve more than just
management of networks. lltis has given birth to the Telecommunication Management Network (TMN)
framework and related slllndnrds. We will address these in Chapter I0.
1.11. Network Management Perspectives
As we said earlier, the NMS primarily manages the networks that transport infoonation. However, from a user's
perspective, networks are means to an end, namely to have access to infonnation ucross the networks. Thus, the
users' needs require a total solution to mana&re the networks, system re.sources, and appucations that nm on
systems. Applications coukl be specific user applications, or general-purpose servers such as file servers, database
servers, and DNSs. Softwareproducts have since·been developed to address such system-wide solotions.

An lT manager is interested in more than managing networks, sys1ems, and applications. l:!e or she would like to
amoma1e other functions such as back up of databases and programs, downloading of software updales from a
centml location, and a host ofother support functions. These are required to run an IT opemtion efficiently and in a
cost-effective manner.
Another area ofsystem mnnageme.nt is logging and archiving ofevents. This is illustrated by a·case history when
the system performanceduring nom1aJiy slow activity time at night was poor. Further probing the system resources
indicaled that the system was busy with processes beiilg executed from outside the institution. The system bad been
"compromised;" i.e., had been broken into. The intruder could manipulate the normal system resource tools so as to
bide lhe intruder programs. The intruder was fiuaUy discovered from the archival system log.
Solutions to the total IT services are currently being offered by commercial <endors. We wiU discuss them along
with network and system management t·ools and systems in Part ill ofthe book. We will present here a high-level
view of some ofthe aJternale perspeclives of1he broad aspects ofnetwork mnnagemenL
I. U. I. Network Mllnll~eruent J'crspccti••c
Domains: ll1e·network managemenl overvi.ew given so mr in the chapter can be perceived as managemem of a
domain. The domain can ·be any ofa selected group ofparameters having common attributes. Thus, a geographical
domain refers 1
0 1be subdivisions of a large geogrophical region. For example, In lndia 1be u:lecommunictllion
administration is div.ided into circles, and e<tch circle maintains its own telecommunication network.
Another classification of a· domain can be based on v-endo:r products. Thus. we could have different vendors'
management systems managing their respective products. A third perspective of.looking at domains can be &om
the technology perspective. For example, IP-based products, telecommunication products, broadband
communicmion products, and digital ttansport ·products such as SDH cot~d each define a domain managed by a
sepamte NMS, as well as a different administrative group.
Protocols: Network management can be perceived from the protocol used 1omanage the network such as lotemel-
based SNMP and OS!-based Common Mnnagemenl lnfurmation ProtocoVCommoo Management information
Service Element (CM!P/CMJSE).Tmffic nse ofvarious protocols at each promcollayer can be monimred.
Network and Transmission Technologies: An end-to-end network system could be viewed as comprising multiple
network technologies traversing different transmission media and carrying information in different ttansmission
modes, each managed from a different network management perspective. Thus, an end-te>-end communication.
which can be represented as a logical circuit, could be made up of network elements comprising IP-based routers
and ATM-based switches. h can tmvcrse globally through coaxial cable in an access network, wireless
transmission over continents, fiber optic cable over land on a WAN, ru1d twisted copper wire at home. The
transmission mode could be digital IDM, or ATM, or a broadband access mode. An integrated NMS is used to
manage end-to-end availability ofa circuit that deploys multivcndor and multitcchnology networkele.ments.
1.1 L.2. Sen •ic.e M:tnagement Pen~t>ective
The network is used to provide service to customers and consequently what needs to be managed are the·services.
The real concern ofservice providers is more about seme management. Providing quality ofservice to satisfY the
customers' needs requires network managemem. However, while network management. focuses on the physica.l
network, se.
rvlce management focuses on services offured over I he network and those services meeting customer
needs and satisfaction. Various qualicy ofservice (QoS) parameters u.re defined and an SLA is reached between tbe
service provider and thecuslomer. There are several OSSs that provide different types ofservice management.
Communication services can be offered as public switched network services, lotemel. services, virtual private
network, real-time interactive audio and video services, and others too numerous to list. Computing services are
offured to clients using applications nmning on servers. These servers and applications running on them need to be

managed centrally by the service provider or enterprise that owns them. This management is also known as
enterprise management. It monitors the health of system resources, a.
s well as the applications that run on them.
There are managed service offering.~ available to manage multiple enterprise networks from a common
management facility.
1.11 .3. OSS Per.>pcctive
While the EMS. NMS, and enterprise management >')'stem are designed to manage the network and network
resources, OSSs support !he operation of network nnd service management systems. [o Section 1.9 we described
the supporting functions of networking needed to provide communication services as operations, administration,
maintenance. and provisioning (OAMP).
Provisioning System: The logical and physical network has to be provisioned to provide the.des.ired service to U1e
customer. An OSS, provisioning management system, does this function us.
ing several other OSSs such as the
inventory mllJlage.ment system, the service order system, and the element and NMSs, Provisioning management
includes. circuit provisioning, service provisioning, llJld network provisioning.
Inventory Management System includes inventory ofequipment and facilities. We can generalize equipment ns
active components forming nodes ofa n~
-twork and facilities as passive components linking the .nodes.
Customer Relations Management (CRM) operation support system manages complaints reported by the CL~tomers.
A proactive approach to CRM is theservice provider calling the customer on detecting a service outage indicated
byNMS.
Trouble Ticket and Work Force Management manages the troubles detected by the NMS and generates work order
in the Work Force Management System. Various OSSs help with the remote testing, either on-demand or
automated, in installation and maintenance.
IP Telecommunication Application Management: The traditional analog services of voice nncl video are now
o.
ffered as digital services. Such services as voice-over-IP lllld video-over-lP applications require· not only
management of data, but also coooectioo management. Sessions that are equivalent ro a circuit need to be
established and managed.
1.11.4. e-Busin~.~s Manag~men t
The <>business management and privacy requirements are associated witb EKOmmerce applications. This Includes
application management in Internet retaiJ aclivities, ns well as bllJlking automated ieller machines.
I.J2. NMS Platform
NMSs and tools are available in various platforms-hardware and operating system. Popubr higb·end systems are
housed on UNIX-based servers. Low-end NMSs run either on Windows or Linux-based platforms.
Most big)H)nd NMSs are equipped witb remote client capability and can be accessed either via Java client or Web
browser. Client platforms are either Windows or UNIX based.
Common troubleshooting and monitoring of network element parameters could be done by using sinnple
networking and network management tools. These are part ofTCPIIP stack. For example, nerwor.k connectivity
could be tested using ping and lraceroute commands in UNlX and tracert in Microsoft Windows. We will discuss
NMSs and tools in detail in Chapter 9.
1.13. Current Status and Futu re of Network Managl'mcot

Current NMSs are based on SNMP protoool. Most commercial network components have embedded SNMP
agents. Because ofthe universality ofthe IP, transport ofmanagement infOrmation for SNMP managemem, which
is TCP/IP-based, is automatically resolved. tn addition, most of the popular host-operating systems come with
TCP!fP protO<:OI suite and thus are amenable to SNMP management
Current NMSs, however, suffer &
o m several limitations. One of the limitations of SNMP-based management
system is that values of man.aged objects should be defined as scalar values. OSI-based management protocol,
CMrP. is object oriented. However, it bas not been successful due to the·complexity ofspecifications of managed
objects and the limitation of large memoty in computer systems in the past. Another limitation of SNMP-based
management is that it is a poU-based system. ln otber words, NMS polls each agent as to its status, or fur any other
data that il needs for network management. Only a small set oftransactions is initiated by a managemem agent to
an NMS as alarms. To detect a mult quickly. or to obtain.good.statistics, more frequent polling ofagents needs to
be done by the NMS, which adds to network traffic overhead. There is an alternative solution to this problem,
which is deployment ofremote monitors as discussed in Chapter 8.
Some ofthe above constraints in SNMP-based management have been overcome by emerging advanced network
management discussed in Chapter 16. Object-oriented techno logy has reached a matured stage, and the hardware
capacily to handle object-oriented stacks Is now commercially available. Titus, object-oriented oetwork
management is being reconsidered. Tltis bas potential application in Telecommunications Management.Net~Wk
d.iscussed in Chapter 10. Network managemem systems are currently built with object-orierued protO<:Ois and
schema, sucb as Common Object Request Broker Architecture (CORBA) protocol and Extended Markup
Language (XML) schema.
An active network, which is tbe direction of nexi generation network, would include embedded network
management applications. Besides the advancement of research and development in network maMgemeot io
standards, protO<:Ols, methodology, and new technology, there is considerable a.otivity in management applications.
which form the topic of Chapter II. Of particular significance are event correlation technology in fault
management., and secured nelvork and communication in security management.
With the proliferation of till} Internet, secured network and communicatio.n has beoome extremely impo11ant.
Existing management standards do not go far enough in this. However, security management has taken on the role
of a special topic in network management. Topics of high interest in this field are ftrcwalls that cstabHsh secure
networks and cryptography that as.~ure secure oommunication.
IT itself is exploding and gives rise to new challenges for expanding the horizon of network managemen.t.
Transport ofvoice, video, and data is integrated in broadband multimedia services. Broadband multimedia service
is based on ATM, IP, and MPLS in a WAN and several emerging ae<:ess technologies such as HFC, Asymmetric
Digital Subscn'ber Loop (ADSL), and fixed and tnobl.le wireless. Quality of service in integrated services is
important. Managing these new service offerings forms the conte.nt ofl'art IV.
Another re-emerging technology Jbr network management is the wireless technology. This is being widely
deployed for WAN, mobile. broadband access. and home networks. Much work on standardization ofmanagement
ofthis technology needs to be done in this area.
Summary
We presented in this chapter an overview ofdata and telecommunication network;, as well as converged networks
and how these networks are managed. Till} telephone network was shown as a model to be followed in
accomp.lishing a reliable, dependable, and quality data communication netwo(k. We elCplained the difference
between data communicat·k>n and tek:communicatk>n networks, although th.is distinction is fast disappearing.
Desktop processors and LAN technology have contributed to tbe client~rver distributed computing environment,
which has changed Lhc fltture direction ofdam communication. We briefly talked aboutlhc lnternel and intranel in

t01lay's environment. Adoption ofstandards bas played a significant prut in the popularity ofthe Internet. OSI and
CPs play an important part in data communication today. We also treated difficulties associated with rea.J.time and
non-real-time management of different segments of broadband networks and services. We bave presented ,o;ome
practical day-to-day experiences ofnet~vork managers, including "war stories" to make us realize the importance.of
network management. We saw a bird' s-eye view of oetwor.k maoagcme01 and described how network components
and networks are managed by network mafll!gement systems. We e:.1ended the concept ofnetwork management to
managing networks and systems and all of IT services. The future direction of IT management is undergoing
changes due to advancements in software and IT. Possible futuro directions in network management technology
were addressed nt the end ofthe chapter.
Exercises
Note for Problems 1--4: nis important that a network administrator befamiliar with both the protocols employed in
the network and the tools with wltioh its operation may be investigated. There are several tools that are
fundamental lOr administration of an lP network; the after used ones are ping, nslookup, and traceroute. These
commands sbould be available on UNIX platli>rms. You may get the syntax of their usage by logging into a UNIX
system and accessing the 01
1-line manna) by invoking the command man commandna·me. Similar tools or
commands are available in Windows 95/NT machines (ping, iracert, nslookup either buill in or external software)
connected to the Internet. Problems 1- 7 are intended to familiarize you with exploring a nerwork. You should be
able to do these exercises using the commonly available networking tools and on the Inter.net using webs.ites 1iUCh
as wbois.domaintools:oom and itemic.net.
l.n doing these exercises, if you have a problem reaching the destination host, you may use any other equivalent
destination site. lt is important fOr you to Jearn to use tools and interpret results.
1. Who Is the primary Internet service provider (ISP) In your Institution? Find another Institution served by the
same tSP by using a tr~roulll tool.
2. Educational Institutions In yourstate or province are networked. Discover that network by tracing the route from
your Institute or organization to other II'IStltlttes ororganizations.
3. Drawthe route diagram Identifying each node for thefollowing data obtain~ using a trace routing tool. Wtlat Is
the average time a packet takes to travel from noel host to netman host? noc2% traceroute
netman.cc.gatedt.edu
traceroute to netman.cc.gatech.edu (130.207.8.31), 30 hops max, 40 byte packets
main-rtr.gcalt.gatecb.edu ( 199.77.147.1) 1.045 ms 1.012 ms 0.971 ms.
130.207.251.2 (130.207.251.2) 2.198 ms 1.404 ms 1.837 ms.
netman.cc.gatech.edu (1 30.207.8.31) 3.528 ms 1.671 ms 1.602 ms.
4. Between which two hosts on the route between your slte and www.president.lv is the largest geographic
distance probably traversed? Support your answer with evidence.
5. Ping nsl.bangi!J.net in this e~erdse. State wtlat data you gathered and how it determinedyour conclusion.
a Measure the percent packet loss between a host at y()ur sit.e and the machine nsl.bangla. net, and
record ihe timeof your measurement.

b. Then cletennine where along the route to nsl.bangla.netlhe pac·kets are getting lost.
6. Foreach host on the route between your location and nsl.bangla.net (or any other foreign country), determine
the name of the administrative contacr responsible for It (use whols command from your UNIX system or from
lnternlc.net). List these names alongside the hosts. If you can't find-an administrative contacr for some of the
hosts, then at least state whatyou did find.
7. You can discover the hosts In your subnetwork by usi~ the ping command with your network IP address and
host address of decimal 255. Discover all the hosts in thesubnetwork that you are logged on.
8. In Problem 5, Identify thegateway from your subnetwork to others.
9. Identify the hosts In the neighboring subnetworks and draw the configuration of Interconnected subnetworks.
10. The email system Is based on dlent-server architecture. Send an email to a wrong node address (for example,
misspelling the remote node address). Explain the error message(s) that you get and the servers that you get
them from.
11. Send an email to a remote site with awrong user id, but correct node address. Explain the error message(s) that
youget and the servers thatyou get them from. ·
1.2. Explain the decimal notation In representing the clas.
ses of 1Pv4 addresses. Give an example for eachclass.
13. You are given a class B IP address of 145.4S.x.y for your ne~ork node. /Js a network engineer, you are·asked to
configureyour network for 126 subnets. (Remember that 0 and 1 are reserved.)
a. How would you configure your address for subnets and hosts?
b. What is the maximum number ofhosls lhat eaob subnel can accommodate?
14. An IP network Is connected to a Novell IPX network via a gateway as shown. Draw the protocol layers of the
gateway in Figure 1.27.
Flgurt 1.17. Extrdsc 14

,_.~~ lu.~c- r--- -
rcr ,,.,.
1- --
II' IPX
1- -
~'!J t(O~ J
1- --
l'lly Plw
I I I
15. MBI Corporation uses cc:mall, which is not Internet standard. The company also uses Novell IAN. Novell has
Internet Exchange Protocol, IPX (connectionless datagram service), as Its equivalent to Internet TCP/IP. As you
know well, most of the global email uafflc Is on the Internet with SMTP as the mall protocol. Figure 1.28 shows
the high-level configuration of the two networks connected through a gateway. Fill in the protocol layers ofthc
gateway.
Figurr 1.28. Exr•'tisr IS
SMlP c~mnll
- -
.
~1!.3 81)2.3
- -
~tffi.'Tlltl ll1bcrttol
I I I I
Cabk
16. Picture a scenario where you are downloading a file from a server, located in Europe, which has an X.25 protocol
base<! on the OSI Reference Model. liS physical medium Interface Is X.21. Your clientmachine lsronnected to the
Internet with Ethernet as the physical medium.
a. Draw the delllils of the CXlmmuniClltions oelvork in Figure 1.29(a) using bridges, routers, and a
gateway between lhe server and the client.
Jllgurr 1.29. E•r,..isr 16

0
_ -----~§I~N
iW,N~-----~
t:tJ Notwork ~
Cl..
-nl S<n<:r
(a) L·oumuUltCdlh.m NUt,•cuk. Uetwccnt.ll111 ttnd .S..·I-cr
ICal~>n U)'<:~ ipp:1c:mon 1-ll)'l'f<
lnto1nl.!c~nt <11111!ll)'
>po<l Luy•ll -i- 1'11lMpon U)<t<
C~II'Ct)ii.:! 'Ll:•y~n
I I'A>~•col Medium
I I l'llyS~a~l M<<hum
I
(b) C:~n1munlcmlon lki~CII fnd S)'I'ICI"-' via .111 l•tenncdlnJ.: S)"'<nl
b. Complete the protocol architecture in Figure I.29(b) for the intermediate gateway system.
17. In Case History 2 described In Sertlon 1.7.2, the delay In alarm indication In INMS was attributed to several
possible causes. Givean example for each ofthese causes.
18. ~a network engineer in a Network Operations Center, you are followl"'! up on two trouble tid<ets. You do not
have a network managementsystem and you haveto use the basic network tools to validate the problem before
you can resolve them. Please explain what tools you would use In each case and how it would validate the
customer complaint
a. Trouble Ticket 100: Customer says tbat when be receives messages, the message is periodicaUy
missing soroe cbarncters.
b. Trouble Ticket 10I: Customer in Atlanta complains that when she t·ries to log into the system
server.beadquarters.com in New York, she gets disconnected with a lime--out. However, her
c<>lleaguein ber New Yorkoffice "''POrtS that he is able 1
0 access the system.

2. Review oflnformation Network and Technology
Objectives
Network components and technologies to be managed:
o Nerwork topologie~ LAN and WAN
o Wired LAN topology: Bus, Ring, Star. and Hybl"id Hub
o Wireless LAN
o WAN topology: Mesh and Tree
o Fi.'l:ed and mobile wireless networks
o Fiber networks
Ethemer LAN:
o Physical media and MAC protocol
o I0 and I00 Mbps; I and I0 Gbps Ethernet LAN
o Switched and Duplex Ethernet LANs
o Jlirtual LAN
Token-Ring LAN
FOOl
Network components:
o Bridges
o Routers
o Gateways
Circuit switching and packet switching
Transmission technology:
o Transmission media: Wired and wireless
o Transmission modes
o Multiplexing: TDM aod WDM
o SONET and SDH
Multimedia networks and services
In Chapter 'I we learned thlll a n.etwork comprises nodes and links. Nodes are switches, bridges, routers, or
gateways. Links comprise Local Area Networks (LANs), Wide Area Netwo[ks (WANs), Access Networks. or
Customer Premises Equipment (CPE)/Horne Network~. In this chapter we will review these oomponents &om the
perspective.s ofconcept, technology, aod management. We will limit our review here to Internet-based components
and some ofthe telecommunication components. COmponents associated with broadband-specific networks will be
covered in detail when we address them in later chapte.rs.
Section 2.1 presents various network topologies ofl..ANs and WANs. ln Section 2.2 we start with basic Ethernet
and then traverse the development ofEthernet, Fast Eth.ernet, Gigabit Ethernet:
, and switched Ethernet. Token Ring
'vas the most commonly used LAN in the lBM mainframe environment. Fiber-optic technology uses Token-Ring
architecture to develop Fiber Distributed Data Interface (FOOl). Flexibility ofLAN.facllities has been significantly
increased by the development of virtual LANs (VLANs). Wireless LAN (W'LAN) has become an important
comp<lnent of the modern network.
Network node components form ihe contents ofSectio.n2.3. We stan bY describing the implemenllltion ofLAN as
a discrete component, a hub. LANs are lnterconnecte.d by bridges. A bridged network is made up ofremote. bridges
in a tree !apology. LANs·can also be connected in a mesh WAN topology using rouiers as nodal components.
Autonomous WANs with diverse networking protocols are intercoonected with gateways that do protocol
conversion at network layers and above. HaU:bridgelhalf-router configuration is used for Internet poior-to-point

communication link. The discussion ofSection 2.3 ends with a switching component and the prut it plays in WAN
topology. Wide area network is briefly discussed in Section 2.4.11 is the telecommunication network that oomput.er
(or data) communication traverses a long distance.
Section 2.5 addresses ltnnsmission technology. Il oomprises wired and wireless technology that transports
information over LANs and WANs. l11e mode ofltnnsmissio·n may be either analog or digital; and a message may
be transmitted.in either mode, or part of the way in analog mode and the rest in digita I. This becomes especially
true in broadband multimedia services where data. voice, and video are integrated into a oommon service,
lntegrated Services Digital Network (tSDN). Broadband network made up of hybrid ~hnologies is introduced in
Section2.6 fOr oompleteness and is discussed in detail in Part IV.
2. I. Network Topology
A LAN is a shared medium serving many Digital/Data Tennloot Equipmeots (DTEs) located in close proximity,
such as in a building. LANs could.also be deployed in a campus environment connecting many buildings.
Three topologies are associated with LANs: bus, ring. and star topology. There exists a fourth pseudo-topology that
oombines a star topology with either ofthe other two and is known as a hub. A hub plays an important role in
11etworkingas we will soo.n team.
LAN topologydepicts the configuration ofhow Dl'Es are interconnected. Different protocols are used in different
topological configurations. Bus arcllitecture is implemented in LANs us.ing Ethernet protoool. Token Ring and
FDDl configurations use the ringlopology. PDDI can cover a much larger geographical area than Token Ring on
copper. Fiber rlng topology bas been extended to Synchronous Optical Network (SONET) and Resilient Packet
Ring (.RPR). SONET and RPR can he considered geographical extensions of LAN to WAN, also known as
Metropolitrul Area Network {MAN), and use different protoco~. A star topology is used in cabllog infrastructure
and is ideally suited for bub implementation, or for WLAN using an access point (AP).
WANs are configured using either the mesh or the tree topology. The mesh topology is the most common fOrm lOr
lntemet routing. lbe uee topology is employed in network using brouters, which are bridged routers that do the
routing fu.nction at OSllayer 2. It isalso known as spanning-IJ'eeconfiguration.
The three LAN topologies and hub configuration are shown in Figure 2.1. ln the bus topology, Figure 2.1(a). all
DTEs ore on a shored bus and have equal access to the LAN. However, only one DTE can have control at any one
time. A randomization algorithm determines which DTE has control ofthe LAN at any given time. This topology
is used in Ethernet LAN. Because collisions occur whim more than one station tries to seize the LAN at or about
the sa.me time. the bus LAN usually functions at mucb tess than fuU efficiency. Ethernet protocol is specified by
lEEE 802.3 standard
Flgurt l.t. LANTopologlu

lol BusTopotugy
(t)J Ring 1opo10gy
(c) S!nr ToPQI<lgy
Ethatn&tHub To~an-Ring f'iub
(d)HubConfigurations
Figure 2.1(b) shows ihe ring topology and was most populllriz.ed by fBM's Token-Ring LAN. In this topology,
each act.ive DTE connected to tbe ring takes turns in sending lnformalion to anoiher DTE in the ring, which may be
either a receiving bosto r a gateway to an external network. At ihe time a DTE communicates over ihe ring, it is in
control ofthe ring and control is managed by a token-passing ;-ystem. The DTE holds on to the token while it is
sending data and releases it to its downstream neighbor (round-robin) after its tum is finished. Thus, ihe process in
thls topology is detenninistic and LAN operates at almost full bandwidth·efficiency. IEEE 802.5 StliJldard specifies
token-ring protocol. FOOl technology also uses ring configuration, implementing IEEE 802.4 standard.
Figure 2.l(e) represents a star topology that was once used in star LAN. However, il is at present used in a hybrid
mode, as discussed in the ne,_1 paragraph. In the star topology, all DTEs are connected to a central node and
interconne<aed in one oftwomodes. They can he connected in a broadcast configuration. I n this configuration, all
the oUter DTEs receive data transmitted by a DTE. This would be similar to a bus topology. In the second
configuration, DTEs are connected to the central node, but are interconnected on a pair-wise basis selectively. In

this situation, multiple conversations can oa:ur concurrently be1.ween vnrious DTEs passing through the central
oode.
As mentioned earlier, a hub configuration uses a slar topology in combination with either a bus or a token-ring
topology. Tbe hub configurations shown in Figure 2.l(d) are the most popl~ar LAN impleme11tation. The !tub is
also known as a Layer-2 switch. It is a hybrid between (c) and either (a) or (b). DTEs are electronically connected
to each other at the central node· in either the bus or the ring topology. If they are connected in a broadcast
configuration for an Ethernet LAN, it is called an E1berne1 hub. lfDlEs are connected in a ring topology for use
with token-ring LAN, it is called a token-ring hub.
WAN differs tram LAN in that it links networks thai are geographically sepamt.ed by a long dislance. Typically,
the WAN link connects nodes made upofswitches, bridges. and routers.
WANs are connected in eiiher a.mesh or a tree topology, as shown in Figure 2.2. The mesh topology, Figure 2.2(a),
provides multipl.e paths between nodes. Thus, a message between nodes N I and N6 may traverse the paths NI-
N2-N5-N6, NI-N3-N5-'N6, NI-N2-'N3-N5-N6, NI-N3-N2-N5-N6, NI-N4-N5-N6, NI-'N4-N3-N5-N6, and
N 1-N3- N4-N5-N6. 1llis alliws packets belonging ro a message to traverse different paths, thus balancing traffic
load. It further provides redundancy fur reliabiliiy ofservice. However, a broadcast message from Nl to all other
nodes will be rebroadcast by neighboring nodes N2, N3, and N4 to all other nodes. This could cause flooding on
the ne~vork and looping ofpackets, which needs to be carefully addressed. Flooding is a node receiving the same
packet.s nwltiple times, and looping is a packet going around nodes in a loop, such as N2-N3-NJ-N2 or N4-N3-
N2-N 1- N4 palbs. A mesb topology is usually implemented using switcbes and router'S.
f!lgur•l.l. WAN Totmlugi<s
(a) MeJII Topology (b) rree Topolo9>'
A tree topology is shown in Figure 2.2(b). It appears as a hierarchiesI architecture. The tree structure starts witb a
node, called the header node, and branches out to otber nodes in a tree stnrclure-
. There can be no closed loops in
the network. However, paths beiWeen nodes may be longer. For example, the packet from N4 to N6 has to traverse
the top of the hiemrchy NI and then down to N6. The tree topology is simpler to irnpl.eme.nt than the mesh
·topology and uses bridges 81 tbe OS! data link layer.
2.2. Locul Area Networks
There are two types of LANs that are deployed, bus based or ring based. The most common bus-based LAN is
Ethernet and is the mostwidely deployed LAN. Ring-based LANs are Token Ring and FDDI.
A representation of a campus network with difter~"Dt LANs is shown in Figure i.3. The backbone of the campus
network is a fiber network 10.10.0.0. The notation ofthe fourth decimal position being 0 is used to represent the
network address. Ethernet LAN (10.1.2.0) is connected to tbe backbone via a router. Workstations on tllis LAN

have the fOurth decimal position in their lP addresses from 2 ro 5. 1P addresses 10.1.2.1 and 10.1.2.6 are the
inred"ace addresses to the router and the bridge.
Flgul't 2.3. Cantpll' Nrtwol'k nf LAN1
0
D ~ ~ ~
1().1.12 10.1.1.S 10,1.14 10.1.1.5
~._, r I
t:=::::er,emet 10,1.1.0
I
10.1.1.1
8 rldga I· r-1
10.i.2.6
10.1.2.1
Rau~er
I
QATM ELAN 10.4 1.0
I I
}
The second Ethernet LAN ( 10.1.1.0) is connected.to the first. Ethernet (10.1.2.0) via a bridge. lP addresses 10.1.1.2
to 10.1.2.5 are interfaces to workstations and the lP address 10.1.1.1 is the interface to the bridge. Notice that all
elrtemal tmfftc from I 0.1.1 .0 Ethernet has to traverse I0.1.2.0 Ethernet LAN. I0.2.1.0 is a token-ring LAN
connected to the backbone FDDI ring via a route.r. Two other LANs that are connected to the backbone are ATM
Emulated LAN (ELAN)(I0.4.1.0) via a·router and an Ethernet LAN (10.3.1.0) via two halfrouters. The two half
routers are connected via a dial-up tink. II should be pointed out that most campus networks currently deploy bigb-
speed Ethe.met over fiber medium and LANs are exclusively Ethernet LANs. We will review LANs in this section
and network componeniS in Section 2.3.
2.2. 1. Ethernet
Ethernet uses bus architecture with Carrier Sense Multiple Access with Collision Detection (CSMA/CD). DTEs are
all connected to the same bus and transmit data in a multiple access mode. ln other words, several DIEs can start
transmitting frames at the same time. A frame comprises- user data that are encapsulated with a header containing
the source and destination address. A DTE stariS ITIU!smitt.ing when there is no carrier sensed on tbe 'bus. The
transmitted signal travels in both directions on the physical medium. While transmitting, ifa coll1sion with another
frame is detected, the DTE stops transmitting and attempts again after a certain period. Thus.. the mode of
transmission is a broadcast type with probabilistic collision oftbe signal.

A good iUlalogy to undersUUKI the collision phenomenon is to env1
s1on a hollow pipe with boles all along
represent·ing surtions. There is a person at each ho.le represenc·ing a station. The ends ofthe pipe are sealed aod do
not reflect sound. Let us suppose Joe smns speaking at a bole near one end oftbe pipe. He makes sure that be does
not bear anybody speaking before be smns (carrier sensing). Once he st.ans talking, he has to make sure thai
nobody else starts t.alking unt·iJ he finishes. He does this by continuing to talk and at the same Hmc listening for
other messages on the pipe. If he bears nobody else, then there is no·collision. Ifhe bears somebody else, then his
message bas collided with another person's message; and they both bav.e to Sian over again. The longest time thut
Joe lias to wail.is fur a voice to reach him from a person speakingat a hole near the other end ofthe pipe; and that
persOn starts speaking jDSt heforeJoe's voice reac.bes him. From this ana.logy, we can ca.lculnte thatthe minimum
duration oftime that Joe lias to keep talking to ensure that there is no collision is the round-trip propagation time of
his voice along dte length ofthe pipe. Thus, there is a minimum frame size fOr Ethernet packets, which is 64 bytes.
It is left as Exercise I for the srudent to prove this.
IEEE and ISO standards have been developed for Ethernet second layer MAC. They are IEEE 802.3 and ISO
8802.3, respectively. According to these standards, a physical coaxial segment can be a maximum of500 meters;
and there can ben maximum of 100 DTEs connected to it. A maximum of five segments can be connected with
four repeaters to fOrm one Ethernet LAN. However, iflhere are branches in the LAN, as in n tree structure, then
any one tol1ll Ethernet segment should obeythe above rule.
The daUI rate on an Ethernet bus is nonnally 10 Mbps (million bits per second). When traffic on the bus reaches
about,40% to 700/o of the maximum duta rate of10 Mbps, depending on the packet size, perfo[((laoce degrades
significantly due to an increased collision rate. The bus medium can either be tbick (0.4" diameter, but this Is no
longer deployed) or thin (0.25" diameter) coaxial cable; and DTEs are tapped on to the bus in a T-connection.
Tbe.
re is a maximum segment length for LAN depending on the medium. This is listed in Table 2.1. There is also a
limit on the length of tbe.drop aibl1>-tbe cable from the LAN tap to the connector on the network inler.
fuce card
(NIC) of the DTE. This is also shown in Table 2.1. As can be seen from the table, the original segment length
defmed for I0Base5 determined the minimum ·packet size of 64 bytes. However, with different configurations
sbo,vn in the table (I0Base2. 10Base5, IOBase-T, nod IOBase-F), segmerrt lengths and drop lengths Vlll)' baSed on
thelOedium. However, theminimum packet ~ize is stillmaintained at 64 bytes.
Tabltl.t. Etb<rntl LAN Topology Limits
Type Oesc:.rlptlon Segment length Drop cable Length
10Base2 Thin coax (0.25") 200meters Not allowed
108ase5 Thick coax (0.4") SOOmeters Twisted pair: SO meters
lOBase-T Hub topology N/A Twisted pair: 100 meters
lOBase-F Hub topology N/A 2·kilometer fiber
Ethernet LANs used to be configured by running coaxial cable around the DTEs with each DTE being tapped on to
the cable. This could cause a. great deal of management problem in tracking a.fnuliy DTE.lt is also difficull to
isolate aDTE that caused heavy load on the LAN, or a killer DTE that bas a problem rutd brings the network down
frequently. It is likely that sometime~ the maximum length of Ethernet LAN could have exceeded the allowable
l.imit. The network could then crash intermittently at the limit length. It could also have an intermittent problem
when traffic on the LAN exceeds tbe threshold. ll~ese problems have been eliminated by setting up the Etl~ernet
LAN in a hub configuration, as shown in Figure 2.1(d). All DTE links, "drops,'' are bi'Ougbtto a hub ICH:ated in a
central wiring closet illld connected to a dedicated por1 of the hub. DTEs are connected inside the hub in an

Ethernet configuration with active electronics. Problems assl)<liilted with a DTE can now be isolated 1
0 a port in
this configuration aod resolved in a much easier fashion.
2.2.1. Fast Ethernet
The hub te<:boology described above led to the development ofFast Ethernet technology. Fasl Ethernet operates at
a speed of I00 Mbps data rate on an unshielded twisted pair (UTP) cable and is c~lled IOOBasc-T. The maximum
length from Ibe hub to the DTE is specified as 11 I00-meter or a 200-meter rouod trip. This produces a maximum
path delay, which is the delay be1ween two DTEs of400 meters, plus a repeater delay ofooo repeater instead of
four repeaters. This is less than onc>tenth the delay in straight Ethernet MAC specific11tions (5,000 meters) with
four repeaters.Thus, speed can be increased ten times from I0 Mbps to I00 Mbps. However, to be consistent with
IEEE 802.3 standards, an additiooal sublayer, convergence layer. needs to be introduced in the physical layer
above a physical medium-dependent (PMD) sublayer (similar to what we saw in the OS! network layer). This is
shown in Figure 2.4. The physical medium should be capable of carrying a. 100-Mbps data rale signal over U~e
maximum leogth oflhe drop cable, which is 100 meters. Category 3 UIP cabJe.cannol carry such a bigbdata rate.
Hence, fuur pairs of UTP cables are used to distribute the data, each pair carrying 25 Mbps. J,!ence, the
terminology 100Ba<;e-T4 is used, that. is, 100 Mbps carried over fuur twisted pairs. This limitation could be
overcome by using two pairs ofCategory 5 UTP cable in full-duplex mode coofigumtio.o, which we will discuss in
Section 2.2.4. TbemininiUm packet size of64 bytes is mainmincd fOr Fas1 Ethernet.
Figu.-r 2.4. IOOBasr-T F0$1Ethtrnet Pr·oroool Archlleclu,..
Notwor~
Datalm~
LLC
MAC Subiayer
Ptlysical
ConvorgcnC4 Layer
PMDSub!ayer
LLC' LO!)lcal L1
nk Control
MAC. Medium AccCM Co111rol
PMO: Physlc~l Medium Dependent
2.2.3. Gig;lbit Etlr en~ et
With the successes ofEthernet and fiber-optic communications, tbe logicalevolution in Ethernet technology led to
tbe development of Gigabit Ethernet, Ethernet operating at I Gbps (gigabits per second). Gigabit Ethernet is one
hundred times the.speed of regular Ethernet, ten times ihntof Fast Ethernet, and faster than FDD! opemting at 150
Mbps.
Along with the deve.lopment of Gigabit Ethernet, a pamllel task was undertaken to double the bandwidth of
Ethernet by full-duplex operation. We haveso far conside.red only half-duplex operation in the CSMNCD scheme.
We will first describe Gigabit Ethernet in the CSMNCD half-duplex mode in this section and consider the full-
duplex mode for all types ofEthernet in t11e following subsection.
An approach similar to that of Fast Ethernet was taken to make Gigabit Ethernet compatible with the existing
Ethernet network. IEEE 802.3z protocol, whose architecture is shown in Figure 2.5, maintains the data link layer
components, logical link control (LLC) and themedia access control (MAC
) 1he same, and modifies the pbysicaI

layer. Physical layer archit~ture combines the physical interface ofthe high-speed f?ibreChanoel (developed for
fiber-optic communication) with that of IEEE 802.3 Ethernet frame format.l1 consists ofrour sublayers: physical
medium-dependent (PMD), physical medium attachment (PMA), convergence, and reconciliation, which interfaces
with the MAC layer.
Flgurt l.S. If.Ef. 802.37. Glg~bll El htrotll'r~toc:ol Al'hhtc•urt
NeM'Ofk
LlC
Data lllll< MAC Sublayer
Co~ve'l)enee Sublayer
(Eocod~r/Deco<,kr)
Pltr-sia 11 P~1A SUblayer
1
Serlallze110<1seriai<Ler)
PMD Sub!ay<tt
LLC: Logle<ilin~ Colrtrol
MAC; Medium Access Conttoi
PMA; F~)'Sitlll M<!<l1
um Allachmenl
PMO. Physical Medl<L'Il Oepencent
Gigabit Ethernet specification initially pennits use ofthree physical media They are: long-wave laser over single-
mode and multimode .fiber, IOOOBase-LX; short-wave laser over multimode fiber, IOOOBase-SX; balanced
shielded 150-ohm copper cable; and UTP cable. IOOOBaso-T.
Both shon-wave (780 nanomeier, light frequency) and long-wave (1300 nanometer, near-infra-red frequency)
lasers are specified to be transmitted over multimodc fiber, whereas only long-wave laser specification addresses
transmission over single-mode fiber. There is no support for short-wave la.o;er over single-mode fiber. This is base-d
on cost perfurmance. Long-wave laser over single-mode fiber (1300 nanomeier laser over 9 micron fiber) can be
used up to a ten-kilometer disl8nce, whereas multimode fiber typically extends up to two kilometers. Commercially
available multimode fibers are 50 and 62.5 microns in diameter with fiber connectors that can be plugged i.nto
equipment. Tabl.e 2.2 summarizes approximately ibe various combinations of media, mode, and drop length (on<:>
way). Attenuation is in the rangeof 0.25 to 0.5 decibels per kilometer, after which regeneration or amplification
may be required.
Tablt :u. Glgobll Ethtrntt Tot>Oiog..v Lhulb
9 Mk.ron Single SO Mk.ron Single SO Micron 62.5
Mode Mode Multimode Multimode
lOOOBase- 10 km
LX
lOOOBase-
SX
3km SSOm 440m
550m 260m
Micron Balance Shielded UTP
Cable

TAble 22. Glgobll Echtrntl Topology Lhnils
lOOOBasf>-
CX
9 Mkron Single so Micron Sl~~&le SO Micron 62.5
Mode Mode Multlmode Multlmode
Mlaon Balance Shielded UTP
Cable
25m
100
m
In Figure2.51be PMA is a serializer/deserlaliz.er that handles multiple encoding schemes of the upper convergence
layer. The encoding scheme is different between optlcal (8B/IOB) and copper media in the convergence layer. The
reconciliation layer is a Media-independent interface (MIT) between the physical media and the MAC layer ofthe
data link control layer.
An added complication of going to I Gbps speed is the minimum frame size. Original Ethernet specifications,
based on 2500 meters in length with !bur repeaters, eacil producing approximately a 5-microSECOnd delay and I0-
Mbps data .ane, required a minimum ofn 64-b)te fmme, shown in Figure 2.6(a) to detectany collision. The time to
accommodate the 64-byte frame is defined as the slot time, which is 51.2 microseconds. An idle time of 96 bits
was allowed between frames, as shown in Figure 2.6(b). Fast Ethernet with a IOO"meter drop, I00-Mbps data mt.e,
and onerepeater (minimum time each packet needs to traverse in a hub configumtioo) would take a little over five
microseconds. Thus, a slot time of5.12 microseconds with a 64-byte minimum fmme si~e meets the minimum 64-
byte slot size, as shown in Figure 2.6(c), to be compatible with original Ethernet specifications. A round-trip delay
in Gigabit Etheme1 is primarily determined by the repeater delay. To be backward compatible with original
Ethernet specifications baSed on CSMA/CD, the minimum packet size was extended to 512 bytes, but. the
minimum frame size was still kept as 64 bytes. For smnll frames, a carrier exiension was allowed, as shown in
Figure2.6(d), to increase the number ofbytes in a slot to 5l2 bytes corresponding to 4.096 microseconds.
l'iguJ'tl.6. Elhtrntl F01111•1S and 801.3 Frome

(a) IEEE 1!02.3 Fl'lllre Fo-rnal
~ l~lc 802.3 FBm!l
Idle I
(54 BytesMin 1
Slolllme~S12M~
(64 B)'lco)
(b) 10 Mbol Ell-.enlel Frat.,
' Idle
802.3 Frame
Idle I
(64 BylesMW> I
Slot lime1 5 12 MlaOSetOndt
(648ytes)
(c) Fast ElhometFrorre
ldlo
&02.3 Fra'OO
(G4 B~tes Mm.)
Slol lill'C ... 01'0 M~Cl06«0<>d>
~128vt!!l
(d) Glg<ibll EIIKlrn« Fm'l10
An additional modification wasmade to GigabitEthernet specifications to permit bursts offrames 1
0 be transmitted
by a single slalion. This is called packet bursting. Devices could send bursts of small packets and utilize full
bandwidth copacity. ln sucb a situalion, the transmil.ling Station should not allow idle time between frames. Tbis
feature improves the effic.iency oftransmission, especially in the backboneconfiguration.
Wilb increased data rale capabili1y, Gigabit Etherne1 can transport muliimedia service lbat includes voice, video,
and data. Quality of Service (QoS) that can establish priority of service to acoomplisb real-lime 1ransmission is an
essential requirement for implementation ofmultimedia service. ffiEE 802.1p spwifYing theclass ofservice (CoS)
meets this requirement in a limited way. In addit ion, Resource Reservation Protoool (RSVP) can be used for
advance reservatk>n ofbandwidth for this purpose.
2.2.4. Full-Duplex Eth'"..-nct
We have so fur discussed in the last two subsections intreasing the bandwidth of Ethernet by two orders of
magnitude by migrating from 10 Mbps Ethernel lo Gigabit Ethernet. We will nov discuss how dalll rates of
Ethernet, Fasl Ethernet. and Gigabit Ethernet could be doubled by migrating from a half-duple.'< to a fuU-duplex
configuration.
As mentioned in the previous subsection, CSMNCD configuration is a half-duplex operation. This means that the
signal could traverse only in one direction at a given time in the cable to avoid collision with another signal ln
Section 2.2.1, we gave the analogy of speaking into a hollow pipe 1
0 demonstrate !he collision. Let's extend that
analogy to the case where there are 1wo hoUow pipes and the sound is allowed to travel only in one direction. One
pipe carries sound in one· direction, and the· other in the opposite direction. ln this case, each person c.an be
speaking on one pipe and receiving a message from somebody else on the o1her pipe at the same time. This
analogy applies to the switched LAN where each station is connected to the hub by two channels, This is!he basic
concept ofa full-duplex configuration. Carrier Sense Multiple Access with Carrier Detection (CSMNCD) does not
apply in tbis con.figuratlon.

With an active LAN implementation with repeaters ilnd the sophistication of electronks in a ltub, CSMA/CD
restriction could be removed and a. hub with a fu.JJ-duplex operation could be· implemented. lEEE 8023x
speciJications, shown in Figure 2.7, were developed for this purpose. Using this seheme, the bandwidth could be
doubled for each type of Ethernet configuration. Thus, the Ethernet fulkluplex configurution could handle 20
Mbps, Past Ethernet 200 Mbps, and Gigabit Ethernet 2000 Mbps. The full-duplex configuration is generally used
in po,
int-to-point communication This feature can be turned on or off in config1.1ring U1e hub. For a point·t<>-point
link, an optimal flow control feature specified in IEEE 802.3x can be.exercised. The receiver can send a "pause
frame•··ro the transmitter to comrol the flow in case ofcongestion.
Figure 2.7. 1EEE802.J J l'rotocot Arehittc:tur.
Nerwlrt
Oato Unk
LLC
MAC Sv~layor
CSMAICOor l'ui-Ouplex
Alys!Ci;ll
Because ofthe 802.31. protocol extension, the notation for Ethe.rnet type is modified with an "x'' exte.osion. Thus,
IOBase-T, IOOBase-T, and IOOBase-F are modified to be IOBase-Tx, IOOBase-Tx, and IOOBase-Fx. The Gigabit
E;themet types already denoted ending in x, the option being set to either full- or half-duplex.
Limitations in Gigabit Ethernet implementation to be compalible with original Ethernet with CSMA/CD are
removed in full-dupleK implementation. Thus, the carrier extens'ion, slot time extension. or packet bursting i's not
applieable. The Ethernet 96-bit interfuce ,gap (idle time between frames) and 64-byte minimum packet size would
still apply.
2.2.5. Switched Ethernet
Another outcome of hub technology is the switched Ethemet. lnstead ofjust the broadcast mode inside the hub,
packets are opened to see the destination address and passed through to theappropriatedcstination port. The switch
hub can be implemented as a learning device by reading the source·address and thus building a routing table to
speed up the process. Pairs ofDTEscan communicate with each other in parallel as long as they are different DTE
pairs and consequent ly, multiples of I0-Mbps channels arc traversing the .
Ethernet hub at the same time. Tills is
shown in Figure 2.8. There will, however, be a collision if a DTE receives packets from two other DTEs
simultaneously and needs resolution.
Flgurt Z.S.Swllcbo<l Eibtrotl Hub

Not all pons in a switcbed hub have ro operar~: ntthe same data rate. A typical arrangement will ~for one pon io
operate at a high data rate and. will be connected to a server D'TE, with other pons co.tmected. to cl.ieot DTEs. A
switched hub in a client-server configuration is shown in Figure 2.9 with the server operating atlOO Mbps aod the
clients at I0 Mbps.
Figuro. l .9. Swil<h<d Hub iu • Clitnt-S.n·~r Cuufigumliou
1!
5enrer
I
IOOMbpe
I
Switohod Hub
I
s
WorkstaU«! 'Mlrkstatlon
2.2.6. IO·Gigabit Ethernet
A I()..Qigabit Ethernet or IOGb.E or 10 GigE is the fastest of Ethernet standards. It combines the technology of
standard Ethemei, full-duplex Ethernet, and switched Ethernet to create a LAN hub with nominal data rate of I0

Gbps over fiber, IEEE 802.3AB, and over copper UTP as specified by IEEE 802.3ao standard. A tO-Gigabit
Ethernet LAN does not follow the CSMNCD protocol [Wikipedial]. llte tO-Gigabit· Ethernet standard
encompasses a number ofdifferent physical layer standards, with each physical pon·in a device supporting any of
the many different modules that suppon different LAN or WAN PHY standards.
2.2.7. Virtu11l LAN
Another advantage of the switched Ethernet is the capability to establish VLAN. Using a ·network management
system, any port can be assigned to any LAN, and thus LAN configurations can be changed without physically
moving equipment. In a corporate environment., this has the advantage of grouping personnel, for c:.xample, into
different administrative groups with shared LAN without physically moving their location.
As an Ulustraiion, MAC addresses for hosts in Figure 2.10 cculd be assigned to t~vo different LANs. Switching
occurs by the Svitch opening the packet received on a port, reading the OSI layer-2 MAC !!ddress, and then
transmitting it on another port lh!!t may be connected to a different LAN at u different speed. We thus have
switched a packet from one LAN to another, which is the function ofn bridget:hat we w~l discuss in Section 2.3.2.
However, it is wortb noting here that the workstations that are physically connected ro a switched hub belong to
1wo LANs, each being defined as a Virtual LAN (VLAN).
Flgurt 2.10. Vb1u11l LAN$
~ 'L.J=I
-~~-~
~lot Swltthe~HuD
PollforSubnels
200 100 ISO I
and
zoo 100 160,1
vt.AN VLAN
200.100.160.1 200.100.160.1
1'he concept ofVLANs is shown in Figure 2.10. 1l1e router directs all packets destined for subnets 200.100.150.1
and 200.100.160.1 to the same pon·on the router. They arrive at the switched hub and are routed to DTE I thiough
DTE 5. Ea.ch of the five DTEs shown in the figure could be assigned an IP address belonging to either
200.100.150.1 or 200.1 00.160.1 ood thus will be intermingled between the two VLANs.lfDTE I and DTE 3 both
belong to 200.100.150.1 VLAN, then traffic emanating from DTE I destined for Dl'E J would have been switched
within the same VLAN. DTE I could be assigned an rP address 200.100.150.2 and DTE 3 could be assigned
address 200.100.160.2. l,o this case, they belong to diffi:rent VLANs. MAC addresses remaining fixed (they are
assigned in the factory); the packet is now switched between the two VLANs.
Service providers now offur VLAN capability that Is spread across a geographically wide area and traverses
through switching offices and WAN.
2.2.8. Token Ring
Although Token-Ring LAN is a legacy LAN, we will describe it he.re as its ring ccnftgumtion, and fail-safe
redundancy aspects have been adopted .in later versions ofLAN and MAN, such as FDDI and RPR, respectively.
Token Ring uses the ring topology and is specified by lEEE 802.5 protocol. There is no segment length limit as in
Ethernet LAN. All DTEs are connected in a serial fashion in a ring shown in Figure 2.11.

Fi~urt Z.ll.TokLn·Ring LAN
A token is passed around (counterclock,vise in Figure 2.11) in a 1midlrectional mode; and the DTE that has the
token is in control of the· LAN. Let us consider in Figure 2.11 a situation where DTE 4 bas just completed
trllllSmission ofa message and bas released the token. DTE I .is waiting to pass a message to DTE 3. As soon as the
token is received, DTE I bolds on to the token and transmits its message to DTE 3. 1lte message bas tbe source
and destination addresses. DTE 2 looks at the destination address and does not pick up the message. DTE 3
examines the destination address, and realizes that the meJ>sage is for itself. It then picks up the message and
retransmits it witb acknowledgment marked in the trailer ofthe message format. The frame goes around to DTE I
with DTE 4 just passing the message through. Recogniz.ing thal the message has been received, OTE I releases the
control token and now OTE 2 bas a chance to send a message. [fthe message was not accepted by OTE 3 for any
rellSOn. such as a corrupt message. then tbe message trailer is so marked and appropriateaction is taken by DTE I.
As can be seen, in the token-ring LAN. MAC is deterministic in cornrast to the probabilistic nature in Ethernet
LAN. Siandards that specify token-ring MAC are IEEE 802.5 and ISO 8803.5. This is good configuration for
heavily loaded networks.
The maximum size. of a frame is not limited by the 802.5 standard. However; in order that no one station
monopolizes tbe ring tbe maximwn token bolding time by any station is configured, which determines the
maximum .frame size. The minimum frame size is the size of the token. The ring shoukl be long enough to
accommodate the entire token; otherwise. theioken starts wrapping itself around and all the stations are in an idle
mode.
Because ofthe serial configuration, it is important that any failure ofOTE, or turning the DTE of!; should not halt
the operation of LAN. One scheme to prevent this failure is to design the Token·Ring NIC to create· a short
whenever there is a filllure or it is turned off. This is anailgous to serially connected Christmas tree lights. When
one bulb bums out, the bulb shorts the connection so that.t.be rest ofthe lights continue to be lit.
lf there i's a break in the link segment ofthe ring. the downsi'ream DTE sends a beacon to ihe others indicating a
failure. For eNample, ifthe link between DTE 4 and DTE I brel.ks, DTE I will send the beacon.
Ring fai lure can be permanently resolved. by a dual-ring configuration, where the second ring is redundant as
shown in Figure 2.12(n). Let us assume that tbe normal mode of operation is along the inner ring and the token is
going around in the counterclockwise direction. The outer ring is tbe redundant ring and acts as backup. Figure
2.1 2(b) shows the situation where DTE I has tailed. DTE 2 does not receive the signal from DTE I. OTE 2 will
send a beacon. Under this condition, OTE 2 and OTE 4 go into a lo<:>trback condition. DTE 4 receives the token on
the inner ring and forwards it on the outer ring to DTE 3. DTE 2 receives tbe token on the outer ring ruld fOrwards
it on the inner ring.

Figurt 2.U. Tok•n-Ring Dulii-Ring Configurotion>
(a) To~on·Rina O
uai·Rino t.lnn~emcnl
(b)TOkCIJI·Rinaore laolpilon
1
c) Tilllon·lllng Sogrn•nt lsola!Ol
Figure 2.12(c) shOW$ the situation where thesectbn ofthe ring between DTB 4 and DTE I is broken. DTE I sends
a beacon. DTB 4 and DTB I perrorm loop-backs and the continuity of the rings among all four stations is
csmblishc:d using both inner and outer rings.
2.2.9. FOOl
Fiber Distn'blned Data Interface (FDD!) LAN came into being to take advamage offiber-optic lnlDS
rrussion media
for LAN technology. It operates ala drua rotc of 100 Mbps and can include up to 500 DTBs in a single segment of
l00-kilometer length without repeaters. Separation between neighboring stations on the· cable can be up to 2
kilometers. A fiber-optic cable has the advantage of low-noise interference compared to copper cable, and hence
FDDI is ideally suited for a campus backbone network. As mcntioocd earlier, FDDI is oon.figured as a ring

oopology and bas a Ioken fur medium access control. Thus, il fullows 1EE.E 802.5 1oken-riog standard, but with
some significant di:flerences. It is adopted as an imemational sl8ndard by ISO 9314 aod American Not-ional
Standards Institute (ANSI) H3T9.5.
Figure 2.J3(a) shows tbe netWO[k configumtion of PDDI. It is uSually implemented as a. dual ring lilr high
reliability. One ring is termed as primary and llle second one ns secondary. Stations can be connected to lbe ring
either as a single attached station (SAS) to the primary ring, or as a dual attached station (DAS) to both rings. A
hierarchical topology can be created using cooccmrators, as shown in Figure 2.13(b). Concentrators permit tbe
attachment. of only SASs, but arc economical for wiring and expansion ofUIC POOl network.
Figuro.l .13. FOOl Coufogm·•llinns
SAS oo
ngieA!to<nooSIDiooo
DAS OUol AI~ SllltiQft -IJA$;. $1'1u;. ~'IIChi<J S1odoft
(P) FOOt CQ,figuntion w
•th Cooclenntot•
Although the topology of FDDl is similar to the Token Ring, the control token-passing algorithm is different l.o
the Token Ring, only one DTE utilizes the ring at any given time-
. whereas in PDDI there can be many frames
traversing the ring with communication between multiple pairs ofstations.
2.2. 10. Winllcss LAN
Wire.less LAN (WLAN) growth bas been very mpid.and is being deployed at homes, enterprises, and public places.
W"tF~ as il is popularly known, is an IEEE 802. 11 protocol LAN. 802. 11b and 802.llg operate at a 2.4-G& band
and 802.lla operates at a S-GHz band. rEEE 802.11 working groups bave been making amendments 10 802.11 10
address scalllbility, provisioning, performance, QoS. and security issues. We will address these along with
management issues in Cbapter 15 on Home Networking.
The prevalent configurali:>n for deployment ofWiFi Is a hicrarch1cal cortfiguration, also known as infrastructure
configuration. This is shown in Figure 2.14. WLAN may be visualized as a wireless interfuce to a wired neiwork.
Thus, in Figure 2.14, the Access Point (AP) converts the 1EE.E 802.3 Ethernet protocol on a wired medium 10 JEEE

802.11 WiFi protoool overa wireless medium. The wired interfuce is oonnooted 10 the external network via eilher a
router or a layer-2 swiJ·ch.
Flgut•t 2.t4. Wlt·tle" LAN: HitrorchiroiTopology
SUitions I, 2, nod 3 in Figure 2.14 can be either fixed or mobile or nny combination. A typical configuration in a
laptop oomputer is either a removable interface card or built in. Communication between wireless stations pas.ws
through t:he AP, which is aho the controller. the J'Bnge ofWiFi is limiled, and the area that is under the control of
an AP is caUed the bas.ic service area. The stations associated with a basic service area are usually coru1eeted by a
wired network to another basic service area.
A second WLAN topology is U1e ad hoc network oonf~gumtion. In this configumtion, wireless stations
communicate with each other oo a.peer-to-peer level with one ofU1e stations acting a.
s the controller, or a beacon as
it is called.
2.3. Network Node Components
A network node is a compo.oent al either end of a network link, such as a bub or a router. ll is also a device that
connects two networks, such as a bridge connecting two LANs. or a gateway connecting two autonomous
networks. Resources for network node are hubs, swi1ches, bridges, routers, and llllteways, or a combi.nation oftbe
above such as a. brouter (bridged router) and 8 swiJ·chcd hub. A DTE, such as a workstation, is not considered a
node. However, a workstation that has two network interface cards (NICs) oonnectinglo two LANs is a bridge and
is considered a node. Hubs are plaifol1115 housing one or more functio.ns. Switches now use solid-state devices.
Progress in solid-state tccltnology has contributed to the advancement of switching technology that includes an
ATM switch. Other network nodes are smartswitches with buflt-in intelligence ofvnrious degrees.
ln 11 simplistic view. 11 node can be looked at as aswitch, a bridge. a router, or a !lllteway. The basic concepts oftbe
four primary oodal components are shown in Figure 2.15. Figure 2.15(8) shows a switch, where inputs and outputs
are ofthe same format. For example. ifthe input format is an ATM formal, the output is abo an ATM foml81. The
switch can be used to switch both analog and digital data. When used in lhe analog mode, as in circuit switching, a
call is.set up fa-st (connectionthrough the switch is made) and then the analog signal is passed through. The switch
is insensitive to lhe information content. When il is used in tbe digital mode, it is used as a packetswitch. Each
input packet ls looked at and U1en switched to lhe appropriate output port based an content.
Figurr 2.15. Bosk Network 1~od• Compon•ots

ATM ~ATM
ATMS...tch
(a)SWIICII
l..oatll.AN
IFlltor I• lou , '"'''lR
OJUng
e xto«iol 1..1W
Etflemel
- - Elllemol
P•ck,_r.
- Brldgo p~~L5
(D)!OriUI)o:
Loco NotWO(~
l'lltUt ~ ~l"""u•vJ
El<IOmAI Notv.ori.
IPI'llci<•LI IPPetlutll
R<Mot
(e)louttt
IP
I· AY11:=~1
X26
Notwollc NOIOric
Poclots PAcl41$
G<ll!!wO)
A bridge can be viewed as an int.elligent packet switch al the data link layer and is shown in Figure 2.15(b).
Besides switching input packets to appropriate output ports, it can filter those packets as well. This is useful for
connecting two LANs. If traffic is pertirxmt to the LAN only. it is fLltered out. If it is to be delivered outside the
LAN where it was generated, then it Is switched through the bridge. In an intelligent bridge, knowledge can be
learned over time by t!Je bridge as to whicb packets should be delivered to which ports. Input aod out·put protocols,
in practioe, are usually tbe same. However, some bridges can also do protocol coovers.ion, as we will learn in
~tion2.3.2.
A router cannot only do all the functions ofa switch aod a bridge bw also route packets to the appropriate port in
the correct direction ofits destination. It functions at the network layer. Thus, in Figure 2.15(c), input packets from
a node in an IP network are sent out as IP packets to another node io tbe·some network or to sonJe other network.
Not aU networks use the same protocoLln this case, a gateway is used to oonvert one protocol fOrmat to another
protocol.format. lnFigure 2.15(d),a gateway is shown belween an lP network and anX.25 network.
2.3. L.l l ob.~
Flgure 2.16 shows the role of various components in a network. The router, the gateway, aod the half-router
ftmction at the nelwork layer and route packets. Bridges, local and remot.c, operate at the data link layer and
connect two LANs. Hubs are used to build LANs as we lean1ed in U1e previous section. We will review various
networkcomponents in this section.
filgu.rcl.L6. N<lWo.rktd Corupootnt5

As mentioned earlier, a bub is a platform with multiple ports. It is implemented to perlbrm some specific functions
or a combination of functions. For example, it could house a simple LAN or muhiple LAN segments. It can
perform 3 switching function and thus act as a switched LAN. When it switches between LANs, it performs 3
bridge function.ln this section, we willco~ider a hub used to implement LAN.
Hubs can be looked at as active LANs-DTEs con.oectcd with repeaters in a LAN configuration. Limitations of
length and number ofstations that nrc imposed on LANs are overcome by "homing" the wiring from the-DTEs to
the hub in the wiring closet and connecting tbem in the topology desired. The only limitation is the drop length
from the bub to dte smtion, such as the I 00-meter maxlmum length in Ethernet configuration. Any DTE can be
connected to any port of tbe bub. Stacking hubs and.daisy chaining them can increase the number of ports. DTE
configurations can be changed from a centrally located hub. Further, any DTE could easily be disconnected from
tJIC LAN for troubleshooting without impacting tJIC operation ofother stations.
Hubs can be stacked to increase the number of ports as shown in tbe stacked hub configuration in Figure 2.17.
Stackable hubs have a common backplane. Thus, it· is equivalent to increasing the number ofports in a bub. For
example, two I(>-po.rt hubs will behave as a 32-po.rt hub.
Figut-. 2. t7. Sltt<ktd Rub Configunulon
00
0
00
~
00 a
0 {!
0 0
00
00
2.3.2. Britlg<;,,
Bridges nre used to imercoru!CCt LANs. Three types of local bridges coOJ!Cctiog two LANs nre shown in Figure
2.18. Figure2.18(a) shows a simple bridge configuration connecting two Ethernet LANs. This configuration can be
looked at as two LANs connected by a repeater, e;xcept thai now traflic among DTEs in one LAN does not go over
to tbe other LAN. The only traffic that l$ exchanged between the two LANs via the brldge Is that which requires
intcr-LAN communication. Figure 2.18(b) shows several LANs connected by a multiport bridge. ln this case, the
bridge opens tbe packet, reads the MAC address, and switches the packet to the appropriate por1 that is tbe path to
the destination address. UsuaUy the bridge is a self-lenrning bridge. II looks at all. the packets that are received and
records the source address and the port· where it was received in a table. It uses tlus table to transmit packets. If a
destination address L~ not in the table, it does a flooding on all ports and discovers the correct port lo add to the
table. The table is periodically (less than a few minutes) purged of inactive addresses.
Figure l.L8. Lotat Bridge C<>nfigura!lons

A bridge switches data packet.~ between LANs and to accomplish this has a store>-and-forward eapability. Local
bridges are usually developed as a single protocol device, and have the primary femures ofswitching and filtering
oUl intra·LAN traffic. However, because of the stol'>and-furward capability in a bridge, additional features could
be incorporaled lo convert protocol. Figure 2.18(c) shows a multipart, multiprotocol bridge configumtion, wbere
Ethernet and token-ring LANs are interconnected. Pro1ocol conversion isdone 81 OSI layer 2.
1.3.3.1~emole :Bridge
Figure 2.18 shows bridges in local LAN configurations. This implies that LANs are brought to a centralized wiring
closet and are interconnected via 8 bridge. Figure 2.19 shows a remole bridge configuration, where two bridges at
remote locations are linked via a WAN. WAN arcltitecture mostly uses routers. However, using a remote bridge
and a leased dedicated telecommunication link, we can connect remote LANs.
Fll(ure 2.19. R•mol• Brldg•

I ·-- Remote Bridge
LANs can be· connected with bl"idges tbat are networ.ked using either the tree. topology or tb.e mesb topology.
Bridged networks operate at the data link layer. There are two nen,mk-routing algorithms used in bridged
networks-the spanning-tree algorithm for bl"idging Ethernet LANs and the S:Ource-routing algorH·hm for bridging
token-ring LANs.
2.3.4. TrluJsparent Bridge
Figure2.20 sbows four LANs octwor.ked using thrCe bridges in a tree topology. Each bridge has knowledge only of
its neighbor and is transparent to other bridges and LANs,.as described below, hence the name transparent bridge.
Figurt 1.20. Transl'•r•nl Bridl!< Ntcwork
The transparent bridge uses n routing algodt'11m, called a.spanning-tree algorithm. A spanning-uee algorithm builds
and stores a table ofporis associated with destination addresses. When a packet arrives, the bridge sends the packet
on another port to its de.stination. The bridge has no knowledge as to exactly where the destiMlion LAN is. It only
has knowledge ofthe neighboring node responsible fOr that destination address.
The transparent bridge learns routing information by a backward leuming process. That is, when a packetarrives ut
a port. it·notes the source address ofthe packet and associates that address with that port in its routing table. It then
forwards the packet to the port associated with tbat destination. lfthe destination address is not in its routing lllble,
it dOes a broadcast message to acquire the address.

As shown in Figure 2.20, the topology of the tmnspareot bridge network is the tree oopology, which means tbat
there are oo closed loops. One of the nodes acts as the header node, wb.icb is transparent bridge A in the figure.
Although there may pbysically be more tban one palh between two LANs, the spanning-tree algorithm eliminates
all but one link during ibe operruion. For eXllmple, iflrnnsparent bridge B had links to both Ethernet 3 and Ethernet
4, then tbat would form aclosed loop, Ethernet 3-transparent bridge B-Ethemet 2-transparent bridge C-Ethernet
3. The spanning-tree algorithm would prevent tmnspare.nt bridge B from se.nding or receiving packets on its link to
Ethernet3.
Let us track a message from a host attaehed io LAN 3 sending a message to LAN 4. It takes the pat.balitbe way up
the tree to the header bridge A, and then traverses down the other balfofthe t'ree to LAN 4. Thus, the headerbridge
oormally needs to b3ndJe more traffic than other nodes.
2.3.5. Sou rc~Rou tlog Bridge
A source-routing bridge is used to network token-ring LANs, as shown in Figure 2.21. In the source-routing
algoriH1m used in a bridged token-ring network, the source is awareoftbe entire path to the destinaJion. ln additloo
to the destination address, the source inserts the route that the packet should take in the packet. Thus, intennediatc
nodes make no decision as to the· path tbai the packet takes. TI1is is the reason that the token-ring bridge is called a
source-routing bridge. 'TI1c routing table can be stored either centrally on a server or in each source-routing bridge.
The route·is determined by broadcast packets flooding the entire network.
fllgu.-.2.21.Sourcr-R.outing Bridg• Ntlwoo·k.
Comparing a source-routing bridge with a transparent bridge, the latter is more robust and reliable, whereas the
fOrmer is faster. Thus, changes in tbe network due to addition or deletion of hosts, or due to filllures, are tracked
easier lhan in a source-routing bridge. In a source-routing bridge, the entire routing table has to be rediscovered,
which is a heavy resource"ConslUOptlon process.
Bridges are used for special-purpose nelvorks and bave several limitations. Due to dissimilarity in the rout.ing
algorithm, communication between media using different protocols bocomes dlffioul~ for example between
Ethernet Md Token Ring or FDDI. Besides, routing algorithms are difficult to create and to maintain. Routers,
which opernte 81 the network layer, ru:e designed fur routing and hence are better suited for this purpose..Routers
and gateways can route packets between different media and different networks (using different network protocols)
in a trnnsparent manner. We will now discuss the role ofrouters in networking.
2.3.6. Rout~rs

Routers and gateways fonn the backbone of networking. Although we bave shown alternative ways ofnetworking
with bddges in the previous se<:tioo-sometimes cheaper and a short cut to es18blish enterprise ne1working.-t.be
clean approach to establishingcomputer networks is with the use ofrouters.
A router, as the .nrune indicates, routes pockets through the n~1work. Each router in a computer network has some
knowledge ofpossible ·routes that a data packet could tnke to go &om the source 10 the destination. It has the high-
.
level data on what is the best overall route, as well as detailed local data on the best path for the next hop in t.he
link. This is built into a routing table tbat it periodically upda1es and stores in its database: Tile router employs a
broadcast scheme us'ing an Address Resol11 ion Protocol (ARP) to determine 1J1e port associaled with destination
addresses. The router may also rend 1he contents of a data packe1 arriving 81 a given po.rt 10 delermine its source
and destination address, as well as what type ofdata it is and when it was received. II then, using the routing table,
intelligently routes it to one or more output ports toward its destination address. The output goes to a single port if
it is a data packet going between a source and a destination; or the output is directed to multiple ports if it is a
broadcast or mullleast type ofpacket. Figure 2.22 soows a router oonfaguratioo with protocol architwturc. Notice
1hat network layers have the same protocols (NP). However, the data link layer protocol(DP) and physical layer
protocol (Phy), as wellas the physical media I and 2, could be different.
Flaurel.l2. Roul.r Confi~urotlon
Routers permit loops in their topology and thus are more universal lhan bridges. TI1is enables load balancing of
u:
affic as we.IJ as sel£-heallng ofthe network In case ofa IJnk or router fuilure. Routers have o;arlous algori1bms to
optimize load balancing of traffic and economize on cost. Several routing algorithms are in use, Of lhose, open
sborlesl path firsl (OSPP) is the most widely used. In Ibis algorithm, each router broadcasts routl)-request packets
on the links thai il is connected to. Other routers in the network acknowledge the reques1 and repeat the process.
Thus, u distributed routing database is built using an algorithm for the shonest path and is kept updated whenever
there is a.change in oe1work configuration.
Network managers can build rou1.ing tables for optimizing their network perfurma.nce with respect 1
0 several
parameters, such as least-(;OSI route, delay, 'bandwidth, elc. The perforrnaooe of a'bridged netwo.ck is belier than a
router network due to the additional network layer in I he latter case. Bence, a bridged network is used in some
special applications where speed is of importance. However, routers are spe<:ifically designed based on a network
layer. whose main purpose is networking. Thus, degradation in perfonnance.using routers over bridges is a small
price to pay for the far-reaching benefits we achieve.
2.3.7. GatewRys and J>rotocol Converters

Agateway connoots two autonomous networks. Eacl18utonomous network is se.lf-contained in allaspects-routing
algodt:hms, protoco~ domain name servers, and network administration procedures and policies. Wben such an
autonomous network communicates w~h another autonomous network, it traverses a gateway, as shown in Figure
2.23. Generally, the prot~! conversion is done at the network layer as shown in the figure.
Flgurt 2.23. Gateway Conflgunllon
NP - NP
- N
f f-
-
OP - tip or -
-,
Phy
' P~l'
T
Phy
I
Phyaloal M~lum
Since protocol conversion for a gateway is done at tb.e network layer. il could generally be combined wiLh a routing
funct·lon. Thus, a router with protoeol conversion could also be considered a gateway. Node N in Figure 1.16 that
connects an [p network wiib a proprietary subnetwork is nn example of this. Node N not only does prot~)
convers.ion, but also bas the routing table containing infonnation on both networks. 1n this scheme, Node N would
have an IP addte$S, but nodes NI, N2, and N3 may follow a proprietllry addressing scheme.
A protO<:Ol converter, shown in Figure 2.24, does prot~l conversion at the application layer. The protocol
converter used to be distinguished from a gateway, butthis is no longer tho case. Gateway is the generic term that
is currently in vogue. An exrunple of this would be a protocol converter that would be used between two email
systems. Let usconsider a compa.ny that uses X.400, an ITIJ-T messaging system. Wben a person wants to send nn
email on the lntemer to another person, who is using J.nter.ner standard Simple Mail Transfer Protocol (SMTP), a
protoool converter (gateway) converts X.400 protocol to SMTP.
Flgurt 2.24. Protocoi·Convtrlu Configuralion

AP AP
-_ AP AP
pp
~ ~ PI"
SP SP SP Sf>'
TP Tl' TP w
NP NP NP NP'
DP DP OP OP'
PHY PHY PHY' PUV"
I I _J_ j_
2.3.8. Multiprotocol Uoutcn; Jllld Tu nn~ling
An alternative to ihe use of gareway to communicate between autonomous networks is runneling using
multiprotocol router. Tunneling is generally used when the sourceand deslination stlllions are on similar networks,
but the data have to traverse intermediate network systems, which may be using different protocols. In this ease,
the da.ta frame does not go through a protocol conversion in the intermediate networks, but is encapsulated and
"tunneled'''through as pass-through traffic.
Figure2.25 shows communications between two Ethernet LANs on IP networks. One ofthem could be in the USA
and the other in India. However, the data have to go through Europe, which is on a X.25 packet-switched data
network. The mukiprotocol router at the near end encapsulates the IP packet in an X.25 frame and transmits it to
the far-end multiprotocol router. 1lte far-end multiprotocol router de-encapsulates the frame and routes it as an IP
packet again. The path throughEurope behaves very simllnrto a serial Link.
··igur< 2.2.'1. Tunntling Ul<lug MtdllJli'Uibt'OI Ruutcrs
Another application for tunneling is when 8 station with 8n £P address belonging to a LAN wants to communicate
with another LAN in a distant locatiort, but from a location other than the locaJ LAN. This would be the situation if
the station were a portable PC iUJd the person traveling needs to communicate from a foreign location. Let us
picture the scenario where Joe wants to communicate from Seattle in northwest United States to Sally at Los
Angeles on the West Coasrofthe United States. Joe's PC belongs to a network domain in New York, which is in
the East·Coast ofthe United States. The initial message is routed to the serve.r of the LAN that the station belongs
to, in Ihis case New York. 1lte server, recognizing Ibm the station is currently outside of its domain, klcates the

fOreign agen1 who handles the domain that Joe is currently at and infurmsJoe and the foreign agent Fromtben on,
thesender "tunnels" the packets directly to the user via the fOreign ageni.
2.3.9. 1-l~tiJ-Brid gc Configuration of ltouteJ"
There are situations where it is desired to have point-to-point communication. For example, when a residentiaJ
station communicates wilh an Internet Service Provider (lSP), Point-to-Point Protocol (PPP) could be used. ft
provides astandard method for mult.iprotocol datag:rams over point-to-point links. This method of conununication
has been eldended to PPP Multilink Protocol (MP). Using MP, datagrams could be split, sequenced, traru;mitted
over multiple parallel links, and recombined to construct the original message. This increases the bandwidth and
efficiency ofpoinl-to-poinl link communication.
With the expanding universe ofthe Internet, there are sma.ll corporations, as well as small lSPs, who would like to
establish diaJ.up seriaJ links. They require connections to the Internet from their local LAN only when they need
them. Typically, they do not need permanent dedicated links. A number ofproprietary Jfpp protocols nre·currently
in use. The roost common protocol is the Serial Link Internet Protocol (SLIP) fur UNIX.IIITF has standardized the
Internet DP to be used with point-to-point links. Half-bridge provides amethod toconnect tbe LAN via a bridge to
a router.
FigiJre 2.26 shows a half-bridge configuration. The router pon connecting to the bridge is configured as a serial
interface to the PPP half-br.
idge.. The imerface functions as a virtual node on the Ethernet subnetwork on the bridge.
lbe serial interface has no lP address associated with the Etbernet subnetwork. lbus, ifLbe Ethernet subnetwork
address is 155.55.123.1, the serial interface on the router could be assigned an lP address 155.55.123.5.
Figuro.l.l6. lilltf-Bridgr Configuration
Router
Sooal
n.tpU!
PPPIMP
•
Bridge
When a packet destined to the Ethernet arrives at the router, ~ is converted to Ethernet packets. encapsulated in
PPP frames, and sent on the Ethernet bridge link. In the reverse direction, Ethernet packets encapsulate-d in PPP
frames are extracted by tbe router. which converts tbem to lP packets, iUJd routes tbem on the lntenJet.
2.3.JO. Edge Routell!
Edge routers may in general be ecnsidered as those elemems that perform routing functions at the edge of a
network. ln other words, tbey are ingress and egress network elements of a typical WAN. Depending on tbe
application, the function.s of-this .router vary. For example, if it is an edge router to access network, it needs to
handle the "triple play" function of real nod non-realtime traffi.c.. If it is for an MPLS application, it serves the
function ofan MPLS edge router, which we will learn more about in Chapter 12.
2.3.11. Switches

lt would bave been logical for us to suut reviewing the switcllcomponent before we discussed bridges and routers
as network components. However, we have chosen to delay its discussion up to now for a good reason, as it
logically Oows into discussing WANs.
Switches opemte ru the physical layer of the OSI Reference Model that we discussed in Section 1.5.1. ln Section
2.3 we described a switch as a component rhat rtiakes a physical ·connection between input and output ports and
that the bits and.bytes coming in go out exactly tbe same way. Bridges and routers use the switchingfunction when
they route packets.
Mo51 switching technology is based on solid-state technology, and the speed. of switching is getting faster and
faster. Th.is enables networks to achieve a d(gital rate of gigabits per second. The performance of a network is
determined by how fast we can switch and mulliplex data using switches (and consequently in routers and bridges).
More importantly, end-to-end perlbrmance of the network depend~ on the~. lat.eocy, and lateocy variation in
tnlllSporting data from the source to the destination. Voice, video, and data. have different quality-of-service
requirements.. Based on these requirements, different types ofend-to-end circuits are established using switches.
The switching function accomplished in establishing circuits can be classified into circuit switclling and packet
switching depending on bow it is used. Telephone communication uses circuit switching. A physical path from
end-to-end is established prior to talk.ing, which is te.nned call setup. During the actual telephone conversation, the
path remains connected whether there is a conve-rsaiion actually happening or not. That is, the allocated bandwidth
for the pat.h is wasted during tbe idle time ofthe-conversation. Thus, when you are on the telephone and tbe other
party gives you a telephone number, you may say "Please wait wbi le I gel a paper and pencil to write.'' The
facilities remain idle during that" time and could have been used by others. A "nailed up circuit." where a
pe.nnrinent path is esuiblisbed !Or the session, is gcod !Or v(lice and video communications where latency and
latency variations are intolemble.
Computer traffic is bursty in nature and lends itselfmore to packet switching. It wot~d be a waste of bandwidth to
use cirouit ~-witching for computer data neil:lrks. Packet ~-witching utilizes the fucilities and, hence, the bandwidth
available more efficiently. Data are framed into packets and each packet Is switched independently. Data from
mu.ltiplesources are mnltiplexed and thus the total available bandwidth is shared.
Packe.t switching is used in routers. The maximum size ofthe packet is limited to make the router efficient. Packet
sizes can vary from source to source. as well as from the same source. The message from a single source is divided
into multiple packetl> and tmnsmitted over the network to rhe destination. Each packet may mke a different path
from the source to the destination and may arrive out of sequence. Thus, they have to be reordered at the
destination. This is termed datagram s..YVice and is shown in Figure 2,27(a). The message from DTE A bas been
split into three packets. Packets I and 3 take path A-B-0, and Packet 2 tmvels path A-C-8-D. At DTE Z, Packets
I and 3 arrive before Packet 2 and hence .have to'be reassembled in the correct order.
Figurc 1.27. Packcr Switch Configurations

(o) Oalagfam Confi!J.!ratlt>rl
~~ r.;;
JP~I3 j Pkt2jP~I1! ~~~
~t3jPktZjPI<lt j
(blVIrtual CircuitCot1f9urntiQn
It is desirable in many s~uations, such as in broadband service using ATM (covered in Sectim 2.6),lo have aU the
packets from agiven source to a given destination take the same path. This is analogous to circuitswitching in that
U1e path is fixed for the entire session. The concept ofsession is U1e same as in circuil switching. A virtual path-
virtual circuit is established during the call serup between the· Sl)urce and the destiniltion and a "virtual circuit
identification" (one, for each hop) is associated with the channel carrying the traffic. The path and circuit.
identifications are termed virtual as they resemble the operation in circuit switching, but different in thai the
connect·ion is not physical Figure 2.27(b) shows the virtual circuit path for the same message as In Figure 2.27(a)
from DTE A to DTE Z. Packets arrive in thecorrect order at DTE Z in this situation. Although the initial 0211 semp
is an overhead, subsequent data troosmission is fasler than in daLagram service. We will discuss more how the
virtual path- virtual circuit configuration is used in Asynchronous Transfer Mode (ATM) servicein Chapter .12.
Circuit and packet switching are applicable to a WAN, which we will review now.
2.4. Wide At'ca Networks
The main difference between a WAN and a LAN is the geographical separation between source.s and destinations.
Ifthe ·end stations are within a building or campus of buildings, it is still considered a LAN with a possible high-
speed backbone LAN, such as FOOl.
As we 5aw in Section 1.2. computer communication network rides on top oftelecommunication network, which is
a WAN. Although most telephone and video communications traversing the WAN are still circuit switched, datu
traflic generated by computer communicalioos is packet switched. We previously discussed two kinds of packet-
switched servioes-datagmm service and virtual circuit service.
Virtual circuit can be established on a session basis or on a permanent basis, The former is Cl!lled a switched virtual
circuit (SVC) and the lntter a pennanent virtual cirouil (PVC). Geographically distributed organizations would
lease PVCs from publ.ic scrvioe providers to handle large amounts oftraffic. Otherwise, SVC service Is used more
often. Public teleoommunicat!on service providers offer these services. However, private corporations, using their
own Svitches and le.ased lin.es from public service providers, set up large enterprise data networks.

We can partition WAN from a network management perspective·into 1wo sections and analyze the components and
services lhat oeed to be managed io each. The two end seclioos of WAN are the subsc.riber loop sections, where
iofom1ation flows from central offices of the service provider(s) lo customers' premises. The other section is
trnnsmission between switching offices.
Subscriber loop sections could be either passive, such ns dedicared pairs ofwires from the cenu:al office to the
customer premises, or active links such ns coaxial cable interspersed with amplifiers to boost t.he signal along the
way. lo either case, a digi1al subscriber line (DSL) terminates in a network interface unit (NIU) at the customer
premises. Examples of NTU are Channel Service Unil (CSU) for interfilcing DSL wHh ana Jog equipment at
customer premises, and Digillll Service Unit (DSU) tilr DSL iuterfuce with digilal equipment. The responsibilliy of
I he service provider is up to the NIU. Thus, componenls that need to be managed nre the NIUs and the active
components on the looptransmiss.ion line.
1'he trarunnission section consists of link t:ransmlssion fucilities and nodal components. These are between central
offices in lhe case ofa public sw.ilcbed network, Md between the routers ofservice providers in private networks.
We have looked at nodal components already. We wiU now consider transmission media and modes ofLANsand
WANs.
2.5. Tnmsmiss-ion Technology
2.5. 1. Intr·otluction
Transmission technology deals with transmission media iUJd transmission modes. We will look a1 transmission
medi.a firs1 and 1
.heo nt 1ransmissioo modes.
A transmission medium consists·of the link that carries data between two physical systems. There is a coupling
mechanism-a transceiver (denoting transmitter and receiver) that delivers 10 and receives daUI from the medimn.
Transmission media can be broadly classified in1o wired media and wireless media. Transportation of information
is aocomplished using physical transmission fitcilities, such as wires and optical fiber, or via wire.less media using
technology like radio frequency speclnnn, infrared, and light waves. ln lbe former case information i.s lraosmitted
from pointto poiol, whereas in the bitter case it.is generally done on a broadcast basis.
Both wired and wireless transmissions are used lOr local as well as WANs. The physical connection and the
electronics ofthe transceiver play an important part in LAN, as theydetermine how fast and accurately information
can be transmitted to and received from the various transmission media. We observed I hat the bandwidth of all
types ofEthernet LANs could be doubled by changing from s.implex to duplex configuration. fn fact, advMcemimt
of new 1echoologies depends on enhancements to existing ones. For example, ATM to the desktop has been
aborted because ofEthernet technology's increased ability to handle large bandwidth (in gigabils per second) to the
des~"top. We also saw in Section 2.3.1 how hub technology has increased ·throughput in handling a large number of
s1ations on a LAN.
Wireless LAN has so fur found only limited use for high-speed communication. However, wireless technology is
very e>.tens.ively used for laptops. mobile communication, satellite transmission. and television access in rural
areas.
2.5.2. Wired TnuJSmi.ssion
Wired transmission technology uses three media: coaxial cable, twisted-pair cable, and optical fiber. Tbe key
parameters to look for in choosing tbe lransmissi>n medium are tbe JOllowiJlg: loss of signa~ insensitivity to
environmental noise sources (such as cross talk and spurious radio frequency signals generated by appliances),
bandwidth handling capability, and transmiss.ion delay. The selection ofthe medium is also detennined by the type
ofswtions on l.he medium and I heir access control mechanism. We listed the limitations and capabilities ofvarious
LAN media for Ethernet LAN in Tables2.1 and 2.2.

There fire two types of coaxial cables-thick iUJd thin. The thick cable is 0.4 centimeters in diameter and is not
used anymore. The thin coaxial cable is 0.25 centimeters in diameter and is present in legacy systems or small
LANs, where il can be economically installed without a hub.
A twisted-pair cable consists of a. pair of wires that are twisted. The gauge of tbe wire and lhe type of twist
detennine the quality oftK:Bnsmission. They fire available as unshielded twisted pair (UTi>) and shielded twisted
pair (STP). Obvious.ly, the IaIter reduces the interference of radio frequency noise better than the former. Most
twisted-pair cabling that is used in LAN is Category 5 (cat-5) UTP. With cat-5 cable, lhe drop length for IEEE
802.3 LAN given in Table 2.1 can beextended from I00 to 150 meters at I00 Mbps. cat-6a cable e.xtends the data
mte to I0 Gbps.
The fiber-optic medium provides the·best quality transmission. Ofcourse, it is the most expensive. However. it is
economical when LANs need to be networked in a campus environment or building with multiple stories. As
shown in Tables 2.1 iUJd 2.2, point-tO-J?Oint drop for Ethernet coukl be as high as 2 kilometers, and in Gigabit
Ethernet, we can extend it up to 9 kilometers.
lt is worth noting lhe· importance of cabling in geographically placed network components. As we all know,
implemenlers always try to stretch the limits of specifications or economite in the inSiallutio.n process. For
example, the maximum dislance for a cat-3 cable would be stretched beyond the standard distance of 100 meters.
Altematively, instead ofcabling all workst;ltions using cat-S and optical fibers to a central location where patch
panels and hubs are collocated, hubs would be distributed tQ economize in cabling cost and only cat-3 cable is
used. However, there is a price to pay in operations and maintenance for this approach since hubs could not be
shared and any failure ofa remote hub would take much longer for service restoration.
Wired WAN media comprises b1mdles oftwisted pairs (such as in Tl and loop fucilities), coaxial cable for analog
transmission (for example, NI), and optical fiber (underwater sea cable).
2.5.3. Wireless TratL.~mission Media
Wireless medium is used in WLAN as well as inmobile and sateiiJte communicafuns.
Wlreless LAN uses input sOurces such as a hand-held portable· communication device or a computer with a
wireless anten1111. Wireless LAN technology focuses primarily on transmitting data from portable stations to a
wired LAN access point by rndio frequellCy, infrared, or opticaltransmiss~n. Since the range of transmission is
limiied for all these, they all function within a given region or cell.lftbe portable station is a moving target, then
lhe signal bas to be handed over from one cell to another cell.
Two tast-growing segments of wireless technology in the non-LAN environment arc of interest for data
communication. They are Personal Communication Services (PCS) and digital cellular services. Both ofthese are
based on cell-based technology. Data arc transmitted by wireless to local cell antennas from where they go to the
central locatk>n by wired network. PCS is all-digital technology. It operates at lower power (100 watts) and
antennas are more closely spaced (1/2 to I mile). The digital cellular technology, although analog, carries digitize.d
signal. It needs higher-power antennas, which areseparated filrther apart (severaLmiles).
Another area of wireless technology i.s broadband mukimedia services. Multimedia is transmitted using satellite
wireless tec.hnology from a centml oftice to the customer's premises. The return path is via telephone lines.
2.5.4. Trnnsmission Modes
The data transmission mode can be either digital or analog. Narrow-band LAN technology uses digital mode of
transmission. Broadband and WAN technologies employ bolh analog iUJd digiial modes of transmission. When
infurmation is transmitted in an analog transmission mode, it can be transmiUed in either baseband or on a carrier.

ln a pby~ical medium, digital transmission is a series of ones and zeros. A pby~ical medium is shared by multiple
sources to transport information to muk·iple deSiinmions. The distinction between various transmission
technologies is how information bctwoon pain> ofend users is coded to share the same medium. They should be
multiplexed and demulliplexed efficiently at the nodes to provide the leasl·and as constant a dellly as possible, as
well as high thrOughput.
Figure 2.28 shows three basic modes of transmission. They are Time Division Multiplexing (TDM) transmission.
packet transmissk>n. and cell transmission. Tl is the early implementation of TOM digilal transmissk>n in the
United Slates by the Bell Sysmm. Figure 2.28(a) shows TOM transmission ofT I carrier, wllich carries 24 voice
channel!;. 11teT I carrier has a bandwidth of 1.544 MHz. and is equally divided among 24 voice channels, each with
a bandwidth of64 kl:lz. Tite topoff.igure 2.28(a) shows.howthe 1.544 MHz. transmission "pipe" is divided into 24
small dedicated pipes among the 24 channels. The bonom half of the figure shows the multiplex.ing of the 24
channels as bit stream on the physical medium. 11tey are multiplexed cyclically from Channel I through Channel
24. llte maximum bandwidth available for eaeh channel is 64 kHz., but it is all available during a complete session.
A session Is deftned as the duration from establishment ofa connection to tearing it down between a pair ofusers.
Notice that all ch.annels bave equal bo.ndwidth and occupy the same slot in the transmission ch.annel. When the
receiver synchronizes to the imnsmitter, it· is able to d&-multiplex the channels, but both the transmitter and the
receiver know exactly which sbt each user's do.ta occupy. Since a physical connection is set up between thenvo
end stations prior lo data transmission. the time delay is constant; which is essential fbr voice and video
transmission. Nodes in Ute network using IDM are circuit switches. As mentioned in Seclion 2.3. Ll, the end-to·
end connection is physical. The video channe~ which requires more bandwidth (exact bandwidth depends on
compression ofdata and quality ofservioe required), occupies more channels.
Figu•·• 2..28, TOM, Plirktl, ond Ce11Tran.smlsshtnl1od..
Channel l
Channel24
5
If Uset1
nne
User 2 u....3 User4
TJme
(atT 1 TimeOivlllon "ulll;)lexlng (lOM) na~smosSJon
rtme
(b) Paclet Tmnsrnissian (IP)
II
limo
(C) Cell T!3nsmission (ATM)

Figure 2.28(b) shows the packet transmission mode. We notice that packets of differenr users are randomly
multiplexed. While each user' s data is traversing the medium, the full bandwidth oftbe medium Is available to it.
This is in con!nist to TOM, where only a fraci"ion ofihe medium bandwidth is available to any user. ft can also be
noticed that Lbe size ofall the user packets need not be the same. Another noticeable factor is Lhat since the circuil
connection is not pre-established, each packet contains addresses of ihe originator and the destination. We briefly
described a packet switch in Section 2.3.11. Obviously, packet switches are used with packet transmission. A
packe.t Svitch Ill each .node looks at the address ofihe destination and routes it using ihe appropriate path. Each
packet can take a different route depending on the availability oflinks and bandwidth based on different algorithms
used. The packets may arrive out ofsequence at the receiver, and rhe end-to-end transmission time for·each packet
is different. This transmission mode. is acceptable for data transmission, but not for voice and video. Data
transmission can tolerate bursty traffic.
The cell transmission mode, shown in Figure 2.28(c), combines the best of the above modes oftransmission. The
packets are nil of ihe same size and are small in size. Each packet .bas tbe full bandwidth of the medium and the
packets are statistically multiplexed. The packets all take the same path as in the circuit-switched TDM mode,
using the virtual path-virtual circuit concept. This mode of transmission is called the ATM and is one of the
fundamenta Iconcepts ofATM technology.
A recent development in WAN transport techoo.logies Is the evohJtion ofthe mulliprOLOcol l.abel switching (MPLS)
transmission mode using the MPLS protocol. It can be visualized as an enhancement over lP and ATM protocols
and backward compatible with either ofthem. A label, called the MPLS label, is inserted between Ioyer 2 and layer
3, as sbown in Figure 2.29. Thus, for an IP-based protoco~ ihe MPLS label is inserted between the IEEE 802.3
MAC header and the network layer IP header. ln the case ofihe ATM protoco~ MPLS shim wiihoutthe TTL field
replaces VPI and VCI fields. 1l1e MPLS transmission mode attempts to take advantage of the richness of lP
cbaracteristics and high performance ofATM
t'lgw·•l.19. MPLS Transmission Mod•
ATMCeti Header
tP H OI>Cior MAC H oi>Cior
GFC:4·811 Gonone Flow Hoador
VCI· VIrtual Clrtvl!ldont~lor
Cl.P· Congostlon Pnorfly
LllbeiHDOdOr
VPI. Vinunl Pmh ldenlifler
PT1: 3·Btl Payload Typo
HI:C·Heador Emlf Cooltol
Da1a
8
IPHoo.aor
An !P-based network is feature rich because ofits extensive implementntion and compatibility with Ethernet LAN.
lt routes packets inteUigently. However. it is slow in performance as it has to open each packet al layer 3 to
detenuine its next hop and its output port. Simultaneous transport of real-time and non-real-time Lraffic is difficult.
In contrast to IP, the ATM protocol is a high-performance cell-based protocol switching cells ai layer 2. It is
capable of handling real-time and non-real-time traffic simultaneously, and lhus is superior to the lP-based

network. However, its address incompatibility with the popular Ethemet LAN, along with difficult end-t~end
circuit provisioning, has limited its usageat the customer premises network and hence related applications.
In general, the packet header contains forwarding equivalence class (FEC) information to choose the next bop in a
router. In so far as the forwarding decision is concemed, all pockets belonging 1'0 a particular FEC ore assigned the
snme path l.eaving the node. The MPLS label is a short, fixed length, locally significant i.demifier, wl1ioh is used to
identify an FEC.
An MPLS protorol is being deployed in o convergent network lOrbroadband servicea handling real-time and non-
real-time traffic simul!aneQusly, thus achieving high quality of service transport. lt can be deployed in the legacy
network ofeither IP or ATM base.
Currently most information is tmnsmilted in digital mode. The legacy digital sySie.m is a T-based hierarohy (TJ ,
T3...) in North America and an &based hierarchy (E I, 62...) in the UK and Europe and uses packet or fmme
technology. The laler implemenmtion ofdigital mode of transmission in mllllY WANs is the Synchronous Optical
Network (SONE1), wblch is addressed in the next section. More recently, the WAN transmission mode has started
migrating to MPLS over JP.
We can visualize the above transmission modes as modes oftmnsmission at the basic or atomic level (although not
quite true). Eacb oftbe modes-TOM, ATMcell mode,IP packet mode, MPLS packet mode-is transmitted using
its own protoco.l. Thus, they can be cons.idered as modes based on protocol. However, modem trnll~mission
technology is capable of eanying a large amount of infurmatioo; i.e., large bandwidth of information; and this
should be taken advantage of in designing transmission systems. For instance, optical fiber can cany a terahertz
(THz) bandwidth signaL However, the quality of the signal transmission ,get~ worse when the signal bandwidth is
large. lt is due to network element limitations and propagation constrnints. Fortunately, we ca.n transmit a large
amotmt of infOrmation using the snme physical medium by employing the multiplexing princip.
le discussed in
TOM In Tl or El IDM, 24 or 32 channels can be multiplexed by logically partitioning the physical medium into
24 or 32 channels.
Using muk·iplexing approach, the p.hysical optical-fiber medium can be used to carry muk·iplexed tower bandwidth
signals using S)'nchronous Digital Hierarchy (SOH). This mode of transmission is known as SONET in North
America and SDH in Europe and Asia and is discussed more in Chapter 12. Nodes in the optical transmission
network are used to regenerate the signaI using regenerators. c.hange path by using optical or digital cross-connect
network elements, and drop and add lower-level digital signals at various inrermediate points along the path by
using Add-Drop Multiplexers (ADM). Figure 2.30 shows a SONET transmission mode. The tower-speed digital
signals DSliEI, DS IC, DS2, designated as Virtual Tributaries (VTs) ore mukiplexed into a VT Group. A SONET
frame comprises an overhead and synchronous payload called a synchronous )XIyload envelope (SPE). The speed
ofdigital daia is synchronized using a SONET basic signal rate of51.84 Mbps called synchronous transport signal
Ievel-l (S!S-1). Higher-rate signals STS-N are generated by interl.eaving bytes from lower-l.evel STS-ts. The
numbers in parentheses in Figure 2.3.0 indicate the number ofinput signals ihat need to be multiplexed.
Flgttr<lJO. SONET Trans-wi.ulou MOlle

OS1
1.544 Mbps
E1
6.312 Mboa
053 44 736Mbt»
ATM4.384
Af M 140.760 M>po
SfS.1 (N)
STS·:k(N/31
In Figure 2.30, STS·I comprises seven VT Group signals, or a DSJ signa~ or a 48-Mbps ATM signal. STS-3
SONET signal, also known as STM-1 in SOH, is m~e up of a 150-Mbps ATM or E4 signal. Trnnsmission rates
fur SONET/SDH signals are presented in Table 2.3.
'rabltl.3. SONET/SDH Transmission Rates
SONET Signal SOH Signal Bit Rate (Mbps)
STS-1 51.84
STS.3 STM·l 155.52
STS-12 STM-4 622.08
STS-24 1,244.16
STS-48 STM-16 2,488.32
STS-192 STM-64 9,953.28
ST£.768 STM-256 39.81432
The second method of the Increasing capacity of infotmation in an optical tniJlSmissloo medium Is to tnlce
advantage ofthe optical wavelength of transmis~ion. 'This is known !l'l wavelength diviSion multiplexing (WDM).
This is identical to freq~,~ency division multiplexing at (relatively) lower frequencies. Information can be
transmitted over multiple wavelengths using multiple transmission protocols, as sltown in Figure 2.31. rn order to
Illustrate tltis point, transmission modes sltown in Figure 2.28 are depleted In Figure 2.31 as components in the
WDM trnosmlssion, each submode traversi11g ai a different wavelength. Several hundreds of terurof-gigabits
signals can be transmitted over the long-haul WAN and soon-haul MANs.

Figurt Z.31. Multiwavrl•nglh Fib<n WDM
_ _ r==l_,___,-
Trmo
i UHf I Usor 2 Usor3
Channell
Channoi2
Usor$
2.6. lntegrnted Scn•ices: ISDN, Fr11 me Relay, nnd Broadbnncl
Integrated Services Digital Network (lSDN) can be divided inlo narrow band and broadband ISDN. Broadband
ISDN is called broadband services. ISDN was introduced by Bell Syslem to integrule voice and dala over
telephone loop facilities. The same principle is tL'ied in integrating voice, vid..--o, and data and providing them as
broadband multimedia service.
The early fOrm of inlegrated services network Is Basic ISDN. It Is a full-duplex digital interface between the
subi;(:riber and the central office. It consists of two basic channels. 56-kilobaud rate each. oombined with an 8-
kilobaud signaling cbanne~ referred to as 2B+D.
Basic ISDN was extended to Tl and El rates of 1.544 Mbps and 2.048 Mbps. Tills is called the Primary ISDN
interface. TheT I interfa.ce carries 24 channels and the·El interface 32 channels.
Witb the improved qualityofrra.nsmission media, the lSDN concept was extended from the subscriber interface to
a WAN. To achieve near real-time quality lbr voice, the performance ofWAN needs to be improved. Tllis was
done. by a frame relay service, which eliminates hop-to-hop flow and error oontrols in a traditional packet
switelling network, including X25. Flow and error controls are relel?illed to higher layers 81 the ends ofa link. The
frame relay access speed can go up to 2 Mbps.
However, on-line videos require a much larger bandwidth than could be achieved with frame relay. This has led to
early implementation of broadband ISDN, or, as mentioned in the beginning of this section, more. suceinotly,
broadband network. Broadband network and serviee havecontributed significantly to advances in three areas. 'They
are ATM (Asynchronous Transfer Mode), SONET (Synchronous Optical Network)ISDH (Synchronous Digital
Hierarchy), nnd broadband access technology. In Cbapler 12, we will discuss ATM, which is a cell-based
transmission mode, and SONET. which is a digital hierarchy adopted universally.

Broadband nccess technology, which addresses the link from the cenlral office to the customer's premises, is
implemented using one of th.ree technologies. Hybrid fiber coax (HFC) technology is a two-way interactive
mullimedia communication system using fiber and coaxial cable facilities and cable modems. The second
technology uses a DSL. There are several variations of implementing this. generically refe.rred to as xDSL. For
example; ADSL stands for asymmetric DSL. The tltird techno logy uses wireless transmission from the switching
office or head end to the custOmer's premises via satellite transmission.. We will learn in detail about broadband
service and 11ocess network technologies in Part. IV.
Figure 2.32 shows a broadband services network. The WAN is 11'. ATM, or MPLS. The WAN is linked to the
customer's premises using either optical links, OC-n (Optieai Carrier-n)ISTS (S)'nchronous Transport Signal), or
one of the three access technologies (HFC, xDSL, or wireless). The customer network consists of two classes,
residential customers and corporate customers with a campus-like network. Residemial customers are either
residential homes or small and medium enterprises (SMEs) that use broadband services, but do not maimain high-
speed access network to WAN. Service providers perrorm that function bringing radio, video, lnternet, and other
services to homes. Multiple services are multipleJred by multiple service operators (MSO) and are piped to the
customer's premises via common facilities. Service provide.rs ioter.
IBce with each other via gateways, which could
be either generalized routers or ATM switches.
Frgurt l.J2. BroJKIIJand Strvleu NriOt'k
Summary
OCnl
STS...
lJnk
ln this chapter we learned network ooncepts and teclmologies that would help us understand network management
in Parts U. ffi, and IV.
Network topologies can be clnssified as LAN and WAN topologies. There are three network topologies associaled
with wired LANs. They are bus, ring, and Slar. The most predominant commercially employed LANs are a hybrid
ofthestar tDpology with either the bus or the ring topology-the hub topology.
WAN is implemented u~ing eilber a mesh or a tree topology. Mesh topology is tbe common implementation iUJd is
·the topology ofthe lntemet. Tree topology is used wben a network is made up ofbridges.
We· discussed different types of common LAN implementntion--Ethernct. Fasl Ethernet. Gigab~ Ethernet,
switched hub, Token Ring. and FDDL Of tbese, IEEE 802.3 Ethernet LAN is the predominant type. This uses
CSMNCD MAC protocol. We addressed the introduction of full-duplex. types of Ethernet that double the
bandwidth. Ethernet can be implemented using various types of transmission media-;;oaxial cable, UTP, and
optical fiber. Fast Ethernet at I00 Mbps and Gigabit Ethernet at I Gbps speed can be implemented by employing

hub technologY,. Switched bub multipues the throughpm by simultaneous conversations between pairs ofnodes.
Virntal LANs, implemented using switched hub, enable logical association ofworkStations with VLANs.
Token Ring and FDDJ both use deterministic MAC and hence are mere efficienl over mndom access Ethernet.
IBEE 802.5 defines the speed ofthe Token Ring as eilher 4 Mbps or t6Mbps.
FDDr is based on IEEE 802.5 protocol and operales at t00 Mbps. lt is typically used for backbone LAN. Because
oftbe·need fur reliabiuty oftbe backbone, FDDI can be configured as a dual ring with DAS, in contrast to a single
ring with SAS.
Network nodes comprise hubs, bridges, routers, gateways, and switches. Hubs play a significant rote in forming
LANs as discussed above. Bridges function at the data tink layer and can be interconnected to fOrm a network. A
network consist.ing ofEihemet bridges is called a transparenl bridge nerwork and should meet the criterion of not
having any loop inthe network. (n contrast; a network made up of1'oken-Ring bridges, source routing bridges, can
have loops in the network. 1'his is because the source specifies the route in Ute-data packet and imermediille nodes
do not make any routing decisions.
Routers and gateways function at1he network layer. Routers and gateways form the backbone ofthe Internet. The
difference between a router and a. gateway is !hat the former just routes, whereas the latter does protocol
conversion. Ifprotocol conversion is done at the application layer, it is called a protocol converter.
Packet switching is the s~vitching of data packets. Packet switches, in geneml, perform datagram service. That
means eaeh packet oftJIC same message can take difierent routes and may arrive out ofsequenoe. Henoe, they have
to be reassembled at the receiver in Lhe correct S<:quence.
We can also configure packet switches to form a virtual circuit. In this case, all packets ofa session between the
source and the destination take the same path in the network and arrive in the same sequence that they were sent. A
virtual circuit can be established on a per-session basis, in which case, it is caled a switobcd vimaal circuit(SVC).
Tbe virtual circuit is set up and tom down eacb time.l.n conlrast, lOr a pennanent vlrhaal circuit (PVC), call setup is
done and left tbere permanently.
A WAN is established using either SVC or PVC. WAN is distinguished from LAN by large geographica.l
sepamlion between the souroe and the destination. Il is generally carried over the focitities of telecommunications
network.
ln discussing transmission technology, we covered wired and WLAN technologies. The role of coaxial cable,
twisted-pair cable. and optical fiber was reviewed. LAN transmits dotn in digital format. WAN and broadband
teChnology services r.ransmit information in both digital and analog modes. We addressed tbe various transmission
modes of TDM. oell, and packet technologies. Optical-tiber technology was presented, which can carry
information in the tens ofgigahertz bandwidth in tbe SONET/SDR and WDM transmission modes.
We coded our discussion of network technology by introducing ISDN and broadband multimedia se.
rvices. Tbey
handle voice. video, and data transmission in an integrated manner. The WAN in broadband services is ATM-
based SONET and the access to customer premises uses BFC, x.DSL, or wireless technology.
Exercises
1. The maximum allowed segment for Ethernet is 500 meters and the maximum number of segments that can be
oonneaed by repeaters Is Omlted to five. The minimum length of the frame that can be transmitted Is thesum of
the round-trip delay and the repeater delays. Assume that the speed of transmission on the cable is 200
meters/microsecond and that the total round-trip delay in traversin·g all the repeaters is 25 microseconds. Show

thatthe minimum frame size (numberof bits per frame) of an Ethernet frame Is 64 bytes.
Note: Tbe maximum frame size .is 1,518 bytes.
2. Gigabit Ethernet using CSMA/CO Is spedfied to have a too-meter drop c.able. Show that this corresponds to a
slot time of512 bytes to detect collision. Assume a repeater delay oftwo mlcroseconds.
3. The Engineering Department of12 persons In asmall corparatlon Is on a regular 10Base-T Ethernet IAN nub with
16 parts. The busy group started complaining bec.ause of the slow network performance. The network was
operating at 50% utililatlon, whereas 30% utlfilation is acceptable. If y<>u are· the Information Technology
Engineer ofthe corparation and have to resolve the problem technically,
a. Describe fuurchoices for resolving tbe problem, maintaining tbe LAN liS Etbemet LAN.
b. State the advantages and disadvantages ofeach approach.
4. In Exercise3, you are told by the IT Managerthat the problem Is to be resolved by using bridges and the existing
hub that could be configured for four subnets. A good rule of thumb Is that a LAN utilization of 4% yields good
and satisfactory performance. Assume that 12 workstations are functioning at a peer·IOiJeer level with
distribution oftraffic betweenany two.statlons being the same. What would your new configuration be?
5. Design an Ethernet LAN using a10/100 Mbps switched Ethernet hub to handlethe following specifications:
Number ofclients = 16 operating at I0 Mbps
Number ofserver =I
5()0(o ofthe tm.ffic is directed to the server
Draw the oonfigu.rtltion and indieale tbe transmission modes (half..duplexor duplex) on the ports.
6. Repeat Exercise 4 If the trafficto the seriler Increases to 80.
1. Two virtual IANs, 145.50.50.1 belonging to NM lab and 145.50.60.1 belonging to Networking lab, each have
three workstations. The former has workstations 140.50.50.11-13 and the latter 140.50.60.21-23. They are
connected to-a switched hub as shown In Figure 2.10 on ports 2 through 7. The NICs assocfated with parts are
made by cabletron and their MAC addresses -start with the vendor's global prefix 00.00-D (hexadecimal
notation) and end with 11, 12,13, 21, 22, and 23 (same as the fourth declmai positfonofthe IP address).
a. Create a conceptual matrix table, 115 shown below, which would be generated by the bub that
relates the IP address, the MAC address, and the port number.
IP Address MAC Address Port Number
b.
c. Tbe workstation 23 is moved from Networ:ldng lab to NM lab. Show the appropriate parameter

changes on the hub and lhe wo rksmtion.
8. In Exercise 7, Port 1 of the hub is connected to a router as shown in Figure 2.10. The IP and MAC addresses
assodated with the NIC on the hub Interfacing to the router are 145.50.50.1 and 00-()().100-00·()().01 and that
with the NIC on the router Interfacing with the switched hub of 130.30.40.1 and ()().()().10-00.()()..64. Extend the
matrix ofExercise 7(a) to Include Port 1, usin·g the same convention for the MAC address.
9. In Exercise 8, the router Is connected to the switched hub by a single physical cable. The router maintains two
sets of tables, one to determine the subne1S on 11S network and other to determine the host on the subnet as
shown below.The third deGimal ofthe IP address Is allocated to subnet designation.
Network Table
N etwor~ Subnet Host
145.50 50 0
0
145.50 60 0
Subnc1 Address Tables
Network Subnet Host Port
145.50 50 1
145.50 50 11
12 1
13 1
145.50 60 1 1
21 1
22 1
23 1
a. What is the mask used by the router to filter tbe subnet?
b. Show bow two packets ruriving in the router and addressed to 145.50.50.1 I and 145.50.60.2 1 are

dirc<:ted to the swil.chcd hub by using the above table.
10. Design a client-server network with two servers operating at 100Base-T Fast Ethernet speed and the clients
operatflg atregular lOBase-T Ethernet speed using a 10/100 Mbps NTC. The hub Is located In a wiring closet, but
the servers and clients are not Assume that a s~tlsfactory performanCI! Is achieved ~t40% utiHzatlon of the LAN.
11. Which of the following Is correct? The maximum throughput of an 8-port switched hub over an 8-port non-
switched hub is:
a. rhesame
b. 2 times
c. 4times
d. 8 times
U. It is assumed In Exerdse 11 that the LAN operates at maximum uUilzatlon. However, a regular LAN can degrade
In performance to an Intolerable level at 50% utilization. What Is the approximate (Ignore contention of more
than one station trying.to reach the.same destination at thesame time) percentage utilization Improvement ofa
12-portswlt.ched hub Ethernet LAN over a non-switched hub Ethernet LAN?
13. The minimum size of the frame In a token-ring LAN Is determined by the token size, which Is 3 bytes long and
should be contained In the ring under Idle condition. Assume a 16-Mbps LAN and the speed of transmission as
200 meters/microsecond.
a. What should be the minimum length ofthe ring in meters?
b. Each station normally adds a bit delay in processing the data. What is lbe addirional lengtl1
gained by adding one station at a time?
14. Repeat Exercise 13 for an FOOl rlng.Assumethespeed of transmission as300 meters/microsecond.
15. Explain the reason why the performance of an Ethernet LAN decreases with increase In the number of stations
on the LAN, whereas it lr~Creases (at least Initially) with the lnaease In the number of .statfO<lS In a token-rllg
LAN.
16. Draw network configuration and protocol layer Interface architecture for a multlprotocol bridge that
Interconnects an Ethernet LAN to a token-ring LAN.
17. A short message Is transmitted from a source at Switch A to a destination at Switch Z. The shortest path
traverses through 5 Intermediate switches. A switch causes an aver;ee delay of 5 mlll!seconds to process a
packet Assume all the packets of the message leave at approximately the same time (although they leave
sequentially),asthe duration of the me,ssage isshortcompared to the trans·misslon delay in the switches.
a. A ssume lbe message i.s senl as a datagram and the datagram packets take multiple palbs, each
packet traversing the shortest path going through 5 intermediate switches and. the longest path
going through 10 intermediate switches. Calculate the latency time if tbe packet reassembling
time is ignored at the destinalk>n.
b. What is latency ifa virtual circuit is established along the shortest path?

18. How many (a) El channels and (b) 051 (Tl) channels comprlse·anSTM·lSOH signal?

Part II: SNMP and Network Management
Part ll, comprising C hapters 3-9, is devoted to unders tanding the principles of network and system
management. Chapters 3- 7 discuss the management of a TCPIIP netwock using Simple Net~ork
Ma.nagement System (SNMi>) versions I, 2, !!lid 3. Remote monitoring. wh.ich is also part ofSNMP
management, is discussed in Chapter 8.
In Chapter 3, teclmical fOundations on standards, models, and language.. which are needed ro build
network management based on various standards, are introduced NetWk 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 of models and concepts of network
management is covered. Specif'.:atlons of most protocols 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 messages are presented. The
structure of manageme_
nt information (SMn is presented using ASN.I synt;lx. The definition of
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.ocoloperalions 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 ifthe course includes a project as part of its requirements. 1strongly
recommeod it-especially for an undergraduate course. A list of projec~ which have been used in
senior undergradunt.e and graduateclasses, is present.ed in Appendix B.
Chapter 6 addresses SNMPv2. SNMPv2 adds several sigoificanl enhancements to SNMPv'l,
inclnding efficient transferring of bulk data between systems. One 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
applications, which are part ofSNMPv3 specifications.
The SNMP mrinagemenl system is based on polling. Remote 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 ofthe operating system, wbicb would be of immense help in day-
tQ-day use and operations ofthe 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 engineering. The design ofthe network management system for varioll~ veltical netvork
applications, as wellas 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 wifespread 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
o lEBE 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 ofnetwork 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 ofthis 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 generaI 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 ofthe 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, threeareas ofnetwork need managing. They are network, systems, and services; inter-layer
protocols; and intra-layer protocols.In this book our focus wiUbe 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 this 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;magcmcnt 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 variousfunctions. lt is the most comprehensive set ofspecificat.ions and addtesses all seven
layers. OSI specifications 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 classes and inheritance rules.
Besides specifYing the management protocols, CMlP/CMIS also address network management applications. Some
ofthe 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
OSI/CMIP
SNMP/Internet
TMN
Salient Points
lntematioual standard (ISO'OSO
Management ofdatacommunications·network-LAN and WAN
Deals with all seven layers
Most complete
Object oriented
Well structured and layered
Consumes large resource in implementation
Industry standard (lETF)
Originally intended fur management of Intemet components, currently adopted filr
WAN and telecommunication systems
Easy to implement
7 Most widely implemented
lntemational stllndard (ITU-T)
Management oftelecommunications network
Based on OSf network management framework

TAble 3.1. Network MAnAgtmtnl Standllrds
Standard
IEEE
Emerging
Technologies
Salient Points
Addresses both netwotk and administrative aspects of management
eTOM industry standard tbr bus.
iness processes for implementing TMN using NGOSS
framework
IEEE standards adopted internationally
Addresses LAN 8J)d MAN management
Adopts OS! standlll'ds significantly
Deals with first two layers ofOSI RM
Wei>-B85Cd.Enterprise Management( WBEM)
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
telecommunications sySiems, It is easy to implement !!lid is the most widely implemented network management
system today. We will discuss SNMP management 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 Telecommunications
U nion-Telecommunications) stllndard and is based on OSI CMIP/CMIS specifications. lMN extends tbc concept
of management beyond managing nctwor.ks and network components. Its specifications address se.rv.icc 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
telecommunications industry. lt is an extension ofTMN. It is being developed by TeleManagement Forum (TM
Forum) as component of NGOSS (New Generation OSS) [Reil U
y and Creaner, 2005]. The main difference
between the TMN and eTOM approaches is that the fonncr has been developed starting from networks and
network equipment (bottom up), while eTOM is a top-down approach. The eTOM framework has been
incorporated within tbe TMN tramework as a set ofstandards (M.3050.lC).
Tbe IEEE sUUJdards for Local Area Network (LAN) and Metropolitan AreaNetwork (MAN) specifications shown
in Table 3.1are only conoemed with OS! layers I (physical) and 2 (data link). Those speciJications 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. The 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 offbe various physical media and protocols to the network layer. Tbe others in series arc tor specific
mediaand protocols. For el(Sffiple, 802.3 specif'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 usesan XML documeni-prowssing siandard method for proce-
ssing duta.
Common Object Rcqlest Broker Arcbitecmrc (CORBA)-based Network Management is an object-oriented client-
server model thut uses GORBA. The objects are defined usic
ng lnterfilce Description Language (IDL) and uses a
distributedmanaged objects nrchitecture.
With the Web-based management system, not only can object-oriented technology 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.Ilnagcment M.odcls
The OSI network model is an ISO standard and is most oomP'lete ofall U~e models.lt is structured and it addresses
a.ll aspects ofmanagement. 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 ofdifferent aspects ofnetwork management.
Agurt 3.1. OSI Ntn.1ork M•nagtmtnl Modtl
The organization model describes the components of11 network management system, their fuo~1.ions, and their
in.frastruot·ure. The organization model is defined inISO 10040 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 ofManagement 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 ofmanagement 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. Allbough a discussion of OSI
managemeDI is not pan ofthis book, it is brieflycovered in Appendix A furcompleteness ofr.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. 11tcsecond 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 netvorks 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 ofthe 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 oflayers I and 2 ofthe 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 inPart 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 ofthe 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 Imodel. We will now look at each ofthe models..
3.3. Organization Model
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 nothave an ageD! running in it. The manager communicates with the ageD! in the managed element.
Figure3.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 agentcan also selld a minimal w ofalallll 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 ofa network aDd the information is passed on to aremote site.
Flgun 3.3. Thnt-TirrN<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 oftheir respective components, and MoM manages the entire network.
fllgm-. 3.ol. Ntrwork Msnagemenr Organization Model with MoM

h'<>M ManagerofMaoagers
~·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 Figure3.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 ofsucb 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 ofManagtmtnt 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 ofdesignation {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 the 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 ofall
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 ofall books in all the county's librari~global manager MlB view.
Figure3.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 ofthe elements ofthe network. On the other hand, the MIS is a virtual database and contains the infOrmation
necessaryfor processes to exchange infonnation among themselves.
Agut-. 3.6. Nrlwork Configuration with 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 ofthe hub with a new IP acklre..'>S, and its MlB infoi"IIUIIion
is already in the manager's Mill. Its address and the number ofpons 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 ofa 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 M1B infurmmion
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 ofhub, the number ofports. 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 ofinfOrmation that can be stored in the MIB.
Network Elements: hubs, bridges, routers, transmission facilities, etc.
Software Processes: programs, algorithms, protocolfunctions, databases, etc.
Administrative Information: contact person, account. number, etc.
In fact, anytype ofinfOrmation 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 oflht 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 ofthe 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 ofthe 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 Object Perspective
Ah.hough a managed object·need not be a phys'ical object that can beseen, 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 single 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 example, resetting a counter value to tQ. 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 basicshapes, such as a circle, a .square, etc. We can define the basic objects lhat are required ofa group
(ofobjeds) as the swtus oftbe objed- wbetber ills mandatory oroptional 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 shape. There is a unique identification and name (objecl identifier and de:;c;rlptor)
associated with each ofthem, such as a ring, a donut, etc. There could be many instances ofring and donut; but we
areonly addressing the types ofobject, 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, definition, syntax, access, and status,
A pictorial view ofa circular object in the Internet is shown in Figure 3.9(a).
Figure 3.9. Omctt)lltat Vltws orMIUiaged Object

Access:
ACcess
P<IVII(lge
<f 8 ~~
Syntn; OoOnllon:
MOC!OtofOb)oct s..nRnlica-
Textual Oescrlpton
(a) lnlornol PG!11)0<llvu
NoUJia.Uone:
N<iiiiY~In
Atlrlbv.. Vobn
8
q
BehaviGr
Allllbu!es:
Clrel4, Otmon~n
Altribulas:
EMipse. D•me.•slon
(b)OSI Perspecllw
A managed object in the lntemet is defined by five parameters [RFC t t55). They are:
objectlde11tifwr and descriptor
syntax
access
status
dcfmition
unique 10 and name for !he object
tL'ied to modelI he object
access privilege to a managed object
implemenialion requiremenls
textual desertptlon ofthe semantics ofobject type

Amodification 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 ofthecircular 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 shape and values. Thus, the attribute ofthe object is ac 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 ofits change. Thus, the characteristics ofan OSI managed object are:
object class
attributes
operations
behavior
·notifications
managed object
attributesvisible nt its boundary
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 ofapplication services in OSI. Further, in OSI we can create and delete objects, while these
concepts do not exist in the Internet. Objects in early SNMP 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 ofa pack·et 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 ofpackets.
filgun 3.10. P111:ktl Couulor as Au Exalllt>tt oro M•oaj<d Objtct
(a) Internet Perspective
Characterlstks Example
Objecttype PktCounter

~yntax P>unter
f'ccess Read-only
~tatus Mandatory
Description P,unts numberof packets
(b) OSl Perspective
haract.erlstics Example
pbject dass Packet Counter
f'ttrlbutes ~h'lgle-valued
pperatlons ~et,set
Behavior Retrieves or resets values
Notifications ~erates notifications on newvalue
Too example ofthe same counter as a managed object in the OSJ model is given In Figure 3.1O(b). The counter is
defined as an object class, Packet Counter. Itcould be related 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, orjust retrieve data ifthe operation is get. llte new value 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, aswell 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 ofcommunication (application protocol), and the actual message (commands
and responses). Let us illustrate tbis by an C)(SmpleofAzita buying acar 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 example, 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 ofthe 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 alongwith CMIS. The
Internet uses SNMP for communication. The services are part ofoperations using requests, responses, and alarm
notificatioos.
Agut-e 3.I2.. f1Jm.agement Communicatinn Tro.nsftr J•roc·ocol.~
UOPrtP (lntilnl!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 ofthe .x.25 protocol could be used.lOr con.nectio~H>riented transporting Blld application
messages. TP4 over Conne<:tionless 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 ofthis section.
It Is important for communication among systems that a formalized set ofrule$ Is agreed upon on the structure and
meaning oftbe language ofcommunication, namely syntax and semantics ofthe 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
setofrules used to specifY data types and structures ror the storage of infOrmation. The 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 in 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 ofBac.lms-Nauer
form (BNF), which hoks like:
<name> : : = <definit 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><number>

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><SJE>
The IOrmat ofeach 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'lLSE
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 asTRUE and FALSE. are called keywords.
A group ofassignments makes up an ASN.I module. For example, a name consists offirst, 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 nameof 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 LVO
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 ofan 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.OTY!>< Dtlinltlon Enmpl< I

PersonnelRecord ::= SET
etc:.
{ Name,
tttfe GraplucStnng.
divislo~ CHOICE
marketing (OJ
{Sector.
Country}.
researth (1J
{pr<>:luel·based
baSIC
produdlon (21
{Product ·lmo,
Country )
SEQUENCE
CHOICE
(OJ NULL.
[1) NULL}.
SEQUENCE
Figul't3.14. ASN.I Data 'l'ypo Otfinitlon Epmpltl
Trade·MI!ssage ::=SEQUENCE
{Invoice -oo INTEGER
name GraphlcSI"ng,
detalls SEUUE.NCt: or-
ci'largo
aulhMtlc::~tor
SEQUENCE
INTEGER
INTEGER},
{pM·nO
quantity
REAL,
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 ofdata types, which are built using three construction mechanisms:
alteroativee:
list:
~epet,lHon :
CHOICE
SET and SEQUENCE
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 ofda111 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 ofthe foUowiog orders:
"Smi th"' , "Manager", ( " ~r th'", "Chil e"}
"Manager", '''Sm.lth", (''North", "Chile"}
("Nort 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. 1
4, 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 repelitive 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 ofa 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 anyofthe 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 ofa 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 ofa subtype
Range
Table 3.3 lists some of the frequently used ASN. l keywords. 111e reader is directed to the rereren<:e [Perkinsand
McGinnis, 1997] for a more complete list.
Table J.l.ASN.I Keywords
Keyword Brief Description
BEGIN Startof an ASN.l module
CHOICE list of alternatives
DEFINITIONS Definition of a data type or managed object
END End ofan ASN.l module
EXPORTS Data types that can be exported to other modules
IDENllFIER Asequence ofnon-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 listof repetitive data
STRING Used wit h OCTET for denotlne a stringofoctets
As we said earlier, wecan group assignments thatare related to each other; this group iscalled a module. A funnnl
definition ofa module is as follows:
<mo~>le name> DEFINITIONS :: • BEGIN
<name> :: ~ <definition>
<name> : :• <defini lion>
END
For example, a MID definition module will look like:
RFC1213-MIB DEFINITIONS : :• BEGIN
END
The terms DEFINITIONS, BEGIN, and END arc primitives and are called keywords 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 imponed 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 and 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
ofSMIand 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 ofthe 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
Thefour caregories ofdata type structure, shoVn 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 ofsimple 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

Cttapterl.'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 ofa 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 , Separator, Page~berl
wbere Separator is a data type with value"-." BookPageNumberis 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.
Bookl?ages : :• SBQUENCE Oli' ( Bool<J;>ageNumberl
We could defme the same in an altcmative manner ns
Bookl?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 ofthe chapter number,
separator, and page number is important to keep. However, we could have used the· SET construct to defme
BookPages as
Boo ~..l1age$ : := SET (ChapterNumbe.r, S.eparator, PageNuml)erl

and assigned values 1-2, 2-3, 1-1, ... in a·mndom order. The order ofthe.'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 ofno 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 witbin 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 ofencoding.
The fourth and last catego(y ofstructure is othertype, 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 CHOICE 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
(
I
product - based
basic
P:roduct Type : :=
ProductType,
VisibleString
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:
Research : : • CHOICE
r
produc t -basad ANY,
BASIC ANY
I
Thisdefinition using ANY specifies lhattbe "product-based" entity could be eilhern"NULL or a ProductType da.ta
type, and similarly "basic" could be either VisibleStringor 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 ofuniversal 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 ofa 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
Universal 1 BOOLEAN
Universal 2 INTEGER
Unlversal 3 BIT STRING
Unlve•sal4 OCTETSTRING
UniversalS NULL
Universal 6 OBJECT IDENTIFIER
Universal 7 Objectdescription
Universal S EXTERNAL
Universal 9 REAL
Unlversal lO ENUMERATED
llniversal ll ENCRYPTED
Universal 12- Reserved for future use
15
Set ofValues
TRUE or FALSE
0, Posltlve·and negative numbers
A string of binary digitsor nullset
A string of Octets or null set
Null, single-valued
Set ofvalues assodated wlth the object
Human readable text describing the object
The type is extemal to the standard
Real numbers, expressed inscientificnotation Mantissa x Base.,..,•.,,
Specified list of Integers
Encrypted Informatlon
Untversall6 SEQUENCE and SEQUENCE Ordered list of types
OF
Universal 17 SET and SETOF
Unlversal 18 NumerlcStrlng
Untversal19 PrlntableStrlng
Universal 20 TeletexString
Universal 21 VideoteXStrlng
Universal 22 JASStrlng
Universal 23 UTcnme
Unordered list oftypes
Digits o-9, space
Prlntable characters
Charactersetspecified by CCITT RecommendationT.61
Character setspecified by CCITT Recommendation T.lOOandT.lOl
International Alphabet5, which is equivalent to ASCII
nme format YYMMDDHHMM[SS](Iocal t ime differential from universal
standard time]

TAble 3.5. tlrtl•tffitl ClASS TogASsignn>eliiS
Tag 'TYPe Name
Universal 24 GeneraUzedTlme
Unlversal 25 GraphicStrlng
Unlversal 26 VislbleStrlng
Unlversal 27 GeneralString
Universal 28 CharacterStrlng
Universal 2!1- Reserved for future use
Set of Values
llme format YYYYMMDDHHMM[SS][Iocal time differential from universal
standard time)
Graphic character setspecified by ISO8824
CharactersetspeGlfled by ISO 646, equivalent to ASCII
General characterstrlng
Character set
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 arecl.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 : := [lPPLIC!'l'ION 1) SI!!OOEIICE
[APFLIClTION 21 ChapterNumber,
[ ~PPLIC~TION 3] PageNumber}
Wben defining large modules, the structure can become large. We ca.n introduce descriptive names and comments
on tbe structure for easy reading. Let usexpand the above example as follows:
Pageid : :• [APPLICATION 11 SEOCEIICE (
chapternumber [ ~PPLICATION 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, ICAT!ON 3j I MPUCIT I NTEGeR
Such an expression tOrces tbe encoding to follow the local tagassignment.

The context-specific type, a subset of an application, is limited to that application. Thus, in Example 1 of Figure
3.13, research bas a tag r1] associated with the application ofPersonneiRecord 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 takeon 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>lame12)
badValues t3)
rea<Klnly 14)
genErr(5)
)
A subtype data t ype is derived ~rom a parent type. For example, in th!l PageNumber examp,Le,
if "" 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 subtypeexpression (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 ofdata type lpNetMedlaEntry, wh.ich is a sequence of
fuur mnnnged objects with associated data types as shown below. Each ofthe fi:>ur objects slllrts with a lowercase
letter, and the assooiated data type with either a capital leiter or is a11capital letters.
I pNetMediaEntry :: •SEQUENCE I
J.pNetToMedia!flndex
i pNe t ToMedia Physlddress
i pNetToMedlaNetAddress
ipNetToMediaType
INTEGE:R
PhyaAddress
IpAddresa
INTEGER!

3.6.3. Ob,jcct 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.nl: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.
Thus. theobject identifier for private enterprise1BM 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 of 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 ofthe record, and part (c) shows the description ofthe 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
Frguo
•t 3.17. I SO 88241b•mt>lt Qf U~t ofASN.l
N3mo:
litto.
Jcton P Smlh
O~color
Empklyeo Number
DQW oi H116:
51
17 S&pluo
iiUt!l 1971
MaryTSmih
Nameof Spouao;
Numoor of Chlo:rron
Child lnfonn~tion
2
Name Ralph f Smith
Da1o of Blnh 11 No"ember 1957
Child lnform<>tion
Name Susan B Jones
Dale of Bin~ 17 July1959
(a) lnlormal desafptlon ofpersonnel record
PersooneiRecord ::=(APPLICATION OJ IMPliCIT SET{
NCJtne.
tiUe {OJViSibleSiting,
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 DaleJ
Name::= )APPliCATION 1)IMPLICIT SEQUENCE (
glvonName Vlsi~leSirlng.
lnillal VIGlbleString,
famllyName VlslbleSII'Ino)
EmployeeNumber :a (}PPLICAflON 2) IMPLICIT INTEGER
Date:• [APPLICATION3) IMPLICIT VlslbloSirlng - YYYYMMDO
(b) ASN.1 de.Crlpliool of Clio rocoo
d •lfo.lc1uro
l1ue
number
dateOfHire
nemaOfSI)CIOSe
Q>lldron
(givanNamo 'Jotvf, Initial T. famllyNana "Smll~"},
"0il1lCIOI'
'51'
"19710917"
{olvoanName 'Ma,y'. lnlllafl"'. fnmilyNAme "Smilfl').
{l (9lvonNomo 'Rolph'. lnlllol ' T", fomllyNomo 'SmPh1,
daloOfBilth ' 19H11 t11,
{ (giV'O~Namo •s u,..,n·. initial ·.a·.fom,lyName· Jones")
date01Bil1h "1959071T}ll
{c) ASN.1deS<lrlpUonof arocord Vlllue
PersonneJRecord is a structured dnta type, SETwith 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 ascomponent types. A third structured data type that we notice Is SEQUENCE fur thedam 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
stnrcture in thise.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 efficient 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 lLV. denoting Type, Length, and Value components ofthe 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
--------------....____
fag Humber
(Hih bits)
J
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 00000010.
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 ofthe.value field in the number ofoctets. The length is defined as a series ofoctets.
It is either one octet (short) or more than one octet (long). The most significant bit (811 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 ofthe 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 ofoctets. The simplest data type value to
encode is an OCTET STRING. An octet string of'OCIB'B (the string is designated with apostropheson both sides
and an 8 denoting hexadeoimal .notation) would look like
00001100 00011011
The complete TLV for the string ofoctets 'OCI B'H is made up from universal (00) Primitive (0) data type ofa tag
value of4 wiU1 a one-octet length field to indicate that there are twooctets ofvalue 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. ITthe 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 ofthe 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 I01 I. Refer to Perkins and
McGinnis [1997.) for the encoding ofother 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 ofamacro takes the fOrm shown in Figure 3. 19.
Flgur• J .t9.Slructun of an ASN.t Macro
<macroname> MAC~O . "
BEGIN
EN
O
TYPE NOTATION ::" qynwxOfNewType>
VALUE NOTATION ::= <syntDxOIN9wValuo>
<auxtflatyASstgnments>

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 isused 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 ReferPart 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 ofthe usage ofthe OBJECT-IDENTITY macro, let us considera 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 esclasses 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-IDENTITV M»<ro
<:s8113 OBJECT-IDENTITY
STATUS -~
DESCRIPTION Agradualo-levolnetwork mnnagomont C:OUJSO
offe111d INeryI<!II by Conege ofCompotllll) 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.
Panill ofthe"
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. Relevant 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 ofthe network and its status.
Fauk management involves detection and isolation of the problem causing the failure 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 rcsolved. 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 oftroubles from !he automatic generotion of"n trouble ticket by an NMS
to the resolution ofthe problem.
Performance management is concerned with the performance behavior ofthe network. The status ofthe 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 voiUJnein various segments ofthe 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 traffic 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
nelvoiks and nelvork resources from 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 ofthe 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. The traffic statistics, trouble ticket
adm.inistratkln data. and accounting management results are inputs to service and business management.
Summary
The foundations ofstandards, 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,
Telccommunications Network Management, and1EEE 802--and a 6.flh emerging one 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 ofthese bas been addressed In detail.
Some parts ofthe OS! model are appiicablei.o the other three management models.
The organization 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 primarycommunications 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
objects. 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 configuration, fault, performance,
security, and accounting. We have addressed each function briefly In thL~chapter.
Exercises
1. What are thestandards used for the various layers In an Ethernet-based networkthatis 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 Cabletron 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. is managed by general-purpose NMSsuch as HP OpenVIew Network Node
Manager. Draw a two-tier management network t hat performs conf~guratlon and fault management Explainthe
rationale for your configura~on.
3. Redraw the management network configuration of Exercise 2 as a three-tier configuration. What are the
requirements on thethree-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 responsibility 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
offunctions that you need to do to fulfill yourtask.
6. Write an ASN.l module that specifies DaysOfWeek as SEQUENCE type with each day ofthe week (dayl, day2, •.•)
as the type VisibleStrlng. Write the ASN.l description
a. for the structure and
b. for Ihe 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. Giventhe definition
olass : :• SET t

name
size
gr aduat e
I
Vi&ibleString
INTEGER
BOOLEAN
which ofthe followingset ofvalues 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 listand anordered list in ASN.l syntax
b. IdentifY the differences betweentbem
c. Differentiate between lis! constroction and repetitive constroctionusing 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 male and female.
U. A high school class consists offour boys and four girls. The names ofthe 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 following cases, wrlte an ASN.1 description for record values by selec:llng appropriate data
types. Start with data type Studentlnfo, I!sting Information on each student
a. A random Iist·ofthe students
b. An alphabetized list ofstudents
·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 ofboys 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
example ofeach ofthe fiVe functional applications thatyou would implement.
4. SNMPvl Network Management: Organjzation and Information
Models
I
Objectives
? ETF SNMP standard
o History

o RFC, SID, and FYI
Otgiini'Uition model
o 2- and 3-~r models
o Manager and agent
Management messages
Structure ofmanagement information, SMI
Objecr type and instance
Scalar and aggregate managed.objects
Management information base, MIB
NMS pbysicaIand 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 1
0 an SNMPNMS. Thus, ifa 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 ofthe 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 ofspecifications. 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 arecovered 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 onecould 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 primarilyorganization, 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 ofrelated 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. Managed Nl•hvork: Case Histories ami Examples
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 AnNMS is a powerful
tool, but it could also bring your network down, when not"managed'' properly.
As part ofmy experience in establishing a networkoperations 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 ofthe
visits was to an AT&T Network Control Center, which monitored the network status oftheir 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 funetinning 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
ofa 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 ofnetwork management capability.
ln aootber visit to a major international 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:elligcnce built in the system.
On a more intimate level, one of thedirectors ofln.furmation Techno logy was narrating his experienceofresolving
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 side 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 offthe discovery tool as it
was flooding tlte netwotk and degrading performance. Thus, powerfiJI network management tools also need to be
managed to avoid degradation ofnetwork performance. There are horror stories ofthe 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 ofadminlSiering. fur e-xample. configuring tbe network. This came-across as an extremely interesting
comment to me as1 was once involved in automating the inSinUation and maintenance ofa 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
ofnetwork 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 ofa larger
network managed by the NMS. As we roentiooed above, an NMS can auromarically diswver any componenl in the
network as long asthe component has a management agent. The management agent could be assimple as aTCPIIP
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 ofclemems in the network in Chapter 12. Let us
accept for now thnt it hos been accomplished somehow.
flgurt 4.1.Man•ged LAN Ntlwork
0
~
NMS
192.168.252.110
---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 ofa 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 ofthe 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 ofan
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 havebeen discovered sod mapped by theNMS, 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 lnfonuation ,cquir•d by Rn NMS

Tille: Sys~em lnlorrnalion • 172 16.462
N.lmcCJ< 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
NameorIPAddress: 172.16.48.3
S)<llornN"""'
5)stem Oescrlpllon
S)Stt!fllCmmd
S)S._ l<>c:>lion
S)~tt!fll ObjeCt 10
S)$11!fn Up Time
• 3ComUnkilullde! FMS. SWversion!3.12
ISO CK!I docUntemelpriVate.e:ntOfl)tfsesA3.tJI.S
. (3141UM182)l04 days. 4:!10:,UI2
(b)SY'lllm lnlonooiJOI on t72.16.46.3Hub
r,:;;;:-System lniOflllllllon r011ter1.gotedudu
IN~ or IPAdaoss 172 162521
System ConliiCt
System LocatJOn
Sy;tem ObieciiO
SystemUp TirTle
r0Aer1-Qatach edu
Cls:o ltllluwtwork ~ri~Jnv SY"'f" Son"ato;
lOS (tm) 7000 Soliware (C7000 .JS~). Version
• 11.2(6),RELEASE SOF1VIARE (gt1)
; Copyrlglt (c) 10a6 1007 toy CieooSyd.omo, lnc
Complied Tuo CG ·IAAy•!l7 19.11 by la.lOfl9
•S04f9.dod.llltometpnval!l.!lfltfl1PIIsescssco.clscoPIOducts
CtsC07000
. {31513795)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 oftiJe·
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,380,437
hundredths.ofseconds, 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) showssimilar parameters fur the second hub, I72..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 ofeach 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 Figure 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 theNMS 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) showsthe title and name or IP address
ns routerl.gruch.edu. By using a network lookup command, the I.P address ofrouter 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 ortPAddross 172.1o.46.3
(b)Addresses oh 172.16.46 3 Hub Ports
Tllkr Syott!m ln!Oflllati¢n· rotJinrl gated> t!<lu
Name or IPAddress 172.102$2 I
maex ll'ltertace IPAO<ll'e$$ Networ< M&i1<
23 LEC I 0 192 16831 255 25b255.0
25 LEC39 192.168 252 1 25525$.255.0
13 Elll&me2,0 tn 16.46 1 255 255.265.0
10 Ethem&t213 172 10.<111.1 255.UU65.0
17 Ellleme1.214 172 18.521 25525U55.0
9 Elhame11Q 172.16.551 255,255.255.0
2 Elhomol C/1 tn i6.56 1 25S 255 255.0
15 Elhomo212 172 16.67 1 266.26l.255.0
8 Elllemetl/1 172 16.5&1 255.25b 255.0
14 Elheme1211 172 18.60.1 255,255 255.0
NC!!WOO< AOcteSS
92 !68 30
192.168.:152 0
tn.16460
172. 1
0 49.0
172 15.52.0
172.1655.0
17V6560
112 u; 57.0
172.!8.5&0
172 16.60.0
(C).Addresses on Rolter Ports (Partial Ust)
LIII~AOCII*SS
DxOOOOOC3920Q.I
OltOoilOOC3920SI
OxOOOOOC392CAC
Ox()()l)()OC3920AF
OxOOOOOC3920BO
OotOollOOC392QA6
OxOOOOOC3921)g()
OxOOOOOC3020AE
OxOOOOOC392QA5
DxOOOOOC3920AD
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.ch 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 ofthe matrix. The IP address in
the third column 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 ofFigure 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. History ofSNMJ' Management
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 ofthe TCPIIP suite now.
We learned to use this in the exercises in Cbapter I. PING is avery simple tool that is used to investigate the health
of11 node and tbe robustness ofcommWJication with it fiom the source node. lt Slllrted as an early form ofnetwork-
monitoring tool.
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 using 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-baled network. An Internet Advisory Board (lAB) was formed to
administer Internet activities, which arecovered in the nel1 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 ofSNMP. 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. Internet 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 teohnology.
Wilh the growth ofthe Internet, the1ETF organization bas grown to be the protocol en~ineering. development, and
standnrdi7.ation arm ofthe LAB.

The Internet Networld.nfonnatlon Center (InterN!C) is an organization tbatmaintalns several archives tbat comain
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 assignmentsas requested and to maintain a registryofcurrently 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. Ifan FYI or SID is revised, its.RFC number will change,
but its FYI or SID number will remain constan! 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 otherInternet documents are:
£tp :/ /ftp .int ernic . net /rfc
ftp : //nic .mil/ rfc
ft:p .nic •.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-levcI 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.
SMIv2 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.ltP 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 ofthe information model. We present a detailed definition ofa
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<:hanism. 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. Organization 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
M
Anllgor
I
SNMPAgent
Networ!l
Etomonl
Noiwo!kAgorrt
N
atWUik
£1e11'1eht
(b) MuttoplaManagers-One A:lant Model
We can question the need ofmultiple 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 knowledgeoftl~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 networkof 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 ofmilure-even to the level ofidentification ofa 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 managementsystem 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; telecommunications
management network, managing wireless networks, etc. lo aU tbese cases, tbey are part ofan 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 built 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 ofa 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 tO 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 SN
M
P
I· ·ISNMP SNMP
Man..ger ~ Agent Manager
t t
SNMPAgent SNMPAgeol
Network NeiMtrk
Element Element
4.6. System 0 •ervicw
Now that we have learned the re.lafunsbip between tbe network (management) agentand 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 network 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· SNMP A,gent
~
.&mfPt.lo""!l"'
J
,llopffcat.on
..
l
§
~
i
if
~
l t
...
a: .. 1-
~ l ~
a:
iS ~
SNMP~nt
ApplcabM
i
I = :
I
! c
....
! §
!
;i
;
i
?;
~
~
- -
SNMP SttMP
UOP LOP
---
IP IP
Dl.C Cl.C
PHY PHY
As we stated in Chapter I, the.!ru.ernet 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 logically remote users." TvO companion RFCs are RFC 1155,
which de.s(:ribes the structure 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 of
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 object. 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
ofthe 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 ofthe requested objectwith 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, ifa network object has a threshold value set for a parameter, such as the •=~mum number ofpackets 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 ofdat.~-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
NMS and responses to it from network components. Thus, a newly added networkcomponent 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 ofthe 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. lnformntiOn Mollet
The information model deals wiih SMJ and MIB, which are discussed in the foUowingsubsections.
-1.7. 1. Introduction
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 ofmanagement information.
We discussed the types ofmessages 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'RfC 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. Structure of Mam•gement lnfom.:llion
A managed object can be considered to be composed ofan 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>• and ln$1an<r
I Object
I
Object
I ObJ
ect
I
l)pe tnsoancol
I
Name:
Syntax: Enoocl111!l:
08JECT
tOENTIRE!
ASN. l BER
figure 4.11 sbows the situation where there are muJtjp(e instance;; ofan 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 ofthe object.
Figure4.tt. ~1anogrd Obj•<t: Typ• with llutliplt lnstanres
Name:
OBJECT
IO£NTIFIER
Sy·nux:
ASNl

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 OBJECTJOENTIFIER 1.3.6.1. Ofcourse, there can only be one
instance ofitt Thus, a managed object is only ·a means ofidentifying 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~ ofan object type is defined
using theabstract 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 ofthese 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 ahybrid mode, for example,
int ernet OBJ~Cl' IDENTmER : : • (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 ofthe unique nameand theunique node number on the managementtree.
Flgurt 4.t 2. OUT<rt nC Furrnais of Otclaration ofOBJECT IDENTIFJER
lntomotOBJECTIDENTIFIER ·" ( lso(1) orp(3) d«<C6) 1~tomot( 1 ) )
lntomotOBJECT IDENTIF'ER ~: ( 13 6 1)
InternetOBJECTIDEIITt<IER ;.• ( o>o "'11 dod inl<l•'hOI)
InternetOBJECTIDENTIAER :=< ( ISO 019 00<1(6) lntemot(1))
InternetOBJECTIDENTIFIER :;: ( 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
mqmt
experiment~l
private
OBJECT IDENTIFIER : :• (internet 1)
OBJECT IDENTI FIER : :- {internet 2 I
OBJECT IDE:I'lTib'IER : := {in tamet 31
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 "internet" node nre shown in Figure 4.13. We will discuss objects in the Mffi tree in
the next section.
Figure ~.t3. Subnodt.! undtr tnttrnd 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 private(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
ente:-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). Nodes under any ofthese nodes are entirely (eft to
l be discretion ofthe vendors.
l'igu•·• 4.14. PrlvPieSublr<< for Conm~tt•tial Vendor
~

Syntax. ASN.I syntax tl111t w~ introduced in Section 3.7 is used to define the structure of object types, Nor all
constructs ofASN.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.nder structure.
f!lgur•·I.IS. SNMPASN.I Oata'l'yJI<
I
=1 ....
[ _,.,.,
_...
__.
Thethree 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.
Table 4.1. SN~fP-bostdASN.I OalllTyflt Siructurt
Strutture Dat~Type· Comments
Primitive types INTEGER Subtype INTEGER (nl..nN)
Special case: Enumerated INTEGER type
OCTETSTRING 8-blt bytes blnaryand teXUal data
Subtypes can be specified by either range orflxed
OBJECT IDENTIFIER 0bject position In MIB
NUll Placeholder
Definedtypes NetworkAddress Notused
IpAddress Dotted declmaiiPaddress
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 ofsecond units
Opaque Application-wide arbitrary ASN.lsyntax, double-wrapped OCTET STRING
Constructor types SEQUENCE SEQUENCE OF listmakerTable maker
Primitive or simple types are atomic in nature and are: INTEGER, OCTET STRING, OBJECT IDENTIFIER, and
NULL. 11teseare 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 iscalled 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 nameassociated W
"
ith it:
error- status LNT~GER
noError{O)
tooBig{l )
genErr {S)

aut bor izationError(16)
Any non-zero value indicates tbe type oferror 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 oflength 4 in network byt.e order.
CC!unter 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 ofdat;ltypes that continl!liUy increase, such as input pncke.ts received on an iorerface or otdputpacket 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 ofinterfaces 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 ofa second the number ofunit.~ 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 ofthis.
Opaque is an appUcation-wide data type that suppons the capability to pass arbitrary ASN. I synta"' It is used io
create moredata types based on previously defined data 1ypes. This is extensivelyused 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
SNMPvJ, 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 ofEXTERNAL lype. encoding
other than ASN. I may be used in opaquelyencoded 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 managementsyntaX. SEQUENCE is used to build a list and SEQUENCE OF is used to build a wble. We can
conceptualize ·the listas values in a row ofa table.
The syntax for list is
SEQIJENCE t <t ypel>, <t ype2>, ,,, , <t ypeN>
wbe.re each type is one ofASN. I primitive types.
The syntax.fortabie ls
SEQUENCE Oli' <entry>
where <entry> is a listconstructor.
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 frorn a list ofobjects. The U
st ofo~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
ObjectSyrrta"' 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 OBJECTIDElmAER ObjoetSyntax
I lpMEnlAddr (lpAddiElllry I} lpN:Idru s
2 lpAdEn~flndOJC [lpAddrEntry 2) INTEGER
3 IPAl!EntNetl.lask (IJ)AcCUEnlry 3} lpAddross
" lpJdEnl!lca~IAddr [lpAc!drEntry 4} INTEGER
5 IPAQEniReeJmMuS!te fopAddrEntry S} INTEGER
8 ~II)' flpACdrT~ 1) SEQUENCE
Ust lpAdd!Enlly .•
SEQUENCE
lpAd£lliA<Ich
lpA!IEn~flndBx
lpMEniNet~ta•k
lpA:ll!nII!Qo)IA<Jdr
lp.Adl:niReasmM;IXSWI
)
I~
INTEGER
lpAddtess
INTeGeR
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 upofinstanoes ofipAdd.-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 DaloTy1><> 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 IDEN1lfliER is encoded with each subidentifier value encoded as an octet and concatenated in the same
order as in the object identifier. Since a subidentifier 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
consistsofthreeoctets(43, 6, and l). Thus, the encoded format is:
00000 llO 00000011 00 l01011 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
" lamlged 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 ofManaged 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.
SyniJ!x·
Oofi~itoon;
Accass:
Stall.is:
(system 11
Olsp1ay5lnno (SIZE {0 255))
·Alcx~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 thisconlllln only
p<nl<oblo ASCII chonte:lora..•
read-only
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 ofa 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 ofa.managed object. Thus, it describes whaJ rype ofobject 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 ofeaob instance is left to the specific protO<:ol that is used. and is not part of
the specifiCations ofeither SMI or MIB. Thus, instl!llces ofthe 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 ofthe object type. Thesyntax ofsysDescr 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 ofread-<~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 object. once defined, can only be
made obsolete and not removed or deleted. Ifit is current, the implementation ofit isspecified 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 ofsimpleobject 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. Titis 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-TYPEMacro 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
DESCRIPTION
::= isysUlm , )
'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 oporotlngsyslem. onu notwor~mg scnware II IS
mandalory that lhls r.omaln only prlnlable ASCII cneraclolll.•
(b) AScalaror Single fnstence Maao: sysDescr[RFC 1213)
The body of the macro module consisiS ofthree pans: lype notation, v.alue notation, and supponing productions.
lYPB NOTATION defines tbe data types in the modtdeand VALUE NOTATION defmesthe name ofthe 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 ofany oftbe 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 ofthe system group in the MIB, as we sball See in Lbe next .sectioo.lts
OBJECT IDENTIFlCATI.O.N is {system I}. DESCRIPTION defines the textual description of the object
Aggregate Object. An aggregate object is agroup ofrelated objects. Figure 4.19 shows an example ofan 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 1
0 implement it.
Figure ~-19. Sptdfltallons for on Aggrtgott ~hnogcd Objet!: lt)AddrTobl<

( OfJJECr 1
lfMEftiAdct
s~
I bAdci£nlrl 11
-.-
Dotlft!Uoft .TheIP acclres3 10""""'thiS1<1tlyI 11lormaton
-
Slat.•
-
sw...
OCr1.an;$•
rC3d..,..'Y
mant.alorl
(~/2)
NTESER
·The-....,...,_.......,.IO<nlfiN"'"
n:ertoce~-,. wrt•~ The
ncarfoce~ t>t•-......ollwniEx ..
,.....,.,__.......... by ... _ _ol
-·
"1!8d-<>nly
........-.,
"'""'"' 1r~enuy31
t>ldC<OU
-n.,swoofT1M1< .UOO>Iod.,dh""IF'-ol
lbt~ry ""'""""'"'lho""'•~i&oniP»I,...,.;n,
.t4 IN NM-~ 1141 ltiiO I ...... IIW hCI&I bU.t ..1100 "
--oriy
--...y
~~ ,....,.,.'Enlry4)
ll,._ rtm:GER
o.r.r- ·n..-oiii'O--~~~tiC ..1eiP
---•)tM'dlnQesouur-on~~~e
lk>Qocllll"""'*--OIIIWIIII ..IP-al
hl.-.ry For~ -nlelriOinll~
.. _1>'_ _ .. _,.. ___ ..
I Tha•'ll... .,...lobolh 11-. 011t.ocai...O""""""
----ll'f!lllltnlrlyootr.-
~llnttl....
- 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
rpiC-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 ofthe 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
subnet mask, broadcast address inlilrmation, and the size ofthe 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 ofthe use oftbe above.specifications in a table, let liS consider the ful.lowing entry in an lP add.ress
table:
OBJECT 1
OBJECT 2
OBJECT 3
OBJECT 4
09JECT 5
(ipMEntAddr J • ( int e r net "123. 45 . 2 . 1" . )
(ipAd~ntiflndexJ = ( "1" J
(ipJd.EntNett~as k )- (internet "255 .2.55 .255. 0 "
tipAdEntBcas t:AddrJ - ( •o• 1
(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 ofthe 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 comments 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 additionalclause, 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 columnarobjects.
fllgu.-. 4.20. Aggngatt Msnngtd Objtcl Macro: it>AddrTsblt IR•'C 115Sl

- lhEIP-Iable
- Tht IPodole5S ""*"""""""'1h6ent<y'$ f' od.l""""'19 onlonrotJon
'I>Add<Tiilll<! 01!./ECT-lYPE
SYNW< SEOliENCEOf li>lddr&try
.ACCESS 1101---
STATUS onandal""f
llE~tPllON
1"he ableorad:lres$irlg llllor!r,al#lreeanlto d1G..~. ll' aotte5SK-
=-I'P20J
ioM<lre•ttv OBJB;f-1YPI:
SYNW<~r1
ACCJiSSooO--
STATUS '""rmtc<y
IIESCRJP110N
'Theaddre5S01QintannatJ:IO 10'oneoith>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 OBJECTlYPii
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- •otuoo1 ftAidl1' •
•(lfAd<llfnll) 21
II:AdEniNtl- OIIJECT-TYPE
SVNTIVC~
IICC€SS -~
STATUSro~
Ol'SCRIPlJON
"1114ts.bnet~ilssCcle1edw.Ot11>eIPllddreaollh'$en~~y Tl'evollleoCillemi)$Jtia""
tP: ~wrM- alCDe 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"eiPaddressofflcsetrtry Forexsmpl!!,..,.nlhelnlatnel
01llnlard •1-oneo ~ add..,.. is'"""' lhE v<ll<., w1 be 1 lha valle """""' 10 l:ofl>
lheSJbne!Jand- t><oad:asaadd:e$ses used by11>eentliVon fills (ICgieaD InterlaCe·
~ I Or.Add!Etnry <4 I
fJ;Ac!EniRaosmNaxSlreOBJECr.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 thisway 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 ofobject 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,eC1NameFROM RFC1155-SMI
O•!IOiaySUing FROM RFC1158-MIB
OBJECT·TYPE MACRO ·•
BEGIN
TYPE N011TIO"' ..=
- 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! (VALUEObjedName)
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) Iempty
RelerPan :"'"REFERENCE' vare (raft>re<!CeOisj>:ayS.mg)l ~
lndexPM :-:"fNoex··r lroexTypesT 18'1lll(y
lnduTwes := IndexType llodelrTypes• • IndexType
lndaxType ..:-
-lfirldexcbjed, use SYNTAX
-value ollllemn.,_lden1
-OBJECT-TYPE iniOCaliOil
value (tnllexoo,ec;tOQjec!Name)
-olherwtS!! use named SMI type
- mU!I ca>form to ~yntu Mlow
IOype lndexT)II>IIl
OcNa!Part ·•
·oa:VAl' •r~~...(dofvot... ~tSynuu) "I 1O<rC>1Y
END
lndexSyntex •
CHOIC~(
number INTEGER (0 .MAX),
oli"''J OCTtTSTRINO,
object OBJECT iDENTIFIER
oooress NelWOI1<AO<Jr_ _
ipAddre$$ lpldlllest
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. DBFVAL 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 ObjrclTobit
rE.t.2 [[ T E.2.2
:l
T.E.t.3
II T.E.2.3
:I
TE.1.4
II TE.2A
II
TABLE
T
r E.3.2
T.E.3.3
T E.3.4
I l T£4.2
II T.E.4.3
II T;E.4 4
II TE.52
II T.E5.3
II T E.5.4
(b)wmpioofn >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
convention used in denoting each object in the rows. The columnar objects in each row are denoted by the
concatenation ofthe object identifier ofthe 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 normaUy think ofas 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 isthe value ofthe index ofthetable. For
example, ipAdEnt:Addr, which is theiP address, is the index for the rP address table example shown in Figure4.20.
Hence, the value of ipAdEntAddr will dete.
rmine the row oftl~e table.
Let us apply this conceptual table to the rP address table example we h.ave 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-lustauctl1au•g•d Objtcl: ipAddJ'Toblt
Row
1
2
3
4
I!>Ad..-Ta~(1.3.6 12.1.4.20}
lpl.~d<Efl11'( 11)
IJ)IIdEnlllddr (1)
IPIOEnlllhoo• (21
lpldEniNc1Mn1~ (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 mgmrmib ip lpl:ldrToble l)MdrEnuylpii:!EntBcasilddr
1 ' (; ! 2 t .o4 20 I A.
lp,AdEoiA<Idr ii>ACIEnllllrd~~ IP/I<IEntNetMool< IPAI!El>t5east tpA<!EntRe.•mt.l~•
Mur Si<C
123.46.~.1 1 255.255 255.0 0 12000
113.46.3-~ ) 25$..25500 1 12000
165.8.!.25 2 2liUS525M 0 10000
9.96.8.U8 ~ 2S5 2552550 0 15000
lb) Objecllnsu n<:Mof illAddrTable C1.3.B.1.2.1.4.201
ColumoarCbiect l'lowtln (b) Dbj6Ctldanufief
,.,....En!Ada
13 6. t 2.1.•.20.1.1 l (1.3.8.12 I 4 20 1 1123 •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 1
0 fot Speo;r,. tnstooc:<!$

Figure 4.23(b) shows the tabular presentation ofan JP address ~able. The table shows four rows and six columns.
Each ofthe four rows in the £P address table indicates a set ofvalues assooiated with each instance ofifAddrEntry
in ·the table.
The first column in Figure 4.23(b) is the row number, which is added to the other five columns (column 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 ofthe 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 columnar 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
associated with each row of the table. The last three columns in Figure 4.23(b) represent the columnar objects
ipAdEniNetMosk, ipAdEntBcastAddr, and ipAdEntReasmMaxSize.
Figure 4.23(c) shows the representation of the object identifier associated with each instance. There 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 ofthe columnar object.
Let us first look at the first row of Figure 4.23(c). We want to represent the object identifier associated with the
columnar object 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 columnarobject 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 ofFigure 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 ofFigure 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 ofthe 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.
Frguo
•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
mgml
C)(OCrirDcht.at
pmate
enlefpn>es
OBJECTIDENilFIER ··a{ o
ntornot 1)
OBJECT IDENTIFIER =(intomel2 I
OBJECT IOENTiriER :;-( ln~mot 3)
OBJECTIDENTIFIER ::• { tnteme14 }
OBJECT IDENTIFIER;-• { prlTote 1I
- dettniJOn ot ob)!lCII)'JJM
OB.IECT·TYPt=lllACRO .~
BEGIN
END
TYPE NOTATION • • "SYNTIX" IYI"' ('TYPEOI>J
octSynte.Q
·Access'~ss
' S IAlUI;' SUlWS
VALUE NOTATiONcs v•lue (VALIJE Obfoc1Norra)
Access •• 'll!lld·onJy" I"!ud-write") 'Wrt~"I"
1>0I·accessibla'
6nlua ;:• ··-m"ndato;y' l 'oplion.nr 1•o~loto'"
- namesolObjeel$1n t~&MIB
OojecllNanle .~
OBJECTIDENTIFIER
- syolllx ol ollJoc1S 1n theMIB
Ob)O«!Syn!3X ·-.
CHOICE{
llmplo
SiMp~Syntflio(l
- Noto 1~11 otmple SEQUENCEs aro not dfootly montoonod ~ere 1
o k(lql l~illll'
11~1<1 (I t provont mlsuoo) fiow~var, applia!Uan-wdo typot, which a1o IMPliC.
lrlv encodod tlll)plo SEOUENCEt.may Opi>OOt In Ul~ fOllowing CHOICE
oppiiCQt)on·mdo
Applle:$t.on~ynuu
SlmploSynthX •
CHOICE (
nurnb<lr
INTEGER
1nng
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 eradQfl~. ..,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 ofM!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 manageror 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.sion 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 ofthe criteria for choosing objects to be included in smndards is that it isessential 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 ofthe 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 Structur<
<modur. ru~mo > DEANtnONS ;:. 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 whoseOBJECT IDENTIFIER is 1.3.6.1.2.1.
Figure-1.26. lulem<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 ofthe 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 Placeholderfor transmission Information

TRbl• 4.4, MIB·U Groull'J
Group OlD Description (Briel)
snmp mib·211 Information on SNMP protocol
The·System groupcontnins objects describing system administralbn. Tb.e interfaces group defmes interfaces oftb.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 associated with the respe~:c.ive protocol ofthe 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 ofeach 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 ofthe Transmission group is mandatory fbr thai
system.The SNMP group will be addressed in Chapter Sas part ofthecommunication 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
specificationson each group and understand the structure oreach MIB group.
Some a amples associated with managed objects .in the group arc presented along with a description ofthe 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 retrievethe 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, suchas contact person and.physicall~ation that helps a network manager.
lmplementntion ofthe System group is mandatory for all systems in both the agent and the manager.lt consists of
sevenentities, which are presented in Figure 4.27 and Table 4.5. The vendor ofthe 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 ofdays, hours, and minutes in their pre.sentatioo, a.
s shown in Figure 4.2. Alehough 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 theentity
sysUpTime system 3 Time (In hundredths ofa second si·nce last·reset)
sySContact system4 Contactpersonfor the·noM
sysName system S Administrative name ofthe 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 Bibernet bridge has severaJ network Interface cards, the group would cover iofurmation
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 ofManaged Objects fur theEthernet-like Imerfooe 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
Legend: lNOEX io bold
Table 4.6. lnter(••u Croup
Entity OlD
~
LJU
Descrfptfon (Brfef)
lfNumber Interfaces 1 Total numberof network Interfaces fn thesystem
ffTable Interfaces 2 Ust of entries describing information on each Interface ofthesystem
ifEntry ifTable 1 An Interface entry containing objects at the subnetwork layer for a particular Interface
iflndex ffEntry1 A unique Integervalue for each Interface
lfDescr ifEntry 2 Textual data on product name and verslcm
lfType ifEntry 3 Type ofinterface layer below the network layer defined as an enumerated Integer
lfMtu ifEntry4 Largest size ofthe datagram for the Interface
lfSpeed ifEntry 5 Current or nominal data rate for the Interface In bps

Tablt 4.6. lncuf>t<t5 Grourl
lfPhysAddress ifEntry 6 lnterfare's address at the protocol layer Immediately below the network layer
ifAdminStatus lfEntry 7 Desired status ofthe Interface: up, down, ortesting
ifOperStatus ifEntry 8 Current operational status of the Interface
iflastchange ifEntry 9 Value ofsysUpTime atthe current operatiOnalstatus
iflnOctets ifEntry 10 Total number of input octets receive<!
iflnUcastPkts ifEntry 11 Number ofsubnetwork unicastpackets deliveredto a higher-layer protocol
iflnNUcas!Pkts ifEntry 12 Number ofnort-unicastpackets delivered to ahigher-layer protocol
iflnOiscards ifEntry13 Number ofinbound packets discarded irrespective of errorstatus
iflnErrors lfEntry 14 Number ofInbound packetswith errors
lflnUnknownProtos lfEntry 15 Number ofunsupported protocol packets discarded
ifOutOctets lfEntry 16 Number ofoctets transmltted out ofthe Interface·
ifOutUcastPkts lfEntry 17 Total number ofunlcast packets that higher-level layer requested to be transmitted
ifOu!NUcastPkts lfEntry 18 Total number ofnon-unlcast paokets that higher-level layer requeste<l tl be transmltte<l
ifOutOlscrds lfEntry 19 Number ofoutbound 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 outputqueue in packets
ifSpecific lfEntry 22 Referenceto 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 ofprotocols. The index for the table isjustone entity, specified by iflndex, as shown below in the
definition ofthe itEntry module under iffable.
!!Ent ry OSJeCT-rY~E
S'iNTlX
ACCESS
STATOS
DESCRIPTION
if'Entry
not-accessible
mandat ory

"An interface e n tl:y containing o bjects at the s ubn.etwoJ:k layer and below for a
par ticular i nt erface."
INDEX {if Index l
; ;- ( ifTab~e 1 }
The index is also shown in bold leitl:rs in the figure and the table.
The entity 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 ofstandard interfilces.
The administrative and operational status that is indicated by object idemificrs 7 and 8 should agree with each other
when the system inerfuce 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 traffic.
An example ofuse of l.nterfaces M1B would be to measure the incoming and the outgoing traffic rate on a given
interface ofan 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 of output unicast
packets (i.fOutUcasi.Pids) every second. Remember thai we get the reading oftwo 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 "network 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) channels) 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 objects thai
need to be specified in a data link layer (DLL)-Layer 2.
DLL can 'be visualized, in general, os comprising several sublayers. These can either be horizontally stacked or
vertically sliced (or "stacked"), as shown in Figures 4.29(a) and (b), respectively. An ex.ample ofthe (ormer is an
interface with PPP running over 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. lulert"ace Subbtytr~

I -; I
IiI
I ~ I
I ~ I
.E
Networi< lay~
Interlace Stblayer 1
Interlace Stblayer2
ln~ce Soblayor 3
(a) lntorfO<:<> Stackod loyoro
(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 ofthe 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 singletable 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 ofsuch conceptual rows,
the value ofiflndex is no longer canstmined. In other words, it can be stated that the index ofa conceptual row no
longer has to be less than or equal to !he value ofiflndex. The·upper layer in !he ifStackTable, ifStnckHigherl.ayer,
is the sublayer above the sublayer under consideration and carries the·value ofthe iflndex ofthat sublayer. Ifthere
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. ffit
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,
suchas a portID. 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 ofthe 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 compatib.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 ufthis group in detail now.
1'be IP group defmes all the parnmeters needed for the node to bandle a network layerlP 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 ofthe

entities, respectively. The group contains three wbles,1P addtess wble,IP routing table. and [p AddressT moslation
table.
Flgure .a.3I. TP Crnu1)
L------1 lpOu!NoRo•loa (I:I) 1----'
Table 4.7. II' Group
Entity
ipforwarding
ipDefaultlTL
OlD Description (Brief)
ip 1 Node acting as agateway or not
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 ofdatagrams 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
lplnDiscards
IplnOellvers
lpOutRequests
lpOutol.scard.s
IpOutNoRoutes
lpReasmTimeOut
lpReasmReqds
lpReasmOKs
IpReasmFalls
lpFragOKs
lpFragFails
tpFragCreates
lpAdddrTable
lpRouteTable
OlD Desaiptlon (Brief)
lp 8 Number ofInput datagrams discarded with no problems (e.g. back of bufferspace)
tp 9 Total number ofInput datagrams successfully deliveredto IP user protocols
ip Total number of IP datagrams that local IP user protocolssupplied to IP
10
lp Number ofno-error IP datagrams discarded with no problems (e.g. lackofbufferspace)
u
ip Number of IP datagrams discarded because no route could be found to transmit them to their
12 de.stlnatlon
ip Ma~lmurn number of seconds that received fragments are held while they are awaiting
13 reassembly
lp Number ofIP datagrams received needing reassembly
14
lp Number ofsucces$fully reassembled datagrams
15
ip Number offallures detected by the IP reassembly algori thm (not discardedfragments)
16
lp Number ofsuccessfully fragmented datagrams
17
ip Number of IP datagramsnot fragmented due to "Don't FragmentFlag• set
18
lp Number ofdatagram fragments generated as a result of fragmentation
19
ip Table of!Paddresses
20
tp IP routing table containing an entry
21
lpNetToMediaTable ip IPAddressTranslation table mapping IP addresses 1D physical addresses
22
lpRoutlngDiscards lp Number ofroutingentries discarded even though they werevalid
23

We can use the lP Mmlo acquire any information associated with the lP layer. For example, to Jearn the value of
the managed object, ipForwardlng 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 wrong
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
Flgur•'i.33. JP Roodiug Tablr
o
pAddrfable
(lp 20)
Figurr-1.34. fP AddrrssTran.slaliou Tablt

lpNetTOMe<llaPnysAG<ltoss (2) lpNetToMe<lliNl!lAddntss (3)
Tobit 4.8.1P Add.n!SS Table
Entity OlD Description (,Brief)
lpAddrTable lp20 Table of IP addresses
lpAddrEntry lpAddrTable 1 Ooe of theentries in the IP address !ilble
lpAdEntAddr lpAddrEntry 1 The IP address to which this entry's addressing Information pertains
lpAdEntlflndex lpAddrEntry 2 Indexvalve ofthe entry, same·as lftndex
lpAdEntNetMask lpAddrEntry3 Subnet mask for the IP address ofthe entry
lpAdEntBc.astAddr lpAddrEntry4 Broadcastaddress 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 entry 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 on the table-access mechanism 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 ipRouteDest. As in llle !P address t.a.ble, the ipRoutciflnde~
has llle same value as llle iflndexof llle InterfaCes t.able.
Table 4.9. IP RoutingTable
Entity OlD Desalptlon (Brief)
lpRouteTable lp21 tP routi~ table

Tablo4.9.1P Rou1iog Tablt
Entity
lpRouteEntry
lpRouteDest
lpRoutelflndex
lpRouteMetrlcl
ipRouteMetrla
ipRouteMetrid
ipRouteMetri~
ipRouteNe>(!Hop
lpRouteType
ipRouteProto
lpRouteAge
ipRouteMask
lpRouteTable 1 Route to a particular des11nation
lpRouteEntry 1 Destination IP address ofthls route
lpRouteEntry 2 Index of Interface,same aslfln~x
lpRouteEntry3 Primary routing metric for this route
lpRouteEntry 4 An alternative routing metric for this route
ipRouteEntry S Analternative routing metric for this route
ipRouteEntry 6 An alternative routing metricfor thisroute
ipRouteEntrv 7 IP address ofthe nexthop
lpRouteEntry 8 Type ofroute
lpRouteEntry 9 Routlrll! mechanism by whichthis route was learned
ipRouteEntry
10
lpRouteEntry
11
Number ofseconds since routin,g was iast updated
Mask to be logically ANDed with the destination address before companng with the
ipRouteDestfield
ipRouteMetricS ipRouteEntry An alternative metricfor this route
12
ipRoutelnfo lpRouteEntry Reference to MIB definition speclflc tothe routln,g protocol
13
Figure 4.34 and Table 4.10 show the IP Address Translation table- It contains cross-references between IP
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 entities, ipNetToMedialflndex and ipNetToMedinNelAddress. Again, the
lpNetToMedialftndex bas the same v.alueas iflnde·x.in the Interfaces group.
Tablt4.1 0. IPAddrt.ssTranslation 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)
lpNetToMedlaEntry lpNetToMedlaTable 1 IP address to physical address for the particular Interface
lpNetToMedialflndex lpNetToMedlaEntry 1 Interfaces on which this entry's equivalence Iseffective; same as lflnde.x
lpNetToMedlaPhysAddress lpNetToMedlaEntry 2 Media-dependent physical address
lpNetToMediaNetAddress (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 FOtWArdlngTobit
Tobit 4.11.IP I'OIWArdlngTAbIf
ipForward ip24 Contains information on IPforward!ng table; deprecates IP routing table

Tablo4.ll.lP Forwardin.gTAblr
Entity 010 Description (Brief)
lpForwardNumber ipForward 1 Number ofentries in the IP forward table
ipForwardTabie· ipForward 2 Routing tabie·ofthls enttty
ipForwardEntry lpForwardTable 1 A particular route to a particular destination under aparticular policy
ipforwardOest lpForwardEntry 1 Oestination IP 'outeof this address
lpForwardMask lpForwardEntry2 Mask to be loslc.aliy ANO
.ed with the destination address before comparing wth
the lpRouteDestfleld
ipForwardPollcy lpForwardEntry 3 Set ofconditions tnat selects one multipath rot~te
ipForwardNextHop lpForwardEntry4 Address ofthe next system
ipforwardlflndex lpforwardEntry S iflndexvalue ofthe Interface
ipforwardType lpForwardEntry 6 Type ofroute: remote, ~ocal, invalid, orotherwlse; enumerated Integer syntax
ipforwardProto lpforwardEntry 7 Routing mechanism by whi~h this route was learned
lpForwardAge lpforwardEntry 8 Number ofseconds since routing was.last updated
lpforwardlnfo lpforwardEntry9 Reference to MIBdefinl:t lonspedflc tothe routing protocol
lpForwardNextHopAS lpForwardEntry Autonomous system numberofNext Hop
10
lpForwardMetrlcl lpForwardEntry Primary routing metrlcfor this route
11
ipforwardMetricl lpForwardEntry An alternative routing metrlcforthis route
12
lpForwardMetric3 lpForwardEntry An alternative routing metric for this route
13
lpForwardMetrlc4 lpForwardEntry Analternative routing metric for this route
14
lpForwardMetrlcS lpForwardEntry An alternative routing metric for thi sroute
lS

The entity ipForwnrdPolicy defmes the general set ofconditions 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 ofthe networking exercises in Chapter I. It is part ofihe TCP/lP suite
ofprotocols. All parameters associated with ICMP protocol are covered.in this group.
As mentioned in Section 4.2, !CMP is a precu[sor ofSNMP 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. Thesyntax 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
lcmptnMsgs
IemplnErrors
icmplnDestUnreachs
icmplnTimeExals
icmplnParmProbs
icmptnSrcQuenches
lcmp 1 Total number of ICMP messases received by the entity lndudll'lfllcmplnErrors
icmp 2 Number ofmessages received by the entity with ICMP-speciflc errors
icmp 3 Number of ICMP Destination Unreachable messages received
icmp 4 Number ofiCMPTime Exceeded messases rea.ived
icmp 5 Number ofICMP Parameter Problem messases recelved
icmp 6 Number ofICMPSource Quench messages received

Tablt 4.12. ICMP Croup
Entity
icmplnRedirecls
icmplnEchos
kmplnEchoReps
icmp 7 Number ofiCMP Redirect messages received
icmp 8 NumberofiCMP Echo (request) messages received
lcmp 9 Number of ICMP Echo Reply messages received
lcmpln1imestamps icmp 10 Number ofICMP 1imestamp (request) messages received
icmplnTimestampReps icmp 11 Number ofICMP Timestamp Reply messages received
icmplnAddrMasks icmp 12 Number ofICMPAddress Mask Request messages received
icmplnAddrMaskReps icmp 13 Number ofICMPAddress Mask Reply messages received
icmpOutMsgs lcrnp 14 Total number ofiCMP messages attempted to besent by this enUty
lcmpOutErrors icrnp 15 Number ofgood ICMP messages not sent, does not Include the ones with errors
lcmpOutDestUnreachs lonp 16 Number ofICMp Destination Unreachable messages sent
lcmpOutTimeEl<cds lcmp17 Number ofICMP lime Exceeded messages sent
lcmpOutParmProbs lcmp18 Number of ICMP Parameter Problem messages sent
lcmpOutSn:Quenchs lcmp19 Number ofICMPSource Quench messages sent
lcmpOutRedlrects lcmp20 Number ofICMP Redirect messages.sent
lcmpOutEchos lcmp21 Numb:er ofICMPEcho (request) messages sent
lcmpOutEchoReps lcmp22 Number ofICMPEcho Reply messages sent
lonp0ut11mestamps lcmp23 NumberofiCMP11mestamp (request) messages sent
lcmpOutTimestampReps icmp24 Number ofICMP11mestamp Reply messagessent
ltmpOutAddrMasks lcmp 25 Number ofiCMPAddress Mask Requestmessages rent
icmpOutAddrMaskReps icmp 26 Number ofICMPAddress Mask Reply messages sent

TCP Group. The transpon layer of the l,nten~et defines Transmission Control Protocol (TCP) fOr a connection-
oriemed circuitand 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 aelive sessions from this table with addresses and ports of local and remote entities.
Figurr -1.37. TCI' Grout>
Table 4.1 J. TCPGrout>
tq~RtoAigorlthm tcpl nmeoutalgortthm for retransmission ofoctets
tcpRtoMin tcp2 Mlnlmum value for timeout In milliseconds for retransml.ssion
tc.pRtoMax tcp3 Maximum value for timeoutin milliseconds retransmission
tc.pMaxConJl tcp4 Maximum number ofTCP conJlections
tcpActlveOpeJlS tcp5 Number ofactive connections made CLOSED to SYN-SENT state
tcpPasslveOpens tcp6 Number ofpassive connections made LISTEN to SYN·RCVD state
tcpAttemptFalls tcp 7 Number offailed attempts to make connection
tcpEstabResets tcp8 Number of resets done to either CLOSED orLISTEN state

Tablt 4.13.TCP Grourl
tcpCurrEstab tcp 9 Number ofconnections for which the currentstate Is either ESTABUSHED or CLOSED· WAIT
tcplnSegs tcp 10 Total numberofsegmentsr~elv~ Includingwith errors
tcpOutSegs tcp 11 Total number ofsegments sent excludl~ retransmission
tcpRetransSegs tcp 12 Total number ofsegments retransmitted
tcpConnTable tcp 13 TCO connection table
tcplnErrs tcp 14 Total number ofsegments 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<
tcpConnTable tcpU TCO connectiontable
tcpconnEntry TcpConnTable 1 Information about a partlo:ularTCP connection
tcpConnState TcpConnEntry 1 Stille of theTCP 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 Remoteportnumber
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 udpLoeaiAddress and tKipLoeaiPon, and are indicated in bold letters.
l'igu•·• 4.39. liDP Cruup
Table4.15. UDPGrnup
udplnDatagrams udp 1 Total number ofdamgramsnallvered to the users
udpNoPorts udp 2 Total number ofreceived datagrams for whichthere is no application
udplnErrors udp3 Number ofreceived datagrams with errors
udpOutDatagrams udp4 Total number ofdatagrams sent
udpTable udpS UDP listener table
udpEntry udpTable 1 Information about a particular connection or UDP listener

Tablt 4.15. UDP Cn>llfl
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 ofpractical
necessity than the need fo.r setting st;lndards. The lntemet EngineeringTask 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 the11etwork 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 areget-
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 ofother scalar objects. Mult4>1e instances ofa 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 since been added to the MIB, although
they have not been approved as a standard.
Exercises
1. Refer to Figure4.3 to answer the foilowl~ questions:
a.. What are the classes ofnetworks shown in Figure 4.3(a)?
b. Explain the function ofa 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 Inthe document. (You do notnave 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 thethree 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 IPAddress 10.2030.40InTLVformaL
6. Refer to RFC 1213 for the following 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 following SNMP martaged entitles:
a. IP address 125.52.66.24
b. A row in the lnterfaces table (the rowspecificat·ions only, not the objects in the row)
c. MAC address ofan 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 objectsthat are used In the procedure and present the macros for theOBJECTTYPE.
9. Explain how you would determine whether a device is actingas 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 answerthe following questions:
a. List t.he columnarobjects under ipNetToMed.iiEntry.
b. Draw an object instance table for ipNetToMediaTable as in Figure 4.23(b) without the row
column. Fill three rows ofdata 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 (Atlanta Braves Company), whl,n sells 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 thatcan be accessed by the tP address; wnlcn havethe following ORJECT DESCRIPTORS:
br a nch.l - 100. 100 . 100 . 15

brancll2 - 100 . tOO . 100. 16
Each branch has two types ofproduc1s whose irwentory are
ha:t s
j a.oket 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 ofthe company.
a. Dmw a MIB subtree.
b. Write a MIS module.
12. A network manager dlscovetS th<rt a network romponent Is performing poorly and Issues an order tl 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 tothe 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. WhatOBJECTTYPE would you use to Identifythe address of the neighboring gateway from your local gateway?
16. An rr manager gets complaints from users thatthere 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 problem to a single faulty network Interface card. Explain
howshe loc;,rllzed the problem. You may use RFC 2358 to answer thisexerr.ise.
17. FDDils heavily used as a backbone network Ina corporate complex.
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, ifName and lfAIIas were Introduced In lfMlB module. Explain the purpose·of these

r>ew managed objects In r>etwork management and give an eKample for each case.
19. Illustrate (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. SNMPvl 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 SNMPvI communication and functional models. Although SNMPvl does not rormally define the
functional mode~ applications are buih in the community·based accesspo.licy ofthe SNMP administrative model
5.1. SNM P Communication 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 of a collection of network management Slations 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 I157]. First, it should
minimize the number and comple!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
architectureshould be independent ofarchi1eeture and mechanisms of particular hosts and gateways.

Only non-aggregate objeciS are communicated using SNMP. The aggregate objects are communicated asinstances
ofthe 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 netvork 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 coldStan, 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 ofthe trap.
SNMP me.ssages are exchanged using a coonectionless UDP transport. protocol in order to be consiste.nt with
simplicity ofthe model, as well as to reduce traffic. However. the mechanisms of SNMP are suitable for a variety
ofprotocols.
5..1.2. Adminlstnu ive Model
Although the topic ofadministrative models should normaUy be discussed as part. ofsecurity 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, wewill discuss it now.
In RFC .1.157 the entities residing in management stations and networlt elements are calJed SNMP application
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. letus 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 oflhe two entities is called.an SNMP community.
The SNMP community name, called tbe community, is specified by a string ofoctets. 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 study. We also
have the analogous s.
ituatioo where a managercommunicates 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 simplest form ofauthentication 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 community name is also
assigned an SNMP access mode, either R6AD-ONLY or READ-WRJTE, as shown in Figure 5.2. A pairing of
SNMP MIB views with an SNMP access code iscalled a community profile.
Flaure 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 theother hand, ifthe 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 available 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. Jfthe access mode is defined as read-write, that operand is
available for all three operations ofget, set, and trap. An example ofread-write access is sysContact in the system
group. 1lte write-only access mode Is used to setthe operand value ofa 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.
Ifa corporution has two operations in two cities, Manager I in NOC I and Manager 2 in NOC2 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.
flgurt 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 ofManagers (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 ofNew 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 ofthe 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 nelvork, 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.SNMl' 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 ofa 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
Datallr* POU
1 ~1 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 ofthe protocol in SNMPv I is 484 byles (1,472 byles now in prnctice).lt is mandatory that allfive
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..SNi11' 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 ( -1lorlhis RFC
vers1on.1 (0)
).
communily - communtty name
OCTET STRING,
dOlO - o.g.. PDIJo lf·trlviol
l
Am ·-eutl1onllcatlon Is being used
- protocol data un.ts
POUs::=
CHOICF (
get-request
gct-noxt•rcqucsl
get-response
set-request
trap
l
GotRoquoo~POU,
GetNexiReques~PDU.
GeiResponse-POU,
SotRoquootPOU.
Trap-POU
- lhe Individual PDUs and commonly used data types Will be defined later
END
Basic operations ofthe 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 ifan error is encountered in any oflhe steps.
A trap may be generated incase ofautbenticatioo failure. On successful receiptoflbe message, a rerum message is
generated, ifthe origina.l message is a get-request.
A managed object is a scalar variable and is simplycalled 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 lnformallon
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, whichare defined in RPC I157 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 ofa 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 ifthe 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 ofseven 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< Trops
Generic-Trap Type
coldStart(O)
warmStart(l)
Hn~Down(2)
llnkUp(3)
Desaiption (Brief)
Serldlng protocol entity Is relnltlaii~ing Itself; agent configuration or protocol entity
Implementation mav be altered
Sending protocol entity is relnitlaltzfng Itself; aget~t conflguratlon or protocol entlty
Implementation not altered
Failure ofone of the·cornmunlcatlon llnl!:s
One ofthe links has come up
authentfcatfonFallure(4) Authet~tlcatlon failure
egpNelghborloss(S) loss of EGP neighbor
enterpriseSpedflc(6) Enterprise-specific trap
S..lA. 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 thissection.
GetRequest PDU Operation. Figure 5.10 shows a sequence <Jfoperations in retri.eving the values of objects in a
System group. It stans with tbe get-request opellllion using a GetRequest 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 ofthe figure. The message from the 8gem process sl.arts
on the righr 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 theSystem group.
Figul"t 5.t0. Gtt·Rtque<l Oprratlon for Sysrrm Group
II)<OwluO)
.... f..,.OOOU Oo _ . ,
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 theobject sysDescr. The agent
process returns a GelResponse PDU with 8value "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 IDENllFlER specified in the request. Figure 5.11 shows 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 GetNex
1Request 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:"
Figurt S.ll. Gn -Nui-R<qut51 Optrttlioo for • Sysrtm Group

-c.~......~o~:OS;t•.,.
c.u..,
- GetRespons (SY-"ObJectiD:I):.enuup(
I
-GeR-,.,.v,T.....o.m7349530
""
-G<>~e l•r•Cooml:LO= ••1
"'l<l~i'IJ-o-·no:l"l ~
~ ·
- Gc!R.._..(6)1SOCO>OO.Oo'1
- G<lR..)IO<UIO(SysSoMcoos.o-12)
Gel
~~~(NSwr::tNA.,._)
TheSystem 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 ofa 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 seaJar objects. They are followed byan 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.Jl. 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
sameas in Figure 5.12, now drawn to rollow the sequence ofoperations. 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 thedata in the table by traversing all the instances
ofa columnar object. The number ofiostances 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 ofwhat lhe nexi object in a Ml8 tree is, especially on the
table representing an aggregate·objecl. l:n SNMP, objects are retrieved using lexicographic convention. We will
flrst explain 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
"-•Uo> I
-o.>ll'-(1>,1
~-Ill) t·-
tTE.Il ~
= t l LIIJ
_,T.I.lll -
~~."T£-12)
- -ITE.21)
( T£.2.11 -...J
~-I TE.2.2)
( li.2.21::;1
- (TE-3.1)
I rE.l-11:-i
-(T.E.Hl-.:1
- --(TE-32
- Reopoos.fZ)
;o_,_t?l =::l
I
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.mbtr &'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 object 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.
le 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 ofthe 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 leafnode 1.1.18. Thus, !he rule at a
furked node is to always keepto 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
3.4
3.21
9
Figu>
.. 5.14. MIB Exllmple for Lulcogrnphic 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 ofa table, ifit is the next lexicographic entity.
Figure 5.15 shows the principle ofoperation ofthe functioning ofget-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 ofA filled in. Subsequent requests from
the manager areget-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 ofthe
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 identif
y 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 ofissuing 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 ~~Tr-(•.,tJlllltf') I
.,.__.- ~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 rowobtained 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. Wewill now look at lllePDU for llle System group example shown in Figure 5.10
us.ing a sniffer tool. Sni trer is a managementtool lllatcan capture packet.~ going across a !ransmission medium. We
have used this tool to "sni£1'' some SNMP messages to display how messages actuaHy look. We are presenting a
series ofmessages 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 noc1btc.gatech,edu.s.nmp > noc3.btc.gatech.edu.l64:
Community c ~ubllc;
GotResponse(172l
Request 1
0 =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 rorSyscrcn Co11la<l
t3:5'6:24.89t369nocl.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(411
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 ofnoel 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 GetRequestmessage
is Ill bytes in length. The SNMP version number is not tilled in. l11e seven object IDs from system.~-ysDescr.O to
system.sysServices.OaU 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 ofStt·Rtque-st.and Responsr for Sy.sttm Loc:Atinn
13:56~7.874245 noo3.tliC.gatoeh.e<lu 164 > noc1 txc.gatech.edu.snmp:
Commuroity= netmaro
SetHoq...,.,t(37)
Request tO=3
system.s)'Slocation.Oe 'BTCNM 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 01
11• 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 NMLab·
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 nocI. 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 ofmessages ror sctling the emilysysLocatlon with the value "BTC~ Lab."
Figures 5.20(a) and (b) are a repetition ofFigure 5.14 ofthe GetRe.questand GetResponse messages. We now see
!he completed version of!hesystem group dam.
5.1.5. SNMP MlB G1
·oup
Figure 5.21 showst 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 oftr80SIIctions in tbe descriptioncolumn in the Ulble indicates ins and
OUI.S of the SNMP protocol entity. AU entities exoept snmpEoableAmhenTmps have the syntax, Counter. The
implementation ofthe SNMP group is mandatory-obv.iouslyl
Flgw·• 5.21.SNMP Grout>
Tabl• S.4. SNMP Group
Entity
snmplnPkts
snmpOutPkts
snmplnBadVerslons
snmp (1) Total number of messages delivered from transport service
snmp (2) Total number of messages delivered totransport service
snmp (3) Total number of messagesfrom transport service that are of unsupported version
snmplnBadCommunltyNames snmp (4) Total number of messages from transport service that are of unknown
oommunity 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
snmplnASNParseErrs
snmplnTooBigs
snmplnNoSuchNames
snmplnBadValues
snmplnReadOnlys
snmplnGenErrs
snmplnTotallleqVars
snmplnTotaiSetVars
snmplnGetRequests
snmplnGetNexts
snmplnSetRequests
snmplnGetResponses
snmplnTraps
snmpOutTooBigs
snmpOutNoSuchNames
OlD Description (Brief}
snmp (6) Total numberofASN.1 and BER errors
snmp (7) Notused
snmp (8) Total numberofmessages from transportservice that nave 'tooBig' errors
snmp (9) Total numberofml!$<18es from transportservice that nave 'noSuchName' errors
snmp
(10)
snmp
(11)
snmp
(12)
snmp
(13)
snmp
(14)
snmp
(15)
snmp
(16)
snmp
(17)
snmp
(18)
snmp
(19)
snmp
(20)
snmp
(21)
Total numberofmessagesfrom transport service that nave 'badValue' errors
Total number ofmessages from transportservice that nave 'readOnly' errors
Total numberofmessi!l!es from transportservice that nave 'genErr' errors
Total number ofsucce.ssful Get-Request and Get-Next messages received
Total numberofobjects successfully altered by Set-Request messi!l!es received
Total numberof Get-Request PDUs accepted and processed
Total numberofGet-Next PDUs accepted and processed
Total number ofSet-Request PDUs accepted and processed
Total numberof Get-Response PDUs accepted and processed
Total numberofTrap PDUs accepted and processed
Total number ofSNMP PDUsgenerated forwhlcherror-status is 'tooBig'
Total number ofSNMP PDU.sgenerated for which error-status is 'noSuchName'

Table 5.4. SN~1P Go·our>
Entity
snmp0U1BadValues
snmpOU1GenErrs
snmpOU1GetRequestS
snmpOu!GetNexts
snmp0u1SetRequests
snmp0U1GetResponses
snmpOutTraps
snmpEnableAuthenTraps
5.2 Functionnl Model
OlD
snmp
(22)
~criptlon (Brief)
Total number ofSNMP POUs generated for which error-status is 'badValue'
snmp Not used
(23)
snmp
(24)
snmp
(25)
snmp
(26)
snmp
(27)
snmp
(28)
snmp
(29)
snmp
(30)
Total number ofSNMP POUs generated for whloh error-status ls 'genErr'
Tot;!l number of SNMP G.et-Requesti>OUsgenerated
Total number ofSNMP Get-Next POUs generated
Total number of SNMP Set-Request POUs generated
Total number ofSNMP Get-Response POUs generated
Tolal number of SNMP Trap POUs generated
Override option to generate aU1bentl<atlon failure traps
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 offunctions (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 ofread 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.ment 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 ofthe SNMP agent MIB. It is the function ofthe 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 thecommunity 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 wlh 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 SNMP 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 Iallure. Treat the t;rap as generic and leave he speclflc trap field blank.
The onlyvarBind thatthe trap sends lssysUpTime. (Referto RFC 1157 and RFC 1215.)
4. AnSNMP managersends a request message toanSNMP agent re<(uesting sysUpTime at 8:00A.M. Fllllnthe 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
Interfacesgroup for lfNumbervalue of3. Wrtte lhe POUs with tile fields filled In for
a. the get-reques1 PDU, and
b. the get-response PDU wilh ooSuciNameerror 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 aseparate get-request message issent for each data value.
9. Repeat Exerdse 7 with aVarBfndUst. 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. Composedata frames for SNMP POUs for the exampleshown In Figure 5.16for the following two.cases:
a. 1l1efirst 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
arequest from noel. Usethe following system status to answer this question.
Versi on = 0
Communi t y ~ netman
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 Responsefrom lhe managed object to lhe manager.

6. SNMP Management: SNMPv2
Objectives
Cornmunity-b!L'led security
SNMPv2 enhancements
o Addi1 ional messages
o Fonnalization ofSMl
Get-bulk request and information-request
SNMP MIS modifications
Incompatibility with SNMPvl
Proxy server
Bilingual manager
SNMPv.l, which was originally called SNMP, was deve.loped as an interim management protocol with OS! as the
ultrmate ·network management protocol A placeholder, CMOT (CMIP over TCP/U>), wns created in the Internet
Managemerulnformation Ba.se(MIB) fOr migralJng from SNMP to CMIP. Butthe "best-laid plans..." never came
about. SNMP caught on in the industry. Major vendors bad incorpomted SNMP modules in their network systems
and components. SNMP oow needed further enhancements.
Vecsion 2 of Simple Network Management Protocol, SNMPV2, was developed wben it became obvious that OSI
netwodt management staoda.rds were oot going to be implemented in tbe near future. 1l~e wodting group that wns
commissioned by the IETF to define SNMPv2 relensed it in 1996. Jt s also a community-based administrative
fran~ework similar to SNMPvl defined in STD 15 [RFC 1157], STD 16 [RFC 1155, 1212], and SlD 17 [RFC
1213). Although the original version was known as SNMP, it is now ref
erred to as SNMPvl to distinguish it from
SNMPv2.
6. 1. Ma,jor Clumgcs in 5mfPv2
Several signific11nt changes were introduced in SNMPv2. One ofthe moSt signific11nt changes was to improve the
security function tbat SNMPvl lacked. Uofurtunately, aller ligni:ficant eflilrt, due to lack ofconsensus, this was
dropped from the final specifications, and SNMPv2 wa.
s released with the rest of the changes. The security
function continued to be implemented on an administmtive framework based on thecommunity name and the same
administrative frnmework as in SNMPvl was adopted for SNMPv2. SNMPv2 Working Group has presented a
summary of the community-based Administrative Fmmework for the SNMPv2 framework, and referred to it as
SNMPv2C in RFC 1901. RFC 1902 through RFC 1907 prese-nt the details on the framework. There are significant
dilferences between the two versions of SNMP, nod unfortunately version 2 is not backward compatible with
version I. RFC 1908 presen1S implementation schemes for the coexistence ofthe two versions.
The basic components of network management in SNMPv2 ore the saDie as version 1. They are the agent nod the
manager, both performing the same functions. The ~manager-to-manager communication, shown in Pigure 4.8, is
fOrmal i-red in version 2 by adding an additional roessage. Thus. the organi7.alional model in version 2 remains
essentially the same. In spite ofthe lack ofsecurity enhancements, major improvements to the architecture have
been m~~de in SNMPv2. We will list some ofthe highlights that would motivate the reader!s interest in SNMPv2.
Bulk Data Trllllsfer Message: Two significant message.s were added. The first is the ability to request and receive
bulk data using the get-bulk message. This speeds up the get-ne.xi-request process and is especially useful to
retrieve data from tables.

Manager-to-Manager Message: The second additional message deals with interoperabilily between two network
management systems. This extends the communication of management messages between management systems
and thus makes network management systems interoperable..
Stn1cture ofManagement information (SMI): In SNMPvl, SMI is defmed as SlD 16, which is described in RFCs
1155 l!lld 1212, along with RFC 1215, wltich describes traps. They have been consoli.dated and rewritten in RFCs
1902-1904 for SMl in SNMPv2. RFC 1902 deals with SM1v2, RFC .1903 with textual. conventions, and RFC 1904
with conformances.
SM!v2 is divided into three parts: module defUlitions, object definitions, and trap definitions. An ASN.I macro,
MODULE-fDENTITY, is U1lld to de-
fine an information module. It concisely conveys the semantics of the
information module. The OBJECT-TYPE macro defines the syntaK and semantics ofa managed object. The Imp is
also termed notificatbn and Is defined by a NOTIFICATION-TYPE macro.
TCl(tual Conventions are designed to help define new dam types. They are also intended to make the semantics
consistent and clear to the human reader. Although new data rypes could have been created using new ASN.I c.lass
and tag, thedecision was made to use the existing defined class types and apply restrictions to them.
Conformrince Statements help the customer objectively compare features ofvarious products. It also'keeps vendors
honest in claiming their product as being compatible with a given SNMP version. Compliance defines a minimum
setofcapabilities. Additional capabiliiies may be offered as-options in the product by vendors.
Table Enbnnoements: Using a newly defined columnar object willi a Syntax clause, RowStalus, oonceptual rows
could be added to or deleted from an aggregate object table. Furtlter. a table can be expanded by augmenting
another table to it, which is helpful in adding additional columnar objects to an <;Xisting aggregateobject.
MID Enhancements: In SNMP-v-2, the IntenJCt oode in the MID has two new subgroups: security and snmpV2, as
shown io Figure6.1. lltere are significant changes to System and SNMP groups ofversion I. There arechanges to
the System group made under mib-2 node in the MIB. The SNMP entities .in version 2 are a hybrid, with some
ent·ities from the SNMP group, and the rest from the groups under the newly created smnpV2 node.
F'lgut•t 6.I. SNMl'v2 lnltrtlfl Group
'transport Mappings: There are several changes to the communication model in SNMPv2. Although usc ofUDP is
the prefurred transport protocol mechanism for SNMP management, other transport protocols could be used with
SNMM. The mappings needed to define other protocols on to UDP are thesubject ofRFC 1906.
6.2. SNMPv2 System Architecture
SNMPv2 syste-m architecture looks essentially the same as tbat of version I, as shown in Figure 4.9. However,
lbere are two significant enhancements in SNMPv2 architecture, which are shown in Figure 6.2. First, ·there are

seven messages instead of five as in Figure 4.9. Second. two llliUlager applications can commwricate wiili each
otherat.the peer level. Another message, repon message, is missing from Figure 6.2. This is because even though it
has been defined as a message, SNMPv2 Working Group did not specify its details. It is left for the implementers
to generate the speci!icaiions. ll is not currently being used and is he-nee omilled from the figure.
Flgun 6.2. SNMPV2 Nth•'~rk ~bnagtmtnt Arcbi!trturt
}~~ " }~
l SNMP ~""'a001 ~
·l SNM.P..i.::tn11gor
il ~
l;>pil<a1.""' AA>Ico""'
,.l~
i I ! " ;a
" ~ !!
!II!
.. ~
!l• 11
f t
~~ ! ~ ~
H i t ~ ~
!~
H hl ~ ~ 4 I f 7 <f .:.
ti
~ 'I
dJ! . ~ ~ ~ j! s
!; "§. .. i 0 1'. & - [i
5/.Ml' ~ 941.!?
....... 91"1'
POV
-
UOP UDP VDP
p I.P IP
1).1; lii.C Olol;
rt•v ,.,,. f'ltlV
I t
The messages gel-request, get-next request, and set-request are the same liS in version I and are generated by the
manager application. The message, response, is also the same as get-response in version I, and is now generated by
both agent and manager applications. h is generated by the agent application in response to a get or set message
from il1e manager application. It is also ge.nerated by the manager application in response to an inform-request
message from another manager application.
An inform-request message is generated by a manager application and is transmitted to another manager
npplicatioo. As mentioned aboVe:, the receivingmanager application responds with a response message. This set of
communication messages is a powerful enhancement in SNMPv2. since it makes lVO network management
systems interoperable.
The message get-bulk-request is generllted by manager application. h is used to transfer large amounts ofdata from
the agent to the manager, especially If it includes retrieval of table data. The retreval is fast and efficient. The
receiving entity generate.s and fills data for each ent:ry in the request and transmits all ihe data as a response
OleSSage back to the originator ofthe request.
An SNMPv2-trap event; known as trap in version I, is generated and transmitted by an agent process when an
exceptional situation occurs. llle destination to which it is sent is implementation-dependent. The PDU structure
has been modified to be consistent with other PDUs.
Another enhancement in SNMPv2 over vers.ion I is the mapping of the SNMP layer over multiple transport
domains. An example ofthis is shown in Figure 6.3, in which an SNMPv2 agent riding over a connectionless OSI
tnmsport layer protocol, Conncctionless-Mode Network Service (CLNS), communieates with an SNMPv2

manager over tbe UDP transport layer. RFC 1906, which describes Lranspon mappings, addresses a few well-
known 1.ranspon L1yer mappings; otbers can be added using a similar structure.
Flgul'f 6.3.SNMl'vl Network Mnna:gement Arthitectuft on Multiple TrRI1SI)Or• Domains
( !mt.tP...._
J
AF01J
-""'
I I ' I
!I{
f .
l l l t
'
C>IUP SN.II'
POIJ
,.._
lOP
IP
Dt.C
PHY
Pan.,l..,o
CINSc-·llodoN-'SOrviOo
UOP Uw<O.--l
Dt.C; 01111 l"kCCtliiOI
-L """"'-
"P!>>ICOI...
r--r-
1I i -
Ii
! i
1 ~
l l
1),jM.P
Q.NS
"'
Dt.C
PHY
Details on tbe MJB relating to SNMPv2 are covered in Section 6.4 and communication protocol aspects of
messages in Section 6.5. Although not a standard, RFC 1283 specifies SNMP over Connection-Oriented Transport
Service (COTS), a connection-orienled OSI transport protocol. However, SNMP is not specified over connection-
oriented Internet prolooo~ TCP.
6.3. SNM Pv2 Str ucture of Management Information
There are several changes to SMI in version 2, as well as enhancements to SMIV2 over that of SM!v l. As stated
earlier, SM!v2 [RFC 1902) is divided into three pans: module definitions. object definitions. and notification
deftoitions.

We introduced tbe concept ofa module in Section 3.6.1. which is a group ofassigrunents that are related to each
other. Module definitions describe the semantics ofan information module and are formally defined by an ASN.I
macro, MODULE-IDENTITY.
Object definitions are used to describe managed objects. 'Tite OBJECT-TYPE macro that we discussed in Section
4.73 is used to define a managed object. OBJECT-1YPE conveys both synt;lx and semantics of the managed
object
Notification in SMlv2 is equivalent to tmp in SMivl. In SMiv I, lmp is fOrmally specified by an ASN. I ma~TO,
TRAP-TYPE. ln SM!v".., mtification is specified by an ASN.I macro, NOTIFICATION-TYPE, and conveys both
its syntax and semantics.
In addition to the above three parts, there is an additional part defined in SMiv2, which formalizes the assignment
ofOBJECT IDENTIFIER. Even though we have two assignments in SMlvl, namely. object name and trap, they
are not fi>rmally structured. In SM1v2, llJI ASN. I macro, OBJECT-IDENTITY is introduced fi>r the assignment of
objectname and noti.fkatioo to OBJECT IDENTIFIER, as shown In Figure 6.4.
filgun 6.4.DdliJI.tlous or SMJ ror SNMJ'V2 (Skele•ou}

SNMPv2-SMI DEFINITIONS ::=
BEGIN
-the l><'llh lo lhP. root
END
org OBJECT IDENTIFIER := {iS!l 3}
pt~vato OBJECT IDENnFtER ·:= {intsmo.l4)
enterposes OBJECT IDENTIFlER ::= {pnvate 1}
security OBJECT IDENTIFIER ::= {in!em!!l 5)
&nmpV2 OBJECT IDENnFIER .:• {tn!emetG}
- transport domains
snmpDoma1ns OBJECT IOENT1FIER := {snmpV21)
- transpon proxies
snmoProxys OBJECT IDENT1FIER ·:~!snmpV2 2}
-modi.ie fdcntilles
snmpModules OBJECT IDENTIFIER .:= {snmpV2 3)
doflnltJOnc for lnformoll<ln m~uloc
MODULE-IDENTITY MACRO
E!EGIN
<dau~e~• ::• «vDfue3•
END
- dcfin1Uons lor OBJECT IDENTIFIER assognm::nts•
OBJECT·IOENTITY MACRO ,;"
BEGIN
ElllO
<clauses> ·=<values>
- names or objects
obfeotNomo .:• OBJECTIDENTIFIER
noliflmltionNamo : =OBJECT IOE!I.'TIFIER
- syntaJ orobjects
<obje01Sy1118X Prod~ctklns>
<datSJType Product1ono
- dcfin•Von of objects
OBJECT·TYPE MACRO .:=
BEGIN
<clauses> ::=<values>
END
- definition lor nolll1cat10n
NOTIFICATION-TYPE MACRO
BEGIN
<clauses> ::=<values>
END
donn1t1on ol odmonlotrntlon ldontofcro
z;eroOotZero ::• { 00 ) -a value lornull tdenbfiors
6.3. 1. SMl Ocfinitwull for SNMPvZ

Figure 6.4 shows a skeleton ofthe SMIV2 and the reader is referred to RFC 1902 for a complete set ofdefinitions.
We na.ve lllken the liberty of presenting the definilions with some additional comments (marked by *) and
stmctural indentations to bring out clearly the BEGIN and END ofmacros.
Definition~ begin with the ltigb-level nodes under the Internet MIB. Two additional nodes, security and SNMPV2,
are introduced. The security node is just a placeholder and is reserved for the future. The snmpV2 node has three
subnodes: snmpDomains. snmpProxys, and snrnpModules. The M(8 tree showing aU these nodes defmed in
SMIV2 is presented in Figure 6.5.
Figur• 6.5. NMP'Vl lnltrll•l Nod•• l>tllned In SMh1
2
6.3.2. lnfonnation Modules
RFC 1902 defines information module as an ASN.I module defining infOrmation relating to network managemenl.
SMI describes how to use a subsetofASN.I to defme an information module.
There arc thrEe kinds of infOrmation modules thai are defined in SNMPV2. They arc MIB modules, compliance
statements for MIB module.s, and capability statements for agent implementations. Tltis classification scheme does
not impose rigid taxonomy in the defmition ofmanaged objects. Figure 6.6 shows an example where conformaoce
infOrmation and compliance statements are part of the SNMP group of SNMPV2 MIB. As we shall see later, the
SNMP group in SNMPV2 contains some ofthe objects ofvers·ion I and some new objects and object groups (to be
detmed later). It also bas information on conformaoce requirements. In the·example shown, the mandatory groups
in implementing SNMPv2 are snmpGroup, snmpSetGroup, systemGroup, and snmpBasicNotiticationsGroup.
Thus. if a network componcm vendor claims that its management agent is SNMP<2 compliant, these groups as
they are defined in SNMPV2 should be implemented.
Figur• 6.6. EUmJ!Io oCch•SNMP Grouf!lnrluding Conformance ~nd Cornplianet in SNMPvZ MlB

SNMP12-t.IIBOEFINm<>NS;,
BEGIN
~MIB MODULE IDENTITY ·~ {srrnpt,locjuVs 11
S!VJ1;1MI80bjecls OBJECT IOENTlFIER ::<" (snmpMIB I)
-~SN.!Pgtoop
OBJECTICENllFIE~ ::;(rrnh-2 1I}
OOJ:CT-TYPE •=(snmp 1}
OBJECT-TYPE ={...-.nr')
09.JECTlt::EN'llFIER "7" (SnmpmCObpelsCI)
OBJE<:T-lYPE ~( srmpSel 1)
- CQII-Iolotrnill!on
Sftfr4>MIBCorlOIII"atlCe
OB.ECT IOENTlFIER -,. {<n~MIB 2)
SM1)MIBCompf-
08JECr IOENllf IE'! :~ (Sl11PPoii!ICOnlllt!'llar'CO If
St111'1:1MI8Gt~ OBJECTIOENnFIER ·:~ (snmplltiBQ)nfMn.-vce 21
- llCmpliJMe&~aliments
ann'088~nce MOOULE-COMPUANCE
S"AfUS wran1
OESC!IIP'TION
1ho c:omll'oar~Ce sUiieiTIInllotSNW'1 onbueswl!ldl
lo~o at1llt<r SNMPvZ 11118.
MOOI.lE - lhls IIIOdlle
MANOAlORY-<JROUPS {•nm~Group• .,.,pSet<lRlup.
oyao....OIOIJp
anmj)EIMic:NOil~tOilp}
GROUP Snll!liCotnmuMyGmop
DESCRIPTION
'Tille IJ'OUPta111811d<1101yI« SNMP12 •nlll,._ Wlltcll wppon
caniYWIIIy.OOsed 81AOOI'IICOllon
·:• (!ll'mpt,IIBComDoWICfS 2)
- uri!$ <A corlCINI'OiliU
sn~roup OBJECT-<JROUP ""{snmpt.ll11Gioupa8}
Cftii'4>CommunotyG<OUp 08JECT-GROUP ~ ("""!'~UB"-111
sn~i!GIQJp OBJECT-GROUP • (*'"'flMIBGtou~ 10)
END
M1B specifications contain only compliant statements in them. The agent-capability statements are part of
implementation in the agent by the vendor. It might be included as pan.ofan "enterpriscspeci.fic" module.
The information on SMlv2 has been split into three parts in the documentation. Mffi modules for SMlv2 are
covered in RFC 1902.The textual conventions 10 be used 10 describe M1B modules have been formalized in RFC
1903. The conformance information, wllicb encompasses both compliance and age.ot capabilitie-
s, is covered in
RFC 1904.
6.3.3. SNMl> Keywords

Keywords used in the specifications of SMN2 are a subset of ASN.I . But it is a dift'ereot subset from that of
SMivl. Table 6.1 shows the comparison ofkeywords used in the two versions. We will address the new keywords
fur specific applications as we discuss them. ft is worth noting herethat some of the general keywords have been
replaced with llmited keywords. lllus, Counter is replaced by Couoter32, Gauge by Gauge32, and INTEGER by
lnteger32. TheNetworkAddress is deleted from use and onlyIpAddress is used.
T•blt 6.1. SN~fP Ktywords
Keyword SNMPvl SNMPv2
ACCESS y y
AGENT.CAPABILITIES N v
AUGMENTS N v
BEGIN y y
BITS N y
CONTACT-INFO N y
CREATION-REQUIRES N v
Counter v N
Counter32 N y
Counterfi4 N v
DEFINITIONS v v
DEFVAL y y
DESCRIPTION y y
DISPLAY-HINT N y
END v v
ENTERPRISE y N
FROM y y
GROUP N y
Gauge v N

TAble 6.1. SN~1P Ktywurds
Gauge32 N y
IDENTIFIER y y
IMPLIED N y
IMPORTS y y
INCWDES N y
INDEX y y
INTEGER y y
lnteger32 N y
lpAddress y y
lAST-UPDATED N y
MANDATORY-GROUPS N y
MAX·ACCESS N y
MIN-ACCE
SS N y
MODULE N y
MQDULE.COMPUANCE N y
MODUlE-IDENTITY N y
NOTIFICATION-GROUP N y
NOTIFICATION-TYPE N y
NetworkAddress y N
OBJECT y y
OBJECT-GROUP N y
OBJECT-IDENTITY N y

Tablt 6.1. SN~1P Ktywonls
OBJECT-TYPE y v
OBJECTS N y
OCTET y y
OF y y
ORGANIZATION N v
Opaque y v
PROOUCT-RElfASE N v
REFERENCE y y
REVISION N y
SEQUENCE y y
SIZE y y
STATUS y y
STRING y y
SUPPORTS N y
SYNTAX y y
TEXTUAL-CONVENTION N y
TAAP-T'fPE y N
nmelicks y y
UNITS N y
Unslgned32 N y
VARIABLES y N
VARIATION N y

TAble 6.1. SN~1P Ktywurds
WRITE-SYNTAX N y
It is also to be noted that rerenmce in lMPORTS clause or in clauses of SNMPv2 macros to an io.formntiooal
module is not through "descriptDr" as it was in version I. It is referenced through specifying it:s module name, an
enhancement in SNMPv2.
It should be observed that the expansion ofthe ASN.I module ma.cro occurs during the implementation pha.se of a
product, and oot at run-time.
6.3.4. Module Definitions
The MODULE-IDENTITY macro is added to SMlv2 specifying an infurmational module. 1:1 provides
administrative infurmation re£11rding the informational module as weU as revision history. SMiv2 MODULE-
fDENTITY macro is presented in Figure 6.7.
F·lgurt.6.7. MOOUL£.1DENTITY Marro
MOOULE·IOENTll'( MACRO ::=
BEGIN
END
l'(PE NOTATION ::=
•LAST.UPOATED' Vdl~" (Upo!dtu UTCTinMI)
"ORGANIZAllON" Text
"CONTACT-INFO' Text
"OESCRIPTlON' T"'"
ReviSIOnPart
VALUE NOTATION :::
valUEt(VALUEOBJECT IDENTIF1ER)
Rev~Part ::= Revisions I!!J11ply
Revi$l00$ ::::Revision 1Revls!Oos Rllll>slo~
Revidon :::
"REVISIOW value lUTCTome)
"DESCRIPTION" Text
- u£6 '"" NVT ASCII ehor.>e~er sal
Text ·:=- s'ling-
Figure 6.8 shows an example ofa MODULE-IDENTITY macro (a real-world example ofa oo~rex.isrenl module)
for a network component vendor, lnfoTech Services. l.oc. (isi), which is updating their privat.e-coterprises-is.i MlB
module {privute.enterprises.isi}.
Flgurt 6.8. EXAn>l>lt orMODULE-IDENTITY Macro

lsiMIBModule MODULE-IDENTITY
LASI-UPOATEO '98021011002'
ORGANlZATION ·rnroTedi Services. Inc."
CONTACT-INFO 'Marn Sl.tlramantan
Tele: 770·111-1111
Fax. 770·11H1222
ema3: m~n•s®bellsouth net•
OESCRJPTION 'Ve~ion 1.1 ofthe InfoTech Setv100SIMIB module"
Revision "9T0~02 1500Z"
DESCRIPTION "Rev,sion 1.0 on Septamber 2 1997 was a draft
versiOn"
The last updated clause is mandat·ory and contains the date and time in UTC time furmat [RFC 1902]. "Z:' refers to
Greenwich Mean 'Time. The Text clause uses the NVT ASCU character set [R.FC 854], which ls a printable set. All
clauses, eKCeptthe Revl~ioo <>lause. must be present in the macro.
6.3.5. O bject Definitions
The OBJECT-IDENTIIY macro has been added in SM1v2 and is used to define infurmation about an OBJECT-
IDENTIFIER.lt is presented in Figure 6.9. The STA'nJS clause bas one ofthree values: current, deprecated, or
obsolete. 'The value mandatory in SMJvl is replaced with the value current in SMJv2. The value optional is not
used in SMiv2. The new value, deprecated, has been added t!> define objects that are required to be implemented in
the current.version, but mny not exist in future versions ofSNMP. This aUows fbr backward compatibility during
tlte t.ransltion between versions.
Flgur• 6.9. OB.IECT-IDENTITY M~Kro
OBJECT-IDENTITY MACRO :=
BeGIN
END
TVPC NOTAT10H -
"STATUS" Status
"t!ESCRIPTION" Text
R.r.,rPott
VALUE NOTATION -.
StaltJS.:=
RolcrP0<1 :·•
Text ::=
value !VALUE OBJECT IOENTIFIER)
"current" 1"deprecated" !"obsolete"
'1lEF£REIIICE'Toxt f empty
-~lnng -
Akhough the REFERENCE clause was used only in an OBJECT-1YPE construct in SMrvl, it is u.sed in many
constructs in version 2.
Let us extend our hypoihetical example oflnfoTech Services and suppose thatlSlrtiakes aclass ofrouter products.
It is given an OBJECT IDENTIFIER as isiRouter OBJECT IDENTI'FJER ::= (private.enterprises.isi I ). The class
of router products can be specified at a high level using lbe OBJECT-IDENTITY macro as sbown in Figure

6.LO(a). The· status of the ~iRouter is current iUJd is described as an 8-slot 1P router. A reference is given for
obtaining Lhe details.
Flgut•t 6.10. Exomplt ofOB.TECf-fOENTITY m
nd OB.ll!:cr-TYI'E Ma<t'O<
IS!Router OBJECT-IDENTITY
S'TATUS turftnt
OESCRIPl'lON 'An 8-ol<lt IF> tO<.Otor 10tho 1P rc.JIOf r..mly •
ERENCE 'lSI l.'.oiTI0<1lnd<lm No lSI R123 dalod Ja.,...,ry 20,
1997"
~to t<~to'J)ricu tsl 1)
(a) Elc3mplo ol an OBJECT·IDENTITY Macro
routO!ISil23 OBJECT·TYPE
SYNTAX On:olaySrnro
MAX·ACCESS teacl-orly
STATUS CUmlnl
DESCRIPTIO" ·An 8-<slot IP rouor !hat can switCh upto
100million pild<ets per second •
... fllltRoul<rt ,,
(b) Example of an OBJECT-TYPE Maao
A specific implementation of the router in L~iRouter clllss of products is routerls'i123. This Is a managed object
specified by rhe OBJECT-1YPE macro shown in Figure 6.10(b). We are already familiar with the OBJECT-TYPE
macro by now.
Let us make sure that we clenrly understand the terminology used with the term OBJECT. OBJECT IDENTIFIER
defines the adminislrnlive idemification ofa node in the MIB. The OBJECT IDENTITY macro Is used to assign no
object identifrer value io the object node in the MIB. The OBJECT-TYPE is a macro that defines the type of a
managed object It is al~ used to de$CI'ibe a new type ofobject. As we have learned in the previous chapters, an
object instance is a specific instance of the object (type). Thus, a specific instance of the routerfsi 123 could be
identified by its 1P address I0.1.2.3.
Comparing Figure 6.10(a) with Figure 6.10(b) we observe the difference between OBJECT-rDENTlTY and
OBJECT-TYPE. The status clause appears In both. The dc.scrlpilon clause that also appears In both describes
different aspect~ of 'the object. The OBJECT-rDENT!TY describes the high-level description; whereas the
OBJECT-TYPE description focuses on the details needed for implementation.
Let us now visualize t.he router in Figure 6.10 with several sloLS lbr ioterfuce cards. We wan[ 10 detioe the
parameters associated with each interfuce.. The parameters that are managed objects (or entities) are defined by an
aggregate object, IITable. For example, the i.INumber for our router e.xarnple amid be 32 if the router has eight
slots and each card has four ports.
SMJv2 extends the concept table for an aggregate object from a single table to mnltiple tables. This allows fi)r
expansion ofmanaged objects when the number ofcolumnar objects needs to be increased, or when the objects are
best organized by grouping them blerarohically. Let us first cortslder the case of adding columnar objects to an
existing table with ihe 10Ilowing restrictions: (a) the number ofconceptual rows is not affected by the addition; (b)

there is or~e-to-one correspondence between the rows of the two mbles; and (c) tbe INDEX of the second 111ble is
the same as thatofthe fll'st table. This is shown in Figure 6.11.
Flgure 6.1 I. AugmentAtion ofTablrs
TotJel
If1£.1 .CJ. I
I ~
ITI.E1.C~2 IITLE1CU
In.e1.C12 I~ I1U2.eu IIT2.&C52
ITI£ 1.CU
IIl t.£1 C1.J
II li.Ei.CU I~ I)ll2CJ,
IIT2n.C53
IT1.£1.CI.•
IIf t.E1C2..4
II T..ELC34
~~~lll'-CH Il=cs•
'""~: Cor~""*fU.(Q
FI'St...Umnmobjed., T- 1 1. T1.HC11
2. Tl El CIZ
I 11!1 CU
4. f1.!1.C14
Table I is called the aggregate object tableI and has three colunm.s and !bur rows; and. Table 2 is called the
nggregate object1llble2 and bas two colulllllS and four rows. There is a one-to-one correspondence in rows between
the L0 tables. The row object for tableI is tableIEntry, and the row object fOr table 2 is table2Entry. The INDEX
is defined in Table I for both tables and it is the columnar object T I.E.I.Cl . We are lL~ing the notations Tl , El. Cl,
etc., fur easier visual conceptualization ofthe instance of an object in a table using the prefures of table ID (e.g.,
Tl) and e.ntry (e.g.. El). The eolunmar object nomtion starts with C (e.g., Cl). The value or values suffixed with
the columnar object identifier uniquely ideutifies the row. Thus, the· list of objects identified by the index
TJ.El.CI.2 is the ones in the second rows ofTnbles I and 2. The valoo ofthe columnar object T2.E2.C4 in Table
T2 corresponding to index TI.BI.CI.2 is T2.E2.C41. Table I is called the base table, and Table 2 is the
augmented 111ble. The indexing scheme comprises two clauses, the INDEX clalL~ and the AUGMENTS clause,
The constructs for the rows ofthe two tables in Figure·6.11 are shown in Figure 6.12. 1lteobject tnblelEntry has
the INDEX clause and table!2Entry bas the AUGMENTS clause that refers to table! Entry. 11tecombinati:>n ofthe
two tables still provides !bur conceptual rows, Tl.El.C1.1 through T I.E I.C1.4 (ideutified by the index), the same
number ofrows asin the base wble.
Figure6.ll. ASN•.
t ConstrueIs for Augmtnlallon ofTAblts

lablelEnlly 08JECT·TYPE
SYNTAX l (lbleT1Enlry
MltX·ACCESS not.,o<)<}s.ible
STATUS currant
DESCRIPTION "An e mry (con(l!fltual row) in labl~ T1'
INDEX [T1.EI C1)
: =(table! 1)
lable2Enlly 08JECT·TYPE
SYN1AX lableTlEntry
MAX·ACCESS rot·aac:esSble
STATUS current
DESCRIPTION "Art umry (CO!IQIPl1~1 row) Inl;lliltt Tl"
AUGMENTS {lllbleiEJltry)
:• {tablo21)
Figure 6.13 shows an example of augmentorioo of lables. We M>e augmented ipAddrTable in the standard MIB
with a propriemry tabl.e, lpAugAddrTable that could add additional information to the rows of the table.
lpAddrTable is the base table and ipAugAddrTable is theaugmented table. to a practical case, the ipAugAddrTable
could add t:l more columnar objcc1S defining the board and ponnumber associated with the ipAdEntliTndex.
Flguro 6.1
3. Exan11
>1< of A ugn~<nt•llon of Toblts
ipAII<IfTible OBJECT·TYFE
SYNTAX SEOUEI'CEOF lplddtEntrf
Mllli·ACGf:SS noN>a:eSSible
SiAlliS ~urrent
OESCRIP110N 'The lllbla .."
--~plO)
"""""•Erlly OBJ;CT·TVF£
SYNTAX pAd;lt&ity
MAX·ACCESS IIOt-accesstble
STATVS c:u"""t
DESCRIPTION 'Theaddi8SSingln'oonallorf
INJEll {
lpMEJlWl<llj
::=OoAdd<Table 1)
lj)Ao.gAddrTa!>!e
SYNTAX
08JECT
·lYPE
MAX·ACCESS
STATUS
OESCRIP110N
-=ftpAug 1}
SEQUENCE 01' l~..nlly
ool~c
CUfrEnl
'Theaugonenl!d ll!ble b fPAddti!SS Table c!er111ng
- ..no~,.,., """"'""'
lj)Ao.gAddrErtry OBJECT·TYPE
SYNTAX I!)AU'JAMtEnl!y
MAX-ACCESS nol·acx:ei!S>ble
SrAlJS CUtr4;f11
DESCRIPTION 'Th<t~ orlormobon...'
AUGr.£NTS (lpAddtE"try}
": (lpAuoldc!fTallle I)

Atable with a larger number of rows (dense table) can be augmemed to tbe bose Lable with combined indices of
both, as sbown in PigJJre 6.14. The lNDEX c lause for combining unequal-sized tables is the combined indices; te.,
combined columnar objects as the·INDEX clause for the added aggregate object. In Figure 6.14, Table I consists
of two rows and three rolumnar objects, T I.EI.Cl, TI.EI.C2, and Tl.EI.Cl, with the first columnar object
Tl.EI.CI being the index. Table 2 has four rows and two columnar objects, T2.E2.C4 and T2.E2.C5, with its ftrst
columnar object, T2.E2.C4, being the i.odex. The combined index fOr specifYing the aggregate object ofTable 2
appended to Table I is the set of both first columllllr objects, TI.EJ.CJ and T2.E2.C4. Table 1 is called the base
table and Table· 2 is caJJed the dependeD! table. As we see in Figure 6.14, the combined base table and the
dependentiablecould have a maximum of8 conceptual rows ( muHipUcation ofthe rows ofthe two tables).
FlgW't 6.t-l. Combined Indu ing ofTabits
ToO>o 1
1 1U I.CU
.....
Fbi etli.lmnatobt«Ji:tsIn fat.1011 an:f2
~~~IIA»ir~
I. TI.I'I.CI 1,T2.E2.CII
I fl.f l ,C11.TZE:I.CU
J II El Cll.T2~CI.3
< TI.HCI I 'f'2aC4c
5 TI.I'I.CU. T:!.~.Cj I
l T1 Rl C14. r.u::tCAc
FigJJre 6.15 sbows· the coDSiructs for augmenting a dense table to a base table. The two wble objects, t.ablel and
table2, are nodes under the node table. The table! Entry defines a row in table I with the columnar objectT I.EI.C I
as the index. The wble2Eotry is a row in t.able2. lis index is defined by the indicesofboth tables, namely T I.EI.C I
and T2.E2.C3.
fllgu.-. 6.15. ASN.I Constructs tor Augmtnling OtiiSt Tablt

13ble1 OBJECT-TYPE
SY!IITAX SEQUENCE 0Ftanle1Entry
MAX-ACCESS not-aocess1Die
STATUS Cllrrent
DESCRIPTION "Table 1 unde• r
:-: ( !able 11
tableiEnlly OSJECT-TYPE
SY!IITAX Table1i:111ty
MAX-ACCESS not-acoossible
STATUS currem
DESCRIPTION "1n entiY (conceptual row) in Table 1'
INDEX (T1.E1.C1)
:=(table 1 11
lilble2 OBJECT-TYPE
SY!IITAX SEQUENCE OF tahle2Entry
MAX·ACCESS not·accessiblo
STATUS curren1
OESCRJPTION "Table 2 undetr
:=(table 2}
lllble2Entry OBJECT-TYPE
SYNTAX Tu!Jiu2Eulry
MAX-ACCESS not-oaoosslblo
STATUS CtJrrent
OE3CRIPTION 111 1110t1y (WIICCpiulOI I<>W) lh Tllbko 2'
INDEX (TLE1.C1. T2.E2.C4!
:• (lr.llle21}
We can visualize the application ofaugmentation ofa dense table with an example of a router with multiple slots,
each slot con1ainlng a particular type ofboard, fbr example, LEG and Ethernet shown in Figure 4.3(c).The slot and
the board type will be defined in Table L Eacb board may have a different num·ber of physical pons. The port
configuration is defined by Table 2. By u~ing the combination of tbe two tables, we can specifY the demils
associated witha given port ina givenslot.
The third poss'ible scenario in appending an aggregate object to an cllisting aggregate object L~ the case where the
augmented table has fewer row~ lhlin lhril of the base table. This is called a sparse dependent ta.ble case and is
shown in Figure 6.16. In this eliample, tbe inde~ for dte second table is the same as 1hat fOr the base table and tbe
constructs are similar to the ones shown in .Figure 6.12 except that the AUGMENTS clause is substituted w.ith the
lNDEX clause for tllble2Entry. This is shown in Figure 6.17.
Figurt 6.t6. Addition ofu SpUrl< Tobl<Co a Bas< T•bl<

Tallllt 1
IT1.£1.CU
IIfiEIC22
, T1,tt.C13
II II.EtC21
'"""'
F"""''""'"'"oO,odIn To~• t
II n !1.<:32
II rt!tC"
~
1~1 !1E7C31
~
.Till Cit
ll!EICU
)T1EIC11
~. TlEI.Ct,~
Flgur• 6.17.ASN.I Conslrurts for Augwtuting Sparst Toblo
II1'U2CU

SYNTAX SEQUENCE OF table1Ertty
l
lllblg1 OBJECT-TYPE
MAX•ACCESS nct·accessible
STATUS curtenl
DESCRIPTION "Table 1 under T
::={table 1)
WlllelEnll'f OBJECT·TYPE
SYNTAX TEbie1Entry
MAX-ACCESS not-accessible
STAiiS
DESCRIPTION
INDEX
" . (l<lble1 1)
toble2 OBJEC'T TYPE
currem
•Art entry (conoeptuot rOW)1n Tal:>le 1'
{T1.E1 1)
SYNTAX SEQUENCE OF table2Eruy
MAX-ACCESS net-accessible
STJITUS Cl,lfrMI
DESCRIPTION "Table2 underT
::={table 2)
~e2Entry OBJECT-TYI?E
SYNTAX Tshle2Enlr)•
MAX-ACCESS not-accessible
STATUS CIJIT8nl
DESCRIPTION "M llnl'Y (conoeplualrow) •n Table2'
INDEX {table1Enlr)'}
::=(table2 1)
In SNMPv2, operational procedures were inlroduced for the creation and del.eiion of a row in a table. However,
prior to discussing these procedures, let us first look at the textual convention that was specified to create a .new
object type in designingMIB modul.es. We will return to row creation and deletion in Section 63.7.
6.3.6. Te~1ual Conventions
Textual conventions are desigood to help definition ofnew data types following the stniCture defined in SMiv2. tt
is aio;Q intended to make the semantics consisten1 and clear to the human reader. Although new data types could
have been created using new ASN.l class and tag, the decision was made to use the e.x.isting defmed class types
and apply restrk:tioos to them. This Is accomplished by defining an ASN.l macro, TEXTUAL-CONVENTION, in
SMJv2.
The TEXTUAL-CONVENTION macro concisely conveys the syntax and semantics associated with a textual
conven1ion. SNMP-based management objects defined using a tex1ual convemion are encoded by the same Basic
Encoding Rules that define their primitive types. However, they do have the special semantics as defined in the
macro. For all te:ciual convenlions de·fUlcd in an infOrmation module, the name shall be unique and mnemonic,
similar to the data twe and sbaii not exoeed 64 characters. Rowever, it is usually limiled to 32 cbaracters.
Let us now compare the defmition of a type in SMivl with SMiv2. The textual convention wos defmed in
SNMPvl as an ASN.l type ass'igoment. For example, the textual convention for data type DisplayString in
SNMPvl , from RFC 1213, is
DiBplayString :: • OCTET .STRING
-- 'l'hb da ta t ype l.s used r.o 111odel t exto<1l lnformad.on tak.en !rom t he NVT

ASCII charact er set. By convention, obj ect s with this syntax are
declared as 1a.vinq
SIZE /0 •• 255) .
Thesame example ofDisplayStriog in SNMPY2 is defined as:
DisplaySt r.ing : : • TEXTIJAL-<:ONVENTION
DISPLAY- HINT " 255a ''
STATUS current
DESCRl~ICN "Represents textual information taken from tile· NVTASCII character
set, as defined in pages o, 10- 11 of RFC 854..••.•
SYNTAX OCTET STRING (SIZE (0 •• 255) )
As wecan see from the above example, theTEXTIJAL-CONVENTION in SNMPv2 is defined as data type, and is
used to convey the S)ntax nod semantics of a textual convention. The macro for textual conventions is defined in
RFC 1903, and a skeleton ofit is presented in Figure 6.18. It has the definition of type aod value notal'ions wilh the
furmalized definition ofdam typeJ>.
Fll(ure6.18. TEXTIJAL-CONVENTION Motl'o)RFC 1.903)
TEXTIJAL.CONVENllONtAACRO -•
8EGIN
END
TYPE NOTATDN _;
o.spayP<llt
"STATUS" Slalus
1:1£SCRPTION" TO:ld
R4t.~Pan
'SYIITAX' S)ni3X
VALUE NOTATION .•
vlllua (VALUESyn>.a•}
O:sptayPan ,.. 't>lSPU.Y·HNrText Iempty
Sla~s ::; 'W'Jent'l'doprea!BII'I'ollsolele'
All clauses except DisplayPort in the tEXTIJAL-CONVENT10N macro are self-explanatory and represent similar
clauses as in SMJvl. The DISPLAY-HlNT clause, wbicb is optional, gives a hint as to how the va.lue of an
instance ofan object, with the syntax defined using this tel'ttlal convention, might be displayed. It is applicable to
U1e situations where1he underlying primitive type is either INTEGER or OCTET STRING.
For INTEGER type, the display consists of two parts. The first part is a single character denot'ing the display
format: "a" for ASCU, "b'' !Or binary, "d" !Or decimal, "o" for ootaJ, and "x" !Or hexadecimal. It is followed by a
hyphen and an integer in the case of decimal display indicating the number of decimal points. For example, a
hundredths value of1234 with DISPLAY-ffiNT "d-2" is displayed as 12.34.
For OCTET-STRING lype, the display hint consists ofone or more octet-follllllt specifiCations. A briefdescription
ofeach part is shown in Table 6.2. For example, the DISPLAY-HINT "255a" indicates tbat the Displa.yStriog is an
ASCIJ siring ofup to a maximum of255 characters.
T11bl•6.l. DISPLAY-HINT for Octet-FbriWll

1 (Optional) repeat Indicator An Integer, Indicated by •, which specllle$ how many times the remainder of this octet-
format should be repeated
,.,,
Octet length
3 Display fOrmat
One or more decimal digits spedfying the number ofoctets
"b" for binary, "x" for hexadedmal, "d" for decimal, •o• for octal, and •a• for ASCII for
display
4 (Optional) display separator A single character other than a decimal digit or ••• produced after each application of the
Octetspecification.
chara.c:ter
5 (Optional) repeat terminator A single character other than a decimal digit or ••• present If display character is present
Produced after the second and lllrd part.
cnarac:ter
Table 6.3 shows the types IDr which textual conventions were specified in SMJv2. A briefdescription fur each type
is also given. They are applic11ble to all MIB modules. Only those te.xtunl conventions whose status is current are
given in the table. One of the imponant textml conventions is RowStatus, which is used for the creation and
deletion ofconceptual rows, which we will discuss next.
Tablr 6.3.SMlv2 Tutu•t Con.-rntimu for lnitiot1>atu TYI>es
OisplayString Textual Informationfrom NVTASCII characterset [RFC 854)
PbysAddress Media- or physlca~l evel address
MacAddress IEEE 802 MACaddress
TruthValue Boolean value; INTEGER (true (1), false (2))
TestAndincr Integer-valued Information used for atomic operations
AutonomousType An lndepender>tlv extensible type identification value
VarlablePolnter Pointer to a specific objectinstance; e.g.,stscontact.O, iflnOctets.3
RowPolnter Pointer to a conceptual row
Row5tatus Used to manage the creation and deletion of conceptual rows and Is ~d as the value of the SYNTAX
clause for thestatus column of a conceptual row
TimeStamp Value ofsysUpnme atwhich a specific occurrence happened
nmelnterval Period oftime, measured In units ofO.Ol seconds
Oateandnme Date-time specifications

Tablt 6.J. SMJVl Ttxl,..l Convtnlions for lnillol D•••Typts
DlsplayString
StorageType
Tdomaln
Taddress
Textual information from NVTASCII ch;Jracter set (RFC 854]
Implementation information on the memory reaUzatlon of a conceptual row as to the volatillty and
permanency
Kind oftransportservice
Transport service address
6.3.7. Creation aml l>eletion ofRows in Table,,
The creation ofa row and deletion ofa row are significant new featlU'eS in SMIV2. Ibis is patterned after a similar
procedure that was developed fur RMON, which we will cover in Chapter 8. There are two methodsto create a row
in a table. Thefirst i.s to create a row and make it active, which is ava.ilable immediately. The second metbod is to
create the row and make it available at a later time. This means that we need to know the status ofthe row as to its
availability.
The infOrmation on the status oflhe row is accomplished by introducing a new column, culled the status column. ln
Table 6.3. we observe that for the textual convention. RowStatus is used as the vatoe of the SYNTAX clause for
the status column ofaconceptual row. Table 6.4 shows the stiltus with enumerated integer syntax for the sb' sUites
associated with the row status. llle last three Slates, along with ihe first one ( l, 4, 5, and 6), are those that the
manager uses to crcateor delete rows on the agent. The first three states (I, 2, and 3) are dtose that.are used by ihe
agent to send.responses to the manager.
Tobit 6.4. RowStalll< Tu 1ual Connnlfon
State Enumeration Description
active 1 Row existsand Is operational
notlnService 2 Operation on the rO'II Issuspende<l
no!Ready 3 Row does not have all the columnar objects needed
createAndGo 4 This [sa one-step process of creation of a row, Immediately goes lflto the active sUite
createAndWalt 5 Row Is under creatfon and should not be commissioned lnto.servlce
destroy 6 Same as Invalid In EntryStatus. Row should be deleted
The MAX-ACCESS clause is extended to include "read-create"·for the status object, which ioclude.s read, write,
and create privileges, It is a superset of read-write. Ifa status columoar object is present, U1en no other columnar
obje<:t of Lhe same concept:ual row may have a maximal access of "read-write." BID it can have objects wit.h
maximum access ofread-only and not-a.ccessible. Ifan index obje<:t ofa eonoeptual row is also a columnar obje<:t

(it does not always have to be), it is ealled auxiliary object and its ma.ximwn access is made non-accessible. There
could be more lhan one index object 10 define a.conceptual row in a wble.
Let us now analyze the creute and delete operations using the conceptual table shown in Figure 6.19. The table,
table I, originally .has two rows and three columns. The frrst column, status, has the value ofthe status ofthe row as
indicated by the enumerated integer syntax ofRowSmtus textual convention. The second columnar object, index, is
the index fur the conceptuaI row of entryI; and the third columnar object contains non-indexed.data. We wi.ll
illustrate the cwo types ofrow-creation and row-deletion operations by adding a third row and then deleting it
flguro 6.19. Con<tpiual Tab!< for Ihe Crellllon and Oeltllon or. Row
status.2
I I lndelC.2
I I data 2
StaiUS 3
I I oOCIO)x.J
II dalil3
Row to De aeatecl!l:leletecl
As we not~e from Table 6.4, there are tQ states fur RowStatus, orettteAodGo a.nd createAndWait, which are
action operations. tn the former, the manager sends a message to the agent to cre-.lte a row and make the status
active rmmediately. ln ·the latter operation. the manager sends amessage to create a row, but not to make it active
immediately. Figure 6.20 shows the Creat~>and-Go operation. The manager process initiates a Set-Request-PDU to
create aconceptual row wilh the values given for the three columnar instances ofthe row. The value for the index
column is specWed by theVarBind index.= 3. This is suffi.xed to lite other two columnar objeccs in the new row to
be created. The value of status is spocified as 4, wbkh is the creat.eAndGo slate as seen in Table 6.4. The sel-
reqtlfl~·t message nlso specifJes the defuult value De!Data for dauL3, and thus all the infurmation needed to establish
the row and turn it into lUl active state is complete. The agemprocess interacts with the managed entity, creates the
instnnce succes.~fully, and then transmits a respon.'le to the manager process. The value of the slatus is l, which
denotes that the row is in an active stnte. The respon.o;e also comnins the values of dte other columnar object
instances.

S•tRoq""'t
I &1a:us.,.J--.4
irldet.3 -= l. ~
a..""""'
dMa3 = l)ltrtlpti l
1-3•1. --------y
4
---..ndflA.J-=-3,
::lala J =Dd!OatD J
Figure 6.21 presents a scenario for opemtiooal sequeDCe in the creat"
ion of a row using the Create-and-Wait
method. Again, this illustration takes the same scenario ofadding the third row to the table shown in Figure 6.17.
Only the manager and the agent are shown and not Ute managed entity in this figure. The mliJUlger process sends a
Set-Requcst-POU to the agent process. The value for status is 5, which is to create and wait. The third columnar
object expects a defau.lt value, which is not in the set-reques1 message. Hence. the agem process responds with a
status value of 3, which is notReady. The manager sends a get-request to get the data for the row. The agent
responds with ooSuchlnstance message, indicating that the data value is missing. The manager subsequently sends
the value fur data and receives a response of notinServiee (2) from the agent. The fOurth and fu1al exchange of
messages in the figure is to activate the row with a status value of I. With each message received from the
manager, the agent either validates or sets the instance ~alue on the managed entity.
filgun 6.2I. Cru t..aud-Walt Row Crrallou

R..--
.....---lstaiJS.3 • 3;
nii!J..3;l)
r-------_ GotR..,uest
(c:a!a.3) -
t------SeR&Quo$1
(4111lJ.l~l:letD;r.t)--
Rosponse
1'-faM 'lt2
d4L1-J= O!:!DD I
Re.spons4
lllllao.l- I)
5eUieQUetl
( 51D.!Jt.3. 1, _
A summary ofpossible stnte transitioos is given in Table 6.5. llte first column lists the action; and the transitioos
based on the present state are listed in the next four columns.
I. goto B or C.depending on information available tothe agent.
2. If other variable bindings included in the same PDU provide value-s for aJ Icolumns, which are missing but
are required, then return noError and goto D.
3. Ifother variable bindings included in the same PDU provide values for aU columns, whlcb are missing but
are required, then return noErmr and goto C.
4. At the discretion ofthe agent, the return value may be either: inconsistentName: because tbe agent does not
choose to create such an inslltnce when the corresponding RowStatus instance does not exist, or
inconsistentValue: if tbe supplied value is inconsistent with the state of some other MlB object's value, or
noError; because the agentchooses to create the instance.
lfnoError is returned, then the instance ofthe status column must also be created, and.the new state is B or
C, depending on the infurmation available to the agent. If inconsistentName or inconsistem Value is
returned, the row remains in state A.
·s. Depending on the MIB definition for the column/table, either noError or inconslstentValue may be
returned.
NOTE: Other processing ofthe set request may result in a response other than noError being rerumed, e.g,,
wrongValue, ooCreation, etc.

Tablt 6.5. Tablt ofStAir~ fur Row Crt>~lion And Ddttlon
Action A Status column does 8 Status column C Status column 0 Status column
notexist
Set status column to noError-> 0
createAndGo
notReady
Inconsistent-Value
Set status column to noError, see 1 or inconsistent-Vallle
createAndWalt wrongValue·
Setstatus column to act.ille Inconsistent-Value Inconsistent-Value
see 2·>0
Set status column to Inconsistent-Value Inconsistent-Value
notlnServlce see3 ·>C
Set status column to noError->A noError->A
destroy
Set anv other column to see 4 noErrorsee 1
somevalue
notlnServlce active
lnconsls~nt-Val ue Inconsistent-Value
inconsistent-Vallie Inconsistent-Value
or noError ·>O noError ·>0
or noError ·>C noError .>( or
wrongValue
noError->A noError ->A
noError ->C seeS->0
The operation ofdeletion of a row is simple. A set-request with a value of6, which denotes destroy, for status, is
sent by the maDager process to theagent process. independent ofthe current stateofthe row, the row is deleted and
the response sent back by the agent. The instance in the managed entity is deleted in the process. This is shown in
Figure 622.
flgurt 6.22. Row Odtllon
--------setRequest
($181US.3 '6 l
Oiliel! lni!Utnce
fl ..P<M'"" _________
1
_ 1
n$A>e Oelelad
-1 slatus.3 • 6)
6.3.8. Notification Definitions
Managed
&ltity
The trap infonnation in SMJv I has been redefined using the NOTIFICATION-TYPE macro in SMlv2. As we will
see in Section 6.5, the PDU associated with the trap information is made consistent with other PDUs. The

NOTJFICATlON-TYPE macro contains unsolicited infonnation tbat is generated on an eXJleption basis, for
example, when set Lhresbolds are crossed. ll can be transmiued wl1hin eitber a SNMP-Trop-PDU from an agent or
an lnfurmRequest;PDU from a manager. Two examples of a NOTIF!CATION-TYPE macro, drawn &om RFC
1902 and RFC t907 are shown in Figure 6.23. The first e.xrunple, linkUp, is geoeruted by an agent when a link that
has been down comes up.
Figut·r 6.23. ExRmplrs orNOTIFICATION-TYPE ~1o<ro
~nkUp NOTIFlCATlON-TYPE
OBJECTS fdlndelc)
STATUS c;un-ent
DESCRIPTION
•AfiiiUp Wllp~i'iea lhal tic SNMM Mbly, llelwlg in nnagenl
rol<1, n>eognize that ono of 1M oomrnunleal-lin~ "'Pf""nlod In
1ts conf'91'111lo'l has c:oono '4>-.
·•snn"pTI'JPS 4)
cokiSUtn NOTIFtCATION·TYPE
STATUS CUllIIIII
DESCRIPTION
-A coi:ISiatllfiP signifJt$lhllllhe SI>NM erilly, ICb"'J In
an f>VOnl r.>lo, • roi'IIUcn::ing IIJJdl lu::h IMI Ito conf'l)urotlon II
1NII£red •
•;= SIIf'll!TI'ij)S 1)
The OBJECTS clause defines Lhe ordered sequence ofMJB objects, which are included in Lhe notification. II may
or may not be present. The second example, coldS1art, in Figure 623, has Lhe OBJECTS clause missing and is not
needed.
The ower two clauses, STATUS and DESCRIPTION, have Lhe usual mappings.
We have not presented bere diseussions on refined syntax in some· of the macros, as well as exte.nsion to
informational modules. You are referred to RFC 1902 for a treatment ofthese, which also discusses the conversion
ofa managed objecLfrom Lhe OSI to 1he SNMP version.
6.3.9. Con{onn:•ucc Statements
RFC t904 defines SNMPv2 conformanoe statements fur the implementation of-network ·managemem standards. A
product, generully, is considered 10 be in compliance with a panicular Slllndard when it meelS Lhe minimum set of
features in iiS implementation. Minimum requirements lOr SNMPv2 compliance are called module eomp.liancc and
are defined by an ASN.I macro, MOOULE-COMPUANCE. Uspecifies Lhe minimum MlB modules.or a subset of
modules !.hat should be implemented The actual MIB modules '!bat are implemented in an agent are specified by
another ASN.t module, AGENT-CAPABLLITLES. For the convenience ofdefining module compliance and agent
capabilities, objccls and traps have been combined into groups, which are subsets of MlB modules. Object
grouping is defined by an ASN.t macro, OBJECT-GROUP, and Lhe group of traps is defined by Lhe
NOTIFICATION-GROUP macro.
Object Group. The OBJECT-GROUP mncro defmes a group of related objects in aMlB module and is used to
defme confOrmance specifications. 11 is compiled ducing implemenuu:ion, nol at run-time. The macro is shown in
Figure6.24. The implementarion ofan object in an agent implieJ> that it execlfles the get and set operations from a
manager. Lfan agent in SNMPv2 has no! implemented an object, it returns a noSuchObject error message.

Fi~urt 6.24. OBJECT-GROUP Matru
OB.JECT·GROUP NACRO
BEGIN
END
TYPE I'DTAnON ~~
OotoctsPan
'STAlJS"Status
"tlC:SCRIF>TION' Ta•t
Rll!erf'olft
VALUE NOTATION . •
Objo<:bl'~trt :;-
ObjeCis :
Objee~ ·~
StDM> -
Re!erf'an ==
v;tlt.IO tvAWE OBJECT IDENTIFIER)
·oGJC:CTS" ·rcbJcaa1·
Oojed 1Objoc:ts •••Object
valuo tName Objed Name)
•........,nt•l "d<>p,.,cotod' l•oboototc•
•REfEREl'ICE"TelCl Iempty
- u~ l'lfl NIIT ASCII r.hilmc:lfil'!alt
Text "" - Slr.ng-
The OBJECTS c.lause nameseach object contnined in the conformance group. Each of the named objectS 5 defined
in the same informational module as the OBJECT-GROUP macro and has a MAX-ACCESS clause of''accessible-
IOr-notlfy," "read~nly," "read-write," or "read-create." Every object that Is defined in an lnrormationnl module
with a MAX-ACCESS clause other than "not-accessible" is present in at le.a.<rt one objed group. This prevents the
mistnke ofadding an object to an information module, but forgetting to add it to a group.
The STATUS, DESCRIPTION, and REFERENCE clauses have the usual interpretations.
An example of an OBJECT-GROUP, systemGroup in SNMPv2, is shown in Figure 6.25. The sy&em group
defines the objects, wbicb pcrtnin to overaiJ information about the system. Since ~ is so basic, it is implemented in
all agent and management systems. All seven entities defined as values for OBJECTS should be implemented.
lbere are some new entities, such as sysORLastChaoge, in 'the group that were not in SNMPvl. lbese wiU be
addressed when we discuss SMPv2 MJB in the next section.
flgurt 6.ZS. E>llmt>
l<ur ou O'BJECT-CROUP ~locro
systemGrouo OBJECT-GROUP
OBJECTS (sysOoscr. aysObjoctiD. ly&UpTinlll. sysContaGI. s)'SNarn~.
sytlO<>OtiO<'. oy•So,.,leoo, oyoOAln•ICt.a"!Jo. •ys~IO
sysORUp~me. sysORDQ5C)
STATUS CUirenl
DESCRIPTION "ThOSY$tern orouo delnosobloels thai are common
to all man&!)~!!! systems •
,• (anmpMiBOroupa 0)

Notification Group. Tbe notification group contains notification entities, or what was defined as lrapsin SMlvl.
The NOTIFICATION-GROUP macro is shown in Figure 6.26. The macro is compiled during implemenwtioo, not
during run-lime. Tbe value of an invocation of the NOTIFICATION-GROUP macro is tbe name of the group,
which is an OBJECT rDENTIFIER.
Figurt 6.26. NOTI.FICATION-GROUP Mll<'ro
t<OTIFlCATION-GROUP MACRO
f!EGIN
TYPE NOTATION :.=
Nolfica1iofl$?art
·sr"'rus· Statu;
"DESCRIPTION'Tell
Relerf>ar1
VALUE NOTATION .•-
value {VALUEOBJECT IDEIHIFiERl
NObfocatlonsPilrt ..,
NOhiiCiiUCns ; ,.
"NOTIFICAliONS' "rNo~licatloruT
NctfiCaiO!I INO~~CIIllOI'IS ·; NOUrCIIPon
~mitI' (Nnm• NotlfK:.11101'1NtJrllll)
Nollfk:allcn •·•
END
StaiUS ~,.
Relf:lrPMI ,.
·currenr l"depfQCilte<f 1"GtlsO"ete"
"RFFERENCE'" Tutl ~mply
- useslllB NVI ASCII C71GractorSill
To<t ~=- -· atrtng -
An example of NOT!FlCATION-GROUP, snmpBasicNotiftcationsGroup, is shmvn in Figure 6.27. According to
this invocation, lhe confurmance group, snmpBas'icNolif"JCationsOroup, has two IIOtifications: coldStart and
authenticationFailure.
Figure 6.27. Eumplt oh NOTIACAT!Of1-CROUP MMtro
SIYilpi!asrc.'lotrfcabonsGr oup NOIF1CATION-GROUP
"011fiCATIONS [coldS!illl. au1henllea1>0nfaflure}
STATUS c:umml
DESCRIPTION 1he 1W0 nc~ficao011s wll>eh ~n S'IIMP-2 e!lllly IS
requred lO ll'q)le.'llellt..
" : !snrrpM!BGroups7}
Module Compuance. The MODULE-COMPLIANCE macro, shown in Figure 6.28, defme.s the minimum set of
requirements for implementation of one or more MIB modules. The expansion oftbe MODULE-COidPUANCE
macro L~ doneduring lhe implemenmtion a·nd not during run-time. The MODULE-COMPUANCE macro can be
defined as a.component oftbe information module or as a companion module.

Fi~urt 6.28. MODULE-COMPLIANCE M•cro
MODULE·COMFtii...CE MACRO
BEGIN
TVP~ IIIOTATION -.
"STIITUS' SilllUI
'OC:SCrtiPTIO('I' 10'1
Rot..-Pon
ModulePall
VALUE NOTI11
0 N •
~ckld'tu1 :·~
l.lodUioPo1 "•
MOOutot..,.
Modulo .•
voluo (VALUE OBJECT IDENTIFIER)
"CU"tont') "dop!OQ!tod'1"ObiiOIOIO'
-nercntNCE"Teod 1omoty
Medulot Iompty
Medulo I MOCIUIOtMOOJie
• nnmaof medule -
"MODUlE ModuiONomo
Mllt!dowtyPort
Ccrnplton..,P.n
MOOuloNwno -. mCCJuloiHoiOIIIIICOMOU.IIOIOI!Inllllll I..,IPIY
- ntuslMl be empty unli!SJ oartaln..:l rn IAIB modu'o
MoGul<ldontltlor ·" voluu (1.1oduto10 OBJECT IOEI'ITifiER)tumpiY
l""oo~Pon .,. MINOATORV G~OUOS' T Gtoup.1'
Ou>tJ~» ..
Group :•
Com~IIMcaPM .:•
C<>l'l1>11~n«'• ...
Compllonco •
Co«~vll..,.,.a."'"' •
Objotl :.•
IOIIIPty
OtUUIIIOt"'4'll ' O<wp
vD~Jo (OIO<lpOB..ECTIDEUT1Fl!!R)
Co'np41J!nOCIII Of11)1y
C<mpllnnM 1
Cn"'l)ll""""'c:nmnltnnoo
CcrnpltonooGroup 1O~otl
'GROUP" voluo (lion'" OO.CCT I[ICNTirtcn)
'DESCRIPTION" Te•t
'OBJEcr-.luo (N~m• Ol>j8CJIN>ITiej
SyntmxPM
WniOSfllrotPnt1
Aoc01111Pa11
'DESCRIPTION" Text
...,.""._1bee fwfha1ttunt kit ol.l)ol.l'• SYNTAX c:laYM
SynuxPart ::• "SVNTIIX' typo (5YN'fiXl1ompty
- rooII bea ratl<lomontt..- objtc:USYNINC ol~uw
W<ttoS)'nt•l<PM ~ ·wRtTE·SVNTIIX' IYPfl (VI'nt~NTAXII empty
END
Accfl&PM ::~ ' MIN-ACCESS" A:c<IH Iempty
Aeceu ::a "not--.;"H'..CII!:Ssiblc·l "1!0Ce$Sibkt-for naurv~ I
"rQad-only" f ·re:rd-wn:o"l'tolld croa:o·
u-&C3 the NVT ASCII chotOCIOr3Cl
Tm··;-r;trlng-
The STATUS. DESCRIPTION, nnd REFERENCE clnusesareself-explanatory.
The MODULE clause is used to name each module for which compliance requirements are specified. Modules nre
identified by the module name and its OBJECT fDENTl.FIER. The latter can be dropped if the MODULfi.
COMPUANCE is invoked within an MIB module and refers to the encompassing MID module.
Thffe are two CLAUSES of groups that are specified by the MODULE·COMPLlANCE macro. l11ey are
MANDATORY-GROUPS and GROUP. As the name implies, the MANDATORY·CLAUSE modules have to be
implemented for the system "to beSNMPv2 compliant. The groupspecified by the GROUP clause is not mandarory
lOr the MID module, but helps vendors define specificationsofthe features that have been implemented.

When both WRITE-SYNTAX and SYNTAX clauses are present, restrictions are placed on the· syntax for the
object mentioned in the OBJECT cla.use. 1l1esc restrictions are tabulated in Section 9 ofRFC l902.
The snmpBasicCompliance macro is an example of a MODULE-COMPUANCB macro and is part of the
SNMM MlB presented in figure 6.6. A system is defined as SNMPv2 compliant if and only if snmpGroup.
snmpSetGroup, systemGroup, and snmpllasicNotificmionsGroup are impleme.nted. The GROUP,
snmpCommunityGroup, is optional.
Agent Capabilities. The AGENT-CAPABILITIES macro is lengthy and tbe reader is referred to RFC 1904 fur
exact specifications. A skeleton of!he macro and significant points ofthe macro are covered here and.are shown in
Figure6.29.
Figure 6.29. AGENT-CAPABlUTTES M•rro (Skrlrton)
AGENT CAPABILITIES
BEGIN
TYPE NOTATION :::
ENO
'PRODUCT-RELEASE:"Text
'STATUS• Status
'DESCRIPllON" Test
ReferPart
MooulePart
VALUE NOTATION ::=
Status ..,.
ReferP.art :::
ModulePart ::•
Modules :::
Module ;:::
Value (VALUE OBJECT IDENllFIER)
·currenr l'obsdete•
'REFERENCE" Iempty
Modules J-cmp!y
IAO<llle IModulesWodl.te
- name of module -
'SUPPORT ModlJleNomo
'INCLUDES" "{"GroupsT
Vari<ltlonsPart
The AGENT-CAPABILITlES macro for the router example given in Figure 6.10 is shown in .Figure 6.30. Note
that snmpMIB model, which is SNMPv2-MIB. includes system and snmp MIBs. Those MIBs and the associated
groups are supported by IJIC router. Other standard MIBs and groups supported by the router are indicated in Figure
6.30.
Figurr 6.30. ExllmJ>Ir or.n AGENT-CAPABlUTTES ~htcro

routeflsl123 AGENT·CAPABIUTlES
PRODUCT-RELEASE ' fn!oTech Roula' lstRooter123 release 1.0'
STATUS currem
DESCRiPTION ·tn!oTe.."h 1-l-gh Speed Router'
SUPPORTS snmpMIB
INCLUDES {systemGroup. snmpGroup. snmpSetGrouD.
snmpBasiciJobfJCa!lonsGroun)
VARt1TION coldStart
DESCRIPTION
SUPPORTS
INCLUDES
SUPPORTS
INCLUDES
SUPPORTS
INCLUDES
SUPPORTS
INCLUDES
SUPPORTS
INCLUDES
••=I lstRouter 1 )
"A <X!!dSiiln trap Js generateo on au
1ebllots.·
lF-MlB
~rGeneraiGroup. IIPac!<etGroup}
IPMIB
jlpGroup, icmpGroup)
TCP·MIB
~Cr>G<OiJP}
UDP·MIB
{UdpGroup}
EGP-MIB
{egpGroup}
6.4. SNMv2 Management Information Ba.~e
As mentioned in Section 6.2 and shown in Figure 6.5 two new MIB modules, security and SNMPv2, have beeo
added to the lntemet Mill. 11te SNMPv2 module has three submodules: snmpDomain.s. snmpProx;ys, and
snmpModules. snmpDomains extends the SNMP SUUldards to send manageo1ent messages over trnnsmisskln
protoools otherthan UDP, which is the predominant and preferred way of transportation [RFC 1906). Since UDP is
the preferred protocol, systems that use another protocol need a proxy servioe to map on to UDP. Not much work
has been done on snmpProx;ys, as ofnow.
There are changes made to the core MIB-ll defined in SNMPvI. Figure 6.31 presents an overview of lbe changes
to the Internet MID and their relatklnship. 11te system modul'e and the snmp module under mib-2 have significant
changes as defined in RFC 1907. A new module snmpMIB has been defined, which is {snmpModules 1}. There
are two modules under srunpMIB: snmpMlBObjects and snmpMIBConformance.
fllgm.. 6.31 .SNMPvl huun<i CrouJ>

The MIB module snmpMIBObjects addresses the new objects introduced in SNMPV2, as well as those thaJ are
obsolete. This is primarily concerned wiU1 trap. which bas been brought into tbe same format as other PDUs. Also,
manyofr.heunneedcd objects in r.he SNMP group have been made obsolete.
We discussed confOrmance specifications and object groups in the previous section. 1ltese are specified under the
snmpMIBconformance module. As SNMPV2 is currently defined, lhe.re is a strong coupling between ~ystem, snmp,
srunpM1BObjecls, and snmpMIBcouformanoe modules. Witl1 this picture in.mind, k will be a lot easier to fo!k>w
RFC 1907, which discusses all these modules.
6.4.1. Changes to tit£ System Group in SNM J>v2
There are seven entities or objects in SNMPv2, wltich are common to a system. Additional infurmation is added to
the System group in SNMPv2, which comains a collection ofobjects that suppon various Mill modnles. These are
called object resonrces and are configurable both statically and dynamically. Figure 6.32 sbows the Mm tree for
the System group in SNMPV2. l11e sysORLastChaoge entity and sy!'ORTable have been added to the set ofobjects
in r.he System group. Table 6.6 presents tbe entky, OlD, and a briefdeseriplion ofeach entity lilrtbe System group.
Figurr 6.32. SNM.Pvl SySicm Group

Tnblc 6.6. SNMPv2 System Crou1
>
Entity OlD
sysDescr system 1
sysObjectiD system 2
sysUpnme system 3
sysContact system 4
sysName sy~tem 5
syslocatlon 'System 6
sysServices system 7
sysORLastChange system 8
sysORTable system 9
Description (Brief)
Textual description
OBJECTIDENTIFIER of the entity
Time (In hundrecttbs of a second sJnc:e la.st reset)
Contact person for the node
Administrative name ofthe system
Physical location of the node
Value designating the layerservices provided by the entity
Sy$Upllme since last change In state or sysORID change
Table Jrstln,g system resources that the agent controls; manager can configure these
resources through the agent.

TAble 6.6. SN~1PV2 Syst•rn Group
Entity OlD Desaiption (Brief)
sysOREntry sysORTable An entry In the sysORTable
1
sysORindex sysOREntry Row Index, also Index for the table
1
sysORIO svsOREntry 10 ofthe resource module
2
sysORDescr sysOREntry Textual description of the resource module
3
sysORUpTime $VsOREntry System up·tlme since theobject In this row was last instantiated
4
6.4.2. Cltungcs to the SNMP Group in SNMPv2
The SNMP group in SNMPv2 bas been considerably simplified from SNMPvl by eliminating a large number of
entities that were considered unnecessary. The simplified SNMP group is shown in Figure 6.33 (oompnre with
Figure 5.21 !). It has only eight entities, siK old ones (I ,3,4,5.6.,30) and two new ones (31,32). Figure 6.33 also
presems the four groups ofall SNMP cotites: snmpGroup, sompCommunit)'Clroup, snmpObsoleteGroup, and the
group oftwo objects, 7 and 23, not used even in version I. We will soon see that the snmpGroup is mandatory to
implement for compliance of SNMPv2 and the snmpCommunityGroup is optional. The snmpObsoleteGroup is
self-explanatory.
F·lgurt.6.33. SNMPv2 SNMP Crour>
SNMPGroupOb.f<tcu
1.3.8~ t .l2 111,...0-
4.5 IMl!IComo:nm~r Gtcuo
I.U I'QC.,_
25-2:1 Zot·29

The SNMPv2 SNMP group table is shown in Table 6.7. All the unused and obsolete entities have been omitted fur
clarity.
Tabl• 6.7. SNMP12 SNMPGroup
snmplnPkts snmp Total number of messages delivered from transportservloo
(1)
snmplnBadVerslons ~nmp Total number of messagesfrom transport servrce thatare of unsupported version
(3)
snmplnBadCommunltyNames snmp Total number ofmessages from transportservlc,ethat are of unknown community
(4) name
snmplnBadCommunltyUses snmp
(5)
snmplnASNParseErrs snmp
(6)
snmpEnableAulhenTraps snmp
(30)
snmpSilentDrops snmp
(31)
snmpProxyOrops snmp
(32)
Total number of messages from transport service, ofnot allowed operation by the
sending community
Total number ofASN.1 and BER errors
Override optfon to generate authentication failure traps
Total number ofthe five types ofreceived POUs that were sflently dropped due to
exceptionsInvar-blnds or max. messagesize
Total number of lhe five types ofreceived POUs !hat were srlently dropped due to
Inability to respond to a target proxy
(~4.3. lnf'onnntion for Notification in SNM I'v2
fnformation on traps in SNMPvl has been restructured in version 2 to confurm lo ihe rcstofthe POUs. The macro
1RAP-TYPE, used in ve~ion I and described in RFC 1215, bas been made obsolete in SNMPv2. At the same
time, enhancement to specifkations bas been made, and the terminology has been generalized to "notificatioll," as
the subheading indicates.
The infOrmation on notifications is defined under snmpMIBObjects and is shown in Figure 6.34. There are three
modules under the snmpMIBObjects node: snmpTrsp (4), snmpTraps (5), and snmpSct (6). Tile subnode
designations I, 2, and 3 m1der snmpMJBObjects have been made obsole-te. A briefdescription ofthe subnodes and
leafobjects under smnpMIBObjects is given in Table 6.8.
Figur• 6.34. MIB Modulu undtr snmpMIOObjtCI$

~
~
'"'kDotm(l)
Tal>l• 6.8. Jlllllt>MlBObj«lsl118
snmpTrap snmpMIBObjects 4 Informationgroup containing trap 10 and enterprise 10
snmpTrapOID snmpTrap 1 OBJECTIDENTIFIER ofthe notification
snmpTrapEnterprlse snmpTrap 2 OBJECTIDENTIFIER of the enterprise sending the notlftcatloJl
snmpTraps snmpMIBObjects 5 Collection of well-known traps usecllnSNMPYl
coldStart snmpTraps 1 Trap Informing ofa coldstart of the object
warmStart SJlmpTraps 2 Trap Informing ofa warmstart of the object
linkDown snmpTraps 3 Agent detecting a failure of a communication link
linkUp snmpTraps4 Agent detecting coming up ofa communication link
authentilicationFailure snmpTraps 5 Agent reporting receipt of an unauthenticated protocol message
snmpSet snmpMIBObjects 6 Manager-to-Manager notification messaees
SJlmpSetSeriaiNo snmpSetl Advisory lock between managers to coordinate set operation
Tbe snmpTmp group contnins inmrmation on the OBJECT IDENTIFIERs of tbe trap and tbe ente.rprise
respon~ible to send the trap. A new value, accessible-mr-notifY, has been added to the MAX-ACCESS c.lause to
define objects under snmpTrap.

The entities under snmpTraps are the well-known traps that are currently in extensive use in SNMPvI. The
snmpSetSeria!No is a single entity under snmpSer and is used by coordinating manager objects ro perform the set
operation. Tb.is i.s intended as coarse coordination only; fine-grain coordination may require more MlB objects in
apl?ropriate groups.
6.4.4. Conformnnn• fufornmtion in SNMPvZ
Conformance information is defined by the snmpMIBConfurmance module. as shown in Figure 6.35. lt consists of
two submodules, snmpMIBcompliances and snmpMIBGroups. 11te snmpMIBCompliances module bas been
extensively covered.in Section 6.3.9. Units ofconformance are defined in terms of0.BJ£CT-GROUPS, mentioned
in Section 6.3.9. Table 6.9 presents the various OBJECT-GROUPs defined in SNMPv2 and a.<>Sociated OBJECTS
ror all but snmpObsoleteGroup, wllicb is sllown in Figure 6.33.
Frgnrt 6.3S. MIB Modnlu undersnmr>MlBConronnanct
Tabl<6.9.SNMl'•'l OBJECf-GROUPs
OBJECT-GROUPs 010 OBJECTS
snmpSetGroup snmpMIBGroups 5 snmpSetSerfaiNo
systemGroup snmpMIBGroups6 sysDescr
sysObjectiD
sysUpnme
sysContact
sysName
syslocation

TAble 6.9. SN~1PV2 OBJECT-CROUPs
OBJECT-GROUPs 010 OBJECTS
sysServlces
sysORLastChange
sysORID
sysORUpTime
sysORD.esq
snmpBasicNotilication Group snmpMIBGroups 7 coldStart
authentkationFallure
snmpGroup snmpMIBGroups 8 snmplnPkts
snmplnBadVerslons
snmplnASNParseErrs
snmpSilerrtDrops
snmpProxyOrops
snmpEnableAuthenTraps
snmpCommunityGroup snmpMIBGroups 9 snmplnBadCommunltyNames
snmplnBadCommunltyUses
snmpObsoleieGroup snmpMIBGroups 10 Please see Agure 633
6.4.5. Expanded lnlemct M.ffi-0
As SNMP network management expands covering legacy as well as new technology, M1B modules are
continuously increasi·ng. Figure 6.36 shows an expanded Mffi-JI when SNMPv2 was released and has more
modules than those eovered in RFC 1213. It is not intended to be an exhaustive list but includes RMON MIB
module thatwe will be addressing in thistextbook. Table 6.10 gives a description ofeach group in the MIB.
Figurr 6.36. Expandtd lolrrotl Mffi·U Group

~
~
I
'rablt 6.10. E:q>and•d ~118-11 G•·onp
Group
ifMIB
OlD
mib-2
31
appietaik mlb-2
13
ospf
bgp
rmon
bridge
decnet
mib-2
14
mlb-2
lS
mlb-2
16
mib-2
17
mlb-2
18
Description (Brief)
Extension to interf~ces group for new t~hnologies
MIB for appletaik networks
OpenShortest Path First routing protocol MIB
MIB for Border Gateway Protocol for Inter-autonomous networl< routing
MIB for remote monitoring using RMON probe; theA! are MIBs under this for Ethernet and Token Ring
networks
MIBfor bridges
Digital Equipment Corporation DECnet MIB

TAble 6.10. Exr>audtd MIB-U Grourl
Group OlD Description (Brief)
character mlb-2 MIB for portswith character stream outputforcomputer peripheral
19
6.5. SNMI>v2 l'rotocol
SNlviPV2 protooo.l opermions are based on a community administrative model, which is the same ns in SNlv!Pvl.
Tbiswas discussed in Section 5.2.2. We presented SNMPv2 protocol operations from a system architecture.view in
Section 6.2. rn rhis section we will discuss details ofPDU data structures and protocol operalions.
6.5. I. l):un Structun' orsm tl>v2 POUs
The PDU dma structure in SNMPV2 bus been slllndardized to a common format tor all messages. This improves
tJ~e efficiency and performance of message exchange between systems. ll>e significant improvement is bringing
the trap data structure in the same format as the rest. The generic PDU mes.~ge structure is shown in Figure 637
and is the same as Figure 5.8 ofSNMPv I. The PDU cype is indicated by an JNTEGER. The error-s tatus and error·
index fields are eitherset to zero or ignored in the get-request. get-next-request, and set messages. The error-status
is set to zero in the get.-response message ifthere is no error; otherwise the typeoferror is indicated. The PDU and
error-status are listed in Table 6.11. The error-index is set to zero if there is no error. If there ls an error, il
identifies the first variable binding in Lhe variable-binding list that caused the error message. The firs! variable
binding in a request's variable-binding liS! is index one, the second is index two, etc.
F'lgu•·• 6.37. Si'fM'P12 PDll (all but bulk)
Tablt 6.tl, Valuo:s for Typos ofPOU and ErroNIJJtus F'itld.s in SNMPY2 PDU
Field Type Value
POU 0 Get·Request-POU
1 GetNextRequest-PDU
2 Response-POU
Set-Request-PDU
4 obsolete
5 GetBulkRequest-PDU
6 lnformRequest-PDU

Tablt6.ll. Values forTyptsuf PDU and Error-s1•1u3 Flrkls in SN~1PVl PDU
Field Type Value
7 SNMPv2·Trap·PDU
Error Status 0 noError
1 IOOBig
2 noSu<hName
3 badValue
4 readOnly
5 genErr
6 noAccess
7 wrongType
8 wronglength
9 wrongEncoding
10 wronglalue
11 noCreatlon
12 lnconsistentValue
13 resourceUnavarlable
14 commitfailed
15 undoFailed
16 author!zationError
17 no!Writable
18 lnconslsteniName
There is a difference in usage ofthe error-status and error-index fields between SNMPv I and SNMPv2. ln version
I, any error encountered by the agent in responding to requests from lhe manager generates a non-zero value in

either the error-status field or in both the error-status and error-index fields. Values in variable bindings are
returned only under non-error conditions.
However, in SNMM, if only the error-status field of the Response-PDU is non-zero, the value fields of the
variable binding in the variable-binding list are ignored. Ifboth the error-sunus field and the error-iodexfiekl ofthe
Response-PDU are non-zero, then the value of the error-index field is the index of the variable binding (in the
variablo-binding list ofthe corresponding request) for which the request failed. Vahoes in other variable bindings in
the variable-binding list are returned with valid values and processed by the manager.
The generic PDU format is applicable to all SNMPv2 messages e11cept the Get-Bulk-Request PDU, for which ihe
formal is shown in Figure 6.38. It can be seen thai the format of the structure is the same in both cases, Cllcept that
in the get-bulk-request message, the third and rourtb fields are differe.nt. The third field, tb.e error-status field, is
replaced by non-repeatecs; and the tburth field, the error-index field, is replaced by max-repetitions. As we
mentioned in Section 6.2, the get-bulk-request enables us to retrieve da1ll in bulk. We can retrieve a number ofboth
non-repetitive scalar vnJues and repetitive tabular vnlues with a single message. Non-repeaters indicate the number
of non-repetitive field values requested; and the max-repetitions field designates the maximum number of table
rows requested. We will nex't look at the SNMPv2 operations using PDUs.
Figul'tl).38, SNMPvl GotButkRtctuu l PDU
6.5.2. SJ'MJ>v2 Protocol Opemtions
There are seven protocol operations in SNMPv2. as diS<lussed in Section 6.2. We will ignore the report opemtion,
which is not used. The messages, get-request, gel·nfJXt-request, set-request, and get-response. are in botb SNMPvl.
and SNMPv2 versions and operate in a similar fusbion. The two additional messages that are in SNMPv2, which
are not in version I, are the GelBulkRequest and InforrnRequest. The command, get-bulk-request, is an
enhancement ofget-next request and retrieves daia in bulk efficienUy. This is covered in the next subsection. The
lnfonnRequest iscovered inn subsequent section along with SNMPv2-Trap, which has been modified in version 2.
GelBulkRequest PDU Operation. The gel·bulk,request operation is added in SNMPv2 to retrieve bulk dara from a
remote entity. Its greatest benefit is in retrieving multiple rows of data from a table. lbe basic operation of get-
bulk-request is the same as get-next-request. The third and fuurth field positions are used in get-bulk-request
message PDU as non-repeaters and max-repetitions, as shown in Figure 6.38. 111e non-repeaters field indicates the
number of non-repetitive (scalar) objects to be retrieved The max-repetitions field defmes the maximum number
ofinstances to be returned in the response message. This would correspond to the number ofrows in an aggrega1e
object. llte value for the ma.x-repetitions field is operntion-dependent and is determined by such factors as the
mMimum size oftheSNMP message, or the buffer size in implementation, or the c:.x.p.."Cted size of the aggregate
object table.
The data strueture of the response fur the get-bulk-request operation diffecs from other get and set opera!ions.
Successful processing of the get-bulk-request produces variable bindings (larger array of VarBindLi.st) in the
response PDU, which is larger than that contained in the correspondiug request. Thus, there is no one-to-one
relationship between the VarBiodList oft.be request and response messages.
Figure 6.39 shows a conceptual MlB to illustrate tbe operation ofget-next-request nod get-bulk-request shown in
Figure 6.40 and Figure 6.4J. It is similar to Figure 5.12 with two addirional rows added to the t<oble. To notice the
difference in improvement ofget-bulk-request over get-next-request, let us look at Figure 6.40, which shows the

sequence of operations fbr get-next-request for the MIB ~bown in Figure 6.39. The sequeoce starts with a get-
request message from the manager process with a VarBiodList array of two scalar variables A and B. [t is
subsequently followed by the get~nex1-request message with three columnar OBJECT IDEN11FTERS T.E.I, T.E.2,
and T.E.J. The get-response returns the first iruaance values T.E,l..l, T.E.2.1, and T.E.3.1. The sequence of
operation continues until the fourth instance is retrieved. 1l1e last get-next-request message with the OBJECT
l.DENTLFIERS T.E.l.4, T.E.2.4, and T.E.3.4 generates the values T.E.2.1
, T.E.3.1 , lind Z. This is because there ore
no more instances of the table. lt retrieves the three objects, which ·are logically the next lexicographically higber
objects-D8mely T.E.2.1 (next to T.£.1.4~ T.EJ.I (next to T.E.2.4), and Z (next toT.E.3.4). The manager would
stop the sequence at this messuge·. However, if it continues the operation, it would receive a noSuchNnme error
message.
Flg1lrt 6.J9. MIB ror 0 (>eraekm Stqutncts In Figures 6.40 And 6.41
A
Flgurt 6.~0. Gti-Nui-J{equt>l Oil<I'Aiion for ~liB In Figure 6.39

Figurt 6.4t. Gti-Butk-Rtqut>C Optrotion for ~HB tnl'lgurt 6.39
t-----~.......,,
4.&t£: tUl£3)-----
Tf~~~~~-- __.. I .::.
t!U.~'..!J.l,.Tt..U
T-£:t~Tec.J'1T£'.)
Figure 6.41 shows the S<:quence of operations to retrieve !he MlB shown in Figure 6.39 using the get-bulk
message. The entire MlB data are retrieved io two requests. The fust message GetBulkRequest{2, 3, A, B, T.E.I,
T.E.2, T.E.3) is a request for receiving two non-repetitive objects (the first variable (2) in the requesi command)
and three repetitive instances (the second operand (3) in the command) of the columnar objects (T.E.I, T.E.2, and
T.E.3), The response ret·urns values of A and B for the non-repetitive objects. and the first three rows of the
aggregate object table. The second request is for three more rows o fthe mble. Since there is only one more row letl
to send, the response message contains the information in the last row, the oeXJ lexicograpblc entity, Z. and the
error message endOJMibView. The manager i.nterprets this as end ofthe table.
Figure 6.42 shows the retrie•al of tl~e Address Translation table shown in Figure 5.16 using the get-bulk-reque.st
operation. lnsread of four sets of get-next-request and get-response messages, only rwo get-bulk-request and
response message.s are needed in the get-bulk-request operation.
Flgurt 6.42. Gti-Bulk-Rtqurst funltll<

lt~•l~',)',~~~~:~~~.,
~~·~lltn ..••t·~·~
--~..-t'!.....-....-n,w•o..;,.~,,mo~· •
~------ O..l6u•~•~lt,J
•u1AJ..r""'
~l! ltl'IM)tt-----
SNM.Pv2-Trap and lni>rmRequest PDU Operations. The SNMPv2-Trap PbU perfurms the same function as in
version I. As we notice, the name has been changed, as we II as its data strucwre to the generic fonnm shown in
Figure 6.37. llte variablebindinw; in positions I and 2 are specified assysUpTime and snmpTrapOID. as shown in
Figure 6.43. llte dcstination(s) to which a trap is sent is implemenmtlon-dependCnt
Flgurr 6.43. SNMPVl Tn1p POU
A trap is defined by using a NOTIFICATION-TYPE macro. Ifthe macro conmins an OBJECTS c41use, then the
objects defined by the clause are in dte variable bindings in the order defined in the clause. For e,
x.ample, we way
warn to know what interfa,ce is associated w.ith a linkUp trap. ln this case the l.in,kUp NOTlFICATION-TYPE
would bave iflndex as an object in its OBJECTS clause, as shown in Figure 6.44.
Fi~urt 6.44. Example ur "nOBJECTS Clnun in • NOTIFICATION-TYPE Marro
linkUp NOnFICATION·TYPE'
OBJECTS ( lftnde< )
STATUS eurronl
OESCRIPTIOfl "A Rn~~ lrep r.IQttor..,. thetlhD SNSMP'/2 entity,
nefng In tln ~gent rola ti!COgn<U1111AI ono ol111a
"""'""'"lcolon llnlut rcpruonlod In lls c.onfigurauon
ha•comoup•
An lnformRequest PDU L~ generated by a manager (in conlmst to a trap generated by an agent) to infurm another
manager of infonoation in its MIS view. While a trap is received passively by a manager, an l.ofonnRequest
generates a response in the receiving manager 1
0 send to the sending manager.
6.6. Compatibility with SNMPvl

An SNMP proxy server, in general, converlS a set ofnon-SNMP entities into a set ofSNMP-defined MIB entities.
Unfortunately, SNMPv2 MlB is oot backward compatible with SNMPvl and hence requires conversion of
messages. SNMPv2 tETF Working Group ha<~ proposed [RFC 1908] two schemes for migration from SNMPvl to
SNMPv2: bilingual manager and SNMP proxy server.
6.6. 1. Bilingunl Munuger
One of'tbe migration paths to trilnsition to SNMPv2 from version I is to implement both SNMPvl and SNMPv2
Interpreter modules in tbe manager with a database tbat bas profiles oflbe agents' version. The ioh::rpreter modules
do all the conversions of MIB vari<!bles and.SNMP protocol operations in both directions. The bilingual manager
doe.s the common functions needed for a management S)'S!em. the SNMP PDU contains the version number field
to identil)r the version (see Figure 5.5). This an:angement is sbown in Figure 6.45. This is expensive to implement
and maintain. The alternative scheme is to use a proxy server.
Figut.. 6.45. SNMP BilinguAl M•nagtr
Btlingual Manogcr
SNMPv1
6.6.2. SNMJ• l't-uxy Server
The SNMPv2 proxy server configumtion is shown in Figure 6.46. The requests 10 and responses from, as well as
traps from, SNMPv2 agents are processed by the. SNMPv2 manager with oo ehanges. A proxy server is
Implemented as a front-end module to the SNMPv2 manager furcommunicntion with SNMPvlagents.
Figure6.-16. SNMPvl ProJ<y Strvtr Configuration
(
$NMPv2 MRnAQ!i!r
SNMPv1
Agents
Proxy
Sgrvor
)
- (
- SNM?v2
-~

Figure 6.47 details the conversions that are done by an SNMP v2-vl pro~-y server. The get-Request,
GetNextRequest-PDU, and Set-Request-PDU from the SNMPY1 manager are passed through unaltered by the
proJ.-y server. There are two l'l)()difications done to the GetBulkRequest PDU. 1l1e values fur the two fields, non-
repeater$ and max-repetitions, are set to zero and transmiued as GetNexiRequest PDU. The GeiResponse from
SNMPvl is passed through unaltered by the proxy se.
rver to the· SNMPv2 manager, unless a response· has a
tooBigError value. In the exception·case, the coment~rofthe variable-binding field are rel'l)()ved before propagating
·the response. The- trap from the SNMPv I t~gent is prepended with two VarBind fields, sysUpTime.O and
snmpTrapOID.O, with their associated valuesand then passed on to the SNMPv2 manager as SNMPv2-Trap PDU.
f!lgur• 6.4'7.SNMP vl-vt l'roxy S.n-.r
P,q Ttt"''l'!
~Nnf• ...,...oao - - - - -
1 mA~~·~WON•O
]. ~~"=,.,.?"".:'.o.=:"""'"'
....
="'----1
r,~.·lfoM ,ff'l..,..~"""" fYI"'tMf.ni VI!II·lAH•tw'l1of!Oto
hlld 'CI" ""
r'!lfi>4".. Y41UI•fg 1 .,.VJtT•u"O
7 on"'''I.,.OIOD
Summary
A significant number ofnetwork management systems a.nd agents that are on the market today use SNMP version
I, rererred to as SNMPvl. However, some ofthe fet~tures that have been added to SNMPvl have been formally
def111ed in SNMPv2 We havelearned enhancements in SNMPv2 over that ofSNMPv I in this chapter.
The enhancements to SNMP architecture are the fOrmalization of manager-to-manager.communication and tbe
inclusion of tmps as part of the SMT and messages, instead of as an appendix to SMI as in SNMPvl . Three
additimal messages have been added. They are get-bulk-request, infOrm-request, and report. Only get-bulk-request
and infOrm-request detalls have been defined and the report .is left to the implementers of a system. The report is
not used in practice at present.
There are several changes to SMl in SMJv2. Modules are !Qrmally introduced using the MODULE-IDENTITY
macro. An OBJECT-lDENlTIY macro defines the MID objects; and a NOTIFICATION-lYPE macro defines
traps and notifications. SMiv2 has been split into three parts. each being defined in a separate RFC. They are
l'l)()dule definitions, textual conventions, and confonnance specifications. Module definitions specifY the rules for
def111ing new modules. TeKtual conventions help define precise deseriptions ofmodules fur human understanding.
Confurmance specifications are intended to interpret what the vendor is specifying in tbe network component with
regard to compliance wit.h SNMP management. Object groups are introduced to group a number ofrelated entjties.
Confurmance specifications detail the mandatory groups that should be in1plcmentcd to be SNMP conforrnant. The
object groups also help vendors define tbe capabililies of tbe system when they implement additional groups
beyond that ofmandatory ones.

Two new modules have been added to the lnternet module. They are securily and snmpV2. The securilymodule is,
as ofnow, a placebolder in the MIB tree ns no consensus could be reached within the working group in defining it.
h is specified in SNMPv3, which is covered in Chap1er 7. Tbe System and SNMP groups have been modified in
the Internet MIS. Additional objects have been added to ihe System group that suppor1S various MlB modules. A
large number of eDlirics have been made obsolete in the SNMP module. Obsolete emit·ies are de.fined as an
obsolete group in the SNMPv2 module. The SNMPv2 module also defines the MlB definition for compliance
groups. Object groups defining a collectiln of related .entities are defined to specifY vendor compliance a.od
capabilities.
All protocol PDUs, including trap, have been unified into a oommoo data format. The newly introduced get-bulk-
request is intended to improve tbe efficiency ofget-next request in SNMPvl by retrieving data in large quantities.
The gct-n.ex.t-request is still maintained in this version. lnteroperability between management systems bas been
facilitated by a new message, inform-request We have given a conceptual presentation of mble management, as
this has become important when mull.iple management systems try to set configuration on an agent at the same
lime.
The unfortunate part of SNMPv2 is that it is not bac-kward compatible with SNMPvl. Two schemes have been
recommended for migrating from version I to version 2. Proxy server l$ the preferred approach over that of a
bilingual manager. Proxy server can also be de,>eloped for managing non-SNMP agents with an SNMP manager.
Exercises
1. Definethe OBJECT-IDENTITY modulefor the following objects mentioned inExercise 4.11:
a hats
b. jacketQuantity
2. Write tile OBJECT lYPE modules for lpAddrTable, ipAddrEntrv, and lpAdEntlflndex In an IP address translation
table shown In Figure 4.20 lnSMiv2.
3. Add two columnar objects, cardNumber (of Interface card) and portNumber (port·ln the Interface card), to an IP
address table In a router. The Index values for the IP a!ldress table rows are 150.50.51.1, 150.5052.1..
150.5053.1, and 150.50.54.1. The pac~ets to tile fil$t two addresses are directed to port$1 and 2 of interface
card1.The lasttwo addresses refer to ports 1 and 2of interface card 2.
a Draw aconceptual bnse mble and an augmented tabJe.(ipAug I).
b. Present the ASN.I constructs for both down to the leaflevel ofthe MIB tree. Limit your leaffor
ipTable to ipAdEntAddr object.
4. Table 6.12 snows tile output of a networkmanagement system detailing the addresses of a router in a network.
Three columnar objects (Index, IP Address. and Pnyslcal Address) belong to the Address Translation table.
atTable. Treat the other three columns as belonging to an -augmented table, atAugTable (atAug 1). Repeat
Exerc.ises 3(a) and (b) for this case. Use SMiv2 te>rtualconventions.
Tobit 6.11. Tablt ror &~trtl!>t 4
atlflndex intType lntNumber PortNumber IP Address atNetAddress Physlall Address atPhysAddress
3 6 0 2 172.46.41.1 OO:OO:Oc:35f:1:02

4 6 0 3 172.46:42.1 OO:OO:Oc:3S:Cl:D3
5 6 0 4 172.46.43.1. OO:OO:Oc:3S:C1:04
6 6 0 5 172.46.44.1 OO:OO:Oc:3S:C1:05
2 6 0 1 172.46.63.1 OO:OO:Oc:35:C1:D1
1 15 1 0 172.46.165.1 OO:OO:Oc:35:Cl:D8
1 6 0 0 172.46.252.1 OO:OO:Oc:35:C1:DO
5. In Exercise 3, the router Interfaces with subnets are reconfigured as virtuallANs. There Is only one Interface card
with two ports h~ndllng two subnets each. The packets to the two subnets, 150.50.51.1 and 150.50.52.1, are
directed to port 1 of the interface card; and the packetsto 150.50.53.1and 150.50.54.1are connected to port 2.
The secondtable Is the dependent table, lpDepTabie (ipDep 1).
a. Draw a conneptual basetable and a dependent table.
b. Preseni lhe ASN.I constructs for boih down lo ihe leaflevel ofthe MIB tree. Limit your le.af lOr
ipTable to ipAdEntAddrobject.
6. A table is used In a corporation for each branctl to maintain an Inventory oftheir equipment In the <ll!entsystem
located at the branch. The inventory table is maintained remotely from the central location. Items can be added,
deleted, or changed. The objects that make up the table are:
BranchiD (corp 100)
Table name lnvTable
Row name lnvEntry
Columnar object 1 lnVStaws
Columnar object 2 lnvNumber (index)
Columnar object 3 make
Colum.nar object4 model
Columnar object 5 serNumber
a. Draw the inventoryconceptual table.
b. Write the detailed ASN.l constructs for I betable.

7. In Exercise6, the following equipment is to be added as the lOOth inventory number:
make Sun
model UltraS
serNumber 512345
a. Add lhe conceptual row to the lllble in Exercise 6(a).
b. Draw the opera..ional sequence diagram for cre~.e-and-go operation to creme the new row.
8. In Exercise 6, equipment with the Inventory number SO Is no longer In use and Is hence to be deleted. Draw the
operational sequence to delete the conceptual ~ow.
9. Generate an ASN.lOBJEcr-GROUP macro for Address Translation group In SNMPv2 Implementation.
10. Draw request-response messages, as shown In Figure 6.40 and Figure 6.41, to retrieve all columnar objects of
the Address Translation group snown In Table 6.13. Assume that you know the number of rows In the table In
making requests.
a. get-neKt-request and response
b. ge1-bulk-reques1 and response
c. Compare 1he results of(a) and (b)
Tobie 6.13.Tobie for Ei~rrcl..$ 10
Index IP Address PhysicalAddres$
3 172.46.41.1 OO:OO:Oc:35:Q:D2
4 172.46.42.1 OO:OO:Oc:35:0 :D3
5 172;46.43.1 OO:OO:Oc:35:0:D4
6 172.46.44.1 OO:OO:Oc:35:0:D5
2 172.46.63.1 OO:OO:Oc:35:0 :D1
7 172.46.165.1 OO:OO:Oc:.3S:O:D8
1 172.46.252.1 OO:OO:Oc:3S:Cl:DO
11. Fill in the values for the SNMPv2Trap PDU shown In Figure 6.43 for a message sent by the hub shown In Figure
4.2(a) onesecond after it is reset following a failure. (You maywantto compare the result withthat of Exercise 3

In Chapter 5forSNMPvl.)
7. SNMP Management: SNMPv3
Objectives
SNMPv3 reatures
o Documentation architecture
o Formalized SNMP architecture
o Security
SNMP engine ID and name for networkentity
SNMPv3 applications and primitives
SNMP architecture
o Integrates thethree SNMP versions
o Message-processing module
o Dispatcher module
o Future enll!lncement capability
User security mode~ USM
o Derived from userID and password
o Authentication
o Privacy
o Message timeliness
View-based a.ccesscontrol model, VACM
o Configure set ofMIB vie,vs for agent wilh contexts
o Family ofsubtrees in MlB views
o VACM process
SNMP>/2 was released after much rontroversy, as acommunity-based SNMP fi'nlnework, SNMPv2C, wiihout any
enhancement to security. SNMPvJ was subsequently developed to fulfill that need in SNMP management.
Fortunately, SNMPv3 has ended up addressing more than just security. lt is a framework for all three versions of
SNMP. It is designed to aceommodaJe fut:ure development in SNMP management wit.h minimum impact to
existing management entities. Modular architecture and documentation have been proposed to accomplish this
goal.
The latest set of additional documentation [RFC 341Q-3418, 3584] detailing the spe<:ifications of SNMPvJ is
described in the RFCs listed in Table 7.l. They comprise lETF-adopted.stnndards STD 62.
Tobit 7.1. S~~1""J RFC$
RFC 3410 Introduction and Applicability Statements (not SID)
RFC 3411 Architecturefor Describing SNMP Management Frameworks
RFC 3412 Message Processing and Dispatching forSNMP

TRble7.1. SN~1P'3 RFC.•
RFC 3410 Introduction andApplicability Statements (not STO)
RFC 3413 SNMPv3 Applications
RFC 3414 User-based Security Model (USM) forSNMPv3
RFC 3415 vrew-basedAccess Control Model for SNMP
RFC 3416 Version 2 of the Protocol Operations forSNMP
RFC 3417 Transport Mappiogsfor SNMP
RFC341B MIB for SNMP
RFC 3584 SNMPv3 Coexistence and Transition (BCP (Best Current Practires) 74)
RFC 3410 provides 110 overview ofSNMPv3 Framework.
RFC 3411 presents an overview of SNMPvJ. It defines a vocabulary for des..'!'ibing SNMP Management
Frameworks and an architecture fOrdescribing the major portions ofSNMP Management Frameworks.
.RFC 3412 describes message processing and dispalching for SNMP messages. .Procedures are specified fur
processing multiple versions ofSNMP messages to the proper SNMP Message Processing Models (MPMj and for
dispatching packet dala units (PDUs) to SNMP applications. A new MPM fur version 3 is proposed in 'lhis
document.
RFC 3413 defines five types of SNMP applications: command generators, command responders, notificarlon
originators, nolif'x:ntion reoeivers, and proxy fOrwarders. It also defines the Management lnformarion Base (MIB)
modules for specifYing lar'gets ofmaoogement operatlons, for norificaiion ftltering, and for proxy forwarding.
RFC 3414 addresses tbe User-based Security Model (USMj lOr SNMPv3 and specifies tbe procedure for providing
SNMP messa&re level security. M!Bs for remotely monitoring and managing configuration parameters are also
specified.
RFC 3415 is concerned with the Access Control Model that deals with rbe procedure fur controlling access lo
management infunnation. MlB is specified for remotely managing the configuration parameters for the view-based
access control model (1/ACM).
RFC 341.6 defines version 2 syntax and procedures fur sending, receiving, and processing ofSNMP PDUs.
RFC 3417 defmes the transport ofSNMP messages over various prolocols.
RFC 3418 describing Ihe behavior ofan SNMP entity obsoletes RFC 1907 MIB fOr SNMPv2.
.RFC 3584 describes tbe coex.islence of SNMPv3, SNMPv2, nod SNMPv1. Lt also describes how to convert MIB
modules from SMlv1 format to SMlv2 format

7.1. SNM.Pv3 Key Featu res
One of the key features of SNMPv3 is tbe modularization of archJtccture and documentation. The design of the
arcbilecture integrated SNMPvI and SNMPv2 specifications with the newly proposed SNMPv3. This eoables
continued usage of legacy SNMP entities along with SNMPv3 agents and maooger. That is good news as there are
tens of thousands ofSNMPvl and SNMPv2 agents In the field.
An SNMP engine is defined with explicit subsystems that include dispatch and meSlSge-processing functions. It
manages all three versions of·SNMP to coexist in a 11l8113getnent entity. Application services and primitives have
been expllcllly defined In SNMPv3. This rormalizes the various messages that have been in use in the earlier
versions.
Another key feature is the improved security feature. The configuration can be set remotely with secured
Cl)mmunication that protects &gilinst modification of inf'onnation 1111d masquerade by using encryption schemes. It
also tries to ensure against malicious modification of messages by reordering and. time delaying of message
streams, as well as·protects against eavesdropping ofmessages.
The access policy used in SNMPvl and.SNMPv2 is continued and formalized in the access control in SNMPv3,
designated VACM. The SNMP engine defined in the an;hitecture checks whether a specific type of access (read,
write. create, notizy) to a particular object (instnoce) is allowed.
7.2. SNMPv3 Documeot11Cioo Architcclure
The numerous SNMP documents have been organized by IETF to follow a document architecture. llte SNMP
document architecture addresses bow existing documents and new documents could be designed to be autonomous
and, at the same time. be lnt.egrated to describe the ditTerent SNMP frameworks. The representation shown in
Figure 7.1 reflects the contents ofthe specifications, but it is another perllpeclive ofwhat is given in RFC [3410].11
can be oorrelaied with what we presented in Figure 4.4. Two sets ofdocuments are ofgeneral nature. One ofthem
is theset ofdocuments on roadmap, applicability statement, and coexistence and transition.
Agurt 7.t. SNMP Documtnlation (R<'<unllntndtd in SNMPv3)

Tbe otber set ofdocuments, SNMP frameworks, comprises tbe three versions of SNMP. An SNMP framework
represents the integration ofa set of subsySiems and models. A model describes a specific design of a subsystem.
The implementation ofan SNMP entity is based on a specific model based on a specific framework. For example,
a message in an SNMP manager is processed using a specific message processing mode (we will discuss tbese
later) in a specific SNMP3 framework. Tbe SNMP fhlmeworks documenl set is no1 cxplicilly shown in the
pictorial presentation in RFC [2271], as we have done here. RFC [1901) in SNMPv2 and RFC [2271] in SNMPv3
are SNMP framework documents.
Tbe information model and MISs cover StruciJre of Management lnfurmation (SMI), tel<tual conventions, and
confunnance statements, as well as various MlBs. These are covered in STD 16 and STD 1.7 documents along with
SMrv2 documenls [RFC 2578-2580].
Message Handling and PDU Handling sets of documenls address transport mappings, message processing and
d!spatchi!lg, protoool operations, applications, and access control. 1ltese would correspond to 1be SNMP STD IS
documents tuld the draft documents on SNMPv2 [RFC 1905- 1907] shown in Figure 4.9. RFCs [2573-2575]
address these in SNMPv3 .
7.3. A rchitecture
An SNMP management network oonsists of several nodes, each with an SNMP entity. They interect with each
otber 10 moni1
or and manage the network and resources. The architecture of an SNMP entity is defmed as the
elements of an entity and the names associaled with lhem. There are three kinds of naming: naming of entities,
naming of identities, and naming of management informalion. Lei us first look at the elements of an entity,
including its naming.
7.3.1. li:Jcn.enlS ofan E111ity
The elements oftbe architecture associated with an SNMP enlity, shown in Figure 7.2. comprise an SNMP engine
and a set of applications. The SNMP engine, named.snmp.EnginelD. comprises a dispatcher. message processing
subsystem, security subsystem. and an access control subsySiem.
Figurt 7.2.SNMPvJ Arcblloeture
SKr.:P....Iy
r--
-'~·--...-............
EJ~~
s..>a)O- - ~
..
--·§ ~
.... 1
=:1
~ 8 B

SNM'P Engine. As shown in Figure 7.2, an SNMP entity bas one SNMP engine, which is uniquely identified by an
snmpEngineiD. The SNMP engine ID is made up ofoctet strings. The length oflbe ID is 12 octets ror SNMP-vl
and SNMM. and is variable for SNMPv3. This is shown in Figure 7.3. The first rour octets in both foml8ts are set
to the binary equivalent of the agent's SNMP management prii'ate enterprise number. The first bit of the four
octets is set to I ror SNMPv3 and 0 for enrlier versions. For example, if Acme Networks bas been assigned
!enterprises 696}, the fu-st four octet.~ would read ' 800002b8'H in SNMPvJ and ' 000002b8' H in SNMPvl and
SNMP'2.
l'igw·• ; .3. SNMP Englnt 10
SNMPv1 Entoron10 t.lolhod Funl)liof> ot tho Motnod
SNM!¥.1 (Oih 0«01) (IH2 c;)aala)
~==~====~======~
~al lndi<'-Airt
(~!hOOatJ
The ftfth octets for SNMPv I and SNMPv2 indicate the method tll8t 'the enterprise used for deriving the SNMP
engine lD and 6-12 octets function ofthe method. For a simple entity, it could bejust tbe lP address oftheentity.
The fifth octet oftl-.e SNMPv3 engine ID indicateJI the fonn~~t used in the re~t ofthe variable number of octets.
Table 7.2 shows the values ofthe fifth octet for SNMPv3.
Tablt 7.2. SNMPv3 Engint 10 Fortunf(5th O<ttU
0 Reserve<!, unused
1 1Pv4 address (4 octets)
2 tPv6 (16 octets)
lowest non-s~ial IP address
3 MACaddress (6 octets) lowest IEEE MAC address, canonical order
4 Text, administrativelyassigned
Maximum remaining length 27
5 Octets, administratively assigned
Maximum remaining lerigth 27
6-117 Reserve<!, unuse<l

TRblr7.2. SN~1P'3 Enginr iD FOrlllAI (5111 Ocltl)
0 Reserved, unused
128-255 As defined by the enterprises Maximum remaining length 27
06patch Subsystem. There is only one dispatcher in an SNMP engine and it can handle multiple <ersions of
SNMP messages. It does the following three sets of functions. First, it sends messages to and receives messages
.from the network. Second, it determloes tbe version of the message and interacts with ibe corresponding MPM.
Third, it provides an abstract interliloe (described in Section 7.3.3) to St.'MP applications to deliver an incoming
PbU to the local application and to send a PDU from the local application to a remoteentity.
The three sepa.rate functions in the dispalcher subsystem are accomplished using: (1) a transport mapper; (2) a
message dispatcher; and (3) a POU dispatcher. The transport mapper delivers the message over the appropriate
tmnspon protocol of the network. The message dispatcher roures the outgoing and incoming messages 10 the
appropriate module ofthe message processor. Ifa message is received for an SNMP version, which is not handled
by the message processing subsystem, it would be rejected by the message dispatcher. The PDU dispatcher within
an SNMP entity handles the traffic.routing ofPDUs between applications and the Message·Processor Model.
Message Procc.ssing Subsysrcm. The SNMP message prooessing subsystem ofan SNMP engine interacts with the
d.ispatcher to handle version-specifiC SNMP messages. It contains one or more.MPMs. The version is identifted by
1be version field in tbe header.
Security and Access Control Subsysr.ems. The security subsystem provides security services at the message level in
lerrns ofauthemication and privacy protection. The access control subsystem provides access authorization service.
Applications Module-. The applicarion(s) module. is made up of one or more applicruions, which comprise
command generator, notificalion receiver, prolly forwarder, oommand responder, and notificalion originator. The
first three applications are normally associated with an SNMP manager and the last two with an SNMP agent. The
application(s) module may also include other applications, as indicated by tbe box, "Other," in Figure 7.2.
7.3.2. 1
HDICS
Naming of entities, identities, and management information is part of SNMPv3 specifications. We already
mentioned lhe naming of an entity by ir:s SNMP e.ngine 10, snmpEngineTO. Two names are associated with
Identities, principal and securityName. Principal is the 'vho" requesting servlces. It could be a person or an
application. The securityName is a human readable string representing a priocipnl. The principal oould be a single
user; fur ex.ample, name a network manager or a group of users, such as names of operators in the network
operations center. It is made non-accessible. It is hidden and is based on !hesecurity model (SM) used. However, it
is administrar·i•-ely given a security name; fur example, User I or Admin, which is made readable by all.
A management entity can be responsible for more than one managed object. For example, a management agent
associated with a managed object at a give.n node could be managing a neighboring node besi.des its own. Each
objecr is termed context and has a conte.xtEngiociD and a oonte.xtNnme. When there is a one-to-one relatioaship
between the· management entity and tbe managed object, cootext.EnginelO is the same as srunpEnginelD. A
scopedPDU Is a block of data containing a contextEngineiD, a conteld.Name, and a PDU. An example of this
woukl be a swirched hub where a common SNMP agent in rbe bub is accessed m manage the imermces ofthe hub.
The agent would have an snmpEngineiD and each interfuce card would havea context Engine ID.ln contrast, in a
non-switched hub with each interface card. being managed individually, the snmpEngineiD and contextlD are the
same.

7.3.3. Abstract Service Interfaces
The subsystems in an SNMP emil.y communicate with eacb other across an interface, a subsystem providing a
service and the other using the service. We can define a service inlerface between the 1wo. If the interface is
defmed such thai it is generic and independent of specific implementation, it becomes a conceptual interfuce,
termed abstract service interface. These abst~:~~cr services are defined by a set ofprimitives that define the services.
Figure 7.4(a) shows subsystem A sending a request fur service using the primitive primiiiveAB to subsystem B.
The primitiveAB is associated with lbe receiving subsystem B, wb.icb is tb.c one tb.at is providing the service in this
illustration. A primitive has IN and OUT as operands or parameters, which are data values. These are indicated by
a I and a2, and 'bl and b2, respectively. The IN porumelers are input values to the called subsystem from the
subsystem calling for service. The OUT parnmeters m:e the responses expected from the called subsystem to the
caJling subsystem. The OUT parameters are sent unfilled in the message format by the calling system (remember
Get-Request PDU'l) and are returned filled (Get-Response) by the called subsystem. When the calling subsystem
expects a response from the called subsyS1em. there are directed messages in both directions with a two-direetlona.l
arrow coupling the two, as shown in Figure 7.4(a). In this case the primitive primitiveAB is only indicated in the
fur-ward direction. ln addition to returning the OUT parameterS, the called subsystem could also return a value
associated with the .re.suh ofthe request in terms ofstatuslnformation or result, as shown in Figure 7.4(a). Because
ofthe-execution ofprimitiveAB, subsystem B may initiate a requestfor service from another subsystem, subsystem
C, LL~ing prirnitiveBC overtiJC abstract service interface between subsystems Band C.
Flgun 7.4. Abstract Strvict tnttrfocu
-~ 1
-,1
IIO'IIfi...C:I
s..-
"'"''"""
- Olagllldl<lr I
lbl'""'"•<ts-b; ~u...t....tu-....dS'Uu
1 M$.Jtlef
l -1111>11
t -
In general, except for dispaic.l~er, primitives are associated with the receiving subsystem. Dispatcher primitives are
used in receiving messages from and to the applicailin modules, as well as registering and unregislering them, and
in transmitting and receiving messages from the neh~rk.

Figure 7.4(b) shows the example ofthe application. COIDJII3Jld generator. seudmg a request sendPdu (destined for a
remote emit.y) to the dispatcher. The dispatcher, after successful execution of the service reqltested and sending it
on the network, returns to the application sendPduHandle. The sendPduHandle wi 11 be used by the command
generutor to correlate tbe response from the. remote enilty. There are no OUT parameters to be filled in this
primitive except the Status information. a owever, the conunaod generator does expect the status information,
hence the·coupling arrow indicator in the figure. The disp!!loher sends an error indicator instead ofsendPduHandle
for the status infOrmation if tbe sendPdu transaction is a failure. The dispatcher also generates a request to the
MPM, prepareOutgoingMessage. The prepareOutgoingMessage has both IN aod OUT parameters aod hence
infom1ation flows in bod• directions. The numerous fN and OUT parameters aSSociated with primitives are not
identified in the .figure for the sake ofsimplicity.
Table 7.3 lists the primitives served by the dispatcher, message processing subsystem, security, and access control
subsystems. A brief description is presented fOr each primitive on these.rvice provided and the user ofservice.
T ablt 7.3. Lisl of Prirnilivts
Module Primitive Service Provided
Olspa~her senciPdu Processes request from applicatiOntosend a POU to a remote entity
Dispatcher processPdu Processes Incoming message from a remote entity
Dispatcher returnResponsePdu Processes reque.stfrom application tosend a response PDU
Dfspa~her processResponsePdo Processes Incoming response from aremote entity
Dispatcher reglsterContextE~IneiD Registers request from a context engine
Dlspa~her unregisterContextEngineiD Unregisters request from a context engine
Message Processing prepareOutgoingMessage
Model
Processes request from dispatcher to prepare outgoing message to a
remote entity
Message Processing prepareResponseMessage Processes request from dispatcher to prepare outgoing response to a
Model remote entity
Message Processing prepareDataSements
Model
Security Model generateRequestMsg
Security Model processlncomlngMsg
Security Model gererateRespOnseMsg
Processes request from dispatcher to extract data elements from an
lncoml~ message from 'il remote entity
Processes request from message processing model to generate arequest
message
Processes request from message processing model to process security
data In an Incoming message
Processes request from message processing model to generate a
response message
Intra-Security Model authentfcateOull!oingMsg Processes request to authent ication service to authenticate oull!olng

Tablt 7.3. Li!<l ofPrlrnillvts
Module Primitive Servlce Provided
message
Intra-Security Model autnenticatelncomJngMSj! Processes request for authentication scrvlce'to Incorn'lng message
Intra-Security Model encryptData
Intra-Security Model decrypt Data
Access
Model
Control lsAccessAIIowed
7.4. SNMPv3Applicarions
Processes request from security modeI to privacy service to encryptdata
Processes request for privacy service to decrypt an Incoming message
Processes request from application to access and autttorlze service
requested
SNMPvJ formally defines five types ofappllcalions. These are 001 the same as the functional model tbat the OS!
model acldresses. These may be considered as the applkation service elements thai are used to build applications.
They are command generator, command responder, nolif'Jcation odginator, notification receiver, and proxy
fOrwarder. These ate described in RFC 2273.
7.4. 1. C:ommnnd Generator
A command generator application is used to generate get-request, get-next-request, get-bulk, and set-request
messages. The command generntor also processes the response received for the command sent. Typically, tbe
command geoerator application is associated with t.be oetwork manager process.
Figure 7.5 shows the use of the command genemior application using the get-request example. ln the top half of
the figure, the get-request message Is sent after it passes through lite dispatcher, the MPM, and the SM. The
command generator sends the sendPdu primitive to the dispatcher, which requests the MPM to prepare an ougoing
message. The dispatcher also sends a sendPduHandle to the command generator to tmck the request. The detailso.n
the information excba.ngcd between MPM and SM are covered in Section 7.6. The SM is used to generate t'llC
outgoing message, including authentication and privacy pammeters. The dispatcher then sends the message on the
networ.k.
Flgurt i.S. ComnlJind Ctntr•cur At>t>ll<~llon

----souor
The boltom half of Figure 7.5 present~ the role of the Command gencrat·or wben the get-response message is
received &om the remote entity. The dispatcher receives the message from the network and requeSIS MPM to
prepare data clements, which are addressed in Section 7.6. The SM validates r.he authenticity and pri~acy
parameters. llle dispatcher receives the rellrned message from SM and forwards it to the command generator to
-process the response.
An example of the command generator transaction is an SNMPvl get-request ~-ommand from a octwor.k
management sysrem (NMS) to an agent requesting r.he values of System group (see Figure 5.17(a). llle command
generator sends the oommand and OIDs to the disp!llcber along with version number (SNMPv I) and security
information. ll also sends a tracking ID, sendPduHandle, to the NMS. This would be Request ID (=1) shown in
Figure 5.17(a). When the MPM returns the outgoing message., which could be a secUred (authenticated and
encrypted) message, the dispatcher delivers it to the n~1work using user datagram protoool (UDP) to'be £mnsmitted
to the agent. The command generstor receives the response from the dispatcher (asynclU'Onously) sent bytbe·agcot.
The primitive processResponsePdu would deliver the PDU containing the values fOr the System group shown in
Figure 5.l7(b) to tbe command generator. The command generator matches the response PDU received with
Request 1D c I with the onethat vas sent.
7.4.2. Comm>tnd lleSJlonder
A co111mand responder processes the get and set requests destined for it and is received from a legilimat.e non-
aur.horitative remote entity. It performs theappropriate action of get or set on the network element, prepares a get·

response message, and sends it to the remote entity that made tbe request This is shown in Figure 7.6.lo contrast
to Figure 7.5, In which the top and bottom halfprocesses run on two remotc objeds, the top and bottom ofFigure
7.6 belonglo the same object. Typically, the command responder is in the management agenr associated with the
managed object.
l'lgurt 7.6. Comm•nd Rt5t>Ond<r AprJIItoUon
Commend
Respo,der Olspl!cner
ropotoRcsp nooMGg
umRotpomo.Pda
Dl!iP31cher Mene~o
l'roces!lng
Model
Sl!<Jully
Moclol
Before lhe get-request could be procesSed by the command-responder application, lhe conteld that i!Je SNMP
eogine is responsible for must regist·er with the SNMP engine. It does this by using the regist.erConteKI.EngineiD.
Once ~his is in place. the get-request (saRJe example as used in command generator) is received by the dispatol~er,
data elements are prepared by the MPM. security parameters are validated by the SM, and the processPdu is passed
on to the command responder. This set of processes is presented In the top balfofFigure 7.6.
Once tbe request is proce~ by the Comma.nd Responder, it prepares the get-respoose message as shown in the
bottom balf of Figure 7:6. The message is passed to the Dispatcher using the rerumRespoosePdu. The fi.IPM
prepares the response message, the SM performs the security functions. and the Dispatcher eventually transmits the
get-respon~ message.on ibe network.

Continuing the eX3JIIple discussed in Section 7.4.I for the command generator, the dispatcherin the SNMP agent
receives the message. The message is processed by the MPM and the SM and is renUlled to the dispa.tcher.
Assuming that the managed object has registered il~ contel1 engine ID with the dispatcher using
registe.rContextEngineiD, the message. is delivered to the command responder using processPdu. When the
command responder acquires the System group information, it fills the PDU received witll System group object
values shown in Figure 5.17(b). The retumResponsePdu primitive is used by the command genemtor to deliver the
message to the dispatcher. The dispatcher, after processing the get-response message through the MPM and the
SM, transmits it.across the network using UDP protocol
7.4.3. Notification Originator·
The ootifiCSiion originator appUCSiion generates either a trap or an inform message. Its function is somewhat
similar to the command responder, except that it needs to filld out where to send the message and what SNMP
version and security parameters to use. Further; the notification generator must determine the contextEngineiD and
context name ofthe context that bas the information 10 be sent. It obtains these data using newly created MIBs fur
the notifiCSiion group and the target group, as well as using other modules in the system. We will learn about the
new M!Bs defining the new groups in Section 7.5. The notification group contains infOrmation on whether a
notification should be sent to a target and, if so, what filtering shoukl be used on the illformatlon. llte target tbat
the notification should be sent to is obtained from the target group.
7.4.4. Notitic.ation R«civer
The notification receiver application receives SNMP notilication mcs5agcs. It registers with the SNMP engine to
receive these messages, just as the command responder does to receive get and.setmessages.
7.4.5. l' roxy Fonv!u·der
The proxy fOrwarder application perf
orms a function similar to what we discussed in Chapter 6 on the proxy
server. However, the proxy definition has been clearly defined iUJd restricted in SNMPv3 specifications. The term
"proxy'' is used to rerer to a proxy forwarder applicationtbat forwards SNMP re<1uests, notifications, and responses
without regard for what managed objects are contained in those messages. Non-SNMP object translation does not
fall under thL~ category. The proxy forwarder handles fuur types ofmessages: messages generated by the command
generator, command responder, notification generator, and those that comain a repon indicator. The proxy
forwarder uses the translation table in the pfol<}' group MlB created fur this purpose.
7.5. SNMl'v3 Manageme.nl lnfonnalion Ba.
~e
The new objects defined in SNMPY3 follow the te>.'lual convention specified in SNMPv2and described in Section
6.3. Refer to the RFCs listed in Table 7.1 for complete details on managed objects and M!Bs in SNMPv3. We will
address a subset of the MIBs here. Figure 7.7 shows the MIB of the new object groups. They. are nodes under
snmpModules {1.3.6.1.6.3}, shown in Figure 6.3 L There are seven new MIB groups. Tbe snmpFramewo[kMIB,
node 10 under snmpModules, describes the SNMP Management architecture. The MlB group snmpMPDMIB
(node II) identifies objects in message processing and dispatching subsystems.
Flgur• 7.7.SNIIPvJ M1B

There are three groups defined under snmpModules for applications. They nrc snmpTargetMJB (node 12),
snmpNotificationMIB (node 13), and snmpProxyMJB (node 14). The first two are used fur notitiCation ,generator.
The snmpTargetMJB deftnes MIB objects, which are used to remotely configure the parameters used by a remote
SNMP e.ntity. There arc two tables in that MJB, which are ofspecillc interest for us. They arc sbown in Figure 7.8.
The snmpTargetAddrTable, which is in snmpTargetObjects group. contains the addresses to be used in the
generation ofSNMP messages. There are nine columnar objects in the table, which are listed In Table 7.4.
flgurt 7.8.TorgttAddrrs' oud Torgtt P•r•mrtrrTnblu
snmpTargetAddrTable
(2)
snmpTargetMIB
{srmpModules 12}
snmpTargetObjects
(1)
snmpTargetParamsTable
(3)
Tahir 7.4. SNMPTArgtl Add ress T•blt
Entity
snmpTargetAddrTable
snmpTargetAddrEntry
snmpTargetAddrName
snmpTarge!ObjedS 2 Table oftransport addresses
~nmpTargetAddrTable Row In fhetarget acldress table
1
snmpTargetAcldrEntry loe<~llyadmlnlst.ered name assodated wlththls entry

TRble1-'· SN~1P Targot Address Tobk
1
snrnpTargetAddrTOomafn sompTargetAddrEntry Transporttype of1he addn~sses
2
snmpTargetAddrTAddress snmpTargetAddrEntry Transport address
3
snmpTargetAddrllmeOut snmpTargetAddrEntry Reflects the expected maximum ~oun<Hrlp time
4
snmpTargetAddrRetryCount snmpTargetAddrEntry Number ofretries
snmpTargetAddrTagllst
snmpTargetAddrPararns
5
snmpTargetAddrEntry
6
snmpTargetAddrEntry
7
list oftag value~ used toselect the target addresses for a particular
operation
Value that Identifies an entry In thesnmpTargetPararY)S Table
snmpTargetAddr5torageType snmpTargetAddrEntry Storage type for this row
8
snmpTargetAddrRowStatus snmpTargetAddrEntry Status of the raw
9
1'be second rnble in the srunpTnrgetObjects group is tbe snmpTnrgetPoramsTable. Tbe lead into Ihis labte is by
using the columnar object snmpTargetAddrPanuns in 1he snmpTnrge-tAddrTable. This contains the. security
parameters on authentication and privacy. The columnar objects in snmpTargetParamsTable are listed in Table 7.5.
Tablo 75. SNMP Target ParamtltrsTablt
Entity OlD Desalptlon (Brief)
snrnpTargetParamsTable snmpTargetOb)ects 3 Table ofSNMP target lnfonniitlon to be used
snmpTargetParamsEntry snmpTargetParamsTable 1 A set ofSNMP target rnformation
snmpTargetParamsName snmpTargetParamsEntry 1 locally administered name associated with thisentry
snmpTargetParamsMPModel snmpTargetParamsEntry 2 Message process!~ model to be used
snmpTargetPa~amsSecurltyModel snmpTargetParamsEntry 3 Security model to be used

Table 7.5. SN~1P Torgoc Paronwrrs Tab!<
snmpTargetParamsSewrityName snmpTargetParamsEntry 4 Security name ofthe principal
snmpTargetParam~Securrtylevel snmpTargetParamsEntry 5 level ofsecurity
snmpTargetParamsStorageTvpe snmpTargetParamsEntry 6 Storage type for the row
snmpTargetParamsROWStatus snmpTargetParamsEntry 7 Status ofthe row
The s)lmpNoi.if~eationMlB shown in Figure 7.9 deals with Mm objects for the generation of notifications. There
are three tables in this group-namely, the notification mble, the notificmion filter profile table, and thenotificatkln
fllter table. Tbey are under the node snmpNotifYObjects. The SNMP notification table, snmpNotifYJ'able, is used
to select management target.~ that should receive notificatklns, as well as the type of notificati.on to be sent. Table
7.6 shows tbe eolumnarobjeclS inLbe group.
flgurt 7.9. SN~1P Notili..tion Tablr•
Tablr 7.6. SNMP Notirocation Tablr
snmpNotlfvTable snmpNotlfvObjects 1 Ust of targets and notifi,ation types
snmpNotlfyEntry snmpNotifyTable 1 Set ofmanagement targets and thetype of notification
snmpNotlfvName snmpNotifyEntry 1 locally administered name a~oclated with this entry
snmpN.otlfvTag snmpNodfyEntry 2 A single value that Is used to select entries in the snmpTargerAddrTabie

snmpNotlfyType snmpNotlfyEntry 3 Selects trap or inform tosend
snrnpNotlfyStorageType· snmpNotifyEntry 4 Storage type for the row
snmpNotlfyRoWStatus snmpNotlfyEntry 5 Statusofthe row
The notification profile lllble group, snmpNoti.fyProflleTnble, is used to associate a noti.ficnfion filler profile with a
particular set of target parameters. The third group, the notification .filrer table, snmpNotifyFilterTable, colllains
table profiles ofibe targets. 1Jte profile specifies whether a particular target should receive particular information.
The snmpProxyMIB is concerned with objects in o proxy (orwurding application, such as dte SNMPv2 pro~~:y
server shown in Figure 6A6. It contains a table oftranslation parameters used by the proxy forwarder application
for forwarding SNMP messages.
The SNMP USM objects aredefined in snmpUsmMIB module (node 15). Lastly, the objects fbr VACM fbr SNMP
are defmed in the snmpVacmMlB modnle (node 16). We will dlscuss the details of these Ml.Bs later when we
address security in the next section and access control in Section 7.8.
7.6. Secudty
One oftbe main objectives, ifnot the main objective, in developing SNMPv3 is the addition ofsecnrity features to
SNMP manngement. Authentication and privacy of infonnation, as weU as authorization and access colllrols, bave
been addressed in SNMPv3 specifications. We will cover the auUteot·ication and privacy issues in this section and
in Section 7.7. We will deal with access control in 81:ction 7.8.
SNMPv3 arcbiteotnre peimits texibility to use. any protocol fbr at~henticutio.n and privacy of information.
However, the £ETF SNMPv3 working group has specified a USM for its security subsystem. ft is t-ermed user-
based as it follows the t~itional concept of a user, identifi.ed by a use.r nllllle with which to associate security
information. llte working group has specified HMAC-MDS-96 and HMAC-SHA-96 (see Section 7.7.1 ror an
explanation) as the authentication protocols. Cipher Block Chaining tnode of Data Encryption Standard (CBC-
DES) has been adopted for privacy protocol.
We will discuss the general aspects of security associated with the types of dtreaLS, the security modules, the
message data format to acoomrnodate security parameters, and the use and ma11agement ofkeys in this section. We
will specifically address 1bc USM in the nem section.
7.6. 1. Security T hreats
Four types of-threats exist to network management informarion while it is being trao.sported from one management
entity to another. ( I) modification of information, (2) masquerade, (3) message stream modification, and (4)
disclosure. Tbeso are shown in Figure 7.10, where the information is transponed from management entity A to
management entity B. For the ftrst three threliiS, the signal has to be intercepted by an intruder to tamper with it,
whereas fur the disclosure tbreat, the signal canjust be tapped and not intercepted.
Flgur• 7.t0. S.CurltyThrealS tolboag<m<oi Jufonnatioo

ModifiCOIM ol lnfmmtion
Maflql!lltade
M(assagt!Stroam M
DdincaliOn
MNUt~m.ont t.'-"""!1""""'1
EnliWA En1il)'8
l
I DlllidUIIUJI
I
Modification of information is the threat thar some unauthorized user may modifY the contents of the message
while il is in transit. Data contents are modified, including falsifYing the value of an object. h does not include
cbanging the originating or destination address. The modified message is received by entity B. whlch is unaware
that it bas been modilled. For example, the response by an SNMP agent to a request by an SNMP manager could
be alte,red by this threat.
Masquerodc is when an unauthorized user sends information to another assuming the identity ofan authorized user.
This can be done by changing tbe originating address. Using lbe masquerade and modification of information, an
unauthorized user can perform operarioo on a management entity, whicb he or she is not permiued to do. The
SNMP set operation should be protected against Ulis attack.
The SNMP communicatio.n uses connectionless transpon service, such as UDP. This means that the message could
be fragmented into packets with eacb packet taking a different path. The packets could arrive m the destination out
of sequence and have to be reordered. The threat here is that the intruder may manipulate the message stream
(message stream modification) and maliciously reorder thedata packets to c.hange the meaning ofihe message.. For
example, tbe sequence ofdalll of a table cou.k! be reordered to change the values in the lllble. Tbe .intruder could
also delay messages so that those messages arrive out ofseq..eoce. The message could be interrupted, s10red, aod
replayed at a later time by an unauthorized nser.
The .fourth and last threat t:bat is shown in figure 7.10 is disclosure of management infOrmation. 11te message need
not be intercepted for this, but just eaveSdropped. For example, the message stream of accounting could be
promiscuous.ly monitored by an employee with a TCP/IPdump procedure, and iheo tbe information could be used
lll!flinst lbe establishment.
There are at least two more.threats that would be considered as threats in t'rtldilional data communicat·ioo, but the
SNMP SM has classified them as being non-threats. The first is denial of service, when an authoriz.ed user is
den.ied service by a management entity. This is considered as not being a threat, as a network tililure could cause
such a denial. It is the responsibility ofthe protocol to address this Issue. The second threat thar is not considered a
management Utreat is traffic analysis by an unauthorized user. It was determined by the 1ETP SNMPv3 working
group that there is no significant advantage achieved by protectingagainst this attack.
7.6.2. Security Model

ln normal opemtional procedures, the MPM in the message processing subsystem interacts with security subsystem
models. For example, in Figure 7.2, an outgoingmessage is generated by an applical'ion, which is fJISt handled by a
dispmcher subsystem, then by an MPM, and finally by ·the SM. If the message is to be authenticated, the SM
authenticates it nod fonvnr$ it to the MPM. Similarly for an incoming message, the MPM requests the service of
the security subsystem to authenticate the user ID. Figure 7.11 shows the services provided by the three modules in
the security subsystem to U1e MPM. They are the authentication module, the privacy module, nod the timeliness
module.
Flgur< 7.t l. S~urity Servi«J
r- ~~=-=JL__-
_
-
_
·_
::
__...J
Authoritative SNMP Engine. When two management entities communicate, the services provided by each are
determined by the role they play. i.e.. whether the entity is authorized to perf
orm the service. This led to the
concept ofmrthoritative and non-authoritative SNMP engines. This is depe.ndent on which SNMP engine controls
the communication between the two entities. SNMPv3 architecture defines that in a communication between two
SNMP eng ines, one acts as an authoritative engine and the other as a non-authoritative eng ine. There is a well-
defined set of rules as10 who is the authoritative SNMP engine for each message that is communicated between
two SNMP eugines. For get-request, get-next-request, get-bulk-request, set-request or infurm messages, the
receiver of the message is the aut.horiuuive SNMP engine. Since these messages are originated by a manager
process in a network management system (NMS), the receiver is the SNMP agent. Thus, the agent is the
authoritative SNMP engine. For trap, get-response. and report messages, the sender or the agent is the authoritative
SNMP engine. Thus, an SNMP engine that acts in the role of an agerrt ls the designated authoritative SNMP
engine. The SNMP engine that acts in the role ofa manager is the non-authorirntive engine. 1n general, an SNMP
agent is the authoritative SNMP engine in SNMP communication.
An authorillitive SNMP engine is respons'ible for the accuracy ofthe time-stamp and n unique SNMP engine 10 in
each message. This requires that cwery non-authoritative SNMP engine keep a table oflhetimeand authoritative
engine ID ofevery SNMP engine that it communicatc:s with.
Security Authentication. Communication between two errtities could satisfY the condition otauthoritative and non-
authoritalive pair. However, itshould be the right set ofpairs. Thus, the source from which the message is received
should be authemicated by the receiver. FurU1er. authentication is needed lbr the security reasons discussed in
Section 7.6. L Securily authentication is done by the authentication module in the security subsystem.

The authentication module provides 1wo services, data integrity and data origin authentication. The dalll integrity
service provides the function of anthe01icating a message 111 the originating end and validating it lll the receivi.ng
end. ensuring thai it has not been modified in the communicalion prooess by an unauthorized intruder.
Authentication validation al9o catches any non-malicious modifica1ion of data in the communication channel. The
authentical.ion scheme uses aulhem.icalion prolocols, such as HMAC-MDS-96 or HMAC-SBA-96 in SNMPv3 or
any other protocol in place of iL
The second service tbal is provided by the authemication module is data origin authentication. This ensures thai the
cla.imed identity of the user on whose behalf the message was sent is truly the originator of the message. llle
authentication moduleappends to each message a.unique identifier associated with an authorilative SNMP engine,
Privncy ofrnformation. Tb.e second module in the security subsystem in Figure 7.11 is the privacy module, which
provides data confxlentiality service. Data confidentiality en.sures that information is not made avai·lable or
disclosed to unauthorized users, entities, or processes. The privacy of1he message is accomplished by encrypting
the message at the sending end and decrypting i1 at the receiving end.
Timeliness of Message. The timeliness module is the third module in the security subsystem and provides tbc
fimction of checking message timelin.ess and thus prevents message redirection, delay, and replay. Using the
concept ofan authoritative SNMP engine, a window oft.ime is set in lhe receiver to accept a message. Tbc travel
time between the sender and the receiver should be within this time window interval. The Lime clock i.n both the
sender and the receiver is synchronized to the authoritative SNMP engine. The recommended value for the window
time in SNMPv3 is 150 seconds.
For implementation of 1he timeliness module, lhe SNMP engine maintains three objects: snmpEngineiD,
snmpEngioeBools, and snmpEngineTime. The snmpEnginelD uniquely identifies the authoritative SNMP engine.
The snmpEngineBoots is a count of the munber of times the SNMP engine has re-booted or ro-irtitialized since
snmpEngineiD was last configured. The snmpEngineTime is the number of seconds since the snrnpEngineBoots
coumer was lasl initialized or reset.
The timeliness module also checks the message lD ofa response with the request message and drops the message
if they do ooi match.
We will next look at the message formal in SNMPv3 in general, and the security parame1ers contained in it in
panicular'
7.6.3. Message Fomuu
The SNMPv3 message format Is shown in Figure 7.12. It oonsis1s of four groups of data. Details of the fieIds ln
each group except security parameters are given in Table 7.7. The first group is a single field, which is the version
number and is in the same position as in SNMPv1and SNMPv2.
Frguo't 7.12.SNMPvJ 1frSSA!:f Fornllll

Tobit 7.7.SNMP••3 Jfr55ago Form•l
Field
Version
Message 10
Message flags
Message·se(Urtty model
Se(urtty parameters
Table 7.8)
Plaintext/encrypted
scopedPOU data
Context engine 10
Context name
POU
Object Name
mseVerslon
msgiD
msgMaXSfze
msgflags
msgSecurttyModel
Description
SNMPversion number of the message fonnat
AdminlstraUve 10 assodated with the message
Bit fields Identifying repon, authentication: <1nd privacy of the
message
Security model used for the·message: concurrent multiple models
allowed
(See msgSecurttyParameters Security parameters used for communication between sending
and rea!lvlng security modules
scopedPduOata
contextEngineiO
contextName
data
Choice ofplaintext cir encrypted scopedPOU; scopedPOU uniquely
identifies contextand POU
Unique 10 of a context (managed entity) with a context name
realized by an SNMP entity ·
Name ofthe context (managed entity)
Contains unencrypted POU
Global (header) data defined by the data type header are the second group of data in the message fom1at. They
contain administrative parameters of the message. which are message ID, message max.im.um size, message flag,
and message SM. It is worth noting thai an SNMP engine can handle many models coocurrently In d1e message
processing subsystem. The dispatcher subsystem examines the version number in the message and sends ii to the·

appropriate message processing module in tbe message subsystem. For example, ifthe version is set to snmp12, the
SNMP12 message processing module would be invokod.
The third group of data, security pammeter fields, are used by the SM in communicating between sending and
receiving entities. The values ofthe pammeters depend on the message SM seL in the header data. 1be pammeters
are shown in Figpre 7.12 and will be discussed in Section7.7.
lbe fuurth and final group of fields in the whole message record shown in Figure 7.12 i.s the plaime.x11enorypted
seopedPDU data. The scopedPduData field conlains either uneo¢rypted or encrypted seopedPDU. If ihe privacy
flag is set to zero (no priva.cy) in themessage flag (see header data), !hen this field conlllins plaintext seopedPDU,
which is unencrypted scopedPDU. The plaimext scopedPDU comprises the context engine ID, context name. and
the PDU. A management entity can be responsible for muhiple instances of managed objects. For e.xample. in an
A1M switch, a sing.le managed entity acts as the agent for all I he network lntertilce cards in all its ports. We could
!real each lolerlilce card as 8 context with a context engineID and a context name. Thus. 8 partJcular context name,
in conjunction with a particularcontextengine ID, identifies the particular context associated with the management
infi.)rmation contained in the PDU portion ofthe message. 1be object name for PDU is dam.
7.7. SNI'[Pv3 User-B11sed Security Model
The security subsystem for SNMPv3 is a USM, which is based on the traditional user name concept. Just as we
have defined abstmct service interfaces between various subsystems in an SNMP entity, we can define abstmct
service interfaces in USM. 1b ey define cooceptual inter.fuces between generic USM services and self-<:ontaioed
autbentieation and privacy services. There are two primitives ossoeiated with authentication service, one to
genemte an omgoing amhenticated message (authemlcateOutgoingMsg) and another to val idnt.e the authenticated
incoming mess<~ge (authemicatelocomingMsg). Similarly, there are two primitives associated with privacy
services, encryptData and decryptDtlla, for tbe encryption of outgoing messages and tbe deeryplion of incoming
messages. These wereincluded in the list ofprimitives in Table 7.3.
Services provided by authentlcailin 11nd privacy modules in lbe secur.
ity subsystem for outgoing and incoming
messages are shown in Figures 7.13 and 7.14, respectively. Looking at the ovemll picture, the MPM invokes lbe
USM in the security subsystem. The USM in torn invokes, based on the security level set in the message, ihe
autbentioatioo and privacy modules. Results are returned 10 the MP"M by the USM.
Figun 7.1J. Privltcy Dnd Authruticotdon Service for an Oucgoing Mt..s~.a~
Flgur• 7.14. Prlv•cy• nd A1
rt.IJtnli<allon S.rvk t for an Incoming l1t5Sigt

ln Figure 7.13 that shows the process ofWl outgoing message, we willassume that both privacy and autheoticatioo
flags are set in the message flag in the header data. The MPM inputs the MPM information, header data, security
data, and scopedPDU to the security subsystem. The USM invokes the privacy module first, providing the
encryption key and scopedPDU as inpuL The privacy module outputs privacy parameters that are sent as part ofthe
message and the e.ncrypted scopedPDU. The USM passes the unauthe.nticated whol.e message with e.ncrypted
scopedPDU to the authentication module along with.the authentication l.tey. The authentication module returns the·
autbenrk:ated whole message to OSM. The security subsystem returns lhe authenticated and encrypted whole
message along with the mcs5age length and security parameters to the MPM.
Figure 7.14 shows the reve.rse process of an incoming message going through the authentication validation first,
and then decryption ofthe·message by the privacy module.
The security parameters use.d in the SM are shown in Figure 7.12. Table 7.8 lists the parameters and the
correspondi.Qg SNMPvJ MlB objects. The position of the rel.evant MlB objects associated with the security
parameters belongs to the two moduJc.s, snmpFramesworkMIB and snmpOsmMffi, under snmpModulesMIB
shown in Figure 7.7. The details ofthe position ofthe objects in the MIB are presented in Figure 7.15.
Figu•·• 7.15. SNMPv3 MIB Obj<tU for St•urlty Par•nlfl~r.S

Tobit 7.8. St~orlry l'lli'Amtlt~ond Correspcmdlng MID Obj«IS
Security Parameters USM User Group Objects
msgAuthoritativeEngineiD snmpEngineiD (undersnmpEngine Group)
msgAuthoritativeEngineBoots snmpEngineBoot.s(undersnmpEngine Group)
msgAuthorltatlveEnglnenme snmpEnglnenme (undersnmpEnglne Group)
msgUserName usmUserName (In usmUserTable)
msgAuthentkatlonParameters usmUserAuthProtocol (In usmUserTable)
msgPrivacyParameters usmUserPrlvProtorol (In usmUserTable)
We have already discussed the fD'st tllroo parameters in Table 7.8 associated with engine-TD, number of booiS, and
time since the last boot. They are in the snmpEngine group shown in Figure 7.15. The last three pru:ameters in the
Ulble are in usmUserTable in the usmUser group shown in Figure 7.15.
The fuurth parameter is tho user (principal) on whose behalftho message is being exchanged. The authentication
parameters are defined by the authenti:ation protocol columnar object in the usmUserTable. 1l1e tiSmUserTable
describes the users configured in the SNMP engine and the authentication parnmeters the type of authentication
protooolused. Likewise, th.e privacy parameters describe the type ofprivacy protocol used.
The usmUserSpinLock is an advisory lock that.is used by SNMP command generator applications to ooordinate
their use ofthe sel operation in creating or modifying secrets in usmUserTable.
Now that we have a broad picture, let us return ro Figure 7.13 and follow through the detailed data flow and
processes involved in the USM. Figure 7.13 shows the operation for an outgoing message, which could be either a
Reques1 message or a Response message. The MPM inputs infOrmation on the me-
ssage processing mode-
llo be
used (normally SNMP ve-rsion number), leader dilta, security data (SM, SNMP engine ID, security name, and
security level) and scopedPDU 10 the Security Sub~ystem (SS). This infOrmation is received by ·the User-base
Security Model (UCM) inSS.
In the USM, the security-level settings for privacy and authentication determine the modules invoked. The
encryption key and scopedPOU (corutlXt engine TO, context name, and PDU) are fed iniO the privacy module,
which encrypts the PDU and returns the encrypted PDU along with privacy pammeters to the caUing module,
USM.
The USM then communicates w~.h the auU1entication module.The USM inputs the encrypted whole message along
with the authent'iciltioo key. The autbenticat.ioo module returns U1e authenticated whole message to USM. The
USM passes the authenticated and encrypted whole message, whole message length, and securities parameters
backto the MPM.
The opcralion !Or an incoming message is shown in Figure 7.14. [npulS 1
0 the security subsystem are the MPM
information, he-<ider data, security parameters fur the received message, and the whole message. The output ofihe
security subs)!Stem is scopedPDU in plaintext funnat.

Within r.hesecurity subsystem, r.he opemtioooJ sequence ofaur.heotication and privacy fur an incoming message are
reversed from r.hm of the outgoing message. The message is flfst sent to the authentication module with r.he
authentication key, the whole message received from the network, and authentication parameters received from the
network as inputs. It outputs an aur.henticat.ed whole message to the calling module in USM. The USM the.n feeds
the decrypt key, privacy pammcters, and the cnctypted scopedPDU and receives in return the decrypted
scopedPDU. The decrypted scopedPDU is then pas:>ed on to the message processing module.
7.7J. Authentication Protocols
The secret to secnrity usfng the authentication and privacy schemes iS the secret key that is shared between the
sender and the user. There is a secret key for amhenticatiQn and a secret key for encryption and decryption. The
secret key for the· Usc..Y-based Secnrity Module (USM) is developed from the user password. Two algorithms are
recommended in SNMPv3 fur devek>plng the k·ey from the password. lltey are HMAC-MDS-96 and HMAC-
SHA-96. l11e first letter in the designation s1ands fur the cryptographic hash function (H) used fur geoerati11g the
Message Access Code (MAC). The second part in the designation is r.he bashing algorillim used, the fuSI one beillg
the MDS hashing algorithm, and the second one the SHA-1 hashing algorithm to generate MAC. The MAC is
derived by truncating the bashing code generated to 96 bits as indicated by the last set of characters i.n the
designatbn.
Authentication Key. The authe.ntication key, the secret key for authentication, is derived !Tom a chosen password
ofthe user. The user in onr case is the non-authoritative SNMP engine, which is generally an NMS. l.n both MD5
and SBA-1 algoriihms, tbe password is repeated until it fon:ns exactly a siring of220
octets (1,048,576 octets),
truncating tbe last repetiHoo, if necessary. This rcsuh. is called digestO [Stallings, 1998]. In the second step, tbe
digestO is hashed using either the MDS or the SHA-1 algorithm to derive digest I. MD5 algorithm yields a 16-octet
cligestl, and SHA-1 results in a 20-octet digestJ. A second string is furmed by concatenating the authoritative
SNMP engine lD and digestI. This string is fed into the respective hashing algorithm to derive digest2. The
derived digest2 is the user's authentication key. authKey, which is input to the authentication modules shown in
Figures 7.13 and 7.14. You are referred to RFC [2104] and Stallings [1998) for details on MD5 and SHA-1
algorithms.
The choice between tbe 16-octet MDS-based authKey and the 20-octet SHA-1-based aurhKey is based on the
Implementation. In tbe 20-octet key, it is harder to break the code than in the l(i-octct key. However, the
processing is fa~ter with the 16-octet key. Fnrther, the same 16-octet key derived from the same password could be
used for the privacy key.•aJthougll it is recommended that the same key not be used for both.
HMAC Procedure. The 96-bit. bog code MAC is derived using the HMAC procedure described in RFC 2104 and
RFC 2274. First, iwo functions Kl and K1 are derived using authKey obtained above, and two fixed but differenl
strings, ipad and opad, as defined in the foUowing manner. A 64-byte exiendedAuihKcy is de.rived 'by
supplementing auUtKeywith zeros.
ipad = r.he bexadecimaJ byte Ox36 (00 II0110) repeated 64 times
opad =the hexadecimal byte OxSc (0 IOJ II00) repeated 64 tlmes
K I = extendedAuthKey XOR ipad
K2 = extendedAutllKey XOR opad
HMAC is computed by performing the following nested bashing functions on Kl. 10, and wholeMsg. which is the
unauthenticated whole messageshown in Figure 7. 13:
H(K2,H(Kl, wboleMsg))

The fust 12 oc1
e1S of this final digest are the MAC. These are the authentication pamme1ers,
msgAuthenticationParamete.rs, which are shown in Figure 7.L2 and are included ns part ofthe authenticated whole
message, authenticatedWholeMsg shown in Figure 7.13.
Key Managemenl. A user (NMS) bas only one password and hence one secre1 key digestt mentioned in the
authenlieation key discussion earlier. However, it communicates with all the authorit!llive SNMP ·engines (all the
agents in the network). The shared information is again a secret between the two comnwnicating engines. The
concept ofa locaLized key is introduced ro accomplish this instead of storinga sepamte password for each pair of
communicating engines. A hash function, which is the same hashing function that is used t.o geoemte the secret
key, is employed to generate !he localized .key.
Localized key = H (secret, autboritativeSnmpEngineiD, secret)
where secret is the secret key (digest I) and !he authoritativeSnmpEngineiD is the SNMP engine ro of the
authorit11live SNMP engine with which the local user is co mmunicating. This localized key, differe.nt for each
atnhoritative engine, is stored in each aulhoritative engine wiH1 which the user communicates. Notice !hat the
localized key is the same as authKey.
SNMPv3 permits !he operation ofchanges and modification in a key, but not the creation ofkeys to ensure that !he
secret key does not become stale.
Discove.ry. One important function of an NMS as a user is the discovery or agents in the· network. This is
accomplished by generating a Request message with a security level of no-authentication and no-privacy, a user
name of "initial," an au1horitative SNMP eogioe ro of uro length, and a varBind llst that is empty. The
authoritative engine.s respond with Response messages containing the engine ID and !he security parameters filled
in. Additional information is then obtained via pair-wise communication messages.
7.7.2. E ncryptwn Protocol
The encryption generates non-readable cipherteKt from a readable tex:t, plaintext. The SNMPv3 recommendation
for data confidentiality is to use the CBC-DES Symmetric Encryption Protocol. The USM specffications require
the scopedPDU portion ofthe message be encrypted. A secretvalue in combination wit.h a timeliness value is used
to create !he encryplionldecryption key and initialization vector (IV). Again, the secret value is user-based, and
hence is associated l)'pically with an NMS, The 16-octet priv.acy key, privKey, is generated from the password as
described in the generation ofauthentication code using MD-S hashing algorithm.
The first eight octets ofthe 16-odet privacy key are used 1
0 create the DES key. The DES key is only 56 bits lo11g
and henee t.he least significant bit ofeach octet in the privacy key is di.searded. The 16-octet IV is made up oftwo
parts, an 8-octet pre-IV concatenated with an 8-octet salt. The pre-1V 5 the last eight octets of!he privacy key. The
sak is added to ensure that two identical instances of ciphertel<i are not generated from two different plaintexts
uslng the same key. The salt is generated by an SNMP engine by concatenating a 4-octet snmpEngineBoots with a
locally generated integer. The saltis the privacy panimeter shown in Figures 7.12. 7.13, and 7.14.
The encryption process first divides the plaintext ofscopcd.PDU into 64-bit blocks. The pJainteltl of each block is
XOR-eel with ·me ciphertex't ofthe previous bJoc.k, and the result is encrypted to produce a ciphertex't for the current
block. For the first block, the IV is used instead ofthe ciphertext ofthe previous block.
7.8. Access Control
We. have covered security considerations in network management with regard to data integrity, message
authenlieation, data confide.ntiality, and the tirneliness of message in the previous two sections. We will now
address access contro~ wh.ieb deals with who can access network management components and what they can

access. 1n SNMPvl and SNMPv2, this subject bas been covered using the community-based access policy. ln
SNlviP13, aocess control bas been made more secure and more flcxlble. It is called VACM.
VACM defines a set of services ihat an applicatiQn in lll1 agenl can use to validute command requests and
notification receivers. II validates command requests as to the sending sources and their access privl.lege. II
assumes that authentication of ihe source has been done by the authentication module. In order to perform the
services, a local database containing access rights and.policies has been created in the SNMP entity, called Local
Configuration Dawtoro (LCD). This is typically in lll1 agent or in a mlll18gcr functioning in an agent role when it
communicates with aoother manager.
The U:D needs to be configured remotely and hence securityconsiderations need to be introduced. AMlB module
for VACM bas been introduced toward achieving tbis.
7.8.1. Elements ofthe Model
five elements comprise VACM: (I) groups, (2) security leve~ (3) contexts, (4) MIB views and view families, a.nd
(5) access policy. We will defineeach oflbem now.
Groups. A group, identified as groupName, is a set of zero or more SM (vacmSeeurityModel)---seeurity name
(vacmSecurityNome) pairs on wbose behalf SNMP monogement objects can be accessed. A security name is a
principal as defined in Section 7.3.2 and is independent of tbe SM used. All elements belonging to a group have
identical access rights. Equivalent otagroup in SNMPvl is ihe.commtmity name. Thus, all NMSs (security names)
In SNMPvl (SM) witha community name public (group) would have equal access privilege to an agent
Security L,.evel. Security level (vacmAccessSecurityl,.evel) is the level of seoority of ihe user, namely no
auihenticarion-no privacy, authentlcation-oo privacy. and authenrication-pdvacy. This is set by the message flag
sbown in Figure 7.12. A member using a specific SM and with a given security name in a group could have
differetn access rights by using different security levels.
Contexts. As mentioned in Section 7.3, an SNMP context is a collection ofmlll18gement information aocessible by
an SNMP entity. An SNMP entity has access to potentially more than one context. Each SNMP engine bas a
context table that.lists the locallyavailable contexts by contextName.
M1B Views and View Families. As in SNMPv I and SNMPv2, access rights to contexts are controlled by a MlB
view (see Figure 5.2). A MIB view is defined for each group and it details the set of managed object types (lllld
optionolly, 'the specific instances ot object types). Following the approach of ihe tree-like naming structure tor
MIB, the MIB view is defined as 8 combination of 8 set of view subtrees, where each view subtree Is a subtree
within the managed object naming tree. A simple MIB view could be all nodes defined under an OBJECT
IDENTLFIER, for example, system. A view subtree is identified by the OBJECT IDENTIFIER value, which is the
longest OBJECT IDENTIFIER prefix common to aU (potemial) MID object instances in that subtree. For the
system example, it is {1.3.6.1.2.1.1 }.
An example ofa complex MIB viewcould be all infunnation relevant to a particular networkinterface. This can be
represented by the union of multiple view subtrees, such as a set of system and interfaces to view all managed
objects under the System and Interfaces groups.
A more complex view is a situation where all ihe colmnll1lr objeciS in a conceptual row of a table appear in
separate subtrees, one per cohtmo, each with a similar formal. Because ihe formats are similar, the required set of
subtrees can be aggregated into one structure, called a family of view subtrees. A family of view subtrees is a
pairing of an OBJECT IDENTIFTER value (called the fiunily name) ttlgether with a bit string value (called the
family mask). The mmily mask indicales which subidenlifiers ofiJIC aSS:Ociiited family name are significant to tbe
family's definition. A fiunily ofview subtrees can either be included or excluded from the MIB view.

Access Policy: The access poucy detennines the access rights to objeclS as read-view, write-view, iUJd notify-view.
For a given groupName, contextNarne., securityModel. and securiryl..evel, that group's access rights are defined by
either the combination of the three views, or not-accessible. 1lte read-view is used fOr get-request, get-next-
request, and get-bulk-request operations, The write-view is used with the set-request operution. The notify-view
represents the SCI ofobjecl inStances authorl2i!d for lhc group when sending objecls in anoti6calion.
7.8.2. VACM J>rocess
The VACM process is presented as a.flowchart in Figure 7.16. We will explain the process in terms ofan SNMP
agent with an SNMP·engine haYing responsibility for many conte.xts. 1lte LBbles shown in the figure are addressed
in tlte neKt section on VACM MIS. As RFC 2275 describes, the VACM process answers tlte six questions related
to access of management informalion. They are:
1. Who.areyou (group comprisll18 security model and security name)?
2. Where do :youwant to go (context to be acc~ed)1
3. How secured are you to access the Information (security model and sewrlty level)?
4. Why do you want to access the lnformatlon (to read, write, or send notification)?
5. What object (object type) doyou want to access?
6. Which object(object Instance) do you wanno access?
Figurt 7.16. VACM PrO<"''

The first question is answered by the introduction of the group concept. The group that the requester be·longs to is
determined by the VACM from the SM and the security name. (I uses the security-to-group table for validating the
principal and deriving the group name.
The second question is answered by checking whether the context that needs lo be· accessed is within the
responsibility of the agent. lf the first two questions are answered in tbe alfU"mativc, then the resull.s of those,
namely group name and context·name, along with the security model and ihe security level (answer to how), are
fed into the "access allowed?" process. It is assumed by VACM that the SM and the security level (the third
question) have already been valid11tcd by the security module. Given these four inputs as indices, the access table
provKies the views permitted, view name. lt comprises o.ne or more of the views, read-view, write-view. and
·notify-view.
The answer to the fOurth question regarding why access is needed is used by the "select variable names" process to
select the family ofview su~s eligible to be accessed. The view tree family table is applicable for this selection.
A match is made between the result of this process and the answers to the last two questions as to what (object
type) and which (object instance), t·o make a decision on whether access is albwed or oot.
Each process puts out an error message based on the validation as shownin Figure 7.16.
7.8.3. VACM MID
The processes in VACM use the tables to perform the functions mentioned. A VACM MIB has been defined
specifying the newly created objects. This is shown in Figure 7.17. The snmpVacmMffi is n node under
snmpModules shown in Figure 7.7. The three tables defining 1he context, group, nnd access are nodes under
vncmMlBObjects, which is a node under snmpVacmMlB.
Figurt 7.17. VACMMffi
The vacmContextTable is a list of vacmContextNames. The vncmSecurityToGroupTable has columnar objects,
vacmSecurityMode~ vacmSecurityName, as indices to retrieve vacmGroupName.

The VACMAccess Table, shown in Figure 7.18, is used to determine the access permission illld lhe viewName.lt
has vacmGroupName from the vacmSecuril)lfoGroupTable as one ofthe indices. The olhertllree indices from this
table are vacmAccessContex1Prefix, vaomAccessSecudtyModeL and vacmAccessSecurityLevel. The viewName
representing the three views, vacmAceessReadViewName, vacmAceessWriteViewNrune, and
vacmAccessNotifyVievName, are retrieved from the tllble. The vacmAceessStorageType and vacmAccessStatus
are the administ~:~~tive infi>nnation objecis relating to the storage volati fity rutd the row st;ltus.
flgurt 7.t8. VACI1 Attr.,.Tobie
l ·--.......
(I)
The vacmMlBViews, subnode (5), under vaomMlBObjects, shown in Figure 7.19, has the subordinate nodes
vacmViewSpinLocj(. and vacmViewTreeFamilyAccessTable. The vacmViewSpinLock is illl advisory klck that is
used by SNMP commillld generator applkations to coordinate their use of the set operation in creating or
modifying views in agents. It is an optional implementation object.
Flgw·t 7.1.9. VACJ1 MIB VIews

The vacmViewTreeFamilyTable describes families of subtrees that are available w'ithin MlB views in the local
SNMP agent for each cont~l Each row in this table describes a subtree fur a viewName and an OBJECT
IDENTLFIER. Forexample, ifthe "access allowed?" process in Figure 7.16 yields three values fur viewName. that
would resuh in three conceptual rows in this table. The vacmViewTreeFamilyViewName representing the
vlewName Is ooe ofthe colu.mnar objects and an index in the table. Two indices define a conceptual row in this
t·ahle. The second is vacmViewTreeFamilySubtree. [tis a node representing the top ofihe tree. For example, ifthe
OBJECT IDENTIFIER were 1.3.6.1.2.1.1, it wo1~d represent the system subtree. The OBJECT IDENTIFfER for
the local agent Is determined by the highest OBJECT IDENllFfER that would address aU object instances in the
local view.
ln some situations, we may want to view differentsubsets of a subtree. ln such cases, we can form a family of view
subtrees by using a combination oftwo parameters. The fu-st is the selection of the view, which Is done by a family
mask defmed by vacmViewTreeFamilyMask; and the second. parameter is the family type defined by
vacmViewTreeFamily'fype, shown in Figure 7.19. The family mask is a bit string ·that is used with the
vacmViewT.reeFamilySubtrce. Using this feature, specific objects in a subtree are selected if the corresponding
object identifier matches. Ifthe corresponding bit value is 0 in the filmily mask, it is considered a wild card and any
value ofthe object identifier would be selected. Afterthe selection is made, iftbe family type value is included (1),
the view is inc-
luded If it is ~eluded (2), the view is excluded. Tbere is more flex.ibilily in the views by
introducing a columnar object vacmViewTreeFamilyType that indicates whether a particular subtree in the family
of subtrees derived from vacmViewTreeFamllySubtree and vacmVlewTreeFrunilyMask ls to be included or
exc:ludcxl in acont~1's MIB view.
As an example ofthe System group to be included, values fur various parameters ofthe filmily enlly in Figure 7.19
are:
Family view name = "system"
Family subtree= 1.3.6.1.2.1.1
Family mask =""
Family type = 1
The zero length string. "", fur mask value designates all Is by convenrion.

We could extend the view by adding a second row to the table. Por example. we could add an SNMP group by
adding another row 10 the table with tbe family subtree 1.3.6.1.2.1.11.
Suppose we wnot to add a columnar object to the table. We would add the columnar object with the indexadded as
another row. We could also add all tbe columnnr objects of a conceptual row in a table. A useful convention fur
doing this is to use the definition of columnar object 0, which designates all columnar objects· i.n a table. !'or
example, {1.3.6:1.2.1.2.2.1.0.5} ilentifJCS all columnar objects associated with tbe 5th interface (corresponding to
illndex value of5) in t.be iffable.
Ifmore than one iamity name is present with the same number of subidentitiers, the lexicographic convention is
fu!lowed for the predominance among them. this helps in the following way. Suppose we wanted to choose all
columnnr objects in the above iffable ex.'lmple, except the i1Mna, wbich is the 4th cohamnar object. We would then
choose {1.3.6.1.2.1.2.2.1.4.5} and the Type e 2 to exclude it. Since this is lexicograpbic.ally higher than
{1.3.6.1.2.1.2.2.1.0.5}, t.bis will take precedence. Thus, !.be combination ofthe two will select all St.b row objects
except i!Mlu.
Summary
We have reviewed the latest version of SNMP, SNMPvJ, in this chapter. 1be two major features are the
specificalicns for a formalized SNMP architecnare that addresses Lbe three SNMP frameworks for the tbrce
versions. Two new members, dispatch and message processing modules, are defmed. This would enable a network
management >')'~'!em to handle messages from nod to agents that belong to aU t.bree current versions. It would also
accommodate future versions, ifneeded.
The second major feature is the indusion of security. A security subsystem is defined, wbicb addresses data
integrity, duta origin autbeniicalioo, dat.a oonfidentiality, message timeliness, nod limited message replay
protection. The authenJication module in the security subsYstem addre.sses the (trSt two iSsues, the privacy module
protects data confidentiality. and the timeliness module deals with message timeliness and limited replay
protection. The secur.
ity subsystem is the User-based Security Model (USM). 11 is derived from tbe traditicnul
concept ofuser IDand password.
The access policies of SNMPvl and SNMP~ have been el1ended and made more Oex.ible by ihe VACM. An
SNMP agent handling multiple objects (contexts) can be configured 10 presem a set of MIB views and a family of
subtrees in its MIB views. These views can be matched with seven input parameters to determine access
permission to the principal They are the SM (versicn of SNMP). the security name (principal), the security level
(dependent on the authentication nod privacy parameters), the context name, !.be type ofaccess needed, tbe object
type, and the object instance.
Exercises
1. The first four octets of an SNMP e~fne· to In a system are set to the binary equivalent of the system's SNMP
manageme11t private enterprise number as assigned by the lANA. Wrtte the first four octets of the SNMP er>glne
10 In hexadecimal notation for the four enterprises, (cisco, hp, 3tom, and cabletron,) shown In Agure 4.14 for
the following two versions:
a. SNMPvl
b. SNMPv3
2. Writethe full SNMP engine tO for:

a. SNMPvl for a 3Com hub with the 1Pv4 address 128.64.46.2 in the 6th to 9th octets followed by
Os in ihe rest.
b. SNMPv3 tOr the Cisco rouier interfuce with 1Pv6 address ::128.64.32.16.
3. Describe the SNMPv3 scopedPDU that the SNMP agent (router) responds to NMSwith the data shown In Figure
4.2(c).
4. Agure 7.20 shows a generalized time-sequenced operation for get-request messagegoing from a manager to an
agent. Complete the primitives in Figure 7.20 e)(plicidy identifying theapplication modules used.
figurr 7.lO. Exrrdsr 4
I
I
I
-
M<>QS"
Pro.'O<inJ
Mold
;
5. Draw the dme-sequence operadon similar to that In Figure 7.20 detailing the elements of procedure for get-
response messagefrom the agentto the manager.
6. Detail the IN and OUT parameters of the sendPdu and prepareOugolngMsg primldves shown In Agure 7.4(b) by
referring to RFC 2211.

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 filling 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
gulde to answer this exercise.
noel noc2
messageProcesslngModel SNMPv3 SNMPv3
securltyModel 3 (USM) 3(USM)
seculrtyName "'noel.~~ "'noc:2'""
snmpTargetParamsName "NOAuthNoPrlv-noc1" "NOAuthNoPrlv-nocl"
securltyleveI noAuthNoProv(1) authPrlv(3)
transportDomaln snmpUDPDomaln snmpUDPDom9ln
transportAddress 128.64.32.16:162 128.64.32.8:162
taglist "groupl" "group2"
9. Access RFC 2274 and tist and define the primitives provided by the authentication module at the sending and
receivingsecuritysubsystems. Describe theservices provided by the primitives.
10. Access RFC 2274 and list and define prtmitlves provided by the privacy module at the sending and receiving
securitysubsystems. Describe the services.provided by the primitives.
11. SpecifY the family name, the family subtree, the family mask, and the family type In vacmVIewTreeFamlyTable
for ah agentto present aview 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 thevacmVlewTceeFamllyTable for the three rows th~t present the systemgroup In the IP address table for
the row with IP address 172.46.62.1 without the ipAdEntReasmMaxSize.
8. SNMP Management: RMON

Objectives
• Remote netmrk monitoring, RMON
RMONI: 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 components in the computer
network. SNMPv I set the fuundation for monitoring a network remot.ely 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 ofthe performance ot a computer network is
statistical in nature. This led to the logical step of measuring ihe statistics of important pammeters in the network
from the NOC and the development ofremote monitoring (RMON) specifications.
8.1. Whut is Remote Monitoring?
We saw examples 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
network monitor or tlte probe. Let us distinguish between the two components ofa probe: ( I) physical object that is
connected to the transmission medium and (2) processor, which analyzes 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 managementsystems and tools.
The monitored information gathered and analyzed locaUy ca.n be transmitted to a remote network management
station. In sucha 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, cormected to ihe backbone·
network. The network management system (NMS) is on the l.ocal 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 theNMS 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 ofthe 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 ofmonit.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 theRMON and reported to the NMS. In some situations, a failure could even be prevented by proa.ctive
management.
The overall benefits ofimplcme.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 ofseveral
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 Net10rk
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
mwhen wediscuss 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 I0), 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 functions. 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 byDisplayString. The information content
ofOwnerS!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 ofan interface
card, the OwnerString is setto "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 ofthe
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, ifthe owner ofthe row decidesto 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 resourceclaimed, or it may
be donein a batch mode late.
r. Iflhe desired row ofinformation 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. tn 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 Rowexists and Is 11ctlve. Itis 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 ofthose comprise monitoring oftraffic 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 ofstatistical 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 in1be 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 ofthetraffic pattern or troubleshooting ofan abnormality in
tJIC network.
The above functions associated with the various groups are accomplished using 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 ofthe groups have one or more tables. Thegroups 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 ifdesired for further analysis. These are the
Filter group and the Packe.f Capture group. We will consider RMONI groups and the token-ring extension to
RMONI in Sections 8.3.4 and 8.3.5, respectively.
Table8.2. RMONt MID Grou1>< oud TabIts
Group 010 Function Tables

Tablt 8.2. Rli10NI MIB Go'OUf>S nnd TAbi<S
Groop OlD Function Tab~
Statistics rmon 1 Provides link-levelstatistics -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 thresholcis
Host rmon 4 Gathers statistical data on hosts - hostControffable
- hostTable
-host1imeTable
- hostControi2Table
HostTop 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 capabllity to gather packets after they flow -buffercontroiTable

TRblt 8.2. RMONI Mffi GrOllllS and Tablos
capture through a channel
~pture8uffer'Table
Event rmon9 Controlsthegeneration 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 ofthe groups have tables with "2" as part ofthe 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 of RMONI. The
enhancements 1
0 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 only those rows that ohang!ld since a particular time. 1l1e agent returns a value
only ifibe 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 .row #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
update
fooCoun t s.5.2 9
{Note that row U does not exist for times 4 ilfd S since the l ast
occurred at timemar k 3 . )
(Both rows U and 12 do not exist for timemark greater 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) ofdata. The control table·defines the instances ofthe datr rows in
'Ihe data mble and is seunble to gnther and store different instances of data. The relationship between tbe control
table and ibe daiatable 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'Mfta11'tltO!Oi«W
Vii!Jt Clfdft!hOOJ •~men hwl.ltotClO!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 rollect 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 theiirst intrice of a managed entity. llte value of thecolumnar
objecl, controlDatllSource, idenJifJe.s the source of thedata that is being collected.ln our example, if the interface
#1 belongs to the imerfaces group, thencontrolDataSourcc 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 ofpacket~.
8.3.4.1tMONJ Common and Ethernet G roup~
We.have so fur covered the global picture ofRMON I Ethernet MIB and how data and control tables are related to
each other. Let us now address the nine RMONI commoo 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 ofcollisions is a best estimate, as the numbe.
r o(collisions detected depends on where the
probe 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 oftwo s.ubgroups: the history control group and the history (data) group.
The history control group controls the periodic st3listl.cal sampling ofdata from 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 network 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 excessivegeneration ofevents 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
valuecrosses 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
alarmVariable 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 ofthe variable at the end.ofthe 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 ofdelta 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 contain5statistics 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.mple ofthe 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 ofthe 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 ofhosts. 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 againsteach filter associated with that·channel aod is accepted if il passes any
ofthe tests. A row in the channel tableofthe filter group includes ·the interface1D (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 ofpacket 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~~~~ Tobits
Token Ring Group Function Tables
Statistics Current utilization and errorstatistics ofMAC layer tokenRingMIStatsTable
tokenRingMIStats2Table
Promiscuous statistics Current utilization and errorstatisticsof promiscuous data tokenRingPStatsTable
tokenRingPStats2Table
ll,lA£-Iayer history Historical utilization and errorstatlstics of MAC layer tokenRlngMI.HistoryTable
Promiscuous hls.tory Historical utflizat!on and error statistics ofpromiscuous data tokenRingPHistorVTable
Ringstation Stlrtlonstatlstlcs rlngStat!onControrTable
rlngStationTable
rlng5tationControi2Table
Ringstation order Order ofthe stations rlngStationOrderTable
Ringstation configuration Active configuration of ring stations rlngStationConflgControiTable
ringStationConflgTable
Source-routing Utilizat.ion statistics ofsource 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 ofthe 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 ofRMON l
led ·to the development ofRMON2. 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 ofprotocols, 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 ofthe 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 Management lnfomuuion Base
Thearcbitcdure of RMON2 is the same as RMONI. 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
Protocol dlrectory rmon 11 Inventory ofprotocols protocoiDirTable
Protocol distribution rrnon 12 Relativestatistics on octets and packets protocoiDistComroiTable
protocoiDlstStatsTable
Address map rmon 13 MAC address to network address onthe 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 palr ofhosts nlMBtrixControiTable
nlMatriXSDTable
nlMatrixDSTable

TRblt 8-'. RMON2Mm GroullS a11d Tablos
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 byp<otocol between pairs of hosts alMatrixSDTable
a1Matrfx05Table
alMatrixTopNControiTable
alMatrlxTopNTabie
User history collection rmon 18 User-spedfled historical data on aJ.arms and statistics usrHistoryq,ntroiTable
usrHistoryOb)ectTable
usrHistoryTable
Probe config.uratlon rmon 19 Configuration of probe parameters serlaiConfigTable
netConflgTable
trapDestTabie
serlaiConnectionTable
RMON conformance rmon 20 RMON2 MIB compliances and compliancegroups 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 of U
1e
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 objecl on the unique prolocol ID. Each. protocol is furtber
subdivided based on paramelers, such as fragments. The protocol identifier 11nd protocol parameters are used 11s
indices fur the rows ofthe 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 2074.
The protocol distribution group provides infurmation on the relative traffic ofdifferent prolocols either in octets or
packets. It collects ve.ry basic 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 ofhosts 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 contraI
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 ofthe top N prutocolconversations.
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 ofinstances 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 specificationswere 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 implemcnmtion 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 Ml.
B RMON2 MIB 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.
ftlMandatory for systems implementing RMON I.
8.5. ATM Rcmot~ Monitoring

We will be learning management ofATM in Chapter 9. However, there is a similarity in the use ofremote probes
for RMON on ao ATM network. Wewill address the commonality aod differences here. You may skip this .section
now, ifyou so choose, aod rerum to it after you have studied ATM 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 thehigher-level layers [RPC 2074].
Figun8.7. RMON MIB Framrwork
~ .
,~
llP'fi.JI,... PIU-'1
G"-~~J
~IAOIH Rf.OON·2
t"'C2021,2'J~ NI!WOik lAytr dltlonttoiU'CrouJ
-t-
Ethrnl!l Tol<on•R,.g Swll<lt
0
RM()I>I ~MON
"
DU:sl)· '-t1Y..t
E.&:lltMOI'lt
!RFC1l'ti7) IRI'e t ~W
I wRt.o.'N
- ~- - L - ._____
IETF M
I8o 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 ofATM. 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 intervenlion. Wben RMON instrumentation is either embedded into tbe switch fabrio (c) or
placed between two switches as in (d), no modification oftbe 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 ofthe 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 comains four groups:
ponSele<:t, atmSI8ts, atmHost, and atmMalrix.
Flguo·t 8.9. ATI1 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. ATI1 RMON MID Groups ond Tobits
Groop OlD Function Tables
portSeiTabie
atmStats <ltmRmonMlBObjecrs 2 Basic statistics atmStatsControiTable
atmSt<ltsTable
atmHost atrnRmonMIBObjects 3 ATM per-host atmHostControiTable
statistics atmHostTable
atmMatrix atmRmonMIBObjects 4 ATM per-circuit atmMatrixControiTable
statistics atmMatrlxSDTable
atmMatrlxOSTable
atmMatrixTopNControiTable
atmMatrixTopNTable
The portSelect group !!ddressesport selection. rt is used to define rhe portsio 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 ofselection criteria for a single ATM port.
The atmStats group collecLS 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 behalfof 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 cri1
cria, 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 Ntraffic c;31Tiers.
8.6. A Case Sfudy onlntenef Tl'llffie Using RM'ON

A study was undertllken fOr planning purposes to gather statistics on the [memet growth at the Georgia L
nSLilule 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 oftrnffic by users, packet size,
aod protocol, aod (4) souroe oftmffic based o.n source-destination data.
The network comprised multiple domains of Ethernet and FDDI LANs. The network complex 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 NetmelrL
x 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 oftraffic based on the application
level protocol, such asHITP, 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 Iraversing 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 ofgathering sllll.istics and the U
1ll ofRMON 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.
Results
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 April 996
April to May 18%
2.
3. Note: There was asudden drop in June due to end ofspring quarter aod lhe beginning of summer quarter.
4. Traffic Panem:
o Monthly/Weekly: The only discernible variation was lowertraffic over weekends.
o Daily: '))3 ofthetop 5% peak.~ occurred in the afternoon.
o Users:
Top six domain ofusers (96%) are
Domalnl 20%
Domaln 2
Subdomain I (25%)

Domain 1 20%
Subdomain2 (3%)
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 ofusers contributing to 84% of1he l,ntemet traffic are students(surprise!), Newsgroup
services, and Dornain I.
2. The growth mte oftntemet use during the study period in the spring quan·er was 500/o.
Summ11ry
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 ofview in Part ill of!his book.
Exercises
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,000bytes long
forget·requestand response messages.
a. Whatis the maximum 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 ofa failure.

b. What is the moniroring load on each subnet?
c. If the NMS is still expected to detect any failure within I minut.e of occurrence, what 5 the
overhead on the LAN to which the NMS is connected due to this traffic?
3. a. Describe qualitatively how utilization (number of frames transmitted/number offuunes offered)
depends on the frame siz.e on an EthernetLAN.
b. How would you measure the distribution ofthe frame size on the LAN?
4. a Describe the two methods ofmeasuring collisions on an Ethernet LAN.
b. Compare the two methods in tenns ofwhat you can measure.
S. Two Identical token rings with the.same number of stations operate at different effldendes (r~lo of time spent
in data transmission to that of the total time). One operates at a higher efficiency than the other. You suspect
that It Is due tothe difference In frame siles ofthe data frames in the two rings.
a Whywould you suspect the frame siz.e?
b. How would you prove your suspicion using RMON?
6. How would you measure the types and distribution of f~ames In a token-ring LAN?
7. An RMON probe In a network measures Ethernet packets on hub Interfaces (iffndex) 1 and 2. The counters are
set to zero as the measurement started and Interface 1 has counted 1,000 1,50f).byte packets and Interface 2
has measured 100 64·byte packets. These are stored In rows 1 and 2 of the protocoiOistStatsTable. They are
Indexed by the protocoiOistControllndex of1 and 2and the protocol01rlocallndex of11 and 12.
a Draw the conceptual rows ofthe tables involved with the relevant columnar objects and values.
b. Write each instance ofthe columnar object oft!IC daUJ with iiS associated index. and value.
9. Network Management Tools, Systems, and Engineering
Objectives
System utilities for management
o Basic networki11g tools
o SNMP tools
o Protocol analyzer
Measurement ofnetwork statistics
o Traffic load
o Protocol
o Data
o Error
o Traffic monitoring using MRTG
Mffi engineering
o Limitations ofSMI and SNMP

o Coume.
rs and rates
o Object-oriented design
o SMI tables
o SMl a.ctions
o Guiding principles for MTB design
Design considerations ofNMS
o System aod user requirements
o Local and remote management
o Functional requirements
o ArchitccturaI aspects
o Key design con~iderations
o Functional modules and managers
o RoOI cause analysis
o Distributed network management
o Server and client platfurms
Nen<~orfc ma11agemenl systems
o Display offunctional viewsofnetwork management.
o Examples ofcommercial and open source NMSs
o System and applications management
o Enterprise management system
o Telecommunications management system
Thus far we have covered SNMP standards for lP network management. ll1is includes protocols and Management
lnfurmation Bases (MIBs). ln this chapter we will discuss assorted tools and techniques that can be used for the
management ofnetworks using SNMP (and Other management protocols). In Section 9.1 we suu1 with commonly
available utilities that can be used.for management. This is fOllowed by a discussion oftools fur gathering network
statistics in Section 9.2. Next, in Section 9.3 we examine the design of MIBs (MIB Engineering). which is
important for any vendor of networking equipment. [o Section 9.4 we tum to the design of a typical network
management system (NMS) server for a large tele<:om network. In Section 9.5 we outline several commerei<ll and
free NMS products fur different types ofnetworks.
9.J. System Utilities for Mlm:lgcment
A significant amount of network management can be done using operating sys1em (OS) utilities and some freely
downloadable SNMl' tools. These can be put iogether quickly using simple scripting langu~ges such as Perl
[Cozens; Lidic and Walsh, 2002]. Some of these tools are described below.
9.1.1. Busic ToQls
Numerous basic tools are eitber a part of the OS or are available as add-on applications that aid in obtaining
networkparameters or intbe diagnosis of networ.k problems. We will describe some oftbe more popular ones here
underthe three categories ofstatus monitoring, traffic monitoring; and route monitoring.
Network Status Tools. Table 9.1 lists some of the .network status-010nitori.ng tools that are available in the
LinuxiuNI:x and Microsoft Windows (XP and Visla) environments. We use Linux and UNIX interebangcably in
this section as the same set of basic utilities and too.ls are available on both. This also applies to Solaris.. HP-UX.
AlX. MacOS X, and Free BSD.

TAble 9.1. S1AIIti-M6lliloriu' Tools
Name Operating System Description
lfconflg Llnux Obtains and configures networl<ing Interface parameter.; and status
ping LlnuxfWIndows Checks the status of node/host
nslookup LlnuxfWindows Looks up DNS lor name-IP address translation
dig linux Queries DNS server(supersedes nslookup)
host llnux Displays Information on Internet hosts/domains
The command ifconfig on n ONlX syslem is used to assign an address to n network inlerface or to cooftgure
network interface- parameters. Usually, on.e needs to be a super-user (su) in ONIX to set interface parameters.
However, itcan be used without options by any user to obtain the current configuration ofthe local system or ofa
remo1e system. [n this and other commands, you mny invoke man commlltldnnme to obtain the manual page of a
command in a UNIX system. An eKample ofifconfig is shown in Figure9.1.
Figure 9.1. ExAmpleof lnltrfot t ConllguroiiOJI (lrconllg)
nelmiJ• ifcooftg -a
ldl llag,.:849<UP.l00l'BIICK.RUNUING.MU.i1CAST> miU 8231
lrtet 127.0.0.1 nolmasl< 1000000
hlllefr llags;=863<l.P,BROAOCAST,~TRA!LERS,RUNNING.MULTICAST>
mtu 1500net 192.207.8.31 nellmskffiiiiOO broadE:asl192.:<07.8.255
The option -a is for displaying all interfuces. As we can see, there are two interfaces, the loopbaek interface, loO,
nod the Ethttn.et interface, hmeO. Option - a provides infurmatio.n on whether the interface is up or down, what
maximum transmission unit(mtu) it has. the Ethernet interface address, etc.
One of the most basic tools is ping (packet lntemet groper). A frequent use of it is when an execution of a
command on a remote station fuils. As one ofthe first diagnostics, we want to ensure that the connection exists, for
which the ping utility L~ executed to the remote host. Ifit fails. then there i's a problem with the link. If it passes.
then the trouble is with either the application or something else.
You have already used the ping tool in the Chapter I exercises. It is based on the ICMP echo_request message and
is available in both UNIX nod Microsoft Windows OSs. "Pinging" a remote lP address verifies that the destination
node nod the intermediate nodes have live connectiviiy nod provides the round-trip delay time. By pinging multiple
times, we can obtain the average time delay, as well as percenmge .loss of packets, which is a measure of
throughpm. This 'feature can be used to check the perfOrmance of the connection. There are numerous
implementations ofping. Read the manual page for details on the specific implementation on each host.
The UNIXcommands, nslookup, host, nod dig, are useful for oblaining names and addresses on hosts and domain
name serve,rs. A domain name server provides the ~rvice of locating IP addresses. The nslookup tool is an
interacti.ve program fur making queries to the domain name server for translating the host name to thelP address

and vice versa. The command, by default, sends the query to r.he local domain name server. bm My or.her server
can also be specified. The command dig is a more powerful replacement !Qr nslookup.
For example, thecommand dig nimbus.teneLres.in on thehost beluga yields lhe resJlt shown in Figure9.2.
Flgurt 9.2. Enml'lt ofNrlwork ;ddr.ssTo
·oo
tslaliou (dig)
(boluga]-> dig +nooomme~ts l'lrnbus.tooel mJn
nlmbus.IOnoL
ros.ln. 604800 IN A 203.1992554
1enetres.ln ti041:100 IN NS •olalno.lenet resIn
tenel '"s.ln 604800 IN NS laniRna IGMlm~~on
valcano.tenel.res in 604800 IN A 203.199.2553
;; Ouerytoma 2 msec
~ SERVER 203.199.255..111531203199255.3)
~WHEN: Fri Mar6 1• :12:43 2009
;:MSG S.
IZE rcvd. 14!l
[beluga]->
An interpretation of the above result follows. The host, belu.ga, obtained r.he JP address of nimbus.tenet.res.in
(203.1 99.255.4). from r.he domain's name server 203.199.255.3. This inform:uion is given in lhe ftrSI line of the
output (the A-record). The authority fOr this information, i.e., the name ser~~er(s) for the domain, is given in
subsequent NS-records. The name server that responded io this query is given in the comments auhe end.
lnste~ of the ho51 name, the IP address could also be used as the option paramerer in the dig command. For
example, the command dig +short - x 203.199.255.5 will return the infOrmation that this IP ad.dress is1lSSigoed to
lantana.tcnet.res.lo.dig can give very verbose output. The options +oocomments and +short are used to suppress
some ofthis.
dig or oslookup can help when one wants to find all the hosts on a local area network (LAN). This can be done
using a broadcast ping on the LAN. We need to know the IP address to execute litis command, which we may not
know. However, ifwe know a host name ontl1e LAN, we cou.ld obtoin the lP address using nslookup,
The interootive command host can also be used to get the host name using the domain name server. However, with
theappropriatesecurity privilege, it can be used to get all the host names maintained by a domain name server. the
dig and host utilities also provide additional data on the ho,o;ts, besides bost names. Refer to the manual page for
details.
Network Traffic-Monitoring Tools. Table 9.2 lists several traffic-monitoring tools. One of the tools is pin.g, whioh
we have men.tio.ned as astatus-monitoring tool inTable 9.1. As we stated earlier, by repeatedly executing ping with
a large repeal count (e.g., ping -c I00) and measuring how many of!hose were successfuUy received back, we can
calculate the percentage ofpacket loss. Packet loss Is a measure of throughput. The example in Figure 9.3 displays
zero packet loss when five packets were tmnsmitted and received. It also shows the round-trip packet rmnsmission
time.
fllgu... 9.3. Enmrlt. ofTrnffi<Mouiooo·ing (pillg)

nelma<~; ~ -s m~.e<Ju
PNG miloou 56data bytos
6-ll>ytilS (ron MfT[viiTEOU ( 16.72.0 1Q0~ IWlp_se<f'(l.!lluF4Z. •IS
6-l!>y!eslmm MIT.MlT.EDU (1872.0.100~ ~-""'<-'- tlme:41 ms
&I byles frtrn Mlf,MITJillU (1872.0,100~ lcmp_seq=2. !lmeo41 11>5
&I bytes frtrn MITMIT.EDU (1872.0 100t,lcn!p_seq:3.timao40. 11>5
6-1 bytes rran MITMIT.EDU (16 72.0.100~ k:nD_~. ~. ons
-mlledu PINGStathtJcs-
Spacl<ets trlnsmiUod Spaole!S reootvod 0% l)aCk.et toes
tCIJriCMttp (m5) mtn/ll'lg/ITlilX" ~0/40/42
Tabt• 9.2. Traffic-MonitoringToob
ping UNIX/Windows Used for measuring round-trip packetloss
bing UNIX Measures point-to-point bandwidth of alink
·tcpdump UNIX Dumps traffic on a networ1<
getethers UNIX Acquires all host addresses ofan EthernetLAN Segment
lptrace UNIX Measures performance ofgateways
ethereal, wireshark Llnux/Windows Graphicaltool to capture, to inspect,and to save Ethernetpackets
Another useful tool, he<~vily based on ping. is called bing (point-to-point bandwidth ping). The bing utility
determines lhe raw throughput ofa link by calculating the difference in round-trip times for different packet sizes
from ea.c-h end of the link. For example, if we want to measure the throughput of a hop or point-to-point link
between LJ and L2, we derive it from the results ofthe measurements oflCMP echo requests to LJ and L'2. The
difference between 1he two results yields tbe throughput of the link LI-L2. 111is method bas tbe advanUlge of
yielding accurate results, even though the path to the link LJ-L2 from the meawring sUition could have a lower
bandwidth than the link Ll- L2 for which the measurement is made. However, there is a practical limit to it (about
30 times). In practice, this means that ifyou have a 64-kbps coDnCction to the InterneI, the maximum throughput of
the linkyoucan measure is2 Mbps.
Other commands examine the packets that traverse the network to provide different outputs. The commands,
lcpdtoup and ethereal (also known as wireshark), put a network interface in a promiscuous mode, in which raw data
are gathered from the networkwitbout any filtering. and log the dam. All ofthem could generate an output teld: file,
associating each line with a packet containing infonnation on the protocol type, leoglh, source, and destination.
Because of the seeuriry risk associated with looking at dala in a promiscuous mode in the.sc cases, the user ID is
limited to super-user. An example of the output ofethereal is shown in Figure 9.4. Each line shows infonmation
about one packet. Several packets are Address Resolution Protocol (ARP) requests. In these cases, the souroe MAC
address is shown. Fo.
r ease ofreading, the vendor ID ofthe MAC address is shown in text form, followed by the
24-bit serial number. The three lines in gray scale in the middle ofthe window show packets belonging to a single

HTTP session over a trtu~smission control protcx:ol (TCP) connection. They capture the three-way bandshalre used
by TCP to establish the connection. The first oftbese packets is a connection request from 10.6.21.59 to the HTTP
port on server 10.94.3.215. 11te server responds with an SYN+ACK, and finally, the initiator ACKs to complete
theconnection establishmeru handshake.
Flgurt 9.4. 'fr•tllc: Monitoring u; lng Elhtreot (Wirtsh•rk)
...... ;.. .~..... ..__.. "..... .,..
l~j~.... ~~'-·"
, ~••"lfl'"•o'M • •,,..~
I> (_...,Ill li't t-,;IOMM- 11•........... e.: II......... ~. f..WI
t J.,.,.,, ......., .,...,... ,-go•••llt: •• ..... niOI .. 'Il'
II ...................... .., .... - -·· ~· "'" ... - ... I .. I ·- '
e: :~:!~~::u :~==~::: ~ ....,4,•.
.... :;::::.::~; ::: ;.:!lo ,,..,....... .
r.;t........,._.no LAI/IILJc lti>•-Jl9.......JJiii*--..i~lit•
For an example of tcpdump command output, please see the SNMP get-r6:(uest.and get-response PDUs shown in
Figure 5.17 that were obtained using the tcpdump tool.
The command getet.bers discovers aII host/Etheroet address pairs on tbe LAN segment (a.b.c.l to a.b.c.254). It
generates an !CMP echo_request message similar to ping using an IP socket. The replies are compared with the
ARP table to detennine the Ethernet address ofeach responding system.
The iptrace tool uses the NETMON program in the UNIX kernel and produces three types of outputs: IP tmffie,
host traffic matrix output, and abbre·viated sampling ofa pre-defmed number ofpackets.
Network Routing Tools. Table 9.3 lists three sets ofrouto-monitoring tools. llte nctstat tool displays the contents
of various network-related dam struet.ures in various fOrmats, depending on Lhe options selected. The lletwork-
related data structures that can be displayed using netstat include tbe routing table, intermce statistics, network
connections, masquerade connections, and multicast memberships. The example of tb.e routing tables obtained
using nelstat is given in Figure 9.5. It shows the ports associated with various destinations. netstat is a useful
diagnostic tool for troubleshooting. For example, the routing table information shown in Figure 9.5 iofurms ilte
network operator which nodes have been active·since the last purge ofthe mble, whicb is typically in the order ofa
minute, Tbe most frequently used options of netSLal are: -r that obtBins the conterus of the routing mbleJ>; -i that
prints the table ofaU networking interillces; and - a that prints information about all active Iniernet connections and
UNIX-domain sockets.
Agut-. 9.5. Routiug Tabtt using tlf131al- r

nelstid -r
Ra..mg tables
bUemet.
Destinalion Ga'-ay FI"!JS Reb Usa Netlf Expire
DeUull gwloi!ch 'lei UGC 44 541550 deO
172.16151 gwlilllch 1101 UGi 0 0 deO
ah.llednot 0.8048:eor741>4 Ull.W 9 205:Je83 cleO 2(!2
uucdte::h.MI wc:p.lltecn.nel UH 0 0 oO
sip.IHI9Ch 1101 Dig UH 0 5551 ppp3
c!o!N4411«1notIIW"*" net UGH 0 l4T2 dOO
--~llld>-gw fJW lil!!ct> ..... UGH 0 .7 111>0
t9444m gw.-Mvua Ugc 0 171831 pppe
OSI'F·AU. WCASTNET locolhcst UH 86491 100
OSPF·OOlO.MCASTNE IOt<llt>c>l Ull 25121 <>()
Tablr 9.J. Routr-Monilorin.g Took
netstat UNIX Displays the contents ofvarious network-related data structures
arprarp UNIX, Windows Displaysand modifies the lntemet-to-Ethernetaddress translation tables
traceroute tracert UNIX/Windows Traces the route to a destinationwith routing delays
The arp tool displays and modifies the lntemet-to-Ethemet address translation lllbles (ARP cache) used by the
ARP. Some UNIX systems provide anadditional. tool for manipulating the contents ofEthemet-to-lntemet address
translation tables (RARP cache). The name ofthetool is rarp and its use is similar Ill arp.
The third set ofrouting tools shown in Table 9.3 is traceroute (UNIX) or trncert (MS Windows), which is the'basic
tool used most extensively to dingnose routing problems. Tite tool discovers the route taken by packets from the
source-to-destination througb each hop. It is very useful in localizing the source of.route failure. It is also useful in
performance/packet delay evaluation as the result gives the delay time to each node along the route. traceroute is
based on the !CMP time_exceeded error report mechanism. When an lP packet is received by a node with a time-
to-live (T1L) value ofO, an lCMP packet is sent to the souroe. l11e source sends the first packet wiUtn TTL of:tero
to its destination. The first node looks at the packet and sends an [CMP packet since ITL is greater than 0. Then,
the source sends the second packet with a TTI.. larger than the ITL needed to gei to the fD'St node, and thus
traccroute acquires the second node. This process continues until all the· node.s between the source and the
destination have been determined.
Figure 9.6 gives two sample traces taken close to each other in time between the same source mani.beUsoulh.net
and destination mani.btc.gatech.edu. We notice signiAcam diffurences in the route taken, the delay times, and the
number ofbops. We would expect these differences since each packet in an lP network is routed independently.
Each line shows the router ihat the packet iraversed in sequential order. The three time counts on each line indicate
the round-nip delay for·each router on three attempts made from the source. We notice that there is a jump in the

round-trip delay from 2- 5 milliseconds to g:reatenhao 10 milliseconds when the packe1 crosses over from the local
BeUSouth network. In some lines, for example in lioes 9 nod 13 in Sample I, one round-Lrip delay reads high,
which could be attributed to the router being busy. In Sample 2, the second half ofthe route appears congested,
indicating consistent large round-trip delllys. We also·notice that some ofthe routers respond 'viib their IP address,
while oibers do not. The lines that are marked with astcrisks arc responses from those routers, which have beeo
administratively prevented from revealing their identity in their rcspo1.1ses.
flgurt 9.6. E.umplts of Routt Tn.clo~ (lnKtroult)

Traong l!)tJ!eto rr.anr.blc.gateduldu [199.n 14796)
()~£(a rm>orriJITI of30hops·
Vns 3ms 3 ms tims008001 bms.bellsoud'>net (205 152.8 1)
2 4-m> 2m:s 3~ 172.16.112
3 5 ms 4 ms 3 rns 172.16.4..2
4 Sms 3ms 3ms blms011003..bn~S.Cellsot.ltl.nel (205 152.11.33)
5 ~ ms 4 ms 4 ms 205.152. 13.98
6 • Requesllrmd ClJI
7 5 rns 9 ms 12 ms <05.1522.249
8 33rns 31ms 31 ms ~GW2.A'rl. I.AI.TER NE1(15T130.&.229J
9 68~ 10 11S 11 ms 10S.ATM~)(R1AJl1 AlTERNET(tt$.188.232.66(
10 11 ms 14ms 12rns 195.ATM12·0<l.BR1.All1 ALTER.NET
(146.18a23249)
11 16ms 1-'lma 14...., o1Jonb1-b-I.~Lnoi(•.0.2.1411
12 !9 ms 15 ms 17 rns illanla2-tJ2 bllnp4anolnetl4 0 2.1581
13 21 ms 56ms 328ms atlanl02~bbi1planoLnet(4.02.91l
14 17 ms I& rn:s 17ms 192221.26.3
15 32ms 20ms 18ms 130.207.2513
18 20 ms 11ms 17ms fllribtc.gati!Ch.edu (199.n 147 96j
TraceccmpiEio
Sample 1
r 'Tracllll10<110 to !NI1I tw:.gallleh.edu (199 n 147 9fl)
0/Qf. 1'04.11M16'110130 I!QPII
1 3ms Jms 4 ms lllrnsOOtiWl.bms,beiiSOUli'Ullll rM.1bl!.li1J
2 3ma JtM ,.,. 17218.112
3 Sms 4ms 411S 1
72.18.-4 2
4 Sms 3ms 411S blms011033 bms b4lllsoulhll01 (2()5152 11.33(
' 7 m> 4moo 4 m> 20S IS2.13 91!
6 Ro:lYc51lrrreld wt
7 9ms 8ms 9ms 205.152.2249
8 228,.. 214 (nS 191 ,.. 205 80 16!1.9
0 230,. :).16m~ 234,.. ~tt:bnplonetn91 (11l2411n:ll
tO 243 ms 222 ms 212 rns •1001111-rtlf2.bbn~net(4.0 1 931
11 230 ms 213ms 202 ms >OMa1-f'Or3 bbnj:lanel.net(4.05 4Sf
12 2-'7"" 227 ms ~rna -1-tr2 bbnpt.n<>l.I'IOI(4.0 3.14Sj
13 228ms 235ms 238rns anan:a1-111 bl)nQI.lnelne1(40.2.58J
14 257 ms 238ms allani;l2·ht2.bbnplanotnet(4.0.2.15S]
15 ~ms 234ms 233rrrs auan'a2-a99.obn~net(4.0.2.91J
1s ' 40""' m ms ?SI .,.. 192.n1 '6 3
17 235rns 245ms 225ms 1302072513
18 268rns 243rns lll3nlblc.gatechedu(199n 147.961
TraceOOO'I)Iei4
Sample 2

There are also Web-based traceroute and ping ulilities available in some systems. The use of these oools
significamly decreases the time necessary to detect nnd isolate a routing problem because the final decision is
based on independent data obtained from various host~ on the net.
9.1.2. SNMP Tools
There are several tools available to obtain the MIB tree structure,, as well as its values from a network element.
Each of these tools has several implemenmtlons. We will not go into ~cifie implementations here, but will
describe Uteir funclionality. You may obtain delllils on tbe use 8Jid options from the manual page describing UJe
tool
SNMP MIB tools are of three types: (I) SNMP MIS browser uses a graphical interface; (2) a set of SNMP
command-line tools, which is primarily UNIX- and Lin1Lx/FreeBSD-based tools; and (3) Linux/FreeBSD-based
too~ snmpsnif~ which is useful to read SNMP POOs.
SNMP MIB Browser. An SNMP MlB browser is a user-friendly tool that can be accessed from public software
libraries or commercially purchased. AU eKtract MIB-ll of SNMPvl and some can e)((ract SNMPv2 MI.B. Some
can also acquire private MIB objects. You specifY the host name or the IP address first. Then infonnation on a
specific MIB object, or a group, or 1he entire MlB can be requested, depending on the implementation. The
response comes back with the object ideotifier(s) and valuc(s) ofthe objecl(s).
For example, using the graphical MID browser tkmib (http://www.net-snmp.org) and requesting the variable
system.sysDescr from hoS1 I 0.65.0.32 yields the response shown in Figure 9.7. The MIB tree is shown in graphical
furm in the top window. By clicking on a leaf node in the tree and invoking a get, the response from the agent is
shown in the bottom panel We see that the node is a Linux-based proxy server running kernel 2.6.9-22 with
symmetrical mukiprocessor (SMP) support Figure9.8 shows the resuks obtained by using a text-based browser to
retrieve U-.e system group from host 99.77.147.182.
Agurt 9.7. MIB Bro"~•r Exampit (ikmib) for aSystrrn Drsrriplor Objerl

-...._-..- . ~.a...;:.-.,_,.. .. ..,_J~ .a.u. ...__.a t"u ..._...u _,.•.,... u.,.._• .-
j--·-------·· ··-·~
•
-
Frguo
•t 9.8.Ml B Brows•r Exaonplt (Tt>lllaS<d) ror. Sy51tnl CrOUil
199n147,182:
s~etO . SunOS noc:5 5.6Geneoic_I05141.rosuntu
s~ID.O 1.3.8.1 4.1.11.2.310 1.2
oy>UpT-.0 :8d 22:21:G3.74
~Conlaci.O :
sysName.D : ooc5
~nO
s~.072
sysORl.MtChMtge.O : Od 0;00:00 00
SNMP Collllll8Jld-Line Tools. There are several SNM'P commrutd-line tools available in IJIC UNIX, Linux. or
Fn:eBSD and Windows OS envirenmeots. Command- line lools generate SNMP messages, which are get, get-next,
gelbulk, set, response, and trap. Public domain software packages Crut be downloaded that are capable ofoperating
either as an SNMPvl, SNMPv'2, or SNMPv3 manager. A popular suite is available from http://www.net-snmp.org.
The following oommands are descrihed in SNMPv1 furmat. An option of-v'2 or -v3 is used to generate SNMPV2c
or SNMPv3. respectively.
SNlviP Get Command.
snmpqet [options) host carununity obj ect iO [ob j ect iD)

This command communicates witlla network objet1 using the SNMP get-request message. The host may be eilber
a host name or an IP address. [f the SNMP agent resides on Lbe host wiLh the ma.Lching community name, it
responds with a get-response message returning the value ofthe objecUD. ff multiple objectiDs are requested, a
varBlod clause is used to process the message ccntaining multiple object names (see Figure 4.48). If the get·
request message is invalid. theget-response me.ssage contains the appropriate llmll' indication.
For example,
snropgat 199. 77.147.192 public system.sysdescr . O
retrieves the system variable syst.em.sysDeser
systam.sysdascr . G • "SunOS noc5 5 . 6 Generic_ l05181 -03 sun4u. "
The 0 at the end ofthe objeotlD indicates that the request is for a single scalar variable.
SNMP Get-NeXI Command.
srunpget next [op tion.s) hol!Jt cononunity obj ectro [objeotiO)
Thecommand is siml lar to snmpget except that it usesthe SNMP get-neXJ-request message. The managed object
responds with the expected get-response message on the objecliD that is lexicographically next to the one specified
in tbe request. This command is espec.ially useful to get the values of variables in an aggregate object, i.e., in a
table.
For example.
SOntpgetnext 199 . '17 . 147 . 182 public interfaces .itTab!e.ifEntry .Hindex . 1 retrieves
Interfa~s . ifTable.ifEnt ry . ifindex . 2 = "2 ."
SNMP Walk Conunand
sompwalk [options) host community [object iDl
Thesnmpwatk command uses get-ne.Tt-request messages to g.etthe MIB tree for the group defUled by Lbe objectlD
specified in the request. It literally walks tlirough the MlB. Withoutthe objeetlD, the command displays theentire
MlB tree supported by the agent.
SNMP Set Command. The snmpset command sends the SNMP set-request message and receives the get-response
command.
SNMP Trap Command. The snmp1.rap ccmmand generotes n trnp message. Some implememation hnndles only
SNM'Pvl ·traps and others handle SNMPvl, SNMPY2, and SNMPv3 nod can be speci-fied in the argument. Note
thaltbis acts as an SNMP agent
SNMP Sniff Tool. The SNMP Sniff too~ snmpsnifl; is similar to the tcpdump tool and is implemented in
Linu;JFreeBSD environmeot. lt captures SNMP packets going across Lbe segment and stores them lOr later
analysis.

9.J.3. Protocol Analyur
Tbe protocol analyzer is a powerful and versatile network management tooL We wiU consider it as 8 test tool in
this section, and later on look Ill its use as 8 syst.em management tool. It is 8 tool thul8nalyzes duia packets on any
trnnSmission line. Although it could be used for tbe analysis ofany line, its primacy use is in the LAN environment,
whi.ch is what we will focus on here. Measurements using the protocol analyzer can be made either locally or
remotely. The bns.ic configuration used for a protoco.l analyzer is shown in Figure 9.9. It consists ofa data capture
device that is attached to a LAN. This could be a specialized too~ or either 8 personal computer or workstation
wHh a network interface card. The captured data are transmitted to the protocol analyzer via a dial-up modem
com1ection, a local or campus network, or a wide area netwo[k. 1be protocol analyL.er analyzes the data and
presents it to the user on a user·friendly interface.
l'igu•·•9.9. Basi• Configuralion of • Protocol Auolyar
on
Pftl<ocd C8pbte
AI>Jiyzfl' o-ce
R.wdilli'T-00
~IOOom.....AN «LA'I Unl.
I
~
The protocol analyzers thatare available in 'the commercial market are capable otpresenting a multitudeotresults
derived from tJIC data. Contents of data packets can be viewed and analyzed at all layers of the OS! refi:rence
model. The distribution of various protocols at each layer can be as<:ertained. AI the data link layer, besides the
statistical counts, t.be collision rate can be measu.red for Ethernet LAN. At the transport byer, port information fur
different applic.ations and sessions can be obtained. The distribution of application-level protocols provides
valuable infonnation on the nature of traffic in the network, which can be used fur performance tuning of the
network.
Numoous commercial and opel}osource protocol analyzers and sniffers are now avail.able. Sniffer can be used as a
stand-alone portable protocol analyzer, a~ well as on the network HP. NetMetrix protocol analyzer is a so.
ftware
package loaded on to a workstruion. II uses LanProbe as the collector device, which can be configured also as an
RMON probe.The communication between RMON and the protocol analyzer is based on the SNMJ> protocol, as
shown in Figure 9.10.
Figurt 9.10. Prococot Annlyur witb on RMON Probe
A protocol analyzer functioning as a remot&omon4oring analyLCr collects data using an RMON probe. The raw
data tlutl are gathered are pr&oanalyL.ed by the RMON and transmitted as SNMP traffic instead of raw data in tbe
basic co11figurat:ion mentioned earlier. The statistics could be gatbered over a time period fur analysis or displayed

on a real-time basis.ln the pro~uous mode, the actual data coUected by the probecould be leoked at in detail, or
swtistics at various protocol layers could be displayed. llle results are used to perform diagnost-ics on network
problems, such as traffic congestion. They could also be used with the help ofthe tool to do network management
fimctions such as traffic rero1~e planning, capacity planning, load monitoring, etc.
Using an RMON probe fOr each segme.nt ofthe network and one protocol analyzer fOr the emire network; as shown
in Figure 9.11 , the complete network can be monitored. The RMON probe for each type of LAN is physically
different. Even for lbe same type ofLAN, we need a separate probe for each segment, which could be expensive to
implement.
Fignrr 9.11. Monitoring orTot~l Nrtwork wilh Individual RMO,'II'robu
~
PIOIOOOI Elnotrot
lliAiy<Of !>rot»
0 L ~hoOIOIW>I
9.2. Network Statistics Measun.•ment Systems
One key aspect ofnetwork management is traffic management. We will consider performance management as one
ofthe application functions when we deal with them in Chapter II. Howe~er, we will first consider how the basic
tools that we disCussed in Section 9. l are used to gather network statistics in the network at various nodes and
segments. We will then cover an SNMP too~ Multi RouterTrafficGrapher (MRTG), wltiob can be used to monit.or
traffic.
One ofthe best ways to gather network statistics is to capture packet.s traversing network segments or across node
interfaces in a promiscuous mode. We have learned that protocol analyzers do just IhaL Thus, they are good tools
to gather neh,~;~rk statiStics. Anot-her way to gather network stati.stics is to develop a simple application using a
fimction similar to t.cfl{iump, using a.high-performance network interface card and processor, and analy:re the dow
ror the required statistics. After all, that is the basis on which protocolanalyzers are built.

The RMON M1B !hat we s1ud.ied in Set1ions 8.3 and 8.4, along witlllhe SNMP communication protoco~ provides
a convenient roe<:banlsm 1
0 build network-monitoring sys1ems. The configurmioos shown in Figure 9.10 and
Figure 9.11 can be used as the oetwork·mooitoring system to gather various RMON objects. The RMONI MIB
groups and iables shown in Tables 8.2 and 8.3 are used to g&he.r statistics at 1he data link layer in Elhemet and
toke~rring LANs. The RMON2 MIB groups and tablc·Sprcsemed in Table 8.4 define parameters for higher-layer
statistics.
9.2.1. Tmffic Load Monitoring
Traffic load monitoring can be done ba.wd on the source, I he <k.--stination, and the soui'CC>-<Iestination pair. We may
want to balance the traffic load among the various LAN segments, in whioh case we need to measure the tollll
traffic in each network segment or domain. Datn for traffic monitoring can be snmpled at the data Unk layer using
tbe RMON I MIB hislory group. Traffic relevanl 10 a boSI, eilher as source or as a destinall>n, is available in the
host group. Hosts can be ranked on 1hetraffic load tlutt they carry using the HostTopN group. ln the absence ofnn
RMON probe, there is no convenienl way to measure traffic in a segment directly eKCepl to compute it externally
knowing dte ho&s in the segment.
Load statistics in an IP network can also be obtained by measuring IP packets 31 the network layer level. The
entities in lhe n~-twork layer host and the network layer matrix groups in RMON2 MIB can be used for !his
measurement Figure 9.12, Figure 9.13, and Figure 9.14 show the load statistics measured in a Fiber Distributed
Datalnterface (FDDf) LAN segment using lhe NetMetrix protocol analy.rer as the Load Monitor and FOOl probe.
Flg•tr• 9.u. Lo:<d StRIIslit.s' Moullorlog ofSo~tn:u

DwcUn
Loom: Souru:
LOOP seled•d
orJ609
:"etBost
cssun.UL>tbr:s.emorr.e
rl8bl7S.res.ptech.e
cpk•nc•rs.bubl.bbnpiA
r.l!bl77.ns.gated.e
bon·IAnd.erols.aec
coliegepk·mboaH.bbn
r"14bIS.ret.pfecb.ed
santtnol.c~gJreck.e
o_t~s ~~:a.tec.Ledu
LOV..COi'-nt.IB
SDtttCC'
LOW-COXI1Uil
o.:s... ,··
3G
,
3G J
~<;
•
5G
•
••C: •
180
•
~'<;
-
SIC::
-
810
-
nl(l
0
• c on.b
Flgure 9.13. Load Stati~tirs: MonitOI;ng of &'itinotiont
.l
a:unc"aouaJocu
:3~831M
lOO

r-lhf~vNI- ...~·I_IX ,r ""11 M{;tlro· V•-:~. - : '}PRY ccr;c~.,~t-;--- ,.
!'"- lh1l'
-
I>Q; Lit«:
1~~
15'111RlKIHI O..lludn .,"t"I'C'ma!KIJ
oriD3 LOW..CO:ttJU& JU.'15J.I
~tllost Uuou .~·
ao-sfJ:Ltdn 2C I
r7~H8.N•.aate<b.HI u: I
$btaaal.~t..aattd•.• Je
~ LS:O nu.a•t•t:"-• l C
•t~"" ...C.ptock.~d" •c:
C'!S'(ta.-m..t.aK..ai""T•• 1C
ae-~omaPt ec
:
,.,.__...nfpiHltNiil 35C
lota-MALpl•<b ,..tn 3JIC
LOWC0"-"111:1D 45~C
'
0 :mo
• con...
Jn Figure 9.12 there are 1,609 sources thai generated data packeis. The top ten have been identified, with the
highest entry being news-ext.gateob.edu. The enlry LOW-CONTRIB is a combination ofsources other than those
specifically ideot·ified. Traffic is measured as the number ofoctets. Figure 9.13 presents similar statistical dala on
traffic tl111t is destined to the hosts in the network segment. Figure 9.14 presents the lop ten conversation pairs of
hosts. Each line identities the host-paics, traffic from Netl:fost ItoNetHost2.Oct lto2 and Oct2tol dCJtote tbe traffic
in octets from Net.B.ostl to NetBost2 and NetHost2 to NetHostl, respectively. For example, news-eKtgateciLedu
transmitted 3K octets/9eCo.nd of outgoing traffic 10 and received 60K octets of incoming tmffic from
bowlaoil.erols.net.
Figul't 9.14. Load Statlsti~: Monitoring ofConvrrsa1k10 Pnl~

·~·-au..· ..LUtJ.....Jnt..-rdL lit
""
LOW~1IR18 * Ullmal...:c.prtdY. ~ Cit
<pi<•O
n1<
h'll,loh..... <+ •......ul-J•I•do... 11( ...
•~t.pJIG.HI .,...t..,.dntr.co• ,., eta
t..On> <'O..
''TSUB...a. lAW CO!'llUB n; JJ(
••t:~d..an.Lp.t1.•tt "~+ acw•~,.n,ptt...,.,.
"" JOlt
•~p1ec:~• ...~."-.-k.W....~ t'lk COl
t.OW..roN11UB._.acws-tur••utt.~~~ ~( l..atc
f~U-...LIIIH'Ilt4• ._. IIU.AI...,...INft,t..lllbll:,. lO <IJI1
.""'""C.PfH..<fllitt '"' ..("'th .........t_...
"' IIOX
.v •o ;o
•~to....ws..
9.2.2. Protocol Sl:llistics
Packets cnn be captured by data capture devices based on the filter set for the desired criteria. Prom the. captured
data, we can derive protocol statistics of various protocols at each layer ofthe OS! Relcrence Model Tllis is very
useful at the applicaLion layer level. We can obtain the traffic load for different applications such as file tmnsfe.r
(FTP), Web data (B'JIP), and news groups (NNTP). This information can be used for baodwi!Lh manngement of
real-time and non-real-time traffic.
Figure 9.1 S shows the distribution of protocols at the data link (top left corner), network (top right comer),
transport (bottom left comer), and application (bottom right comer) byers, obtained using NetMetrix Lant>robe and
a protocol nnaly.~:er. Data link and network layers sltow I000/o LLC and 1P protocols. The majorityof tbe transport
layer protocol packets belong to TCP and the Oel.1 in order is UDP. 1lte other category is undefined. At the
application layer(s), the distribution contains HTfP (Web protocol). NNTP (news protoool), FTP-data, UDP-other,
TCP-other, and undefined other. Tbe Georgia Tech lnten:tet backbone network in which Lhe mea_surements were
made carries a complex variety ofprotocol traffic including multimedia trafficand next genel'!llion lnteme1 tro.ftio.
Fll(ure 9.15. Protocol Distribution (NttMttrb)

aLCC
• Otrur
Unk
• uo'
•Othr
Transport
9.2.3. Da1:1 :uul F.r mr Statisti.cs
Network
Application
-
••
•
•OdH•
.....,
• nm>
aft""d""'
• 1.101'·Otloc,
e TCP-Oth.t
Datn and error statistics can be gathered directly from managed objects using lbe specifications defined in various
MIB groups. The RMON statistks grolrps for Ethernet [RFC 1757] and token ring [RFC 1513] contain various
types of packets and er.rors in the data. link layer. Similar information is available on higher-level layers .from
specifieations detailed io RMON2 [RFC 2021]. lnfonnation on statistics can also be !l'ld1ered for the individual
medium from the respective MlBs under the transmission group. For examp.le, statistios on Ethernetcan be derived
from the Etberoet-like statistics group in Etheroet-like intertilce types MIB [RFC 1284], token-ring statistics from
IEEE 802.5 MlB [RFC 1748]. and FOOl data .from FOOl MlB [RFC 1285].
9.2.4. Using MRTG tn Collect Traffic Statistics
The MRTG is a tool that monitors rraf.fie load on netwotk links [Oeliker and Rand, http://oss.oetiker.ch/mrtg]. It
genemtes a live visual representation oftmffic data by reading the SNMP t·raffic counters on routers and creates
graphs thatare enibedded into Web pages. These can be monitored using any Web browser. Visual presentations of
u:affic data are presented as daily view, the last 7days view, the last 4 weeks view, and the last l2 months view.
The generic software can be implemented in either UNTX or Windows NT platform. An example oflhe views can
be seen on htlp://switch.chlnetworkloperulionfstatistic.s/geant2.html.
9.3. .1<fffi E nginceling
In the SNMP model ofmanagement; information about each network element is contained in it.~ MJB (Chapter 4).
The manager's view of the NE is defined by and is limited to irs MIB. The ease of developing management
applicat·ions depends on bow closely the MIB ma.tchc-
s the needs of the manager. ln most cases, Lhe MID is
hardcoded into the NE by the vendor. Thus, care must he taken io designing the MIB. Tbis is the ti:>cus of MIB
engineering.

There are some commonly used constructs in many MlBs. The use oflhese idioms makes i1 easier for the manager
1
0 understand and use the MlB. The SNMP pro1ocol and structure ofmanagemcnl information (SMI), by virtue of
their stress on simplicity, have some limitations. Fortunately, there are work-nrounds 1
0 enable the manager to
accomplish complex tasks despite these limitations.
First we cover some basic principles, limit;uions, and idioms of SMl. We the.n toke a number of frequently
occurring requirements and.show how to design MlBs fur them.
9.3.1. Genet·al l'rindpll'1 and Limitations ofSMJ
SMl provides a very simple view of the network. Every e lemcm is completely defined by a set of vnrl.ables
(euphemistically referred to as objects), which may take on a limited number ofdata·types. These include scalar or
primitive types (Boolean, Integer, IP address, Slring, Counter, etc.) and three stnrctured or constnocted 1
ype.s
(aiT!lys, records, and seiS).
An llrray is 11n ordered list ofelements all beingof the same type. Each elemenl is identified by its index. A record
is an ordered collection ofelements ofdifferent types, witheachelemeru referred to by name. A set is an unordered
collection ofelements. lbe elemeniS could either all be ofthe same type or ofdifferem 1ypes. E.g.• the interfaces
table, iffnble, is an array with one element fhr each interf.
'lCe in rhe node. Each element in the wble comnins a
record with several fields describing the interface (seeFigure 4.28).
As an example ofa set, suppose the manager wishesto define a trap filter in an agent. Tite filler consists ofa set of
conditions that are AND'ed t.ogether. Only if all conditions are satisfied, the trap is fOrwarded. We could define:
Trapb'ilte r : : = SET or Condl.d.ons
Theorder ofevaluation oftheconditions does not matter.
There are restrictions on the cons1ruction oftypes:
An array can contain a record and vice versa. An array can contain a record that itself contains other
records. However, an arraycannotcontain a reoord thllt conl8ins an IUT8y
A record can be defined to bold related variables pertaining to one part of anNE (in one subtree oftbe
MlB). Another record with identical fields butdifferent names must be defined
The SNMP protocol aUows a manager to get or set the value ofa variable (see Figure 3.9). However, it does not
permit a manager 1
0 perfom1 an action such as resetting an interface or deleting a file. In object-oriented terms, an
SNMP object luis member variables nod accessor methods. but does not bnve any general methods 1
0 perform
actions.
The SNMP protocol supports requesr response 11'8llsactions where each IJ'ansaclion can automatically either get or
set a llmit.ed number ofvariables. The limil is imposed by the size ofan SNMP PDU. Il does 1101 allow combining
gers and setS in one ll'Wisaclion, nor does it allow a sequence ofoperations to fonn a session. SNMP transactions
are very lim.
ited compared to datnbase tranS~~clions. The lattec
r allow a large sequence of select and update queries
to be combined in a single transaction. which either succeeds completely or is not executed at all. l.n addition.
access 1
0 therelevant parts ofthe dalabase by other users can be prevented duringthe transaction.
9.3.2. Counters vs. Rates
Rates are cent·ral to network management. Performance is measured largely in terms of rates. For example, the
throughput ofa link is given in bit'llsecond or packets/second, the throughput of a server in triUisactions!second,
and user behavior in requests/hour.

Rlltes are also .important in some aspects of filult management, specifically in determining when the load on lhe
system is reaching its capacity and hence Is l.iable to fail. For example, ifa I Mbls link is subjected to traffic at the
rate of 0.98 Mb/s, congestion is very likely with the consequent increase in delays, packet loss, timeouts, and
retransmissions. If the congestion persists, it could result. in lhe failure of end applications or the ro1~ers Ill either
end of the link. Proactive fault management attempts to spot congestion in its nascent stage and lhcn take
con,gestlon avoidance measures (o preve.nt fuilures. 111e onset of congestion is indicated by ·comparing the live
throughput with predefmed Lhreshokls. The lhreshokl depends on the capability oflhe router to tolerate temporary
overload by means of buffering of packets. Suppose for a router with a I0-packet buffer we set lhe congestion
threshokl at 0.8 Mbls; if the router has a 20-packet buffur, we might increase the threshold to 0.9 Mbls. The
threshold settings depend on tbe mix ofpacket sizes and other practical factors. In practice, the lhreshold is tuned
by the operator based on experience.
The manager may also require the counter value. For example, if broadband subscribers are billed based on data
transferred, the NMS manager would retrieve the counterofbytes transferred and pass It on to the BillingSystem.
A counter is a direct perfi.mnance measure. On a network tink, the network interfuce maintains several counters
such as packets and bytes transmuted, packets and bytes rooeived, errors, etc. Whenever a packet is proces~d. one
or more counters are Incremented appropriately. These counters are thus available to the NM.S agent at oo extra
cost, are always up to date, and accurate. Hence, the MID should include llle counter. Be mindfullllat the ~-ounter
reading wraps aroimd and shoukl be interpreted cocrectly.
A rate is a derived measure. To determine the t.raosmit rate, we periodically read the transmit octets counter and
calcularo the rate:
Tranlmlit rate _ rransmil octets attl transmit octetsat t1
t~ r,
The rate depends on the averaging interval t2 - t1• For example., Figure 9.1.6 shows a 5-second burst of packets
during which 4,000 octets are transmitted. The network is idle for some time therea.fler.
Frguo
't 9.16. Burst Qf•ctlvlty on a Ntl~<ork Unk
~~ ':OCJ)F ~
:t~ I~ IX!O ;Ill»
[~J~i 0 EJ
0 2
-
I
10 t2 16 (SKI)
Table 9.4 shows the rates calculated over various time intervals. Note that the rate varies quite drastically from 0 to
8,000 b/s. The imerval 0-4 is especially troublesome. 1l1e eo1mter is 3,000, but lhe actual number of octets
transmitted is 3,500. Even if tbe Networ.k Interfuce Card (NTC) has hardware to increment the counter for every
octet, this would not be oorrect because we do oot koow wbetber the packet transmission is successful untillhe end
oftransmission.
T!lblt 9.4. Rat•s Clllculat•d ovrr Yftriou.s lm•rvol<
Interval (Seconds) t,. t, Counter Difference (Octets) Rate (b/s)
0, 2 2,000-0 8,000

Tablt 9A. Rail'S Cldoulllltd uvtr VArious lnltn>:tiS
Interval (Seoonds) t,. t2 Counter Dlfferenc.e (Octets) Rate (b/s)
0,4 3,000-0 6,000
0,5 4,000-0 6,400
0,10 4,000-0 3,200
0,16 4,000-0 2,000
8,12 4,000-4,000 0
Thus, we see tbat the·derived measure ofrate is imprecise 811d gives different resulls depending on the averaging
interval. Different manngers may require different averaging intervals and even one manager may require different
averaging intervals at different times. For example, while projecting fnture growth in network traffic ror capacity
augmentation, !he manager may want a !-hour average. To monitor congestion in a link, !he averaging may be
done over 5-minur.c periods. While troubleshooting some problem, IJ1e manager may average over 30-5ei:onds or
less to see instantaneous fluctuations.
Normally, the MIB does not include rutes. It is left to the manager to poll !he counter ai the.desired periodicily and
10 compute the rate.
There11re11 few exceptions. The central processing unit (CPU) load ofa server is usually compuled using some
OS-specific atgorilhm and the OS may not expose convenient cotmlers. Hence, !be agent simply makes available
the rates computed by the OS, say ibe 30-=nd, 1-minute, and 5-minute load averages. The corresponding
counlers are not included in the MJB.
9.3.3. Object-Oricntl'<l Approach to MlB .Enghtl'Cring
A network element has management parameters pertaining to its configuration, its operation, and its performance.
1n a complex device sueb as a server, a backbone router, or a relepbone switch, the number ofsueb parame1ers can
easily be in the IOOOs. For ease ofcomprehension, in ao object-oriented design relared v3riables are collecred into
classes. Similar classes are related to one another in an inheritance tree. Gi~-en a class definition, instances oftbe
class can be created, referred 10 as objects [Bahrami, 1999].
SMI provides the MIB group that is a simple form ofa·class. A Mmgroup is just a subtree of the MIB tree. The
name of the .root node of the subtree 5 the name of the group. Consider MlB-11, which is the standard set of
variables implemented by all SNMP nodes (see Section 4.7.4). These variables are grouped iruo a number of
groups such as the system group, the interfaces group, the rP group, and theTCP group (see Figure 4.26).
In an object-oriented language such as C++ or Java, the language supports useful properties ofthe·class. These
include encapsulation (variables are private lo a class), inheritance (one class inherits the variables and behavior of
another class), and so orJ. We now show how these 00 feature$ can be used in inrormation modeling, taking a
rourer with network interfaces as an example.
In SMI, the aoologous propertiesofMIB groups are more a matterofrecommended pmctice. For instance, the TCP
group has a count oftbe number ofopen connections, tcpCurrEstab (see Table 4.13). Nom1ally, this i.s updated by
!he TCP code and Ibis variable is co.nsidei'ed to be encapsulated with in the TCP group. Howeve.r, it is quite

possible for the interfaces code to examine the TCP headers as packets pass Lhrougb the interface to detect the
start/end ofa session. The interfaces code could directly manipulate lhe tcpCurrEswb variable in the TCP group.
This is a poor pmctice and is error-prone-a packet could be discarded by the LP layer before it reaches TCP. SMl
does not preve.nf this pmctice.
lnherit;mce allows one class to derive some of m.·properties from a similar (usually more geneml) class. For
instance, an inte.rface has properties such as type, speed, address, and packets sent. An Ethernet interlltce shares
these properties and also has additiooal properties such as number ofcollisions. An RS-232 interface has addjjional
properties .such as parity. So, it is desirable to derive Elhernet and RS-232 classes from a base interface class a.s
depicted in Figure9.17.
Figurr 9.t7. luhoritonct lls.d lo D•fino Voriou•l'lr.twork lutrrfacu
lnlllfttce
5paod
typo
add"""'
oc;lets
4
Elhemcu •
nler!ace RS 2321"!6rf~
collliJiont panly
An Ethernet interface object has lhe properties speed, type, address, octets, and collision.s. while an RS-232 object
has tbe propertie.s speed, type, address, octets, and parity.
Naming. An object-oriented language allows the reuse of the same name in different contexts wiihout any
confusion. For instance, given classes Router and Switch, there is no confusion in tbe use of Lhe same member
variable name numlnted'aoes; Router.numlnterfaces rutd Switch.numlnterfaces are· clearly distinct. Similarly,
grouping ofclasses into packages or namespaces permits reuse ofclass names.
SMT uses a globaUy unique hiemrchy to classify names. Hence. the same l111JDe could 'be used in different subtrees
(or groups). The system group in MIB-2 has a sys.Descr va.riable. A vendor could have a sysDescr variable in its
product-specific subtree. They are distinct as mib-2.system.sys0escr and midas.corD:ECT.sysDescr. for example.
1'here are limitations, however. The same name cannot be used twice in the same MIB .file. Hence, it is
conventi.onal to have a unique prefiX for all variables in a MrB group-"sys" fur the system group, " if" fur the
interfaces group, :utd so on. Thus, we have mib-2.sySiem.sysDe.scrand mib-2.interfaces.itTable.itEntry.ifDescr.
Insianiiaiion. Given a class, many objects oflhat class can be created or instantiated. This can be done stntically Ill
compile-time or dynamically at runtime a.sshown in lhe C++ code below.
Router r .l, r2 ;
Rout e r • r3;
//Static~l y create 2 r outers
I I Oynamio creation of a ~~router
l f (condit ion) r3 • new Router;

One agent can in general have only one instance ofa MlB subtree. In the special case ofa subtree that is part of a
table, the agent can have multiple instances. See, for example, ifEntry in the interfuces.iiTable. Even in this case,
creati.on and deletion of rows in the table ("objects") are not as straightforward as the use of new and delete
operators in C++. fn SMlvl, row creation is ambiguous iUld deletion is not supported. In SMiv2. these operations
require special fields to be added to the table (see Section 6.3.7).
Recommended Practices. As telecom devices are complex, the object-oriented design ofa MTB is highly desirable.
SMI bas IJmited support fhr the object-criented design ofa.MIB. Some commonly used practices are as follows:
I. Use of unique prefixes for all variables in a MlB subtree, such as "if' in the interfaces group, "tcp" in the
TCP group, and so on. This makes names longer than necessary.
2. Extensive use oftables to allow '8riable numbers of objects ofthe same type, e.g.. iiTable, tcpConnTable,
etc.
3. .Dynamic creation and deletion of rows (objects) require inclusion of special variables such as rowStatus in
the row ofa table nod a variable such as iiNumbeno count the number ofactive rows.
4. Copy-and-paste ofcertain blocks ofMIB defmition from one file (subtree) to another.
!1.3.4. SMI Tables
Besides groups, in SMI, tables are the most commonly used constrUct for the aggregation ofdata. SMI tables were
introduced in Section 4.7.3 using some examples from MIB-2. An SMl table cons'isls of three levels in tbe
registration tree: table node, entry node, and leafnodes containing columnar data (see Figure 4.22). For example. in
the interface table we have the table node iffable, the entry node ifl'able.ifEntry, and tbe data nodes
iffable.ifEntry.iflndex.l.• iffabkifEntry.ifDescr.l.•etc.
Since only a single entry node ever appears under the table node, it ls a natural question whether ibis can be
omitted with the data nodes directly under the table node. Ao·wever, the entry node is essential because of the way
SMl defines an index. The entry node describes a complete row and only the node Mscribing a row can specifY the
index column (see Clause4.1 .6 in RFC 1212). Since the index is essential fur specifying a leafnode in a table (one
element ofthe table), every table must have an entry node.
We now turn to the selection of the index field. The indeK fi.eld must enable sel.ection of a unique row. If two or
more rows have the same in.dex value. the manager can retrieve only one ofthe rows. This is a.consequence oftl~e
form oflbe SNMP get request in which every dara value is obtained by specifying its complete name. The variable
binding allows only one dal.avalue for one variable name.
Sequence Number as Index. In many cases the rows in tile table correspond to sequence-numbered physical
entities. For example, a 24-port switch bas ports numbered from 0 lo 23; and in a router each internee occup.ies
one physical. numbered slot. ln such cases it is natural to use this sequence munber as the index.
Name as Lndex. COnsider a software application on a server. A unique index can be the name of the application
suff:ixed with the version nnmber. Recall that when a string is used as the index. the ASN.I encoding ofthe string
is suffixed to the objeci lD (OlD) of the row object to specifY a leaf node. Thus, the name of the variable holding
the path name of the Apache Web server application in an appTablc might be appTable.appEntry.appPath.
'A'.'p'.'a'.'c'.'h·.'e'. With the usual ASCO codes this woukl be appTable.appEntry.appPath.6S.I 12.97.99.104.1 0I.
OlD (Variable Name) as lndex. ln some tables the index is an OlD. Suppose we wish to maintain an inventory
table of equipment in a MIB. Each item is identified by its vendor and brand name. Assume that each of these
eqnipments is manageable by SNMP nod has a proprietary Mffi defined by the vendor. Each such MJB is
contained in a MIB group noted in an OlD that uniquely identifes the equipment. COnsider the corDECT wireless
exchange manufactured by Midas COmmunication Technologies. Midas has been assigned the enterprise node (I 3

6 I 4 I 3794} in lbe {private enterprises} subtree (see Figure 4.14). corDECT s lhe first product of Midas and
hence has the OlD {I 3 6 I 4 I 3794 I}. This OLD, encoded in ASN.I, can be used aHbe index in t11e inventory
table.
Mu.llidimensiooal Tables. SMl supports only one index fur a ~able. However, this index can be a concentration of
seve.:al·columns, effectively yielding u mullidime.nsionallllble. An example is the tcpConnTable in which the indeC'C
is the concatenation of local 1P address, local port, remote 1P address, and remote port. These four quantities
togelhcr uniquely identify a TCP connection. Thus, fue slate ofconnectionto a Web server would be given by fue
variable tcpConnTable.tcpConn.Entry.tcpConnState.I0.621.7.2027.10.6.21.1.0.80. Here the host 10.6.21.7 bas
opened a connection to port 80 on the server 10.6.21.1. The local port 520 • 256 +27 = 5147.
Note tbat the rcpConnTab.
le (as also most other such multidimensional tables) is sparse. Tbe total number of
possible index value$ is 23
2;!1
"23
~16
= 296
? 1031
, a truly enormous number. Most hosts have only a row lOs to a
.few IOOs ot: connections open at a time, Hence, the agent should use some space-efficiem datn structure such as a
bash table or a linked list oflinked lists [Horowitz, 1995].
9.3.5. SM.I Actions
For mrinnging a network element it is necessary to perfurm actions such as enable/disable an interfuce, delete
temporary files on a sever, reboot a node, etc. An object in an ol:Jjec:t-oriented progr.anuning language bas actions
(01ember functions). SML ·•objects'· directly onlycontain data butdo not have fimctions.
In a MIB, an action can be performed by defining appropriate semantics ofa variable. Tile semant.ics is given by
the DESCRIPTlON field in the OBJECT-TYPE macro used to specifY the ~ariable. The manager Catl invoke the
action l:Jy an SNMP set on this "action" variable.
There are two way$ in which the agent can inform the manager ofthe result ofthe action (analogous to the return
value ofa function). lfl'he ac1ion completes almost immediately, the agent sends lheSNMP responseonly after the
completion. The value of lhe variable in lhe response indicates the result ofthe fiction. An example is lhe deletion
ofa file.
Some actions may lllk.ean unpredictable amount oftirne, say furmatting a disk. In ihis case, the agent:initiates ihe
action and sends lhe SNMP response immediately with the value indicating that tbe action is in progress. When lbe
action completes, the agent updates d1e same or another variable that can be queried l:Jy the manager. An example
of lhe latter is found in lhe l.nterfaccs group in MlB-2. iftable has one column ifAdminStatus, which the manager
sets to up or down to request a change ofstatus. The actual status is available in iJDpcrStatus. Note carefuUy lhe
DESCRIPTION fields in lhe definitions oftbe variables in Figure 9.18.
•·igur< 9.t8. IITnble V•rinbles for Cb•ngh1g lhc St•tu>oflin tncerr~cc

ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(l), - •eady10 passpacteis
dov.n(2~
teslflg(3) - In some testmode
I
ACCESS read-Nrtte
STATUS mandlltoty
DESCRIPTION
'Thedesired state cf lhe interfaCE The
testi"9(3) mto>indicaiQS th:ll no oper.ational
paclrels C3l bepassed.·
:~ ( tfEntry 7 }
ifOperStatus OBJECT-lYPE
SYN'TAX INTEGER (
up(l ). - ceady to passpackets
dCMn(2)
le$11'tg(3) -on sort><> te$1 m~
}
ACCESS read-only
S TATUS mancbtory
DESCRIPTION
·The aJtrent operatilnal state of lhe interface.
The testing(3) slateIndiCates thatno operational
pacl<e!S em bepassed •
·:={ ifEntry 8 )
9.3.6. SMI Tma•actions
Suppose a manager needs to perform a complex task consisting of several steps. This may happen. fur instance, if
there is misrouting of packets to destinatio.n 69.96.172.9 by an IP romer. The manager may go through the
fo llowing steps to troubleshoot and fiX the problem:
I. Fetch all entries in the routing table with the destination matching any prefix of 69.'16.172.9 (such as
69.96. 172.xxx,69.96.xxx.xxx) using SNMP Get.
2. IdentifY the incorrect entry.
3. Cb.ange the incorrect entries usingSNMP set.
4. Test ihe new route using ping. lfping fails, repeal steps 1- 3.
Dlrring tbjs process tbe manager needs exclusive access to Ihe routing table. lf any orher manager reads and
modifies tbe same rows. confusion may result. What .is required js a lransaction tbat may include a sequence of
Gets and Sets to a subtree of the MIB. The SNMP protocol does Toot support this. Each SNMP request is alomic
and independent of all other requesrs. One reque~1 cannot conlalo both Get and Set. Only n small number of
variables can be simultaneously accessed in a request, limited.by the SNMP message size of484 bytes (vi and v'2).
To implement complex iransactions without modifying tbe SNMP standard, we need to add a few variables with
special semantics (DECRIPTION ~ld). Assuming that we need to provide transactio11-based access to aRoot and
its silbtree, the extra variables are shown in Figure 9.19 and the OOtTesponding declarations are shown in Figure
9.20. Not.e that aDatal , aDara2,... are nodes in the protected subtree. The nodes numbered->!000 are.nodes added
to support transactions.

Figurt 9.19. ~tm Variables for ComJ!IU Tmns1W'tion>
F'lgur• 9.20. Dtdaratioru for F'lgur• 9.19
alockOBJECT-T'PE
SYNlA~ Bodeall
ACCESS read-wtie
STATUS opllonal
OESCRIPTIC»>
"IIrll$ false. SEt iiJe w;ceeds and m.aJ13gerInfo rs saved If
JIUe, setllw I:Tf 0'1<ref sua:eeds and l'e$etS lim~ If Jrue, :set
Jtue lrf ot11et manager failswith bad11ali.S(3)eiTor •
: {aRool1001 )
alAanage~nfo 08..'EC1-1 Y:PE
SYNTAX MaN!ge!fnfo
ACCESS read-only
STATUS opllon~l
OESCRIPlfON
·eonlJlns lhe 111 otllle managerwno mos1 recen~ 51lCCe«!eo tn
O«Jurnng illOd.•
~ {aRool 1002)
aTrmeout OBJECT-TYPE
SYNlAX Time Ti~s
ACCESS read-wrie
STATVS optional
OESCRfP110N
·alock wut be reset aTimeoutTrekS alief ~ng set·
:::raRoot , 003 l
aF«ceUn'ock OBJECT-TYPE
SYNTAX Boolean
ACCESS read-write
STATUS opllonal
DESCRIPTION
,, set by anauthonzed manager,aJod< isreset:
;:: {aRool1004}
To initiate 11 transaction, the manager t~ttempts to set aLock to true. [f the lock was already held by another
manager, Ibe set Jilils wilh an error. The manager periodically retries the set. When the set succeeds, the agent
stores the manager' s identification (typically, IP address and port number) in aMnnagerlnfo. During the
lrnJl$jlction, only this ma.nager is permilted to access the subtree rooted in aRool. to the normal course after
completing its work, tbe manl!ger ends its transaction by setting aLock 1
0 m lsi:.

Suppose the manager forgets to release the lo<:k. After aTimeout elapses, tbe lo<:lc is aUiomatically freed. There will
be a defauh timeout, which can be modified by the manager, subject to n maximum to prevent hogging oftbe lock
with starvation of other managers. Occasionally, an emergency situation may ari~ for which an authorized
manager may need to preempt tbe loek. lltis is done by writing to aFon:eUnlock. Tbe agent will accept tbe write
and replace the current lock. owllllr with the initiator of the fbrciblc unlock, provided lite initiator is in a list of
authoriz.:d managers.
Thus, it is possible to provide complex transa.ctions in which a manager bas exclusive access ro a subtree of an
MIB during 8 session. lltis is accomplished within the constral.nts of SNM'P and SMJ by defining 8 few auxiliary
variables. To c~er m specific needs, tbe set of auxiliary variables can be changed, for instance to define separate
read and write locks,etc.
9.3.7. Sumnuuy: MIB Eoginccting
In this section we fnt outlined some of the limitations of SMI and SNMP. We discussed the suppon provided by
SMI for the object-oriented design of complex MISs. Finally, we present.ed MIB engineering techniques for
handling tables, perforntiog actions, and supporting complex transactions. To learn more about MIB engineering,
the next step is to read some ofthe available MISs fur devices similar to the one at hand and to follow tbe patterns
llterein. The guiding principle in MIB engineer ing is lltat tbe MIB should faciliutte the common needs of most
managers.
9.4. NMS Design
We now rum to the design of an NMS server for a large telecom or enterpri~ network. We flfst outline the
requirements of such an NMS. This determines the architecture. Next, we go into details of tbe important
components ofthe server.
9.4.1. F'unctionall~equirc mcnts
The chara.cteristics ofa telecom or large enterprise network were dLo;cussed in Chapter l. Telecom networks today
provide a variety of:services including voice, data, Internet, and video. A large telecom network serves lOs to lOOs
of millions of subscribers. For example, lndi11, which has the fastest growing-telecom base in the world had 413
million subscribers in February 2009 (http://www.telecomindiaonline,com). Its two largest service providers were
Bharti Airtel with 90 million and BSNL with 80 million subs.cribers. India's telecom base is expected to double in
the next 4-5 years.
The NMS is expected to supporl the full ~:~~n.ge of tlUII, C<lnfiguration, accounting, perfonnance, and security
(FCAPS) functionality(Section 3.10). Based on these, the key requirements are given below.
Scalability. Typically, such a network has a large number of manageable devices including switches, servers,
routers, base station;;, multiplexers, etc. lllese mayrange in number in the thousands in a large·enterprise or Tier-3
telecom network to several million in the largest Tier-1 tek:..-com networks. In most nemorks, tbe number of
elements grows with time. By scalable we mean that the same NMS can be deployed in networks ofdifferent sizes
merely by changing the hardware·plalform. For example, if dual-processor servers with a 2-GB RAM and a 200·
GB bard disk are sufficient lOr a network wiili N element..s, a network. wiili ION elements may require a 16-
processor server vith a 32-GB RAM rutd a [.TB disk. This requires a software design that can expl.oit the
concurrency ofthe 16-proce$50r server.
Scalability is imponant to lite network administrator. Having invested in one NMS and having developed
experienc;: in us.
ing it, the administrator would expect the same product to oouseable a.~ the 11ltworkgrows in size.
For the NMS vendor, scahbility is imporlant for a different reoson. Developing an NMS is expensive, requiring
several years of development by a large team of software engineers. Ha.ving invested so much, the vendor would
liketo ma.ximize it~ revenue by selling the same product to many customers.

Heterogeneity. As the network evolves over many years, il encompasses a diversity oftechnologies, vendors, and
types of equipment. These may support different management protocols such as SNMPvl, SNMPv2, SNMPv3,
CMlP, etc. Some devices may use proprietary protocols. The NMS should easily aocommodate this diversity
without increasing the comple.xity faced by ihe operator.
Geographic Spread. We are interested in managing nel:vorks with a wide geographic spread, which has three
implications. First, the WAN links used to connect the NMS to distant NEs may have a limited bandwidth. say 64
Kb/s or less, compared to 100 Mb/s or more fur a lOOm LAN connection. This bandwidth may have to be shared
wHh subsCribers' traffic. Hen.c:e, tbe amountof management traffi.c generated must be limited. Second, the end-to-
end delay for an IP packet may be lOs or IOOs of mllliseco.nds or even several seco.nds compared to a
submillisecond on a LAN. Third, long-distance links are l.ikcly to fail from time to time resulting in temporary
disconnection ofsome parts ofthe network.
Bursty Load. Some activities such as polling itlnOctets furperformance reports aredone at regular intervals. These
present a steady, predictable load to tbe NMS. Other activities such as handling faults are unpredictable. They are
characterized by long periods ofquiet wilh short bursts ofactivity.
Figure 9.21 shows tbe number of events genernted in a live telecom network, measured at IS-minute intervals
during a 24-hour period. The minimum number of events during an interval is 10, the maximum is 947, and tbe
average is 153. See Jagadish and Gonsalves [2009a] for a more ·ex;tensive discussion of observed fault
character istics.ofa telecom network.
Flgltr< 9.21. Oceltr...UCt ur Flild! EVtiJtS1
.11. Tf t>k:atTd«:om Network durlog •2"-llou.r Period
It is generally too Cli.
'Jlensive to dimension the server hardwarefor the extreme peak load. Hardware is dimensioned
weU above the average load, but 'below tbe peak. NMS software must be designed m handle peak overload
conditions gracefully. It may te.mpomrily delay or discard less imporLant events, but it should not mil altogetbe.r.
Real-Time Response. Fault notifications require responses within a ·short time. This may range from under I
second to IOs ofseconds depending on tbe nature oflhe event. The response DillY be an automatic control action by
the NMS, or k may involve manual intervention by an operator.
Batch Processing. Performance monitoring, especially fur capaciiy planning. requires a period.i: analysis of large
volumes ofpolled data While imposing a heavy load on tbe server hardware, this should not be allowed todegnlde
the reaJ.t ime response.
Diverse Users. 1beNMS bas a variety ofusers. These include:

I. Administrators: These are experienced and privileged staff who have a high level of responsibility fur the
management of the network. They may perform sensilive tasks such as bringing a.major swilch online or
offline, refurmalting the disk in a server, granting permission to other NMS users. Ifa mistake is made in
any iiuch task, it could have serious repercussions on the operation of the network, even leading to
considerable financial loss.
2. Operators: Many staffperfurm rotnine operiltionnl tasks that street manageme.ntaspects ofllle network to a
lesser extent. These i.nelude generating traffic reports, diagnosing and repairing an individual port in a
switch, answering customer queries, etc.
3. Subscribers/Clients: Customers ofthe·network may be given access to see the healih oftheir acoess to lbe
network, to see reports of their SLA agreement such as bandwidth use, etc. They may be able to configure
some parameters oftbeir servi:e., e.g., whether or not an email warning is sent when they near their monthly
download limit. They cannot change anything else in the network or view other customers' infom1ation.
Clearly the NMS must have support for the creation ofa large numbers of users. each having different privileges.
The menus and commands that are avai table to each user should be limited to those that are necessary for the role
oftbat user.
Local and Remote Management. Much of network management Is performed remotely from the Network
Op~'I'Otions Center (NOC). However, there arc users who need to use theNMS &om othe·r locations. Subscribers
may be located anywhere in the network. A teclulician. who is replllciug a filulty hardware un.it, may need to login
lo ·the NMS from the field location to dlvert traffic from tbe fattlty unit, configure tbe replacement unit; and restore
traffic roltting. Accountants and top management may want to see reports on network resource use, expenses, and
gene.ration ofrevenue from theiroffices.
Ease·of Use. Network administration is faced with two challenges: one is the increasing complexity of network
eq11ipment and the other ·the high attrition rate of technical staff. Hence, it is important fur the NMS to have an
easy-to"use Ul. Increasingly, this is graphical (GU!) and may be browser based. At the same time, experienced
users may prefer cryptic commands and keyboard shortcuts that enable them to work faster than with a·point-and-
click interfilce.
Security. There are two aspects lo security; the first is the security of the network and network elements. This
includes providing secure access to network elements for privDeged administrators and operators, preventing and
detecting malicious attacks such as the denial ofserviee attacks, and monitoring and ensuring the CQnfidentiaJity of
sensitive traffic on the network.
The seoond aspect is the security of tbe NMS itself. Tbe NMS perforce llas to have access to every network
element. It can perform arbitrary configuration of net~vork elements. It stores vast amounts of romrnercially
sensitive dalll a·boutthe network operation. As such, it introduces a single point of vulnerability to the network: a
person who con gain unauthori~ access to the NMS may well have complete unfettered freedom to lllmper with
theentire network!
Data Management. With tens ofthousands to mil lions ofnelvork elements, each being polled regularly for sevcra.l
variables, the volume ofdata collected can be very large. Iflost; these data Cl!n never be recovered. CarefUl ba.cknp
ofdata is essential.
These data need to be kept online for 3-12 months and archived of!line for several years. ln some countries,
preservation ofcertain network data for several years is mandated by laws and regulations,
For a telecom network with 10 million subscribers, the typical volume of data collected is shown in Table 9.5.
(De~ails ofthe calculations are given in the exercises at the·cnd ofO:tis chapter.)
Tobit 9.5. Tyfli<al Dol• Storogt R•quirtrutnt for • !Om Substril><.rNttwork

Period 1Day 1Week 1 Month 1 Year
Data Volume 2GB 15GB 60GB 750GB
Note that the disk space requirement is 2-J times the data volume shown in the table. This is to account for inde:oc
files created by the database management ;-ystem (DBMS), temporary copies of data made by the NMS
applications, and temporary working space.
9.4.2. Architecture orthe <MS Server
We now e.xamine the architecture Wid major design aspects of the NMS server in light of ihe requin:ments
discussed in Section 9.4.1. In many cases there is no one correct decision, only design trade-of& where different
designers may prefer different·choices. This is the nature ofreal-world design. ln these·cases, we discuss the range
ofgood cboioes.
The NMS server hns to handle diverse tn.o;ks with very different characteristics. These include polling of
performance pammeters at regular internals, real-lime response to unexpe<:ted events, and a good user interface
(UI). It bas to deal with a plethora of device types. 1t is a large and complex software application and we hence
adopt a Modular ar.chitecnare [Bahrami. 1999). A set of closely related functions is grouped into a module. These
functions interactclosely and use shared data structures. The different modules interact relatively infrequently.
A typical architecture fur an NMS server is shown in Figure 9.22. This section draws many lessons from the
CygNet NMS [Gonsalves, 2000; www.nmsworks.co.in], which bas been deployed in several major telecom and
enterprise networks.
Frguo
't 9.22.. Ar<lollrclurr of an NMSS.n•tr
®

CMIP
TCPI UOP
IP

A number of modules are grouped around a central managed object database (MDB). The MDB CQIItains the
configuration infOrmation ofeach managed object. A managed object is typically anNE (router) or a subsystem of
anNE (inieriBce ofa router). The MDB contains the e<ents and perfOrmance data ofeach managed object (MO).
The MOB must be designed ror efficient access to large amounts ofda1.11.lt contains a code to validate the data and
maintain consistency.
The Diseovery Module L~ respons'ible fur automatically deiecting the presence of new NEs in the·network. lfthese
are of interest to the administrntor, the discovery module adds corresponding MOs to the MDB. 11te discovery
module is a part of the Conf~gurnt ion Manager, which also bas provision ror the manual addition ofMOs. The
discovery module also detects changes to the configuration ofanNE and updates the MOB accordingly.
The Fault. Manager (FM) receives notifications of evenls in 'NEs. It may also infer faults by analysis of datiL For
instance, by comparing measured throughput.on a link vilh link capacity, it can detect a congestion fault. The FM
notifies the operator through various means such as text, graphics, audio, etc. lt may also take automatic corrective
action to resolve a filuh.
One of the important functions of the Performance Manager (PM) is data collection. This is done by periodically
polling NE.s ror relevant performance data. Note that some of these data may be used by the FM as described
above. The other important functim of the PM is data analysis. Reports 11re generated to identifY bottlenecks,
analyzetrends in order to plan capacity upgrades, and to tune the network and system.~. Anomalies in performance
trends may also indicate security problems such as denialofservice attack.
Each module has two logical layers. The lower or core layer contains lhe business logic of the module. For
example, the logic of sending peri:>dic poll n'quests, processing the response, and updating the MDB is in the core
layer ofthe PM. The upper layer contahts the Ul. Typically, this is a graphical user inte.rface (GUI). It may also use
text, audio, video, SMS, and so on.
Functional modnles communicate with the NBs throngh the protocol layer. This layer may .support a number of
common management protocols such as various versions of SNMP, XML, CMIP, and also proprietaryprotocols.
9.4.3. Key 'Desigu Ueci!lions
Jn this sectim we describe key design decisions motivated by the requirements in Section 9.4.1. 11tis is fOllowed
by a detailed design ofthe functional modules.
The NMS server hasio perform 1118JlY functions. It deals with real-world.entities such as switches, base stations,
routers, servers, subscribers, and operators. It needs to handle the properties of these entities nod evenly relate to
them. It is natural to use an object-oriented design [Bahmmi. 1999]. Software objects correspond on&-to-one to
physical objects. This simplifies desig11, makes it easier to adopt the design to new requirements, and resuhs in
more robust software. Most NMSs are written In C++ or Java.
The design needs to be sealable. That is, tbe same software should be able to cater to a network of l00, l,000, or
1,000,000 elements. The design approach that aGCOmplishes this using the choice of hardware and software is
illustrated in Figure 9.23. Scalability can be achieved to a lin1ited extenl by using more powerful hardware.
Suppose that lOONEs could be managed using a server with a 1-0Hz CPU (Figure 9.23(a)). Replacing the server
with a 3-GHz Q>U may increase the capacity to 300 NEs (Figure 9.23(b)). Only limited scal.ability can be achieved
by this approach: today; 3 OHz. is the practical limit ofCPU speeds.
Fij:w·• 9.23.Stlllabl• O.sign Using Tbrrad.s and Process<!

Capacity: 100
sequential
(8}
0
C:300
Sequential
(bl
1 Gl:la Elrlomat SW1ld1 I
O)C • 2<0.0~0
Mulbtllre;~dod. MultJproc>eSJ
C:2400
Multithreaded
16GS
(c)
To further increase the capacity, we may consider a server with multiple CPUs sharing memory (a shared memory
multiprocessor (SMP)). Such SMPs are available inexpensively with up to eight CPUs. However, a sequential
program can use only one CPU. To use multiple CPUs simultaneously, a ooncurre·nt software design is needed.
This is achieved by using multiple threads ofexecution [Tanenbaum, 2007]. Each thread runs on one CPU and can
access the same shared memory. Thus, by redesigningour software to use threads, we could mllllllge I00 >< 3 " 8 =
2,400 NEs with an 8-CPU 3-GRz server (Figure 9.23(c)). These capacity increases are the ideal. In practice, the
aclltnl increase in capacity will be lower as one thread may wait for another one. or threads conflict to access the
samevariables.
Beyond a point, an SMP becomes prohibitively expensive. To further increase the capacity, we need to again
redesign our software to enable it to nan on a·cluster of SMPs interconnecled by a high-speed LAN. The software
needs 10 be structured a.
s cooperat·ing processes lhal communicate with one another using interprocess
communication (IPC) such as TCP/lP, RPC, Java RMI, or XMIJ8.TTP (.Tanenbaum, 2007]. With 100. 8-CPU
SMPs connected by a 1-Gbls Elherne1, the capacity of our server could scale up to 2,400 x I00 = 240,000 NEs
(Figure 9.23(d)).
Note that the numbers of NEs above arc 1be managed NEs only. The total number including unmanaged PCs,
telepbones, etc, may be one to tbree orders of magnitude larger. Tbe actunl capacity nlso depends on the polling
Interval. etc., .so the numbers in Figure 9.23 nreiodieative only.
The server needs to handle event notification in real time. It also periodically needs to generate reports. To as.orure
1hai real-time processing is not delayed by periodic batch processing, the former is given higher priority. If the
software is structured as threads and processes, priorities eao be assigned to these and the OS will ensure tbe real·
time respo~~W.
With a large number ofNEs and dallt saved online fur rnontbs to facilitate analysis, the NMS bas to deal with
enormous vo lumes of data. Most of the data are stnactured with weU-deftncd fields such as <NE id. timc stamp,
OID, vahte> for a performance parameter. Appending incoming daia to a flat file is very efficient. l:lowever,

retrieval based on criteria is very inefficient All major NMSs use an R-DBMS for dalll storage. Examples of
commercial R-DBMS produCls are Oracle, DB2, and SQL server. Open-source MYSQL and PostgrcSql produCls
are also commonly used.
We nexi consider the Ul. To minimim rraining costs and io allow non-technical people (such as accounlllnts and
top management) to use the NMS, it is normal to have a graphical user interfitee (GUI). Nowadays, the GUI. is
o.fteo browser based. This further reduces ·the .learning curve and ensures thai the GUI will run on a wide range of
desktop PCs.
The NMS needs to present a large amount of information to the operator. A well-designed OUI can Us.} color-
coded symbols and icons to present this information without confusion. Color code.s can be used to highlight limit
information that needs urgent attention. Ajudicious use ofaudio further improves the UT. Network admin.istration
Is a 24 x 7 activity. Many NMS servers have the ability to notifY the operator via SMS, pager, or telephone call
wiih iext-to-speech S)nthesis.
9.4.4. Discovery Module
In n large telecom nelvork, the details ofthe NEs to be managed need to be entered into the NMS datlibase. Doing
ibis manually is a daunting and error-prone lllsk. The goal of the diseovery module is to automate this lllsk.
Initially, the discovery module tries to find managettble clements in dlC network and add their details to tbeNMS.
Subsequently, ii periodically checks ea:b NE fur any changes in this configuration. The discovery module also
tries to determine lbe topology ofihem~twork.
Discovery supplelllCnts, but does not replace, manual configuration. For example, the NM'S could discover that a
router bas ten interfaces. Polling intervals for the interface traffic depend on the importnrrce ofthe connected links.
Discovery may set a default polling interval of 15 minutes. An administrator may set the intervals for imporlllnt
interfaces to 5 minutes. For a backup link, the administrator may change the interval to I hour.
The strategy used in the discovery process is to check a range oflP addresses for the presence of NEs using the
simplest and most generic possible techniques. When anNE is round, lbe discovery process attempts lo find out the
type ofNE and it~ characteristics by using more elaborate and specific techniques.
Configuring Diseovery. Discovery is controlled by a conf~guration file, which sets a number ofparameters. A 'basic
setofparalllCtcrs is shown in Table 9.6. Many more pamlllCters could be specified.
Tablt 9.6. Baok Olscovtr)' Paramtltrs
Parameter Value
IP addresses 10.0.0.1- 10.0.0.254,
192.168.0.0/24
Walt Interval 10 seconds
SNMP version vl
SNMP "public"
community
Discover types Router, server, switch
Description
Arange or list of tP addresses
Waiting time betwei!n discovery of sucoesslve IPs to mlnlmlte load on
the network
vl, v2c, orv3
A commonly use<! value
Onlyelements ofthese types are added to the MOB

TAble 9.6. UilSie Dlstovrry Paramrltrs
Parameter Value Description
Ignore types PC, UPS Eiementsof these types are notadded to the MOB
Ois<:overy Procedure. The flow chart oftbe discovery procedure is shown in Figure 9.24. "Cbeck if node present"
is normally done using ping. As ping is unreliable, 2-3 ping requests are sent. In some locatims, ping may nol
work because its ICMP echo request and echo response packets are blocked by firewalls. l:n such cases, attemptillS
to open aTCP connection to a port may be used. This is more expensive in terms ofnetwork bandwidth and CPU
resources on both ends.
Figure 9.24. Dbrove~• Pto<tduro

N
y
Gel.ntatfacos 1,..1o n'ICI
rqotlng lableUpcate MOB
Add lnterf~CflS to MOB
Update lopology

Inserting a newly disoovered element into the MOB usually alsp involves configuring polling for OIDs dependant
on the type ofNE, conf.guring a t.rap receiver and oUter event detcx:tors, and adding an icon to the pictorial map of
the network. Fioally, an administrator may be notified Ill roanually approve and possibly modify the pammeters
and settings for the new NE.
Checking for which management protocol is e.nabled is done by se.ndlng a series of requests to glean information.
For example, a typical.sequen.ce for SNMP is shown in Figure 9.25. ln the steps that check for the SNMP version,
il may be necessary to check for several possible authentication parameters. For example, suppose the read
community for PCs in a network is "public;" for routers it is "x375tz;" and for servers it is "private." For every IP,
each ofthese communities is tried until one is occeptt.'<l .by the agenL
Figurr 925. Oiswv<ry of 1111 SNMP Nod•
SNMPget(lp. v3 avth Info. sysObjedtd)
II respcnao th<:n 1-'e 1
5 ..a
Else SNMPget(Jp. v2c, community, sy$0bjectld)
11 msponse lllen noae Is v2c
Else SNMPget(lp. vi. community.sysObjeclld)
If msponse then node is v1
IfrOdeis vi, v2c or v3 then
lookup sysObjectld to detefmlne typeof node
Based on nooe type use SNt.IPget. SNMPgetnexi. SNMPgetbull< to retrieve
relavali O!Os and tables.
Rediscovery. Periodically, the NMS may check NEs that are in the MOB for any change in their configuration.
This proceS$ is rererred to as rediscovery. Some changes may be deteeted by the NMS during normal operations.
For instance, ifthe PM is polling an interface on a router and that intedilce is permanently disconnected. Poll; will
fail and the FM will show tlte interface status as down. The operator who disconnected the interface will notice this
and delete the interface from the MDB.
Suppose, however, that a new interfuce is connected to a router. This will not be detecte.d by tile polling process.
Similarly, ocw NEs may be conncx:ted to the network. A server that was serving as an email relay may be
redeployed as a Web server.
Rediscovery fbllows a simpler flow chart compared to discovery. We already know the management protocol and
aull1entication infom1ation and the configuration. Rediscovery mainly involves fetching the configuration
information from the NE and comparing it with the details in the MOB. Any new services or subsystems detected
are updated in the MDB and notified to an administr&or for review. Any removal of existing services or interfllces
is presented to an administrator for confirmation before deletion from the MOB.
Topology. The topology of a network depends on the interconnections between routers and switches. Hubs are
usually not SNMP-manageablc and are not included in topology discove.ry. During the discovery process, the
discovery module determines the type ofeach NE and hence idenfi.fies the romers and switches. It then obtains
topology infOrmation from the MIB ofthe router or switch (last two items in Figure9.25).
ln a router, every active intermcehas an IP address. TWs is given by the ipAdEntAddr MIB Variable(TabJe.4.8).
For eacb interfilce, the neighbor's lP address can be found in the i!ForwardNe.xtAop MIB variable (Table 4.11).
The variables ipAdEnWI.ndex and ipForwardlflndex in these two tables form the link. The l.fl'ype and ifSpeed
variables in the interface table give the type and speed, respectively, of the link between this router and the
neighboring router. Next, the discovery process is applied to each ofthe neighbors to further extend the topology.
Note ihniio avoid discovering a very large number of node;, many of which may be outside the domain of ihe

NMS server, discovery may be limited to a certain number of loops. It is also usually timited to the mages of lP
addresses tbat belong to theorganization.
When discovery encounters a loye.r 2 sw4ch, it can find the number of ports &om the dotldBaseNumPorts MIB
variable [RFC 1493]. lfthere are seveml switches in the network, the spanning l'ree uible (dotldStpPortTable) can
be used to find the topology of the extended LAN. Pilll!lly, discovery cnn find the MAC address of machines
connected to each port using the forwarding database (dotldTpFdbTable).
Figure 9.26 sbo''"s an example topology and information about the network tbat could be obtained automatically
through discovery. The diScovery prooess has created a ~imple map with·each link labeled with its speed and type.
The width ofthe lines is indicative ofthe link speed. Each interface is labeled with its lP address. The layout ofthe
nodes and links is arbih:8ry. Aller discovery. the NMS administmtor can manuaUy reposition nodes and links to
reflect their geographical positicms.
Agu..., 9.26. Examptt ofTopology Disrovtr)' of WAN Linla
t!I2.1E80.6 1!12.168.1 ' 511.96112.9
100M
EthErnet
64K
ppp
182.166.1.2
R
2M
HDI.C
59.56.172.23
Efficiency fssues.ln Figure 9.24 we showed a sequential algorithm that checks one IP address at a tim.e. Forany IP
that is not in use, the process waits for three pings to timeout, say 3 :x I0 = 30 seconds. Assume that for each
address in use the disCovery takes 5 seconds.
Table 9.7 shows the total time taken for discovery lOr different networks with varying percentages ofIPs in use. ln
the first row, we have one Class C network that has a total of nboui 250 a">Signable addresses. Of ·these, varying
percentages are actually used. Likewise, in the second row we have ten Class C networks. Consider too first cell in
the t.able. The total discovery time iscalculated as:
Discovery time =Number of IPs In usexsUtteSS time+ number ofIPs notin use • timeouttlme
~ 250 • 0.05 x 5 +250 x 0.95 x 30 seconds
= 62.5 +7,125 seconds ?2.0 hours
Tablt9.7.Tim• to C01nr>ltt• Dis<onry rqutntinlly

I C!anC •200
10Ciol1 C -:2.500
1 O..ss B• 65.000
teClast B·1.000 OCO
5%
20 1'11
200nt
216dy
3321dy
20%
1.7hl 121
lr
174hr 122~•
18Sdy 1S2dy
2ss 4 dt :mSdr
Note: Numbers in italics are days, normal font in hours
The other cell<i are calculated similady.
100%
O.:lhr
3 Skr
38dy
579dy
It is clear from Table 9.7 that sequential discovery is practical only for veiy small networks. During discovery, the.
discovery module spends most ofthe time waiting !Or the response or timeout. The CPU time for each IP thai is
tested may be a1 most n few milliseconds, while the network delay may be IOOs ofmilliseconds (sucoess) to IOs of
seconds (failure).
Hence, lt is feasible t.o have concurrent testing of several rPs wilhout overloading the NMS server. The discovery
module could transmit mes,ages to a number of IPs in quick succession without waiting for replies. Later, when
each reply is received, it is matched with thecorresponding requestand processed approprialely.
Suppose I00 £Ps are tested concurrently. The time to completediscoverydecreases dramatically as shown In Table
9.8. Par small networks, discovery takes a.few seconds tO a ti:w minutes. For a large network, tbe time ranges from
an bour to 3 days. By inc.reasing the concurrency, we could reduce these times further. For a network with 5% of
1.000,000 [Ps in use, i.e., 50,000 NEs, 3 days is acceptable. Keep in mind thai the administrator needs to verify and
perhaps correct the discovered elements, which would take much longerthan 3 days!
Tobit 9.8. Time lo Cmnplelr Oiscovtry wilh Ton Concurrtnl Thrtads
5% 20% 50% 100%
72 s 63s 44s 13S
10 Cia» C -2,500 719. 525~ 400 ~ 125~
1 OassB -e.oco 5.2/!r 4 5Pr 32hr 09/!r
16 Class 8 -1.0CO,OOJ 799hr 69.4hr 48:6hr 13.9hr
Note: Numbers in italics are hours, normal font inseronds
Thread Pool or Worker Pool A convenient method of implementing concurrent discpvery is by using a pool of
wor.ker threads (Figure 9.27). 1llediscovery controller createst.nsks from the mnge(s) ofIPs to be discovered, each
task containing one or a rew £Ps.lt adds these tasks to the Task Queue. Next, it crea'tes a number of worker tllreads.
Each of 1be workers picks up a uisk ftom the Task Queue when it is fi:ee. It execut.es the sequential discovery
algorithm shown in Figure 9.24 for each ofthe lPs in the wk. Whenever a worker completes discovery ofthe lPs
in one task, it takes anothertask &om the queue. Thus. all workers are kept busy until the task queueis empty.

Figurt 9.27. Worker Pool Designfor Conrurrenl Disrovrry
ContJOI
Oala
SNMPIICtv'.PIIP
'
'
''
''.
.''

'
'.'
'.
.
'
Note that the Task Queue is a. shared data stnccture and must be accessed by only one worker at a time. This
exclusive access can be implemented usi·ng semaphores or other mutual exclusion mechanisms [fanenbaum,
2007]. The Task Queue is accessed twice per task, once to add the task and once to remove it. Ifaccess to the Task
Queue is very frequent, the mutual exclusion overhead could become a bottleneck. To avoid this, the controller
normally bundles several1Ps in one 18Sk. E.g., with 1,000,001> addresses and I IP per task, the number of accesses
to the Task Queue is 2,000,000. lf250 IPs are bundled per task, the number oftasks is reduced to 4,000 and the
number ofaccesses to only 8,000.
The optimum number of worker threads depends on the range of IPs, the bardware configurailin of the NMS
server, and the load generated bYother modules. For flexibility, upper and lower limits on the number ofworkers
can be configured in the discovery parnmete.rs. The cont·roller then adjusts the acntal number in the pool
dynamically within these limits.
9.4.5. J'erformance M1U1ager
The PM has two major functions. The first is data collection, which is an online activity. The PM continually
monitors network elements for interesting perfurmanc~7related statistics. These may be processed and are stored in
a database. Example Statistics include iraffic on a link (iflnoctcts and ifOutoctels), rate of transactions bitting a
server, and CPU utilizrllion of a server.
lbe other ·major funl"lion is offiine analysis and report generation based on the collected data. A common
requirement is ana.lysis ofibe utilization ofa network link with projection offurther growth in traffic. This L~ DSed
to plan capacity upgradation before the link becomes a bottleneck.
Data Collection. The PM collects data fur several reasons. Da!n may be used for analysis oftrends i.n order to plan
capacity upgradation. In this case, the data are not needed immediately. Hence, dma collection coukl be done

offline. The agent or a lower-levelmanager polls the variables ofinterest and accumulates the values in a local file.
Periodically, say once a day, a. bulk transfer of the file to lhe NMS server is done. We refer to the lower-level
manager as the local data collector (LDC).
Data collection may be done in order to detect congestion or to implement quality ofservice(QoS). In these cases,
the NMS needs to take immediate action in case of u fnuh. Hence, online da111 collection is required. Here, the
polling is done from the server directly to the agent.
ln both cases, polk:d data nre stored in the same database table. Each poll record contains at least the following
fields:
NE: identification ofthe ageni, typically the DNS name or the IP address
Variablename: OlD or other name
Value; collected value
TimeSillmp: timeofpolling
We now consider some importanl issues in offiine and online data collection.
Offline Data Collection. Let us consider the fields in the poll record. The NE name used by the LDC and the
manager may be different. For elml11ple, the NE may have a local 1P address that is used by the LDC fur its polling,
which is put into the local file. When the file is transferred to the manager, the manager needs to modify this to the
name used by it rortlte NE, which may be a global address.
The timestamp inserted by the LDC is based .on its clock. There may be a skew between this clock and the
manager's clock. Since LDC.~ often run on low-end devices, the clock skew could be very large. The manager
needs'to estimate the skew and adjust the timestamps accordingly.The situation is made more difficult if the LDC
reboots in the mi!dle oftbe day and skews changes.
Finally, the manager needs to ensure that there are no duplicate records or lost records. After trruJSferring the day's
file, Lhe LDC should delete it and start a fresh file. However, suppose lhe LDC does not delete the transferred
records. The manager needs to check. ror duplicates by inserting a unique sequence number in every record.
Online Data Collection. For real-time performance analysiS, the PM pollseach NE directly for variables ofinterest
Sante issues need to be addressed:
Avoid overloading the server: The PM may be polling several variables In a large number ofNEs, e.g., I,000
routers each having20 Interfaces. There are four variables ofinterest in each router. Thus, there are 80,000 polls. If
polls are S}nchronized and each is done with a separate packet, the burst of80,000 replies within a shan span could
overload the server.
The CPU load depends on the·number ofpackets and thenumber ofv8riables. In fact the per-packet overhead due
to interrupts, etc., is ofl.en high. We can reduce the number of paokc.1s by combining a number ofvariables in one
SNMP get request. For exampl.e, an SNMP get response with one vnriabl.e may be 65 B long. If we pack four
variables fur one interfuce into one packet, the length may increase only to 140 B (compared to 4 x 65 ; 260 B for
4 packets). Second, the data collector can stagger poUs toavoid bursts ofpackets.
Avoid overloading the network: Suppose that ten of these routers are in 8 distant part of the network that is
connected to the NMS by 8 64 kbls link. Suppose tlte NMS polls all variables every 30 seconds and it uses one
packet of200 B for each interface. The resultant traffic on the link is (I 0 • 20 x 200)13013/second c I0.67 kb/s.
About 16"/o of the link bandwidth is used for polling only. In addlt·ion, traps, accounting, and configuration
messages will consume more bandwidth. This can seriously affi:ct subscriber traffic on this link. One solution is to
configure different polling rates. Only a few important interfaces are·polled every 30 seconds. OLher interfaces may
be polled once in 5 minutes or 15 minutes. This will reduce polling traffic overhead to 8 negligible level.

Avoid overloading tbe agent: Asingle CPU in a low..eod NE often performs the real functions ofthe NE (routing,
switching, printing, etc.) and processing ofmanager requests. Too many manager requests could overload the CPU
and cause its real functions to suffer. Mitigation techniques mentioned above Viii help 'thi.s problem al.so.
Poll Conf~gumtion. Different metric.s vary ru different rates. For a lilst-varYiog metric, say traffic on a backbone
link, it may be ne<lCSSllrY to poll the counters frequently, say once in 30 seconds-2 minuies. l11e free dL<JI space on
a server varies slowly. We may poll this only once an hour.
Hence, the data onllector should allow lhe poll period to be specified independently fur each variable on each NE.
There may be several variables being polled on one NE, possibly at different periods. To reduce the CPU sod
network load, the data collector tries to club several polls into o~ network packet, e.g,, one SNMPget-request,
command could aconnunodate I0-20 OIDs and their values.
Dynamic poll periods: Suppose a link is being polled at IS-minute intervals. If it experiences congestion, it is
useful to increuse the mte ofpolling to 5 minutes or eve,n I minute,. It is possible for the data collector to suppon
such dynamic poll periods. However, conditions for cbanging the poll period are usually related to faults,
aocounting, etc. Hence, the better design is to have the FM, a.s part of its bandling ofthe congestion fault, to rc>
configure the polling period fOr the variable of interest in the,data onUector.
A novel design optimizes both d1e accuracy of the collected data and keeps the network troffic and server load
within limits [Jagadisb and Gonsalves, 2009b]. The agent or LDC poHs data at a high rate and pushes it to the
NMS at a possibly lower rate. The LDC evaluates tbe error between the data lhat reach themanager nod lhe actual
data. It adapts the rate of pushing to the manager to keep the, error within a specified accuracy objective. Ln
addition, tbe NMS sends feedback to the LDC on its load and.the importance ofthis NE in relation to other NEs.
This factor, which changes dynamically depending on the faults in the network, is used to further adjust the rate of
pusb.
CQncurrency: In a large ~!work, the data collector could be polling several variables in each of IOOOs ofNEs for a
total of IO,OOOs of polls. If tl1e average polling period is say 300 seonnds, the aggregate rat.e of polling coukl be
100/secon.d. This could easily overload the CPU. Hence, the data collector fOr a large network should be
multithreaded and possibly multiprocessed. The worker pool design int·roduced in the discovery module (refer
Section 9.4.4) is approprillte here also.
Overrun: Ideally each variable is polled at precise intervals. For,example, ifa variable is configured for a 2-minule
polling interva~ the polls should take place ns shown in Figure 9.28.
Flgur• 9.28: Ideal Potting ftt 2-Mlnut• lnt,ervals
9:00
doPrlll (1111
Po/Q
904
I
9:00 9:08
In reality, polls may get delayed for a number of rea.sons. Owing to network loss/onngecSiion, the response to o.ne
poll may reach only after the next poll time. The CPU may be overloaded, especially due to a burst of limits. Fauh
handling is usually a higher priority than polling.
A poll tbat is scheduled for 9:02, may actually be executed at 09:02:25.ln case ofsevere congestion, the poll may
be delayed to 09:04:45, i.e., after the next sc,beduled poll time. Suppose polls are scheduled at precisely 2-minute

intervals, with one poll object being created for each poll. Under overload, a backlog ofpoll objects could build up
in memory. This may slow down the system. fun·her in.creasing the overload, and affecting the critical fault
handling. Ifthe overload persists, the NMS server could even cmsh.
The solution is to scl!edule only one poll at a time for each variable. When a poll completes, the next poll is
schedul.ed at the firSI nominal poll time in the firture. In Ute llbove example, ifthe first poll completes at 09:0 I, the
second poll is scheduled at 09:02. However, if the first poll is delayed.and completes only at 9:02:23. t.he second
poll is scheduled at 09:04. This t:actic ofskipping a poll in case ofoverload ensures that the data collector does not
further overload thesystem. Thepseudocode for static and load-sensitive polling is given in Figure 9.29 and Figure
9.30, respectively.
Figurr 9.29. StMtic Polling cuu Couse Systrm Ovrrload
doPo/1 (1v. poll)
(
poll rorOID
process value
schedule (i+ 1)I" poll at tstan + i x pol/Interval
}
Figurr 9.30. Load-srnsirivr Polling Algorilbm
doPo/1 (I" poll)
{
poll for OlD
process value
let k = (titOw- tr..)lpo/1/nteNa/
//k is the index of the next nominal poll
Schedule poll at tsran+k x po/f/nleNal
}
Database Scbema. Polled data are Slored in a database for ease ofaccess and analysis. In a large network, with data
smred for months or even years, the datlibase size can become very large (see Table 9.9). The dat:aliase schema
need to be carefullydesigned to ensure good perf
omuince even with these very large sizes.
Tablt 9.9. Ty(lical Growth of Collt<ltd Data
1 Day 1 Week 1 Month 1 Year

Tablt 9.9. Typl<al C ruwth of Colltclrd Daro
1 Day 1 Week 1 Month 1 Year
Number ofrecords 29m 201m 863 m 10,501 m
Database size 1.6 GB 11.3 GB 48.3GB 588GB
The minimum infonuation stored for each poll ofa variable is: NE name, Timestamp. Variable name. and Variable
value.
The performance ofreport generation depends on the indices in the poll reoords. Ofrhe four fields, it is nonnal to
selecl records by timestamp (show traffic on 20/06/2008), by NE (show transactions on www.server.com), and by
variable (show iflnOctets on several links). lt is rare to select by value. Hence, tables should be indexed on the first
three fields.
Assuming 4 8 per field and three indices, the size of each poll record is 28 B. To nccoum fOr ahe Ox4ces and
temporary copies, we assume 28 x 2 = 56 8 per record.
Assuming 10,000 NEs, 10 variables per NE, and an average poll period of300 seconds, we have an aggregate
polling rate of 10,000 x 10/300 =333 polls/second. Database sizes over various periods are shown in Table 9.9.
A good. DBMS is designed to perform well with the size of one table being up to a :filw million records and
occupying IOs-IOOs MB of space. Beyond these limits, performance degrades and it is desirable to split the data
into multiple tables. On the other side ofthe coin, having multiple tables makes programming more complex. It is
easier to select relevant records from a single table t113n from a set of tables. DBMS performance also begins to
degrade ifthere ore IOOs ofsimull8Jleously open tables.
The polled datacan bedivided into mulliple tables In several ways:
One table per NE
One table per variable (or OJD)
One table per day
Let us examine ibe performance implications ofeach ofrhese designs. We consider the number ofopen tables, the
size ofeach table, the time for insert (done for every poll), and the performance for reports (typicully done in batch
mode). We also consider the safety oftbe data.
With one table/NE, the number ofope.n tables is very lll{ge as all NBs are being polled, by say 10,000 open 1able.s.
The size of each table is modest and insert is fast as there is oo conflict between multiple polls. Reports rll3t
analyze da.ta a.cross manyNEs are tedious to develop. However, reports for one NE access only one table and
hence may mn efficiently.
Considering one table per variablll, the numbe.
r oftllbles is large but less than in the above case. The tables are of
moderate size resulting in good performance. Insert is fast. Almost any report would need to aeoess nl3ny tables,
resulting in aocess conflicts and poorer perfOrmance.
One table/day resuks in only a·few 100 tables. Further, a.ll lnserts are done in the current day's t.able only. Most
reports analyze past datu and. hence there is no conflict between such batch reports and the data collector's inserts.
A Jew online reports access the currem day's table and cause occasioll8J conflict.

Because ofthe structure ofa DBMS table, even a few bytes ofdma corrupted in a table or iiS index could result in
loss ofthe entire table. Hence, having asingle table is a.poor cboice. One wble per day is perhaps the best design.
Loss of one table does not lead Ill loss of all information about some important NE. With one table per NE, we
could lose all data collected about the most important NEI
Conclusions. Table 9.10 summarizes the·different designs and their implications on perfonnance and data safety.
For a small network, a single table is a good choice. For large networks, one table/day is often the best choice.
tbougb some administrators may prefer one table/NE.
Tabl• 9.10. CompArison of OiiTortnl OIIJ11S Scbrrna O.signs
1 Table
Space/r~ord 288
Number of open 1
tables
Insert Slow
1 Table/NE
208
Very large
Fast
1 Table/OlD 1 Table/Day
208 208
Large Few
Fast Fast
Reports 1 table, conflict 1 table, less Several tables, some 1 table, conflict for online reports, no
with Insert conflict confll'ct oonfllct for offline reports
Data safety Poor Good Good Very good
Note that in the l·table/NE, the NE name is the table name and hence need not be a column (and index). Renee, the
space per record is 20 B. Similarly, in the I table/variable case,the variable name is the table name.
Some NMS plalfonns give theadministrator the option ofconfiguring the number of wbles fur dru.a collection and
bow the polled data are split among Lbese tables. Once the choice is made it ~difficult to change as the code for
reports depends on the schema.lltechoice should be madewith due diligence.
9.4.6. F11ult Man.agct·
Fault management is the most important function of tbe· NMS: if the network bas foolts, pe.rformallCe and
accounting beoome almost irrele.vao1. Because ofthe unpredictnble nature of limits and their tendency to occur in
bursts, the design of the fuuli management module is especially complex. [fit is not done well, the NMS server
itselfcould fail when t.he network experieoces a burs1 offaults.
We first define the terms used in fault management. We then trace the path ofa fault through the system. Finally,
we 1ouch on some advanced topics such as root cause analysis (RCA).
Definitions. A mull is a problem in a network element or network link. E.xamples are: a system goes down due to
power fiUJure; a link fails due to a cable cut; a disk gets full; and congestioo on a link when traffic exceeds some
t.bresbold.
When 8 fault occurs, the NMS may detect it as an event. This may be done in diffurent ways by 8 variety ofevent
detectors. One form ofevent detector is a trap receiver tbal bandies notifications sent by the NE. Another form of
event detector is the poll manager detecting that an eleme.ot is down when a poll fails. This is notified to tb.e FM.

Asingle fault may result in several events in lhe NMS. For example, as SNMP traps are unreliable. the agent may
send the same trap repeatedly 10 ensure lhat the manager receives it. These redundant events are fihered out by the
e•-ent correlator.
When an event first occurs indicating the presence of a new fuult in the network, if lhe £1ult is of interest to the
operator, on alarm is created ns the mWJifesllltion ofthis fault. The alarm should remain in lhe NMS as long as the
fault persists. The alarm contains all the informatio.n about the fault and the actions taken by the operator or lhe
NMS in response. Ideally, for every fault of interest, lbere should be exactly one alarm in the NMS.
The alarm is brought to the attention of the operator via an alarm indiCation. The indication may be graphical
(change ofcolor ofan icon on the screen), audio, an SMS. tU1 entry in a log file. etc. The type ofindication depends
on tb.e importance and urgency ofthe·fault.
Sometimes, one fault may result in events !hat cannot be easily correlated. For example, if a link fails, lhe routers
on both ends of the link may independe.ntly repo11 the !BulL This results in two alarms being creilted in the NMS.
Such sintations are detected by thealarm corre.lator, which is a high-level tUJalogofthe event correlaror.
Path ofon Evem in the FM. ll1e first step in fuuli management is detection ofthe fuult event by the NMS (Figure
9.31). This is done by one or more ofa variety ofEvent Detectors in the FM. Difli:rent ~s of events and the
corresponding event-<letCoelion mechanismsare given below:
I. Notification: This deteetor receiv-es notification (such as SNMP traps) sen! by lhe NE and convens them
into event objects in the NMS.
2. Poll failure: When a sUitus or perti:lrmance poll request sent by lbe data collector in the poll manager rails, it
indicates a fauk in theNE. This is infurmed lo the PM, again by creating an event object.
3. Performance thresbold crossing: When the datll coUector polls lbr traffic variables such as itln Octets and
ifOutOctets, it computes lhe· corresponding rates. If any rate crosses a lhreshold, a lhreshold e.vent is
generated.
4. Internal escalation: When a fault occurs in an impo11an1 elemenL the NMS may set a tlme limit during
which tile faull must be attended to. Ifthis time limit isexceeded, an event is generated.
Flgure 9.31. Pat.h nf "" Evtnt thrnugh thf Fa1dt Man-agr.r
The next step is Event Pikering. An NE may generate event:s that are not of interest to lhe NMS. For example, a
router may periodically send a notification about inlerfuces that have not been configured. Any such event that
matches one ofa set ofconditions configured by lbe administrator is discarded by the event filter module.

Next. the event is processed by the Event Correlator. The event correlator first ol1eeks ifthis event is a duplicate of
an event in the Recent Events Table. The event may be a.n exact duplicate (e.g., a router sends n link-down uap
every 10 seconds as long as the link is down). The event may be closely similar to recent events (e.g., a link-down
trap is received and soon thereafter poUing ror itlnOctets on that interfuce tails). ln eiiher case the duplicate evenl
is discarded.
Since duplicate events may be· separated in time, the event correlator nwst examine all events within a time
window. Say, ifthe poUi.og interval is 300 seconds, the time·lag bet.ween the trap and the poU failure may be up to
300 seconds. In this case, the event correlator may examine events in a time window of 500 seconds. Ofcourse,
using too large a time window would result in tbe event correlator loading the NMS server unnecessarily.
The event eorrelator also has to coosider the possibility that the link state ltas changed three times instead ofjust
once. Consider the folk>wing sequence ofevents:
I. I0:31:05: Rourer7, lfl, Link down, Detector: Trap.
2. 10:34:32: Router7, 10, Link down, Detector: Status Poll.
Clearly both evenls are caused by the same physical fuult. in lnterfuce 3 ofRouter7. The first Is generated by the
Lmp receiver, the second by the data oollector's status polling.
AJI the fields ofthe two events match except the timestamps and the event de.tector. Hence, the event correlator
discards event (2). Nextconsider this sequence:
I. 10:43:08: Router7,lfl, Link down, Detector: Trap.
2. 10:44:15: Router7, 10, Linkup, Detector: Trap.
3. 10:46:10: Router7, 10, Link down, Detector: Status Poll.
lfwesin1ply compare fields as in the previous case, we would conclude that event (3) is a duplicate ofevent (1)
and is to be·discorded. However, a closer analysis indicates that the link went down. then crune up wiihio.a mimrte
and again went down a second time. The second link-down trap evidently did not reach the NMS. Event (3) sho1lld
be accepted.
These examples indiCate thatthe·event eorrelator should sean:h backwar~ in the Recent EvenLSTable until one of
Ibree conditions is met:
I. It fmd~ a matching evenl for thesame NE and subsystem (such as interface): the new evenl is discarded.
2. [t finds a different event fur UJe sameNE and subsystem: ihe new event is ncceph::d.
3. 11 reaches the beginning oftiJe time window without fmding a.n event for th.is NE and s.ubsystem: the new
event is accepted.
An event that passes through the event filter and eve.nt correlntor is now converted into an alarm by the Alarm
Registr.orion module. The FM .bas oow recognized the existence ofa new fault in tbe network. This alann will be
notified to the operator by suitable alMn indications. l11e alarm object is used to keep track ofactions take_
n by the
operator and NMS until the fauk is rectified (discussed be.low).lt is possible that one network mult results in tbe
creation of two or more seemingly unrelated alarm objects. The Alallll Correlntor and Root Cnuse Aru1lysis
modules address this problem. These are discussed at tbe end oft.his section.
Ala.rm Indications. The FM indicates the existence ofan alarm to the operator in one or more ways. TheJ>C include:
Viomal: d1e leon for the concerned NE changes eolor and maystart flashing. A PO!>'UP window may also be
used to display information about the alarm
Audio: A tone or other audible jndication is played. Using text-to-speech synthesis (TIS), information
nbout t:he alarm can be conveyed without the operator b.wing to oome nearthe display

SMS. phone call: if the operator is not in the NOC, tbe NMS could send an SMS or dial out to the
operator's pbone and play a message (usingTI'S). This is useful outside normal working hours
Ema.il: if the li!Uit doe.s not require urgent attention, the NMS could send an emalIto the operator
Log: in all cases, the FM writes a message to a non-volutile log o.n disk fur postcmortem analysis. The log
message contains at least a timestamp, name/address of tbe NE, prev.
ious state, new fluIt state, and
descriptive text
For ellQb fauU, which one or more of these indications are used depends on the nature ofthe fault, the severity of
the fault, the importance ofthe·faulty subsystem and NE, and other fauUs thatare curreut.ly pending.
Consider a router with IWO links, one is a leased line that connects the campus to the Imernet, the other connects to
a dial-up modem as a mUback in case the leased line fnils. Now, suppose that a periodic self-test of the modem
falls-an alarm ofcritical severity (red indicated by dotted line) Is generated (Figure 9.32). Soon after, the leased
line experiences congestion of major severity (blue indicated by dashed llne). If the color of the router symbol
reflects the highest severity ofany subsystem, the operator will learnofthe modem failure (unimportruu as it is not
being used) and the con~stion on the leased line (quite important) will be bidden. It is clear that the visualala.rm
i.ndication should reflect the high priority alarm rather lhan the high severity one, shown by the black line.
Flgut'f 9.32. Alltrm lndl""tlon for a Roultr with Two Simutlllo<Oil.!l Faults
Time
Sinoe these priorities are very much dependet:~t on the network, the design oftbe FM should allow these to be
configured by the adOlinistrator.Typically, the fOllowing configurabiJity is supported:
I. For each<NE, subsystem, event>, set the severiiy.
2. For each <NB, subsystem. event>, set Lhe·priority.
3. For each <NE., subsystem. event, severity>. set the alarm indication(s).
4. For each <NE, subsystem, event, priority>, set the alarm indication(s).

Of course, for ease of use, a good NMS will have pr~configured defuulls 1bat satisfy most cases. This
coo.figuratioo ofalarms is usually done through 8 GUl.
Alarm Finite State Machine. As we bave already seen, a fault has a lifetime during which it goes through several
stages. These include initia I occurrence, the operator noticing the fuult, corrective action being taken, Wid clearing
of 1he fault. The fuult is represetrted io the NMS by an alarm object. This alarm object must mirror the phys.ical
reality. The most natural design to represent this behavior is a fa1ite state machine (PSM).
An fSM has stales. events, and aclions. The object remains in a state fur some period of1ime. During thls time i1
may perform some action continuously. The FSM makes a transition to another state only when an event occurs.
The transition is (almost) in5Qltrtnneousand is usually accompanied by some action.
Let us consider a typical FSM for ·a link congestion fuuU (Figure 9.33). The stntes are shown by label.ed circles.
Events are the labels above the transition arcs. Actions are shown in itallcs belowthe arcs.
Figu•·• 9.33. Alarm Fluitt State Ma<hlnr
When a minor congestion event is detected by·1he PM, it creates a new allirm object and puts it in the alerting state.
The alert action taken on ihe transition is to cbange the color of the icon on the. screen (say, to orange), start il
fla~hing, and perhaps start pla}ing an audio message. The flashing and audio playback continue as long as the
alarm is in the alerting Sljlle to catch the operator's attention.
The next event is the operator acknowledging ·the new alarm. Tbe action taken is to stop the flashing and audio
playback. The alarm then moves to the pendingstate. The operator now starts to !like some oorrectiveaction. lllere
are several possible events I hat could occur next.
I. Servi.ce: The operator completes the corrective action and .
indicates ·that the fault has been sc.rviced. The FM
restores the icon co br to normal (green) and resolves the alarm object from its action list. Note that the
alarm object is usually kept in a.hisrory ruble in the DB fur future auditing and analysis.
2. Clear: The fault may clear on its own; say a temporary burst of noise on a link due to opera1ing ofwelding
machines in the vicinity. ln this case the icon is also restored to normal. However. the alarm object is kept
in memory inn zombie state. This is to give the operator n chance to return to the console and indicate the
corrective action ta.ken ifany. That is, the operatorshould service the zombie alarm.
3. Major congestion: The fault may worsen before il is corrected, which typically happens with congestion.
The initial event that caused crea1ion of the alann object .may .have been a minor congestion, say link
utilization exceeding 90%. Before congest·ion control measures lllke effect, utilization reaches 95% and 8

major congestion event is generated. Thi'l causes the alarms to go each to the alerting SLate with the color
changing from orange to red.
The FSM design lends itself to systemlllic, error-free programming. List all sLates and events. Create a transition
Lable with one column for each sLate and one row li>r each evem. Ln each cell of the table, enter the action to be
Laken and the next st;lte. For certain <state, event> pairs, the action may be to ignore Lhe event The next st;lte could
be the same as the current state. For the .FSM in Figure 9.33, the lists ofstutes and events are given in Table 9.11
and Table 9.12, respectively. Note t.bat the diagram in Figure 9.33 is a representation of this table in which
impossible or ignored <state, event> pairs are not shown. The corresponding transition table is shown in Table
9.13. Ln each eel~ the nction is shown in italics and the next state is shown 'below that In some causes, the FSM
may transition to different states depending on a condition (e.g, < Altering, Major congestion> and <Pending,
Major congestion>).
Table9.1I. Lj,t or AlormSt•tes
State Description
Initial Anew, unusedalarm object
Altering The alarm is registered In the list of active alarms. The FM operator has not v.et noticed the alarm. The FM uses
various alarm Indications to catch the attention of tihe operator.
Pending The operator has noticed the alarm. The FM is awaiting the results of corrective actions.
Zombie The FM is aware that the fault condition is dear. The icon color is normal. The operator has yet to indicate the
corrective action taken.
Oosed The operator and the FM are both aware that the fault Is closed. The alarm object Is returned to the pool of
unused alarms and is effectively In the initial state.
Tobit 9.1 2. Ll<t of f'SM EvtniS
Events Description
Minor congestion Utilization on a link exoeeds9~
Major congestion Utilization on a lin~ exceeds 95%
Oear Utilization on a linkfalls below90%
Acknowledge Operator invokes an FM menuor button to Indicate awareness ofa new alarm
Service Operator Invokes an FM menu or button to Indicate corrective action taken
1'oblt9.13.Transition Tablt for Alarm FSM iu Figure 9.J3
Initial Alerting Pending Zombie

TAble 9.13.TrAIISili611 TAblr for Alorlll FSM in Flgur·r 9.33
Minor
congestion
Initial Alerti~~g
Alert action Null
Alerting state
Pendi~~g Zombie
Null Alert action
Alertingstate
Major
congestion
Alert action If ~larm severity Is Minor then: If alarm severity Is Minor then: Alert action
Alertingstate Alerting action Alerting state Alerting a.ctron Alertingstate Alerting state
Acknowledge NA Pending action Pendingstate NA NA
Service NA NA Oear action Oosed state Clear action
Closedstate
Clear Null Oear action Closedstate Oear action Zombie state Null
Null: Ignore fhe event
NA: not appllcabte~thls <state; event> pair should never occur. Usually Indicates a software bug and should be logged and
reported to the s
.oftware developers.
Alarm Correlator and Root Cause Analysis (RCA}. A single faull. in a network may cause many alarm.s in the
NMS. l11ese may appear to be unrelated as they are assoc~1ted with different NEs. Consider an enterprise octwor.k
with a single WAN lirlk ton branch office. The br:anch office ha$ a LAN with$Cve·ml$Crvcrs that are malll!ged by
the NMS in the head office (Figure 9.34).
Suppose the WAN link fails. Router R1 will repon a link-down event via a trap. Polling of~. s~, ~.and s, wiU
fail and thedata collector will generatea nodefailure event for each ofthese. The operator will see a large number
of alarrus. The operator may spend time investigating lh~ or may even decide to ignore them, and hence may
miss the important alartn (the link fuilure in Rr ).

We have seen earlierin this section some simple meLbods to filter and correlate repeated or duplicate events. A11er
!he remaining evenLS are registered as all!rniS, the alarm correlator scarobes for multiple alarms that arise from the
same physical fuult. It then suppresses all but one oftbese to avoid overloading and confusing the operator.
Several correlation techniques are commonly used. AU have intelligence or reasoning behind !hem. The reasoning
methods di-ltinguish one technique &om another. We will discuss lhese approaches in Chapter II .
Similar to lbe·case with event correlation, related alarms may be registered 111 different times. The range in delays
depends on lbe polling interval and could be several seconds oo IO
s of mJnutes. Any alarm correlator could adapt to
this delay in two ways: ( l) It may favor immediate indication, in which case the operator may initiallysee the less
imponam alarm, which is replaced shortly thereafter by the more importam one, (2) It may opt for consistency in
UI and delay indication of any alarm until the e.nd of tbe correlation window. This coukl affect fauh rectitteatbn
time and should be limited.
The reasoning-based approaches described in Section I1.4 re.quire a significant amount ofoperator interventbn to
ensure that the associated IJbrary has sufficienr, but not too much, knowledge. Here we describe an efficient fully
automatic method for detecting the one alarm out ofa group ofalarms that represents the real fault, i.e., the root
cause alarm. This method is based only on the topology and stllle informlltion in the NMS database and uses a
novel graph a1gorithm [Bhatwcharya !1!.1!1., 2005]. It is implemented in the CygNet NMS, which is described in
Section 9.5.4.
lbe goal ofRCA is to show only one primary IIJarm for one fuuk and to suppress secondary alarms. This can be
accomplished by modeling the netvork as a grnph in which each NE is a node and considering the path taken &om
the NMS to reach each node. If node A can be reached.only via node B. A is said to be dependant on node B. If
there are alarms from both A and B, the alarm from B is the root cause and the alarm from A is suppressed. In the
branch office example in Figure 9.34. nodes~. S" Sl, and S3are dependant on node R,. Thus, the RCA algoriihm
presents only !he alarm in R1 to !he operator. As the other nodes are not reachable, their status is shown as
unknown (grey color) rather !hen up (green) or down (red).
Adependency relation can be defmed on!he network elements based on o;arious cril.eria. One c.ritcrion we consider
here is reachability from tbe NMS. The status ofnetwork element A depends on the status ofnetwork elemem B if
A can only be reached via B. The algorithm has two parts. The first part forms a reachability graph &om the
physical topology. lt also takes the full list ofstatus events from the NMS as iLS input..From !his list it determines
!he status ofindividual elemenLS in the network. A(ter the executbn of the first pan, the outpui is the real status of
each element in the network. The real status can be Up, Down, or Unknown. An element with real status Down is
the root cause for itsetf(and an alaan will be generated for this element). Nodes that are reachable ooJy via a Down
node have their status set to Unknown.
The FMcan also optionally generate alarms for Unknown clements. 11 can indicate for each Down node tbe set of
Unknown nodes that depend.on it. This may be useful fur !he operator to dooide on the order in which to attend to
each ofseveral Down nodes.
The second pan of tl~e a.lgorithm takes each Unknown node U and determines r.he Down node D that is on the path
&om tile NMS to node U. This Down node D is !he root cause fur U.The algorithm determines the set of Unknown
nodes {U} that are dependant on each Down node D. The number of nodes in this set gives the operator an
indication of how serious tbe failure of node Dis.
The RCA algorithm is efficient. In the worst case, it t;lkes 0(e) time wbe.re e is die number ofed.ges (links) in die
oetworltgraph.
Inn large·network with I,OOOs of links or more·, it is not fuasible to invoke the RCA algorithm for every alarm that
is registered. A convenient strategy that can be adopted is to maintain a count of the number ofa!arms registered
since the RCA algorithm was last invoked. When tbis count exceeds some threshold, the RCA algorithm is run.

Since different alarms have different importance, it is preferable to use a weighted count. The weight can depend
on the NE and component that generated thealarm, and the severity of the alarm. In additioo, there is a maximum
delay after which the RCA algorithm is run independent of the number of registered alarms (provided there is at
least.one pendingalarm).
For exampl.e, assume that weights are assigned as shown in Table 9.14 and the threshold is 16. ff2 ·critical alarms
occur. the RCA algorithm is triggered. H.owe.ve[, it takes 8 consecutive minor alarms or 16 warning alarms to
trigger the RCA algorithm.
Tabl• 9J4. Sampi• W•igbiS basrd on Alarm S.Curity for QCA luvocacioo 1l.rt$hold • 16
Severity Weight
Critical 8
Major 4
Minor 2
Wamlng
9.4.7. J)istributcd Management ApproachES
A small network can be managed conveniently by a s'ingle NMS. All des'ired functions ore performed by this NMS.
In a large network, a singleNMS may not be able to handle the load ofmanaging the entire network. Especially in
a geographically dislrib1rted network, tbe WAN links may have relatively low bandwidth and COl~d beoome
bottlenecks. Hence, it is desirable to have seve.ral managers. These mnnage.rs may all perform simHar functions, or
lhey may be functionally specialized. For example, one manager could perform only fault management, while
another manager is used only.for performance monitoring.
A distributed management application consis1s ofseveral manager applications running on different management
stations. Each manager performs its management functions either by directly interacting with agents or indirectly
viaother lower-level managerS. Distributed manage.ment can be classified into categnries ranging from centralized
management 81 one end of the spectrum, through weakly dislributed, strongly distTibutcd, to cooperative
management at the other end [Meyer, 1995].
In the cenlnllized and weakly distributed paradigms, there is a well-defined hierarchy ofmanagement stations, and
a manager can delegate tasks only to those strict.ly below it in the· hierarchy. In the strongly distributed and
cooperative paradigms, horizontal delegation is also allowed.
Another issue is the selection of a suitable management technology to implement the paradigm and whether
delegation of management 'tasks is statio or dynamic. For weakly distributed systems, it is cnstomary to have static
code mnning at various lower-level managers. Each manager knows the syslem being managed and is statically
configured to manage il. A lower-level manager can execute a predetined task when requesled by a higher-level
manager.
The dynamic delegtuion of management functions to intermediate-level managers allows more flexibility [Meyer,
1995]. Management operations can be instantiated by higher-level managers by downloading or transtbrring code
to remote mruJageme.nt stations on the fly.

Multitier Architecture. In choosing a multitier archilecmre, there is a trade-off between flexibility and ease of
implemenuuion and deployment [Vanchynathan .£l...Jl.l., 2004]. A strongly distributed or cooperative architecture
permit~ almost unlimited flexibility, while a weakly distdbuted (hierarchical) architecture is much easier to
implement correctly nod efficiently. ln particular, wilh the restricted communication and links between managers,
it is straight rorward to ensure consistency of data that may he replicated in several managers. TillS is much harder
to aChieve with strongly distributed designs. Further, most network operators nod enterprises 1111ve well-defined
hierarchical structures for their networks and their personnel.
Topology. We partition the set of elements to be monitored into groups of manageable size based on some
criterion, say geogrnphical. A manager process monitors each group and these processes constitute the lowest layer
oflhe management architecture (Figure9.35).
Flgw·•9.35. Ultn>rcbkal Multillrr M•n•getuellt
./
/.(
/ !
GG8G
One or more managers that run managemeot processes at higher levelsin the hieraroby area paren1 ofeach ofthese
management stations. This concept can be extended to as many layers as required.
To ensnre predictable behavior, each cluster of network elements can have at mo·st one parent, i.e, exactly one
manager. Ifwe represent each management sullion by a vertex and draw a directed edge (i, j) between two vertices
I and j, ifi is managed byj, tbe topologyofthc resulring network corresponds to a directed ac)~lic grapb (DAG)
[Horowitz, 1995].
9.4.8. ServerPlatfonns
The NMS server.requires two software platrorms, namely the OS and the DBMS. The choice of these is important
as they affect the development effort, performance, securily, reliability, and cost ofthe NMS server. Oncethe OS
and DBMS are chosen, the server design and implementation tend to become specific to these. Changing these at a
later date is c<>stly and time<onsuming. The platform mus1. be s18ble, of modest cost, and with a guarantee that it
will be support·ed ror the foreseeable future.
A detailed comparison oflhe available platforms is beyond the scope ofthis book. We would like to mention the
trend of open-source platforms that elm compete with commercial platforms in all respects. While in the paqt ihe
designer ofa largeand complex software application such ns an NMS server was constr.aJned to run iton one ofthe
commercial platform~. today, increasingly we find designers opting for open-wurce platforms.

Operating System (OS). The OS must suppon !breads, processes, and shared-memory multiprocessors. It must
support very large RAM and disk and a variety of peripherals. h must bave a good programming interface for
access to and control ofits functions. It must efficiently suppon a variety of programming and scripting language
chosen by the designers. lt must have available a range ofthird-party software too~ components. and libraries.
Several popular server operating systems today are Linux, various flavors of UNrx (Sun Solaris, IBM AfX,
HPUX, MacOS X, FreeBSO) sod Microsoi;i Windows. All ofthese meet the requirements stated above though to
varying degrees. Linux, FreeBSO. and NetBSO are popular open-source server OSs. The others are commercial
(Sun Solaris has an open-sburce version available).
Database Management System (DBMS). the DBMS must efficiently support very large amoums of data This
includes hundreds of tables and IOOs of miiUons of records. The DBMS must suppon transactions. It must have
good administrative tools for creating indexes, recovering from table corruption, taking backups, and especially
performance tuning.
As with the OS, tbe designer has a choice· of several high-quality DBMS _
platforms, both commercial and open
source. The viable open-source platforms are MySQL and PostgreSQL. Commercial platforms include Oracle,
IBM 082, Microsoft SQL Server, and Sybase.
9.4.9. NMS Client Design
We now briefly touch on the design oftl-.e· client application that enables users ttl access the functions ofthe NMS.
Recall the requirements for diverse users, ease of use and locaVremote manage~~~ent capabil ilies described in
Section 9.4.1. Since different users may have to login to the NMS from widely dispersed locations, they need to
have tile client application software nanning on their local terminal Nowadays, the terminal is usually 8 PC, which
is capable of doing substantial processing involved in the 01. This iocludes providing a window manager,
rendering of graphics, generation of audio, etc. Broadly speaking, there. are three approaches to the client
application: a dumb terminal, a rich client; and 8 browser-base-d client. These are elabomted below.
Terminal C lient. A "dumb" cbamcter-oriented terminal is used to login directly to the NMS. Terminal emulation
software such as xterm and putty may be run on a PC or server and connected to the NMS server via ielnet or ssh
over a TCP/IP connection. All software functions are performed fully on theserver, including ed.iting ofcommands
typed by the user and rendering (c-olor, boldface) of the text on the screen. Termin.1l clients are useful when the
user is at a remote location with access to only low-end tenninals, or they are sometimes preferred by vete~:~~n
administrators and operators for reasons offamiliarity. Almost any termion~ PC, or server is capable ofbeing used
as a terminal client as is.
Rich Client In this case, tbe client PC runs a special client application that is designed to work with the NMS
server. Tbe client application is usually GO! based. Besides generic GOl functions such as windows, icons, menus,
and a pointer, it may include significant NMS funct iortality. For example, given a t:ab.
le with the details ofihe NEs,
lhe client application may be responsible for generating a geographical map and overlaying on it icons for each NE
and network link. Likewise, the client may allow the user to sort lists and tables on various criteria without the
intervention ofr.hc server.
A rich c lient is usually written in an object-oriented language with good GUI support Perhaps the most popular
language fur rich NMS clients is Java, with C++ and C# also being used.
While tbe rich client can give a very powerful UT and nearly instanl8neous response to many user commaods, ~
suffers from two drawbacks, the first being ponabiHty. T he client application may nan on only one OS a.od
sometimes only one version ofthat OS. Thus, the user bas to ensure that bis'ber PC bas lbe right OS. If the client
application is to run on a variety ofOS platforms, the NMS vendor has to invest a substlintial amount. in so~vare
development and testing on each of these platforms. This has to be repeated wiib every new release oftbe client
application.

Asecond and more serious problem is compatibility with the NMS server. As new verslons ofthe server and c1ieot
are re.
leased, perhaps indepeodcntly of each other, the user has to ensure that the right version of the client
application is installed on the cliem PC. In some cases. the wrong version simply does not work, which is an
annoyance. In other cases, the wrong version appears to work but due to subtle incompatibilities, it performs ihe
wrong functions. For instance, when the server indicates to the client that NEs hnve failed, the client may display
them in g:ree.n (normal) instead of red due to an incompatibility. This is much more seriom; as the operntor will
ignore the fault.
Thesituation is aggravated when an operntor needs to login to severnINMS servers in differcru regional networks.
The servers, from the same vendor, may be of different versions. The operator's PC will need to have several
versions of the client application installed and the operntor would have to run the corresponding client application
depending on which NMS server s/he is working with!
Browser or Web Client. The browseror Web client promises to conthine the advantages oftbe terminal and rich
clients without their disadvantages. lt is rapidly becoming de facto fur NMS clieats (and fur many other
applications also). 11le browser cliem provides all its functionality through the GUI ofa Web browser such as
Firefux, lnten~et Explorer, or SafurL (Firefox is open source and runs on almost any OS platfurm, Internet Explorer
runs only on Microsoft Windows, and Safari Is supplied with MacOS X. The NMS server includes a Web server to
wbich the user coonecls via the browser. The NMS server throws up HyperText Markup Language (HTMl.) pages
lO tl1e browser. For a better user experience, the 1:ITML pages may include some client-s.ide processing through
JaV!lSQ"ipt. Network. maps and icons are usually provided using Ajax.
Since there is no software installed on the client PC, tllece are no issues of version !noompatibilay between tbe
client and the server. Any client-side NMS processing is done through Jav<ISCript code that is downloaded in the
HTML page. It is oat stored on the disk of the client PC (though it may be cached temporarily to enhance
performance).
Today, browsers are ubiquitous. Almost any PC has a good, recent browser insllllled. Many mobile phones,
including some low-end models, can run a browser, though t.be smaU screen limits t.he amount of information t.hat
can be presemed. Almost everyo.ne who uses a PC and the lmernct is familiar with the use ofa browser. Hence, the
trnining effort for new users is greatly reduced.
Owing to differences in the way in which different browsers render an ATML page, the problem ofportability to
different browsers is still an issue, albeit a much smaller one than tharof port11bility of rich client applications. For
instance, a daLa entry fonn in which the labels aod boxes are aesthetically placed in one browser may hnve so01e of
theseGUl componeDLs overlapping in another browser. So, tbe server needs to deteonioe which browser the user is
using and feed HTML pages that are tuned to the peculiarities of that browser. Likewise, Javascript oode thlll
works on one·browser may not work on another browser.
Fornm.ately, the incompatibilities between browsers are decreasing and are well-documented. Also, there are a
variety of open source and proprietary code libraries available that permit the developer to write code thnt works
equally well across avariety of browsers.
9.4.10. Smnmary: NMS.Design
Starting from tile requirements fur management ofa tel.ecom network or ·alarge enterprise network, YC· derived U~e.
architecture for an NMS server. Atler some general design decisions, we discussed thedesign of the mai.n modules
in an NMS server, the.discovery module, PM, and the FM.
lbe FM is tbe most complex oflhe modules in nn NMS. lbis is because it has to deal in real time with a wide
rnnge ofevents that occur at unpredictable times. Rapid muh detection aod rectification is ihe key to the operation
ofa network.The PM is especially relied upon when there are serious mulls in the network. Atsuch a time, the FM

would experieoce a burst in processing requirements. The design oftbe FM needs to be especially careful to ensure
that tbe NMS itselfdoes not fail due to overload during such periods ofsevere network problems.
We traced the path of an event through the PM. We eXplained different methods used to indicate tbe fault to the
operator and the various alann Slates. We explored assorted techniques for the correlation ofseemingly unrelated
events and alarms. These range fro m the simple matching of fields in event records, to sophisticated AI and gJ:Bph
algorithms.
Finally, we discussed approaches to distributed mllllllgement. This enables scaling ro very large neiworks.lt nJso
mirrors the structure oftypicl!llarge organizations.
9.5. Nctwol"k Management Systems
So far we discussed the use ofsimple system utilities and tools for management. This was followed by a detailed
examination of the design of a h.igb.-end NMS server. ln tbe rest of this chapter we will deseribe several
commercial and open-source NMSs. We start with the management of networks, and then cover management of
systems a.nd applications. ThJs is fOllowed by enterprise IIlliJ18gement and telecommunications network
management. Finally, we describe approaches for distributed managemem.
9.5. 1. N~twork Management
A network consists ofrouters. switches, and hubs connected by network links. Servers, workst.ations, and I'Cs are
connected to LANs in the network. Various access technologies may be used In network malll!gement; we 11re
primarily interested in the bealtb and perf
ormance of the routers, switches, and links. We may also monitor the
health ofse.rvers.
The first task involved in network management is 1he configuration ofthe above network elements, their agents,
and tbe NMS itself. This includes discovery ofnetwork elements and tbe topologyofthe network.
Daily users ofNMSs are people in the NOC who do not have lhe same engineering background as those who
designed and implemented the systems.Therefore, ea.o;e ofuse is an Important fuctor inthe selection ofNMSs.For
csample, an operatordoes not constantly sit in front ofa monitor and watch for failures and alarms. Tl1us, when an
alarm goes off, i1 should attract the attention of the operator visibly, audibly, or both. II should pre.sent a. global
picture ofthe network and give tbe operator the ability to "drill down" to tbe lowest level ofcomponent fllilure by
successive point-and-click operations ofthe icon indicating an alarm.
Figure 9.36, Figure 9.37, and Figure 9.38 show hie.ra.rchical views of a nclvork testbed at the NMSLa'b, liT
Madras, which were captured with a CygNet NextGen NMS. (The IP addresses ofthe nodes have been changed for
security reasons.) Figure 9.36 shows the global view with ·network segments and numerous domains behind routers
and gateways. Figure 9.37 Is obtained by clicking the mouse(also colloquially referred tons drilling down) on the
network segment icon 192.168.9.0 in Figure 9.36 and shows the nodes thatare prutofthat private LAN.The.LAN
has a switch (SW-1 I) connected to two routers RTR-1 , and RTR-2), and a few other lP hosts. The port details on
the switch SW-1 I are obtained by drilling downon tb.e SW-1 I icon in Figure9.37. Tile result shown in Figure 9.38
contains 12 ports, some ofwhJcb are free.
Figurt 9.36. Glob~t VIe>~ of Nttwork

.~··~··
IN I&&~ AI
u
.-:;)
Flgul'f 9.J7. Oouia·lu VIew
·.::)
,,.
... ..

,_,..... .......h !... _u..w,
. c ~ ;-,-;-:--:::---:--==--:---:----:--::-:--.=--,
l'iguc·•9.J8. l.lllt rfii<<S Vltw
..
.. ..""
.,

u
·~
'••ffu.,........-~1&
Next, the fault management capability ofthe NMS mustsup·port monitoring ofthe·health ofthe NEs and links. In
an lP network, this is usually done using ICMP ping and SNMP get messages. The NMS reports fRuits to the
operator in a variety ofways depending on t he nature, severity, and i.mportance of the fault. It may assist in the
rectification ofthe tault.
The NMS musi support perfom1Gnce nllll'>lgcment especially of the expensive WAN links. Planning and
management reports keep upper-level management apprised of the status of the·network and system operations.
RepOf'ls in tltis category include network availability, systems availability, problem reports, service response to
problem reports, and customer satisfaction.
Performance management provides traffictrend reports to enable the network administrator to identey bottlenecks.
The adm.inlstrat.or can lake action to alleviate the bottleneck., such as re-routing traffic via an abemnte route, or
changing priorities fOr different classes oftraffic. Performance reports help the administrator see k>ng,-term traffic
trends in order to plan capacity expansion in a timely and cost-eff<:ctive manner. Trends in traffic should add.ress
traffic patterns and volume oftraffi.c in internal networks, as well as extema.l traffic.
Accounting nutn.agement is probably t he least developed full((tion of network management applications.
Accounting management couJd include individual bost use, administrative segments, and external traffic.
Accounting ofindividual hosts is useful to identify some ofthe hidden costs. For example, the library funCtion in
universities and large corporations mnsumes significant resources and may need to be accounted for functionally.
This can be doneby using the RMON statistics on hosts,
Thecost ofoperations lOr the Information Management Services department is based on the service th.at it prov.ides
to the rest ofthe organization. For planning and budget purposes, this may need to be broken into administrative

group coSIS. The network needs 10 be con.figured so tbat all traffic generated by a department can be gathered from
monitoring segments dedicated 10 !hat department.
External traffic fbr an irun.itution is handled by service providers. The l8riff isnegotiated with the service provider
based on the volume oftmft1c and tmffic patterns, such as peak and average tmffic. An intemlil validation of the
service provider's bill1ngis a good practice.
Security munagcment is both a technical and no administrative issue in infbrmation management. lt involves
securing access to the network and the infOrmation flowing in the network, access to dala stored in the network,
and manipulating the data that are stored and flowing across the network. The scope of network access not only
covers enterprise intmnet network, but a!SQ the lnternetthat it isconnooted to.
Security manage.ment also covers security of the NMS itself. The NMS database co.ntaim a wealth of often
confidential information about the organization. This must be made available to authorized personnel, but kept
away from all others. Likewise, a user of the NMS·could reconfigure NEs throughourthe network. Hence, login to
the NM.S must be carefully controlled.
Thus, ·network management involves the complete FCAPS spectrum ofapplication functions defined in Chapter 3.
Configuration, fault, and performance manrigementnre fuund in almost every network management deploymenL In
some cases, the NMS is also used (or security a.nd accounting management.
OpenNMS. This is an open-source NMS (http://www.opennms.org), which claims to be 'the first project aiming to
build a complete enterprise-class open-source NMS. OpenNMS is writ1en largely in Java and has a browser-based
Ul. lt is primarily used fbr managing SNMP devices. It is used to manage small networksofunder25 NEs to large
networks with over 80,000 NEs.
The major functional areas covered by OpenNMS are autodiscovery, status polling ofNEs, perfonnance polllng,
and fault management. Reports are provided using the JFreeCha.rt package. Much of the operation ofOpcnNMS
can be customi2ed by the user by menns of filters. A filter consists of rules, each of which is essentially a
simplified form ofan SQL statement. 11 configures how the component of the NMS behaves. For .example, !.he
notification rules control whether or noi a received event triggers a notification'to the user. Fikers can he added to
control autodiscovery, to specify the list ofLP interfaces ihat are included in dalll collection, polling. etc.
Unlike many commercial NMS products, OpenNMS does not have a graphicnl map fOr the display oftbe NEs and
their status. T he designers of OpenNMS believe that seasoned network administtators prefer to see event lists.
OpenNMS provides event lists grouped in vnrious convenient ways. On 'the maio WebUI pagethere is a "real-time
console" (RTC) that reflects the sUi!liS of categories ofdevices. These categori.es reflect groups of devices like
database servers, We'b servers, etc. However, anything in the database can be used to create acustom categQry list,
and grouping devices by location, building, vendor, IP range, etc., is very common. The categories Jist foUows a
basic tenet ofOpenNM.S; once conf.igured, it should be simple to use and as automated as possible. As new devices
are added, 'the categories automatically update. There is no need for manual customization, such as would be
required with a useful map. (There is a group of developers working on a map, so !his may becomeavailable in due
course.)
By default, the .
FM reooives SNMP Imps. Other event detectors can be configured through XML configumtion
files. When an event is accepted, it results in a notification to the user, which can be on-screen, via email, SMS,
etc.
ln keeping with the philosophy ofbeing utiiJtarinn, OpeoNMS ha.s a vnriety ofreports. Most are simple tables with
some graphs. They lack the frills that may be attriiCtive to a novice, b1rt coolain a wenlth ofinfOrmation in a format
that is eaSY for a network a~inistrator to comprehend.

With OpenNMS, the user bas the ability to do comprehensive monitoring of a network at the price ofjust the
server hardware. llte NMS is customizable by the network administrator without any programming. As with aoy
open-source product, the emerprise ha~ the comfort that it could always get unusual customizations done as the
souree code is freely available. Currently, OpenNMS supports F, P, and part ofC in FCAPS. With the on-going
eflbrts of the developer community, it is likely tl13t other functiorl31 areas will be covered in future. Commercial
support is also available from the OpenNMS Group ti;>r enterprises rhnt need it.
9.5.2. System noel Application Munugcmcnt
Network management addresses only ibe managin.s of a llCtwork (i.e.. managing the transport of infOrmation).
Sys:tem managemem deals with managing system resources, which complements network management For
example, ping is used to test whether a bost is alive. However, we want to know more about the usc of system
resourees on the host, such as the amount ofCPU use on the host or wbether a specific application is running on
Ute bosl.
Historically. enterprises bad two separate and diSiinct organizations. The telecommunications deparunent tookcare
of communications, giving rise to network management. The management of inforDI3tion systems (MIS)
department rook care of the computers, a task that involved sysre.m management. However, in the current
distn'buted environment of client/server arcbitecture, the computing depends heavily on tbe communication
network and the distinction has disappeared. System and network management now fi>rm 11 single umbrella, headed
by a chief information officer. System and network management are beginning to be considered together as a
solution fur information managemeot issoes and problems. System managemeot tools, which used to be custom
developed, are currently available as commercial systems and are being integr'Sted with network management
System management tools mo.nitor the perfunnance ofcomputer systems. Some parameters that can be monitored
are (I) CPU usc, which measures the number ofprocesses that arc running and the resource consumption ofeach;
(2) status ofcritical background processes (called daemons in UNIX terminology): and (3) application servers such
as the Simple Mall TransferProtoool (SMTP), File Transport Proroool (FTP), and Domain Name Server (DNS).
Syst.em management may also include backup of server databases, desktop workstations, and operations support
systems that support operations such as help desk and trouble ticket tracking.
Sevcml UNIX-based tools can be used to monitor systems. Such tools are constantly evolving and are upduted on
Web sites that are used to !nick them. http:!/www.slac.stanfi>rd.edu/xorginmtf/nmtf-tools.ht·ml is a site a~'tive from
1996 thatprovides a oomprehensive li!.-t ofoommercial and open-source networkmanagement tools.
High-End System Management. The Computer Assooiates (CA) Unicentcr TNG and Tivoli Emerprise Manager
TME I0 are two integrated systems solutions availnble commercially [WNet]. Both solutions offer features that
can 'be classified as high end and thus require the vendor's on~oing active participation. They meet the
requirements of large enterprises, particularly as dtey are offered as integrated solmions, which we wi.ll discuss in
Section 9.5.3.
Low-End System Management. System management of hosts can be ncoomplished by installing simple and free
public domain software and configuring it to local system management.
Nagios. This is a fairly comprehensive open-source NMS (http://www.naglos.org). The project has been active for
over lO years so il is stable-.The design is scalable and e<Uensible.
Nagios provides the basic network management features. These include smlus and perfom1ance polling, fault
ba.ndling, and configurailin management. The FM can indjcate lilults via a graphical map, color-coded event lists,
and email, pager, and cellpbone. It allows the administrator to schedule Lhe downtime of hosts, servers, and the
network. The reporting feature supports capacity planning.

Unlike OLDer NMSs, Nagios does not have built-in mechanisms for polling. lnstead, it relies on external plugins.
These can be ex~utables or scripts and hence give subsLantial Oexibility. Nagios by defaull has support for
managing routers, switches, and other I:P network components; Windows, LinlLx, UNTX, and Netware servers;
network printers: publicly available services such as HlTP, FTP, SSH, etc. With its extensibl.e design, Nagios has
more ll1an 200 community-developed plugins available.
It has a rich Ul. which includes a map (unlike OpenNMS described in Section 9.5.1 ). Samp.le screen.shots are
available at bn·p://www.nagX>s.org/aboutlscreeoshots.php. Tbe Ul is customizable to each user. This facllitmes
specializationand ats:o helps maintain security ofscnsit.ivc information.
As with OpenNMS, Nagios is a good choice for a small organization that cannot afford a big-budget commercial
NMS. lt is also suffic.
iently comprehensive and scalable that even large organizations use it. The Nagios Web site
claims that it can handle networks of over I00,000 NBs. Given the high overhead of the external polling
mechanism. the serverhardware would be very expensive ifall the 100,000 NBs are polled.
Big Brother. A well-known low-end system management product is Big Brother [MacGuire S]. Ah.hough it has
very serious limitations in terms of both platforms and functionality, it may be adequate for srnnll and medium-
sized oompany networks.
Big Brother is an example ofsoftware d1at can be implemented with relative ease to manage system resoun:es and
is Web based. A central server on a management workstation runs on a UNIX plat.filrrn and clients on managed
objects. Big Brother is wrinen in C and UNIX shell scripts and hence can be nm on multiple platfurms. The central
management station presents the status ofall systems and applications being monitored in a malrix of colored cells,
each color designating a particular status. It supports pager and email functiOrl$ ihat report the occurrence of
alarms. Software can be downloaded and modified to meet local requirements for ihe operations, services, and
applications to be monilored.
Big Brother performs the dual function of polling cllent.~ and listening1o periodic status reports from cl1entS that
arc UNIX based. Polling checks d1e network connectivity to any system. Client software periodicaUy wakes up,
monitors the system, transmits information to the central server. and ihen goes back to sleep. Textual details can be
obmined on the exact nature ofa problem. The systems are grouped for easeofadministration.
9.5.3. E ntc11>risc MRmtgcment
We will ne.xt describe the two commercially available integrated sokrtions to system and network management.
The two solutions are oflered by two vendors, Computer Associates and Tivoli, the latter has been OO<Iuired by
IBM. Both partners with several NMS •-endors provide integrated solutions.
Computer Associates Unicenter TNG. The CA Unicenter TNG framework [CA] provide.s infrastruoture to support
integrated distributed enterprise management. It is based on a client/server architecture having an agent in each
host and a centralized workstation. CA provides Unicenter TNG agents that can run on a large number of
platforms; a.nd the lisl continues to increase a~ the customer base diversifies. Besides TCPIIP and SNMP. the TNG
framework supports numerous other network protocols, accommodating a vnried enterprise environment.
CA describes Unicent.er TNG as a framework comprising three components: Real World lnterfuce, object
repos·itory, and distributed services. The Real World Interface presents a visual depiction ofmanaged objects from
different user perspectives. Both two-dimensional and ihreo-dimcnsiooal prc.sentations arc available. The objecl
repository is a management infonnalion daLabasc that includes multiplicity of data, sucb as managed objectS,
metadata class defmitions, business process views, policies, topology; and status infurmation. The distributed
services link elements at the oommunications leVel.
Because of the TNG agents running in the hosts, during autodiscovery L11e system discovers not just host
identifications, but also details of the processor, disk, and other components of the system. Tite discovered

components are presented in a Real World lotecface tbat presents a unified GUl at the higher levels. An object
repository stores all the autodiscovered information and any other managemenl information needed to support the
Real World Interface. System and network management· views are ell.1ended lO business process views, whereby
objects related to an administrative group or functional group can be presente.d. This approach makes operations
easier !Or human personnel because they do not have to know the technical details behind the operations they are
performing.
Event management in the lNG framework includes a rule-based paradigm that correlates events across platforms
and presents the resuhant alarms at the central consbie. lllese events include slandard SNMP traps. Standard
dcilling through layers to detect the lowest level component fuJlure is built in asdesktopsupport.
An additional feantre of tbe TNG framework is calendar management, which provides a shared calendar so tbat all
personnel can view each other's activities. 11tecalendar handles both one-time and perk>dic activ~ies. Operations
such as triggering an alarm pager or email can be programmed according to weekly and weekend shift schedules.
Some of the other notable fearures of the TNG framework: are backup aod disaster recovery. customized aod
caaned report generation. aod virus detection-aU of whicb <:ao be programmed as part ofcalendar management
activities. ln addition lo these s1andnrd features, numerous optional modules, soob as advanced help desk
management, Web server management, and software delivery areavailable.
Tivoli Enterprise Manager. Tivoli's management framework, originally named the Tivoli TME 10 framework.
provides sy5tem aod network management and is in the same class as tbe Unicenter TNG framework. Tivoli bas
changed theTME 10 from a two-tier, client/server arcbitecturc 10 a three-tier architecture and has renamed it Tivoli
Enterprise Manager. Tivoli claims that the new architecmre has increased the capability of handling from 300 to
I0,000 managed nodes. The extended tbree-lier architecture also bas a gateway as a middle layer thai is designed to
handle as many as 2,000 agents. The agent module has been redesigned to consume fewer resources.
Tivoli merged with IBM, allowing it to ini.egrate the features of its systems 'vith IBM 's NetV iew NMS. NetVicw
performs the network management function, and the complementary features of the Tivoli management
applications perf'orm the system management functions. The platform is object oriented and uses the staodard
CORBA-compliant object model ror use with diverse and distributed platforms. This feature is somewhat sinlilar to
the Sun Enterprise Manager [Sun Enterprise], whicb also uses the CORBA-compliant OST object model and
standard CMIP protocol. In the management framework, 'Hvo11 management agents reside in the manage-d host
applications. Although the TME Enterprise syste.m does not use SNMP as the management pfoioco~ NetView
han.dlcs SNMP traps.
TheTivoli EnierprLo;e Manager monitors network, systems. and applications in a distributed architecture, as in most
other systems. Event management bas a built-in rule-·based engine that correlates events aod diagnoses problem~. It
further has an automated or operator-initiated response mechanism to oorrect problems wherever possible, using a
decision support system. Service desk technology is integrated with network and system management technology
in1be servic~level management framework.
Tivoli service management comprises problem manageroena, asset management. and change management. The
problem management module tracks cu~omer requests, complaints, and problems. The asset management module
handles inventory maoagement. Tile change manaboemem module incorporates and manages business change
processes.
The Tivoli Enterprise Mruiager framework contains an applications manager module (global enterpdse manager)
lhat coordinates business applications residing in divet:se muJtiple platfurms. An API is provided to permit third-
party vendors to integrate their application software into the Tivoli Enterprise Manager framework. The
applications·manager also measures the responseand througllput performance ofapplications.

Tbe security management module provides encryption and decryption capabilities (optional). A software
distribution module automates software distribution and updates. Operations can be scheduled by the workload
scheduler module.
9.5.4. Telecommwtirations Managruucot Systl'lllS
Unlike an enterprise network, a telecom network provides commercial services to subscribers. The operator bas
legal responsibilities to the subscribers. Telecom operntors are usuallysubject to stringent regulations.
Telecommunications network managemt'l.lt includes monitoring and managing the network with certain distinctive
feal'ures. Apart from support·ing standard management fcnrure.s such as low level, as well as consolidated, mull and
performance .maoagemeni, ·there are cenain filatures that are specific to telecom:
1. A typical tclecol)llllunications network often includes equipment acquired over several years, and a
telecommunications NMS must be·capabl.e ofmanaging these heterogeneous systems from a single point.
2. Most telecom devices that implement tbe lTO-T standard protocols (such as CMIP/CMJSE) differ in details
and this makes development oftbe management application more complex.
3. Somedevices·have only an EMS, whlc.h often hns a proprietary interface, and the NMS must communicate
with tbe EMS mther lhrin with the device agent directly. Thus, often the NMS manages some NEs via an
EMS and !lOme directly.
4. Typical telecom networks include multivendor nwltitechnology equipment, supporting diverse protocols.
SOH and related trilnspon technologies (SONET, DWDM, etc.) continue as the de lilcto technology for
delivering reliable and scalable andwidth services over the last decade; and service providers have large
amounts ofdeployed fiber ibat has been laid out over a period oftime.
5. Provisioning of bandwidth is a common and imponant requirement in telecom networks. Provisio.ning
bandwidth in optical networks in an optimal rnanne.r witbout causing fragmentation of the available
bandwidth is a challenge. For example, if there is a requirement to provision an El circuit (2 Mbps), it
wonld not be desimble to "brenk" an S1M1 link (64 Mbps) to do the provisioning.
6. A related requirement is the mainteoance of the latest inventory in the database so that when there is an
incoming bandwidth-provisioning request, reliable and fresh infurmation about the availability of
bandwidth can be nocessed. Usually, this information is maintained and updated manually. However, a
telecom netwotk Is a dynamically changing entity, so automatic discovery with periodic rediscovery to
synchroni7.e tbe inventory dat:aba.o;e with the actual network is becoming a critical requirement for efficient
and optimal management ofthe network. While autodiseovery ofIP.networks u~ing pingand/or SNMP is a
standard feal'ure in data.~S, the discovery of circuits in telecom networks is a far less straightforward
issue.
7. A typicaltelecom provider assures customers ofquality ofservice via service level agreements (SLAs). In a
tclecom environment this includes pammeters such as call completion rate for voicecalls, signal strength on
wireless links, call completion for dat;l calls, etc. The management system must provide tbe suppon for
SLA management.
8. RCA to diagnose the actual source ofa problem is another imponant feature to be supported.
9. Networks tend to be large, often with hundreds of thousunds ofNcs, and have a wide geographic spread.
The telecom opemtor may have a hierarchical organization with different administrators responsible fur
different regions ofthe network. 1l1eNMS architecture must be scalable and should suppon the ltiernrchy
oftbe operator.
In this section we describe CygNet, a commercial telecom NMS deployed at leading telecom service providers in
India. CygNet is the flagship product ofl'<'MSWorks Software Pvt. Ud., a technologycompany that is a part ofthe
TeNeT (Telecommunications and Networks) group oftbe lndiao lnstitute ofTechnology Madras, India.
CygNet NMS is a multivendor multileclmology management system that has been designed to meet the needs of
telecommunication management. CygNet architecture accommodates most of tbe needs of a telecommunications
management system.

Arohitedure of the CygNet Core. figure 9.39 depicts the architecture of the core CygNet NMS. We describe the
major components below.
Flgurt 9.39. Arthltt<luo·t orIll< CygNtl Cor<
Managed Element Modeling, Storage, and Depiction The elements server is respons·ible fur thisfunction. Network
elements tbat are managed by the CygNet NMS are stored in the topology (topo) dambase. ElemeniS to be
mnnaged by the CygNet NMS c.nn either be added manually or by automatic discovery. A discovery configurator
alk>ws ·the operator to specifY a range of IP addresses for discovering ele.ments, the protocol to he used for
discovery, and other such details. A map-based GUl displays t.be managed elements and the topology of lbe
network, color coded 1
0 reflect the status.
Fault: Management System The CygNet alarms server is responsible for detecting a problem, correcting il, and
restoring tbe system to normal operation at the earliest. Fault detection is done by polling. as well as receiving
notiticatioos. Alarms are generated in response to fault cond~ions in the netwotk, stored in tbe database, and
notifications (visua~ audio, email, SMS) sent to capture lbe attention of concerned persons. Tite fault reporting
feature ensures that infonnation regarding a fitult condition is disseminated in a meaningful manner 10 the
concerned operators. GUI·based views of current. as well as historical faults, are available. The fault: escalation
feature alk>ws the fault resolution time to be minimized and fituk escalation using notifications (traps or TMF 814
notilkatioos), email, or SMS. Muhiple events associated with a common fault in a sing]c netwotk element are
correlated and forwarded as oneconsolidated evcn1or alarm by the RCA module described in Section 9.4.6. This
minimizes the occurrence ofevent stonns that would result in degraded levels ofservice.
Performance Managemenl System The· function of the performance management module is to manage the
performance of individual network elements, links, and services. The PM module perfurms the following three
major functions:
l. Data collection and storage in database.
2. Graphical views ofreal·time performance statistics.
3. Historical reports ofcolleded datafrom database.

Con.figurntioo Management System The configuration management module in CygNet allows the operator to
directly manage and configure network elements using the protocol supported by the network element.
Configuration information regarding variolL~ network elements is stored in the configurmion database..
User Manager This is the authentication and authorization component CygNet ldenlifies several classes of users
with differe.nt privileges and access rights. All users have to be authenticated bef()fe they log on to CygNet. Role>
based access contro~ idle time-out, and.user audit trail are some ofthe features that this module supports.
Archih::ciure ofCygNet as a Telecom NMS. CygNet supports a layered architecture depided in Figure 9.40 thai
enables it to be rustomized fur various specific requirements. The custom components can be added as overlays to
thecore product. This also allows CygNet to scale to very large telecom networks.
Figure 9.40. CygNet as llTrl..om NMS
Telecommunication-specific Subsystems.The CygNet design supports most of the features required fur a telecom
NMS specified at the beginning of this section. Here we describe some aspects of the design that enable effi.cient
telecom management and also certain compone-nts (Mediation Server and Optical Tmnspon Network Managemenl
System (OTNMS)) that are customized fur this purpose.
CygNet bas been designed so that it can be deployed eii.ber in a centralized manner or as a multitiered system. This
provides 11 good scalability option when 11 very large and widely distributed network needs to be managed. Network
management tmffic can be reduced if lower-level management stations transfer managemenl data to the oentm.l
server periodically. 111is deployment strategy also avoids a.single point offitilure (Section 9.4.7, Figure 9.35).
At the lowest level, the CygNet k>cal manager runs lightweight processes that predominantly coUect data. Th.e
collected data are analyzed for performance and fault conditions and summarized report·s are sent to the central
management siatioo. Figure 9.41 depicts ibis configuration. CygNet supports standard interfaces (TMF 814,
SNMP, I'TP, SCP (Secure CopyProtocol)) between the local NMS and central NMS. [Vanchyoathanu .,2004].
Figure 9.41. CygN<t MtdiAtlou S.rver

CygNet NMS
TMF8l 'l
I
TMF814
Pre-procasslng Layer
Adaptation Layer
prop~etary lnt~rfaces I TMF 814
CygNet supports TMF 814, an NMS-EMS interface defined by lbe TM Forum, and increasingly adopted as tbe
sl8ndard tOr management ofoptical transpon networks. (TMF 814 is discussed in more de!all in Clapter 16. Tlis
allows management of newer optical network devices, since many vendors include support for TMF 814 in their
EMSs.
Thereare usually legacyNEs in.a network and these either do not have an EMS at al~ orevc:n ifthere is an EMS, it
does not suppon TMF 814. ln order to integrate· such e<Juipment, the. CygNet Mediution Server designed for
multiple protocol suppon is used (Figure 9.41). 1be mediation server ofCygNet is n middle'vare component that is
between the NMS (or other OS) and the network. II serves to hide Lhe heterogeneity in EMS inte.rfuces from and
provide a uniform TM.f' 814 interface towarru, the NMS. The lowermost adaptation layer allows plugins to oonven
proprielary protocols to tbe formal ofTMF 814. The middle pre-processing layer ped'orms functions such as event
correlation, suppression, filtering, caching, etc. It is a majo:r enabler in bridging legacy and new networks and
expedites integration ofnew equipment into CygNet.
CygNet O.ptical Traospon l'o'MS (OTNMS). This CygNet component is customized for end-to-end management
and bandwidth provisioning of optical transpon networks. The functional archi1ecture of OTNMS has been
designed with a view to making the OTNMS an all-in-one solution for optical network management (Figure 9.42).
Frgurr 9A2. Arthllf<lurr oflhr CygNrt OTNMS

1MS
B
~
•Boodvilh Provisioning
• Root C2usaAnatys;s
• lnventolyApplication
• Alrum ~!.>bon
• NetN<ri Activation
• FaUlt, Parmrmarce Mgmt
• Email. SMSNo~jcalions
• Autodlstole!Y
It suppon.'> automatic, dynamic provisioning ofbandwidth services using a path computation algorithm designed to
satisfY a maximum number of service requesls while optimizing bandwidth use and avoiding fragmenllltion
[M'adanagopal, 2007].
The availability of reliable inventory is central to the success of automatic provisioning. The resource inventory
database in CygNet stores network and computing equipment, logical resources, and topology. It keepstmck oftbe
physical configuration of the network. equipment inventory (cards. pol15, etc.), phys'ical connectivity, and logical
comu:ctivity ofthe different network layers. Data in the resouroe inventory are queried 'by the provisioning system
to satisfY service requests and understand where capacity is av.ailable. However, in a typicaltelecom network, the
inventory maintained by the NMS can become out of date for many reasons, including manual network
intervention, equipment upgrilde, ·network maintenance, card failures, unaccounted deactivations, etc:. Once the
Inventory is out of date, any design baSed on this inventory system is unreliable. The CygNet OTNMS supports
automatic discovery ofNEs, as well as circuits of optical network,s with periodic redisrovery. The autodiscovery
feature ensures tbat the inventory can automatically synchronize itself with the network. This requires
automatically uploading physical, logical, and service information and correlating it to the normalized internal
object models ofthe inventory database.
The CygNet OJNMS has support for SLA-related performance data coUect:ion and storage, Md display of SLA
reporls and throshold alarms to indicas.e SLA violations. It also uses an RCA module to piopo.lnt the actual ca.use of
a fuilure.
Summary
In tllis chapter we listed a number of utilities that are available on commonly used operating systems such as
Linux, UNTX, and Windows. These are invaluable tools in the repertoire of any network manager, and support a
significam amo1mt oftroubleshooting and traffic monitoring. Some of these tools are based on SNMP, others use
assoned protocols SliCh a.
s ICMP or proprietary messages over TCP. We discussed techniques used for monitoring
ofstatistics and the use ofMRTO fur collecting router traffic statistics.

Focusing on SNMP-enabled devices, the vendor needs to design an MlB tbat suppor1S remote management ofthe
dev.
ice. This topic ofMIB Engineering was covered in Section 9.3. Several common MIB designs were presented.
Section 9.4 dealt with the des.ign of an NMS server for a large teleoom or enterprise network. Motivated by Ute
requirements, we presented a generic architecture. We then covered the detailed design of the important
architectural blocks, especially discovery, fault, and performance management. This section draws significantly on
our experience in the design ofa commercial NMS. viz., CygNet.
Finally, we presented severul NMS products, boih commercial and open source. which are commonly used far UJe
management of diffi::rent types of net·works and services.
Exercises
1. Execute the commands nslookup and dfg on a hosttP address and anaiVle the results.
a. Compare the two results fur the common information.
b. What kind ofadditional information do you get from dig?
2. Use dig tQ determine the IP address of www.tenet.res.ln (or the DNS name that your Instructor provides you
with).
3. Use dig to list all the hosts associated with the domain tenet.res.in (or the DNS name that your Instructor
provides you with).
4. Usii'J8 dig, determine the domain name that oorresponds to the IP address 203.199.2555 (or the one tMt your
Instructor provides you with).
5. Ping an International site 100 times and determine the delay distribution and packet loss. Repeat at different
times of day and nlghl Explain anyvariations.
6. Using tcpdump or wireshark on an Ethernet interface on a host, capture ten IP packets. Examine their t>eaders
andcontents.
7. In diagnosing poor network performance- for example, delays- you need to knQW where the bottleneck l.s. Use
traceroute to an lntematronal site on another continent and Isolate the delay In tt>e path.
8. From a workstation In a segment of your Institute's network, dtsc:over all other workstations In your segment
using anetwork tool. Substantiate your results with the data gathered by some other means.
9. As a network manager, you are responsible for the operation of a network.You notice heavy traffic In a host that
Is on aTCP/IP network and waotto find out the details.
a. What basic network monitoring took) ) would you use'?
b. Wbat would you look fur in your results?

10. Using an SNMP tool, determine·which of the nodes given by your Instructor has the longest and shortest up
time. Substantiate your result with the gathered data.
11. The function snmpWalk(subtreeRoot) returns the values of all fhe visible OIDs In the subtree rooted in
subtreeRoot. Using thestandard SNMPv1 messages, devise·an algorithm for snmpWalk().
12. A switch has several ports each having a different speed. Write a complete SMI definition for the table of port
speeds. Assume that the swlll:h OlD Is {experlmental 7).
13. A node may have several hard disks. Write an SMI definition for the Important parameters (brand, type,
capacity) ofsuch aset ofdisks.
14. It ls desired to provide username/password protection to a MIB subtree {enterprises Mldas(3794) corDECf{l)
conflg{i)}. What are the MIB variablesthat need to be a.dded for this purpose? Draw the MIB subtree and for
each variablegive Its ASN.l macro definition-
15. It Is desired to provide access through SNMP to the database for an NMS c.ourse. Design a MIB rooted In
{enterprises NMSWorks(lS760) course(lO)} to hold Information Including the start and end dates of the course,
the number of students registered, and the list of reference textbooks. Draw a pictorial representation of the
subtree. Write the ASN.1 macro definitions of each node.
16. It is desired to store the roll numbers and f inal mart<s for students.in an NMS course in an SMI table. Using the
nodes {enterprises NMSWorks {15760) course{10)) as the base:
a. PK:t.orially dmw the subtree of the management information tree.
b. Writethe complere SMJ macro definition for each new node.
17. F.or a certain trap generated by an agent. It is desired to provide an acknowledgement to the agent that the
manager has received the trap. Using only SNMPvl and SMlv1 without any changes, devise a mechanism to
accornpllsh this.
18. Design a MIB variable rebootNode, which a manager can use to reboot the NE. The manager needs assurance
that the node has been rebooted. Explain carefully the semantics and write the· ASN.l declaration of the
variable.
1.9. It Is desired to manage a traffic light using SNMP. The controller needs to know the count of the number of
vehicles that have· passed, and be·able to change the l ght between red and green. Sketch the MIB subtree
{traffic) for this purpose. For each node in this subtree, write the complete ASN.1 macro.
20. A single-threaded discovery module discovers the subnet 192.168.9.XlOC. This subnet contains 20 NEs of which
four are routers each having ten Interfaces. Each network request from the NMS takes 2 seconds round-trip
time. Eaet1 failure has a timeout of 30 seconds. Approxlmateiy how longwill the discovery process take?
21. Write a pseudocode for topology discovery {similar to Figure 9.26). Assume that routers are SNMPvl-enabled
With a known community string.

22. With a 1~Hz CPU. the average CPU time·taken for status pollfr1f! is: poll manager 0.6 ms, SNMP stack 0.8 ms.
When the poll manager detects a chanj!e of status, It Informs the FM and writes to the DBMS. The CPU times
taken are: F.M lms, DBMS 5 ms. Assume that 10% of the pollsdetect a change ofstatus, and that theCPU power
Increases linearly with the CPU dock speed.
a. Whai is the minimum CPU speed lo handle 1.000 polls/second?
b. If the P.M. FM, and SNMP are run on one CPU and DBMS on a se.:ond CPU, what are the
minimum speeds of these two CPUs for 1,000 polls/second? Assume 20% increase in all CPU
requirements dueto the inter..CPU communicatiOn overhead.
23. A data collector polls for 100 OIDs, each on a different NE. When there is a response, the round·trlp delay Is 1
second per poll. When there·is a fault, the timeout is 30 seconds. Assume·that 20% ofthe pollssuffer a timeout.
a. What is the minimum polling period ifthe data collector is single threaded?
b. What is the minimum number ofthreads needed to achieve a polling period of30 seconds?
24. An NMS manill:es 1,000 large NEs and 100,000 small NEs.. For each Of the large NEs, It polls 100 OIDs with a
polllr11! Interval ofS minutes. For each of the small NEs. it polls two OIDs once an hour.
a. Estimate the volume of dala lo be stored in the polled data tables (excludmg indexes and
tempornry space) per day, per week, per month, and per year.
b. Assume that the network consists of20 regionseach containing l120th oftheNEs. The fOllowing
database designs are being considered: one table/NE, one table/region, one table/whole network.
ln.each case. a new ·table may be created every day,.every week. every month.
c. Draw a table with columns labeled day. week, and month, Md one row fOr each dntabnse design.
In each cell ofthe table, enter the number of records/table and the number of tables if data are
kept online fur 6months.
d. The vendor ofthe DBMS recommends thai one table should not contain more than 500 mill ion
records and that the DB should not contain more than 1,000 tables. Mark the designs thai are
fensible according to thesecriteria. Which one oftbese designs do you prefer? SUite your rensons.
25. A teiecom network that use<:l to serve 100 million subKribers has 1 million NEs. Suppose the poll manager poliS
1% of the NEs for 100 OIDs each at a S.mlnute Interval and 20% of the NEs for 10 OIDs each at a lS.mlnute
Interval.The remalnlr1f! NEsare polled only for status once an hour.
a. Compute the disk space requirements for I day, I week, I month, 30d I year. ASsume thai U1e
disk space requirement is three times the table size to allow for temporary files
b. Suppose the PM also polls the sUitus ofeacn subscriber unit (such as phone, ADSL modem, etc.)
oacc a day. WhaJ is the additional disk space requirement?
26. An NMS Is connected to a remote network by a 64 kb/s link. There are 1,000 NEs In the remote network, each
havlr1f! 10 OIDs of Interest. Assuming 5 OIDs In eacho SNMP get-request, neatly sketch a curve showlr1f! the
bandwidth usedas.a function ofthe poltlng perlod, p. Whatvalue of pwlll result In 20% utflizallon ofthe link?
27. tn Exerdse 26,as~ume that a regional NMS In the·remote network does the polling and once·an hour does a bulk
file transfer of all the data values only to the central NMS. What value of p will result in 20% utilization ofthe
link? Assume thatscp Is used and achieves a compression ratio ofSO'l6.

2!. An NMS is connected to a remote network by a 64 kb/s link. The NE~ In the remote network generate·SO
faults/second. Of these, 1% are criticaland the others are minor. Whatfraction ofthe link bandwidth Is used If:
a. All fnuh notifications are sent using SNMP traps?
b. Critical fault notifications are sent using SNMP traps, and minor tault notifications are sent once
a day using scp'l Assume that a trap is ofsize 100 byte;, and that the information about a tault
occupies 8 bytes inn fiJe. Neglectall other overheads.
29. SNMPvl defines communication only between the manager and the agent. In a network with multiple
management Servers, communication between them may be necessary. For example, when the operator at one
server acknowledges-an alarm, the alarm Indication sttould also stop at the other server. Define a mechanism
usi~ onlySNMPvlforthIs purpose:
30. We wish to have two management servers each with a copy of the database for redundancy·. There -are two
approaches.
a. Each server independently polls the agents and updates its copy of the database.
b. The active server polls the agems and then passes the data onto the passive server.
What are the pros and cons of1hese approaches? Consider criteria such as load on the agents, network
traffic, and Jo.ss ofdata inc~ ofserver fitilure. Thecons.istency ofviews is an important consideration.
Part Ill: TMN and Applications Management
Pan I reviewed the background fur dealing with network management. ln Part II, we discussed in
detail SNMP management and designing a network management system to manage networks. Part
m will address telecommUJiications management network (TMN) and detail network management
applications needed for fuult, configuration, accounting. performance, and security functions.
Chapter 10 takes network management to a higher-level management. TMN, based. on the OSI
modeL It addresses five levels of management-network element layer, element management.
network management, service management, and business managemenL
Applications arc the focus ofChapter II. We will first gain a basic understanding ofhow the tools
and systems tllat we learned in Chapter 9 are used for configuration, fitult, and performance
management. We will then go into more depth on correlation technologies to localize and diagnose
problems tbat.cause mulliple n!arms. lnformation security is a very imporilmt application in network
and system management. Besides basic SNMP security management, you wllllearn about firewalls
and the role of cryptography in authentication and authorization. Accounting and reporting are
important to run any business efficiently, including information technology services. We havegiven
special emphasis to repon generation. To use tools efficiently, policies need to be establis.hed and
made operationaL Some policies may be automated in rnanagement systems, and we will address
this at the end ofthe chapter. We finally cover service level managemem technology that deals with
customer and quality ofservice.
tO
. Telecommunications Management Network

Objectives
Telecommunications management network, TMN
Concept ofoperations support system, OSS
TMN conccptua.l model includes:
o Customers
o Service providers
o Network
o Operations support systems, OSSs
o System operators
lMN standards and documemation
'IMN architecture
o Functional
o Physical
o lnfurmation
lMN service management arcbileclllre
o Networkelement
o Element management
o Network management
o Service management
o Business.management
TMN service managcme.nt
o Operations, administration, maintenance, and provisioning; OAMP
TMN implementation melhodologies
o OMNlPoint
o eTOM
ln lbe second part of the book, we have addressed the principles of network management associated with data
communication networks. Data communication network~ carry information over long distance and are dependent
to a large exteot on the telecommunication nctwotk. which has evolved from the long-distance telephone network.
These networks are owned by public utility companies. which are·either long-distance carriers such as AT&T and
British Telecom, or local exchange telepbone companies, such as Bell Operating Companies. rn this chapter, we
wiU discuss the management of telecommunication networks and servioes provided by these public and private
trtility companies, 1111d service providers.
The standards for management of the telecommunication network were developed by International Standards
Organization as part oflSO management. Hence, it is strongly based on1SO network management, which in tum is
based on Common Management lnfonnation Protocol (CMJP) and Common Management lnfonnation Services
(CMIS). Although this chapter addresse~ telecommunications network management without the requirement of
CMfP/CMIS.
-based management, the reader would have a better appreciation with that knowledge. Toward that
goal, OSI network and systems management is presented in Appendix A.
In 1986, the International Telecommunications Union-Tel.ecommunicntions (JTU-T) proposed the conoept of
Telecommunications Management Network (fMN) to address interoperabiliry of multivendor equipment used by
service providers and to defUJe standard intermces between the servioe provider operations. In addition, it also
ellended ihe concept ofmanagement10 inc.Jude not.only management ofnetworks and network elements, but also
service functions of service providers. It was envisioned as a solution to the complex problems of operation,
administration, maintenance, and provisioning (OAMP) for d1e telecommunication networks and services.

We will firSI provide motivation fur learning TMN in the next section, and then introduce operations systems,
which form !he building blocks ofTMN, in Section 102. Section 10.3 addresses the concept ofTMN. TMN is
based on a large number ofstandards, which are listed in Section 10.4. TMN architecture is described in Section
10.5, TMN mnnagemem service architecture in Section I0.6, and an integrated view in Section 10.7.
!Jnplemcntation issue.s arc dealt w.
ith in Section 10.8, including OMNIPoim program that has been developed by
the Network Management Forum. The current drive for practical implementation of TMN is ha.ndled by TM
forum. The latest development in management technology is covered in Chapter 16.
I0..1. Wl1y TM.N'!
With !he proliferation of SNMP management thai has leftOS! network management by the wayside, we can ask
the que.sUon why we are spending time on discussing TMN. Historically, TMN was born out ofnecessity to extend
the private and proprietary, but well-developed network management systems, and make them interoperable. lo
those days, ihe large telecommunication organi7Btions referred to the systems thilt maintained the network and
network elements as operntions systems. ITU-T fOrmed a working group in .1988 to develop a framework fur
TMN. lSO was also working on standardiz.ing network management wilh OSl management framework using
CMfP. With globali211tion and deregulation ofthe telecommunications industry, the urgency for interoperability of
network management systems was strongly felL. With the slow progress of these standards bodies, industry·
sponsored groups such as the Network Management Forum started developing standnrds in parallel to speed up the
process.
Unfortunately, the standards and frameworks developed were so complex: and expensive to implement using U~e
then-present technology. TMN and OS! network management never got offthe ground. However, TMN is the only
fmmework that addressed not only management of network elements. but also the management of network,
service, and business. These later issues are so critical in 'loday's business environment with numerous network and
service providers (they ore not the same as they used to be). Customer service, quality, and eost ofbusiness form a
three-legged stool (Adams and Willetts, 1996]. You knock out one leg a.nd the stool falls down. TMN framework
not only addresses !he management of quality of network and network elements, but alsp service management and
business management.
Further, in today's corporate environment, buyouts and mergers demand interoperability and business
management. With the work enviroumcn1 going into cyberspace and the lntcmet facilitating global
communicat.ions traversing multiple service providers' networks, the exchange of management information bas
become all the more important. All these motivations have revived Lhe interestin TMN architecture.
It is to be kept in mind thatTMN had been developed based onOSI management prioeiples. However, it could be
implemented, as is now being done. using other management technology, such as the well established SNMP
management as weU as newer one.s described in Chapter 16. Organizations such as TM Forum ore devoting efforts
to accomplisb this.
10.2. Operations Sysfcms
TMN is built using !he building blocks of the operations support system. The use of the terminology, operations
support system, in the telephone industry was changed to operations s-ystem, as it is also used to control !he
network and network elements. For example, user configurable parameters in the An.l network can be controlled
by users via the M3 interf!lCC, as we will learn in Chapt.er 12. The operations system (let us not confuse opemtioos
system with. operilting system) does not directly play a role in the information transfer, but helps in the OAMP of
network and information sySJcms. Figure I0.1 and Figure I0.2 present. two examplesofoperations systems that are
used in the operation of telephone network and services: trunk teSJ system and traffic measurement system. The
terminology ofOSS is back .in common use again. We will use bolh terms in this chapter.
Figur• tO.t. o,..,..tion$ Sut>port S;.ost•m for Notwoo
i< Tronsm~ion

Frgurt IO.Z. Ot>traoions Snpt>orl Sysltm rnrTroiTic Mta!no'tontnl
The trunk test system shown in Figure 10.1 is used to monitor the loss and signal-to-noise ratio in !he r.runk
transmission sySlem in .Bell Syst.em. A trunk is a logical entity linking two switching offices. It can seize any
available cable facility between the swilcbcs while canying traffic. ln order to ensure quality of service, loss and
signal-to-noise on !he trunks are measured at regular intervals by accessing every rrunk at each switching office.
This is done from a centralized rest center. Any trunk rbat taiiJ; ro meet the minimum criteria set for qualily control
is removed from service. 11ws, by removing a trullk out of service as it is failing (bur before ir aet.ually fails), tbe
custo.merdoes not see anydegradation ofservice. The same test system is alsc used for an on-demand tesl to track
trouble.~.
Except during popular holidays such as Mother's Day, telephone service is almost always available for
communication at any time ofthe day. This is due to careful planning and implementation ofadequate fucilities for
traffic to be handled without being blocked. for lack of facilities. Figure 10.2 shows a traffic measurement
operations system, which measures lhe busy status of switch appearance (access point) on each switch. As the
statistics on the number ofpaths being busy increases, either due to the lack ofaccess points or tbe lack ofadequate
muik facilities, addilional equipment is added to reduce blocldng.
The above two examp.
les of operations systems illustrate tile necessity of tbe role of operations systems in the
OAMP oftelecommunication network. They are part of rbe telecommunications network management activities,

and fall under the perfunnance management function oftl~e network management tbat weltave defined under the
OSJ model in Chapter 4.
10.3. TMN Conceptual Model
From a TMN point ofview, the .nerwork management system is treated as no operations support system, as shown
in Figure 10.3.ll manages the data communication and telecommunication network.
Figurt t0.3. T~1N Rtlotlocublp co DAIR •nd Ttltoommuulealluu Nttwork.s
r-:;;:::""
-
We differentiated the data orcomputer communication network from the telecommunication network in Chapter I
(see Figure 1.4). Figure 10.3 extends it to TMN, where opemtions support systems, including the network
management system. form a suppolt network. It is logically a separate network. but may or may not bephysically
separate based on implementation. The telecommunication network inFigure 10.3 consists ofnetwork elernenls of
switching exchanges and. transmission systems. It is primarily the wide area network of communications.
Switching sys:tens include both analog and digital switches. And so are the transmission systems of both analo.g
and digital types and include all means of transport mcilities including twisted pair; coaxial, fiber optics, and
IVire)CS.~.
Data communication network components consist ofLANs, bridges, routers, g;~teways, and hosts. The worksuu:ion
sbown in Figure 10.3 that is anached to the data communication network is a distinct element ofTMN, wbose
interface we wiJI discuss later.
The TMN in Figure 10.3 is a network in its own right, and notjust the management oftelecommunication network.
(II is TMN and not TNM.) ITU-T RecommeodationM.3010 defines TMN as a conceptually separate network that
interfaces to one or more individual telecommunication networks 111 several points in order to send or receive
information to or from them and control their oper!ltion. It consists ofa ·network ofoperations systems including a
network managementsystem. whic.h, as we slllted earlier, is also considered an operations system.
Figure 10.4 shows the TMN conceptual model. Notice that in this model not only are the networks and operations
system depicted, but also services and humru1 resources are brought in. The two columns in the figure depict the
identical components ofthe two service providers, A and B.

Figun I0.4.TMN Coueeplual Modrl
S4MCO P<OVIOer 8
We identify the following components in Figure I0.4: workstations, operations systems, network, services, and
interfaces. Ofcourse, there are the operators wbo ope.rateon the systems and the customers who use the se.rvices.
Customers are provi.ded service by the service provider, and customer service should play a key part in the service
provider's business. Thus, service management is an important conskleration in conceptualizing the TMN model.
The service provided by the service provider to the customer is telecommunication service, wllich means that tbe
telecommunication network needs to be operated efficiently and·economically. The OAMP on the network needs
to be handled in as mucll ofan automated mode as possible to increase lhe response time and to decrease the cost.
Cost considerations lead to business mnnagement, which is addressed by the TMN model
Service management, business management, and network management are all accomplished either partially or
toLally u~ing the operations systems shown in Figure 10.4. System operators interface with the operations systems
using workstations.

The interfuces associated with various functions and services have been standardized in the TMN model. Notice
the lhree imer.faces-Q3, F; and X. Q3 is lhe inted"ace between the operations system aod the networke.
lement. F is
the interface betwren tbe workstation nod the operations system. Infom1ntion exchange between operations
systems wii.hin a TMN is accomplished using lhe QJ interface, whereas operations systems belonging to differenl
TMNs communicate over lhe X interfuce. We will discuss ioterfaoes in more detlil in Section 10.5.
t0.4. TMN Shmdards
lTU-T is lhe standards body that has developed TMN standards. It is ~on the OS! fiamework. Its scope has
been expanded aod a. good review of it has been published [Sidor, 199.5]. llte TMN recommeodations aod scope
are summarized in Figure 10.5 [NMF] and Table 10.1. M.JOOO document present~ a tutorial ofTMN. The other
documents in theM series address TMN architecture, methodology, a.nd lem1inology. The Q series addresses lhe Q
interface, such as Q3 and 0.733, the protocol profile !Or the Q interface. lltese arelisted in Table 10.I. Table 10.2
Iists some ofihe studY groups tharare responsible for various TMN activities.
Figurt t0.5. ntN Rrromrutndocioos and Scot><
-
So!ao<y
£ -
"'-....
D
T... _
Tablt tO.I. TMN Oo<umtnc.
M.3000 Tutorial Introduction to TMN
M.3010 Prinelple1 for TMN
M.3020 TMN Interface SpedflcatlonsMethodology
M.3100 Generic Network lnform<~tion Model forTMN
M.9180 Catalogue ofTMN Managed Objects
J
~
-
-
~..
c•oo-
uoo-
)(?.))~
...
)(7AI)-

TabltiO.J.TMN ~~umtiiiS
M.3000 Tutorial Introduction to TMN
G.774 SOH Network Information Model forTMN PDH Network Information Model forTMN
M3200
M.3300
M.3400
TMN Management Services Introduction
TMN Management Services I
TMN Management Services n
F-interfaC1! Management Capablllties
TMN Management Functions
0,811 Q;812 Protocols for the Q Interface
G.773 Protocol Profiles for the Qlnterface
Tablt l 0.2.1TU-TSiudy Grou1>s
Study Group Study Topk
SG2 Traffic management
SG 4 TMN archltedure definition Generic network model f.interface
SG7 OSI base ma!lagementstandards
Dam network management and MHS
CUstomer network management
SG 10 User InterfacesSpecification languages
SG 11 TMN protocols and profiles
Switchin.s and.signalfng system managed objecrs
ISDN management protocol ond informalion models
Intelligent network management
UPT management
SG 13 S.ISOfj requirements (transpartnetworks) ISDN
Recommendation Series
M serles
X series
Qserles

TRbltl0.2.lTli-TSllldyG ruur>>~
Study Group Study Topic
SG 14 Modem management
SG 1S Transmlssion.system management
Tm11$mission system modeling
SOH, PDH,ATM management
SG 18 Broadband management requirements
JRM (JCG) Overall coordination ofTMN
Re<ommendatlon Series
Vseries
Gsenes
Tbe otber supporting documents are also shown in Figure 10.5. Nerwork traffic llUIJlagemeot, maintenance, and
security are covered in E and M series. Tbe communication protocol, CMIP, and service elements, Common
Management lnfurmation Service Element (CMJSE), are covered in I and X series documenrs. A disrussion oftbe
X series is cove.red in AppendixA. Please refer 10 Appendix Aof[NMF] ror a complete list of the various series in
Figure I0.5.
TMN standards define two types of telecommunication resources: managed and operations systems and the
interfaces between them [Sidor, 1995, 1998]. Architecturill defmitions of the communicating TMN entities, their
roles in TMN, and their interrelationship are described in M.3010. M.3020 provides an overview. The common
services ofOAMP functiO
O$ are defined in M.3200. The functions 11850Ciated with individuallllfN management
service.s are described in M.3200 ser.ies. A generic set ofTMN management functions, based on OSI managemenl
functional areas, is specified in M.3400.
Management application messages and inrorrnation models 10 support OAMP requirements are specified in
M.31 00 series and G.774. A generic network infurmation model is defined in M.31 00 thar addresses common
solutions for the management ofresources ofthe network such as switching, transmissioo.nnd orher rcchnologies.
OS! managementservices and CMIS are defined in X.710. TMN-related messages are contained in ·the information
model defining application protocols and support objects, which are covered in Q-series documents.
Communication protocols are addressed in the respective proiocol-specitic standards do<:umeou. TI>e G series
addresses those that ate not covered in them, butare relevant to TMN, such as SOH network management (G.784).
10..5. TMN Architcchu·c
TMN architecture is defined in M.301 0 describing the principles for a TMN. lltere are three architectum I
perspectives: functional, physica~ and information, as shown in Figure 10.6. The timctional architecture identifies
functional modules or blocks in the TMN envirollOlcnt, including the reference point between them. The
rcquiremeols for interface are spooWed. The physical u.rcb.itccrure defines the physical blocks and interfaces
between them. lnformation arc.hitecture deals with the inrormation .exchange between managed objects and
management s)!Stems, using a distributed objeCI-oriented approncb.. We will look 81 each oftheselhree perspectives
in the next three subsections. You may also obtain more detaJls from the references (Cohen, 1994;.M.JOIO; NMF;
Raman, 1999; Sidor, 1998J.
Figurr 10.6. TMN Arcbiltclurr

Functional
Architecture
ITMNArchitecture
Physical
Architecture
10.5.1. Functional Arrhitectm-e
M.3010 dcfinesTMN architecture made up of five function blocks: operations systems function, network element
function (NBF), mediati.on function (Mf), workstation 1Jnct:ion (WSF), and Q-adapter function (QAF), as shown in
f.ig~~re 10.7. Each function block contains a set of functions. There are multiple instances ofeach function. Thus,
for example, there may be many operations. systems perfOrming different operatioonl functions in the operations
systems' function block. llte communication between the function blocks itself is a function, but not a function
block, defined asthe TMN data communication function (DCF). DCF suppor1s the standard transport protocols.
flgurt I0.7. TMN Full<lion•l An:hlltcllln:
•
Tlo1N A
JirG
&
..~P·~-~-
¢ NcF· N~>twcr1<Elemeflt Furdfon
___:) OSF· Operations Systems Funallon
OAF: Q-AdaolerFun<!IOn
V..~F: Wo~~<•lnti<n Function
The TMN operations systems function (OSP) is implemented in operations systems. As we saw in Section 10.2,
operations systems (OS) such as network transmission OS and traffic measurement OS he.lp mooilor, manage, and
control telecommunication networks and services. Netmrk management, both as a manager and an agent, is also
considered to be an OS. 1hls wou};J include MIB inimernet management and naming lree in OSI management as a
function ofthe OSF.

The TMN NEP is concerned with the managed network elements. Network elements l.bemselves are not prut of
TMN, but are supported by TMN over the standard int.er:fuces. Network elements would include hardware,
software, and systems such as hubs, routers, switches, processes, etc. The network management agent and the
associated MIB are part oflhe NEP. Network elements providing information for management, such as packets
dropped, collision rate, etc., are considered as part ofTMN, i.e., NEF.
The TMN MF block addresses the operations per:furmed.on the infom1ation content passing between the network
elements and operatioDS systems. Such operations include filtering, store and :furward, protocol conversion,
threshokl detection. etc. A physical entity in which the MF is Implemented can be shared between multiple
operations systems and network elements. For example, a remote monitoring device (RMON) can monitor a
remote LAN on various pammeters such liS statistics on users, protocols, and packet loss and report the analy:red
data or raw data to accounting and. perfOrmance management operations systems. In this situation. the RMON
device acts as a mediatxm device performing MF between the network elements on the remote LAN and the
operatioDS systems (or network management systems).
The TMN WSF provides an interface between human personnel and TMN a.ctivities. More specifically, this
function addresses the presentation 115pect. llteconversion function that converts machine-readable infOrmation to
human-interpretable furmat in the presentation functbn belongs in one of the other three function blocks, OSF,
MF, and QAF (e~eplaioed later). TI1is would cover the presentation function such as graphical user interface (GUI)
and human- machine interface ofworkstation~.
Communication between the above four functional blocks, OSF, WSF, MF, and NEF, is assumed to be
standardized. Of course, this is far from the reality of the world. Therefbre, in order to accommodate the legacy
functionality as part ofTMN, a.TMN QAF bas been defined. This is somewhatsimilar to a proxy server in SNMP
management, where non-SNMP network elements are managed by an SNMP m8Jl8ger via a proxy server. Titus,
TMN noncompliantdevices are conneoted to a TMN-compliant system!network using a Q·adapter interface.
Each fun~1ion in the function block. can be considered as providing a service and Ute service block providing a set
of services. An example would be a security management application function as either pan of or a smnd-alone
operations system. As shown in Figure A. l.3 in Appendix A, tltere are several security system management
functions such as alarm reporting, audit tmi~ etc. associated with tlte security functional area. ln fact, all five
management functional areas of configuration, fault, perlormance, security, and accounting residing in a network
management system woukl belong to OSF.
Function blocks arc designed to be nonoverlapping. However, this does not mean that different function blocks do
not use some ofthe same functions. For example, the MIB is a function that is used by several function blocks that
enable them to exchange management information. Another example would be the scheduling function shown in
Figure A.l3. This could 'be used by the performance management application to gather traffic statistics, 'by the
config1.1ration system to discover and del.ete network elements, and by the fault management system to gather
errored-seconds on unstablee.Jements.
Notice that the function blocks in Figure 10.7 are connected with interfilces designated by x, q3, qx, and f. These
are called TMN service intermces or simply, 11lfN interfuces. The TMN interface between function blocks, shown
in Figure I0.8, is called a TMN reference point. A reference point can be considered to be a conceptual point of
information exchange between function blocks. An interface between a management agent embedded in a network
element and a network management system will be a q3 rererence point. When a network m8Jl8gement system
automatically creates 8 trouble ticket in a trouble tracking system, it is communicating via an x-reference point.
When a Web browser interf.'lCes with a Web-based management system. it is accessing an f-retereoce·point. When
a TMN·noncompliant switch is managed by a TivfN·compliant operations system using a Q-adapt.er intermce, it is
interfacing via 8 q.x interface.
Frguo
'r 10.8. Ti1N llrftrtner Pulool

Summarizing, some example~ of network devices imp.lementiog TMN fitnctional components are operations
systems, network management system, application, network element, management network agent, management
information base, RMON. proxy server, GUI, and Web browser. Remember again that DCF such as SNMP. CMIP,
and conunon object request broker architecture (CORBA) is not included here.
The information exchange going across the TMN reference points can be classified into three classes: q...;:lass, f-
elass, and x-class. The q-class reference point interfa.ce.s to fhe management application function. In Figure 10.7,
Ute q-class reference point includes boUt q3- and qx-class TMN reference points. An J.class TMN reference point
is an int.erface between the WSF block and any o!her functio·n block in TMN. An x-class TMN reference point is
an interface between two o~rations system function (OSF) blocks belonging to two different TMNs. as shown in
Figure 10.7.The interface information pertains to functionality ofsimilar nature.
TMN niferen.ce points are designated by lowercase le11ers, q, 1; and x, while the associated interfaces in the
physicalembod ime.nt are identified using uppercase letters, Q, F, and X, as we shall see in the next section.
10.5.2. Physical Arrbltccturc
ITU-T Recommendation M.JOIO presents a model fur the TMN physical architecture, shown in Figure 10.9. A
TMN physical block epuld be an embodiment of one or more blocks, besides its equivalent function block. For
example, an operations system could have its operation function as well as mediation device, which does filtering
of infOrmation. There are ftve lypes of physical blocks representing the ftve functions discussed in the previous
sect.ion, excludingtJ~e TMN DCF.
flgurt I0.9.TMN Pbysk•d Arthhtclurt

TMN
Operations systems are enibodimeniS ofTMN OSF. It is conneded to the mediation device, placing the MF on a
481a·communication network. The dat!l communication network is d1e phys.ical ir.npl.eme.ntalion of DCF, whi.ch to
repeal, is not a function block, but a TMN function, DCF. The network elements, Q adapter, Wld workstations
reflect their respective TMN funCtions.
The Q; F, and X TMN interfaces between the physical devices are alw shown in Figure I0.9, representing the
physical implementation of the respective TMN reference points. The QJ interface is used between the OS and
either anNE or a QA. The Qx interface is shown between MD and QAINE. An examp.
le of this would be an MD
being a proxy server communicating with legacy systems via the QA interface. The F interface is implemented to
connect a workstation to TMN. The X interface is between 1he operations systems belor1ging to two different
TMNs.
10.5.3. l·nrormation Architecture
The TMN information architecture initially adopted the OSI management information architeclW'e, CMIP/CMIS,
defined in d-.e 111J-T X.700 series and discussed in Appendix A. However, with the wide acceptance of Internet
SNMP, e>.tens.ively covered in our earlier chapters, deplo)1nent is in progress using both models in TMN. We have
covered both management models in this book. The OS! information model is object oriented and the SNMP
model L~ scalar. Both model~ are based on the dual roles that entities play in information exc.hange: manager and
agent. Figure 10.10 shows 1he information exchange ·between the 1wo types of entities. 1l1e mrinagcr performs
operations or makes requests from an agent. The agent executes the operations on 1be ne1work elemeniS thai it is
managing and sends response$ to the manager. The agent also sends unsolic.ited messages to the manager
indicatingalarm evenIS.

Fi~urt I0.10. TMN lnformKtion Arddlotlu"'
lnfurmation models specified by SNMP and OS! management deal with the management ofnetwork elements. The
TMN information model has been used in specific technology such as ATM and SDHISONET, which we will
cover in Chapter 12
The information architecture should transport information reliably across the functional boundaries. There are two
types of communication service~ between interfaces: interactive and file oriented. We will discuss the interactive
service in Appendix A. II is supported in OSI by CMlSE over Remote Operations Service.Element (ROSE). In the
Internet dt~tributed computing environment (DCE), thL~ will be handled by Remote Procedure 0111 (RPC). The
ftle-orientcd category is supported by File Transfer Access Management (FTAM) in OST [Raman, l999] and in the
lnternet by File Transfer Protocol (FTP). ln the OS! model, Association Control Services Element (ACSE) is
needed to establish, release, and abort application associations. ln the Internet model, this is integrated in RPC
presentation service. You may consultthe reference (Piscitello and Chapin, 1993] fur more details on this subject.
10.6. TMN Management Service Architecture
Another functional model ofTMN is based on U1e services provided in a TMN environment. The TMN services
are groupe<:~ and presented as TMN layered architecture, as shown in Figure 10. 11 [M.3400]. This layered
architecture is not the same in the strict sense of protocol layered architecture, in that communication can occur
between nonadjacent layers.
FlgiU't I0.11. TMN Strvi<o Archilttlnro

q3
Service Management
q3
N9twol1< Management
q3
EIMient Management
q3
llanaged NeiMllt Elllmont
The lowest layer is the network element layer comprising network elemeniS such as switches, routers, bridges,
transmission faciliiies. etc. The next layer, the network element management layer, manages the network elemeniS.
The third layer is the network management layer, which manages the network. lbe network management functions
In this layer vould include bandwidth. performance, quality of service, end-to-end flow control, network
congestion contro~ etc. 11te network element layer and the network element management layer are vendor
dependent, whereas the network management layer is not.
The servlce management layer is concerned with managing the servloos provided by a network service provider to
the customer or 10 another network service provider. This will include services such as hilling. order processing,
complaints, trouble ticket bandling, etc. The top layer in Pigure 10.11 is the business management layer. This is
concerned with managing a. communications business, SlCh as fiscal considerations, personnel needs, projec1
management, and customer needs and satisfaction.
We notice that the TMN reference point between lhe· various service layers is q3, which is the standard interface
between operations system, networkelement, and MFs shown in Figure 10.7.
The TMN management services are classified into OS! system management functional areas, which are the five
OSJ application functions deseribed in Section 3.9. They are configuration ma11agement, !ilult. management,
performance management, security management, and accounting management. This is presented in Figure 10.12.
Figurr tO.tl.TMN Mnmag•mrnl S.rvlt'ts uud M•n•genanl Fuucliouut A"'"'

TMNIA81VJ9""""'1Swvicos
I Bll$1nei$
• M:lll~)!f'fMiili, I IM••=-~ :...:..I IM=~,, )
l
Syotcm ~a~nt FiJnct.on.Gf ArC&
J C<i'IWI;JuratD:n
M.at'ICQ:!nttnl I J
Ma=!Qntl IParlormance J
Man.t92!!!!!!t l~s.=..:•.l 1 ~1
10.7. TMN Integrated View
Now that we have discussed various aspects and perspectives ofTMN architecture, let us look nt ·the ovemll picture
ofhow all theseiit t.ogether. A representation ofthis is shown in Figure 10.13.
Figtu·• 10.13. Tli1N ~rvic:n and F'nndinns
TMNMal'lllgomuni Socvlatti
(M3ri:::C:m J IMR!liQWJOJ IMat':'=:mJ l.t.ta~
i
Slalom MMOgOft6nl I'Onolbnol AtOno
[eonlij~m!OfJ
_
1!"!ll!!IP"""
1 FouR j
MoMJlOI!Il'QI
[P•iiOrmorceJ
MaM!InJ!I'fl• r;~J LAiCOiii1"'1l I
M'J!I'IJ<!!I'QDI
I
<J2fO T~ Fuldlao Blodtt
EJ Iwsr IEJG EJ
I
Syllom !onaoo.,.nt F•'ICIJCN TMN furotionol Cotnpontnll
roiiJ.;.::_-=-1 r:AIO,o; ~
"'*'"Oft:ntlnl • ~IIMQftf'IOn~ ~
ol • •r~:."'"J
- CMISE
GM
>GETI M·SET/
• • E3>
GET-REOJEST SET-REOJEST
I Rq~O ~,.,Coli
I
I ACSE
I I ROSE
I
+ +
I COrm1UI1C<IIio< Tmnspon $jHv1ce
I
tO'SI ~(et:Enmtion l.ayet)
The four TMN management services-lm~iness, service, network, and elemem-are at the top of the hierarchy.
They invoke the system management functions defined in tbe system management funetional areas. The five

components in the sys1em functional areas are lbe management applil!ation functions: configuration, fuult,
pcnormance, security, rutd accounting.
Tbe management applications in the system functional areas perform eithe.r system management functions o.r TMN
functions. The TMN function "
blocks, OSF, WSF, NEF, MF, and QAP, constitute the TMN function blocks. Tbe
TMN function blocks are made up ofTMN functional components such as network manageme.nt function, MlB,
etc. DCF. although not part ofTMN ftn1ction blocks, is included for completeness.
System management functions include functions such as object management, alarm management, etc. System
management func1ions are discussed in Appendix A, Section A.6. (n Figure 10.13, we could have embedded ihe
system management functions in TMN function blocks and TMN functional components. but have shown them
separ.ately in order to visualize them in a non-OSI e.nvironment. TMN has been exclusively associated with the OSl
environment and it Is only recently that i1 is being considered in the popular SNMP environment.
System malll!gemenr functions and TMN functions invoke the primitive services. Figure I0.13 shows Ute OSI
primitive services ofM-GET, M-SET, etc. Equivalent SNMP services wlll be GET-REQUEST, SET-REQUEST,
etc.
The TMN environment is a diillribuied environmenl. The applications communicate remotely with the
communication transport service using RPC. In the OSI model, RPC Is nccomp.lisbcd with ROSE and ACSE. The
former does the remote operation. and tbe latter establishes and releases the application association. In the SNMP
management mode~ lhe remote operation is accomplished usiog RPC and TCPIIP.
10.8. TMN Im plementation
Although the TMN concept was proposed in the early 1980s, it has not found wide acceptance for several reasons
[Giilho and Hayes, 1995; Ra.mlin, 1998]. Some of these are its strong dependency on exclusive OSJ network
management, high resource requirement, tcclmical complexity, lack of comple1
c Standards, popularity and
simpliciiy ofSNMP managemen.t, and implementation difficulties.
Industry and computer technology were not quite ready in Ute I980s to fully implement (or even partially
implement) the object-orient.ed OSI network management due to its complexity. The objcct-odentcd and layered
OSJ protocol stack demanded processor resources that were beyond the capability of the technology tlten.
However, present-day hardware resources can handle such demands. OS! toolkits are currently available both
commereially and as freeware. Using these tools, products have been developed for trouble ticket administration
(TMN X interiBce) and Integrated Digital L-oop Carrier (TMN QJ interface) recently [Raman, 1999).
Object-orienled technology in those years, as for example DCB and CORBA, was not at the same level as it is
today. This has revived the work on distributed management environmem [Autmta and Strutt, 1994] using the
objoot-orlented approach.
Even witb resources and toolkits available, one cannot avoid the legacy systems interfacing with TMN [Giitho and
Hayes, 1996]. This is accomplished using either the TMN Q adaptation (TMN QA) intermce or adding a new Q
(TMN QJ) interface. The choice between lbe two is based on cost for each approach to accomplish OAMP of a
telecommunications network.
There are three forums that have actively promoted the implementation ofTMN: ATM Forum (now IPIMPLS
Forum), NMF (fonnerly known as Network Management Forum), and recently TM Forum. We covered tbe ATM
Forum's application for ATM in Chapter 9. We will now briefly consider NMF's activilies. TM Forum's activities
are !!ddressed in Section 10.82 and in Chapier 16.
10.8.1. OMNIPoint

An example ofLbe realization ofTMN nrollitecture is presented in Figure I0.14 [NMP]. The left side ofthe· figure
shows the TMN k>gicaJ layered arebitecrure and the right side n physical realization of it. Each L1yer consists of
se~eral management systems providingthe various services. The layered architecture shows the TMN q3 reference
points nod the physical realization the correspondingQ3 interfaces.
Flgurt t0.t4. TI1N ReAIIutlon Eumplt (NMf')
TMN 1.091ea1
L'l!l"f•• Archl!octore
P:!ysbl R<t>ll<ai.Oil 01
TMN ArcM~ro
The Network ManagementForum, later referred 1
0 asNMF, Isan industry-sponsored (onllll. NMF has developed a
program called OMNLPoint. which stands for Open Management Jnteropcrability Point. The objectiv.e is to help
companies implement managemem standards across a wide range of suppliers' equipment. It has developed
documents [NMF) that specify mapping between the lntemct and OSI standards thn! help TMN implementation in
a hybrid management enviroruneot.
10.8.2. cTOM
The TeleManagement Forum (TM Porum) is a body whose mission is to align technologywith real bus iness, and
thus is the oe~ sequential step in the proooss ofTMN implemenllltion. An imponant goal of the 1M Forum is to
atnomate eod-to-end the operations that enable delivery of ''.
information, communication and entertainment
services," and Enhanced Telecom Operations (eTOM) is the framework lo accomplish this mi.ssion. eTOM is a

framework specification and provides a business process model to the 1
.elecommunicalions industry to defme the
processes end-to-end. FigJJre 10.15 depicts the business process archi1ecture defined by eTOM.
Flgul'f JO.JS. eTOI1 8ush1rss Proces..~ Fr'Amewnrk-Levt:l 0 proce..ie.~
Clr~t··.... ~·~
.,._
a.-.,.. 1
1
lliOc;jO .1~),=
'-"'! ...........!' - EI!F-If-1 -
...... ~ ..011«<-1 c-....-~~
__...._
_.._..~-
p._....,.~· ~
·~.~--~
R_....._,,.~
~CorlpW-Q . , . _ ,
,._,
So4'11'r0..~&.._..,_ ~""*~Ul'•'ll~
II
E-~
1 ~~-11 "'-··- 11~~~~-i
-
IF&naol&-
11=::=11--I
,.._.,... ..._.
The business processes are described in a layered hierarchical fashion. where process at each klvel can be broken
down Into lower-level process clements. eTOM is structured In three broad areas or Level 0 processes-Strntegy,
Infrastructure, and Product (SIP); Operations (OPS); and Enterprise Management (EM). Of these areas, the OPS
areas ofservice manngemeDI and operations, and resource management nod operations come within the purview of
network management and address a perspective s.imi.lnr to the functional model covered in Section 3.9. Ea.cb Level
0 process in tum contains detailed components at Le.vel I, 2, etc.
The ITU-T standard adopts 1he management service/function approach, while the eTOM framework adopts a
business process approach thatbuildson the management services/functions to develop a reference framework that
ca1egorizes all business activities a service provider will use. The main difference between the TMN and eTOM
approaches l$ I bat the former ha$ been developed starting from networks and rJCtwotkequipme01 (bottom up) while
eTOM is a top-down approach. 1ltecTOM framework bas been incorporated in toto w.
ithln the TMN framework as
a set ofstandards [M.3050.x].
Figure 10.16 depicts the subset of the layers of the eTOM map that are implemented as applications in a !ypical
NMS product n!ongside a rough correspondence with the more tradiliouaiiTU-T-based TMN visualization. While
the management functional areas in TMN are referred to as FCAPS (fault, confJgurntion, accounting, performance,
and security),they are rererred to as FAB (fulfrllment, assurance, billing) in eTOM.
l'igurr 10.16. t1'0M·t[)o'I11N Modrl

TMN Pyramid
SMLl 2 Sorvlce Nan~~goment
NML, EML: G RC!IOurce Mgmt
eTOM
The applicatK>ns in the box of Figure 10.16 are typically i.mp.lemented as part ofan NMS product .Figure 10.1.7
shows the Level 2 processes for the Level I processes ofFAB activities in service management and operatK>ns, as
well as resource managementand operations. Each Level 2 process element is in tum broken clown Into finer Level
3 element-s .representinga greater level ofdetaiL
Figurr 10.17. oTOM Levrl l Procrssr~to-M.J400 F'w1rlion S.t Grout>s
~M-=~
=.~
=-~=~
-~~r--~,,_~~: --
=.
] • :
....__119, ,-
-v
-
The implementation ofthe OS! management application functions described in Seetion 3.9 is covered in detail by
ITU-T specifications M.3400. The mapping of these functions to Level 2 eTOM processes is shown in Figure
10.17. There Is a one-to-one mapping of fuur of the five functions, the exception being security management
[M.30SO Sup 3]. Figure 10.18 iltustrates the mapping of the specific case of configuration fuucl:ion mapped to
eTOM Level processes.
Flgu•·• 10.18. rTOM L""tll P>'oetssts-to-M.J400 CoullgiU'•tiou Full<'liOJt

11>'10--
~~=u~-~ =-~1
·--- ~t I ~I
r~tv II ··---- I~·-=- ·---1
Summary
We bave presenh::d in lhl~ chnptern brief introduction ro lhe complex subject ofTelecommunicn1ions Management
Network (TMN). Allhough il was proposed byiTU-T in the early 1980s, it isjust now becoming a reality due to
the advancement oftechnology and the availability ofOSl standards and toolk~s.
We learned the role ofoperations systems in operation, administration, maintenance, and provisioning (OAMP) as
they are currently iJnplcroented by telecommunication service providers. We defined their role in TMN. Networ.k
managementsystem is·considered an operations system in theTMN environment.
We defmed the concept of TMN consisting of customers, services provided by telecommunication service
providers, network. operations systems, and system operators. Due to the mukit.ude of servloes provided by a
multit1Kie ofservice providers using a multitude ofvendor equipment, TMN has proposed reference points between
tbe various components tbat defme standard service inter.
filces. The original TMN proposal is exclusively OSI
standards based.
TMN architecture is presented from three perspectives: .functional. physica~ and information. The .funclionaI
architecture is made up of five functions: operations system function (OSF), network elemeot function (NEF1
mediation function (MF), Q-adapter function (QAF), and workstation function (WSF).The interface between !hem
is defined by three 1MN reference poinis: ~ q3/qx, and x.
TMN physical architecture is !he physical manifestation of the functional architecture with tbe functions
implemented in ope~ons systems, mediation devices, network·ele.rnents, QAfs interfucing with non-TMN legacy
systems, and workstations. Tbe data communication function is a distributed function carrying ini>rmation
between function blocks using network management operations, responses, and notifications.
TMN service archirecture consist.~ of fuur layers of management and a fifth layer of network elements. Tbe four
layers of management are element management, network management, service management, and business
management. We presented an integrated view ofalltbe various components, showing bow they all fli together to
form the TMN environment. We discussed lhe issues and recent activities in implementing TMN. We touched
upon tbe recent advancement of technology and tools tbat bave helped U~e implementation ofTMN. The roles
played by the three.forums-the ATM Forum, the NMF, and TM Forum-werealso addressed.
Exercises
1. Shannon's channel capacity theorem provides the fullowing relationship fur maximum channel capacity (bits per
second) In terms of bandwidth 8 and slgnai"to-noise ratio S/N.
C =B lo&l (l+SIN)

The SIN in decibels (dB) is related to SIN in power ratio by
SIN in dB = Hl(Jog,oS/N)
The U"ansmission operations ~'}'Stem dcseribed in Figure I0.1monitors SIN ofa telephonechannel with a
3-klh bandwidth and a cham1el capacity of30 kbps. When SIN decreases by 3 dB, the operations system
issues a warning alann nnd the telephone trunk facility is taken out ofservice ifSIN goes down by 6 dB.
Calculate the channel capacity in bps at (a) warning threshold and (b) out-of-service limit keeping the
same 3-kHz bandwidth fur the telephone channeL
2. Design atraffic measurement operations system·that monitors the packet traffic at layer-2 on the nodes shown
In Figure 10.2. Assume that all traffic Is made up Of unlcast packets and the links and nodes are such that the
packets dropped at any node are· primarily due to traffic overload on the node. The·system measures the
Incoming and ou(l!olng packets handled by the data link layer as it interfaces with the physical and network
layers. Assumethat the system permitsthe user to set the thresholds for action ba.sed on percent packet loss.
a. What Mm objects would you monitor?
b. .Express the threshold parameters fOr congestion (peroeot packet loss) on the node as a function of
the measured parameters.
3. Figure 10.19 shows anetwork management environment consisting of a MoM (Manager of Managers) NMS,
several agent NMSs that manage1n!;llvidual network domains, and managed network elements. Identify the TMN
functions performed by:
a. MoMNMS
b. AgentNMS
c. Managed el.e.ments
Figure lO.t9. Enn:l>t 3
Mc1
M
: M:mo~g!.!r urMi!n:t~.·r~
~I OU. Mun::tgcml!nt rl.l~4.1.w
c:::::::J AH"'" PtO<.-..~
4. A proxyserverconfiguration (Agure 6.46) Is.used to manageSNMPv1 network elements by an SNMPv2 network
managementsystem.
a. What TMN fimction doesa proxy server play in an NMS environment?

b. fdeotify the interfaces ofdte proxy server to the network manager and network elements.
5. In Figure 10.19,Identify all:
a. TMN reference points
b. TMN interfaces
6. Associate M1 through MS interfaces in ATM management (Figure 10.9 and Figure 10.10) with TMN refertmce
points and TMN service Interfaces.
7. CMISE services are fisted In Table A.3. Map these senilres, whereverpQSsible, to SNMPvl.senilces.
8. Repeat Exercise 7comparing CMISE and SNMPv2 services.
9. TMN can be applied to ATM switch management usil'lll either SNMP or CMIP spedficatlons. Research the ATM
Forum specifications refe.renced In Table 123 and Identify the OBJECT IDENTIFIERS for the two modules,
atmfM4CmlpNEVIew and atmfM4Snmpvlew.
10. The ATM objects are defined under the node lnformationModule(O), which ts the subclass of atm.fCmlpNEVIew.
Five managed object dasses are defined under the lnformatlonModule, which are atmfM40bject0ass,
atmfM4Package, atmfM4Attrlbute, atmfM4Name81ndll18, and atmfM4Actlon. Draw a namll'lll tree far these·,
explicitly ldentlfyfl'lll the Object.ID.
11. Flgure·lO.l8 shows mappine of eTOM Level 2 processes·to-M.3400 Configuration Function. Do slml.lar mapplne
ofeTOM Level 2 processes·to-M.3400speclflcatlons for:
a. Faull Management
b. Perfom~ace Management
c. Account·ing Management
11. Network Management Applications
Objectives
Network management and system management
Network management
o Configuration
o Fault
o Perfi>rmnnce
o Security
o Accounting
Configuration management
o Configura/ion managenumt

o Service/network provisioning
o lnvemory malll!gemenr
Fault management
o Fault detection and isolation
o Correlation techniques for root cause analysis
Perjorm(JJlce management
o Performance metrics
o Data monitoring
o Problem isolmion
o Performance statistics
& curity m011agement
o Security policies and proc«<ures
o Security tbi'CQts
o Firewall
o Cryptography: keys, algorithms. authentication. and nuthomation schemes
o Secure message transfer methods
Accounting managemem
Repon management
Policy-based management
Service level management
o Quality ofservice, QoS
o Service level agreement, S.LA
The management of networked information services involves management of network and system resources. OSl
defmes network management as a five-layer archi1ecturo. We have extended tbc model to include system
management and have presented the integrated.architecture in Figure· 11.1. At the highest .level of 1MN are the
functions assodatoo with managing tbc business, business management. This applies to nil institutions, be it a
commercial business, educational institute, telecommunications service provider. or any other organization that
uses networked systemsi.o111anage d1eir business.
Flgurr I 1.1 . Nrtwmi< ond Systrm Manogrmtnl

An institution is a business that provides either a product or service. in either case, there are service considerations.
For example, a product-oriented business has to be concerned with customer service as well as intQmal services.
The service management for a service provider, including a telecommunication service provider, is an absolute
necessity. Please see Section 10.8, Figure 10.14 fOr so.me of the service applications.
The third layer ofTMN deals with network management or system management. Neh,~rk management manages
the global network by aggregating and correlating data obtained from the element management systems. Likewise,
the system management aggregates and coordinates system resources by acquisition of data ·&om the resource
management systems. The complementary functions of network and system management manage the networked
infoonation system composed ofnetwork elemems and system resources.
Our focus in this chapter will be on network management application.s. As we learned.in Chapter 3, there are five
different categories of applications: configuration management, fault management, performance management,
security management, and account management. Others [Leinwand and Conroy, 1996] have treated the five
categories of applications and presented simple and complex tools to manage them.
The subject ofconfiguration management may be looked at not only from an operational viewpoint, but also from
engineering and planning viewpoints. In our Lreatment of configuration management in Section II. I, we have
included network provisioning and inventory managcmem. This is in addition to the configuration of networ.k
topology, which is part oftraditional net.work managemeot.
Fault management involves detection ofa fauk as il occurs in the oelvork, and subsequently locatingthe source of
the problem. We.should finally Lqolate the root cause of the problem. lltL~ is covered in Section 11.2.
1t is harder to detine perfonnance of a network in quantitative terms than in qualitative terms. Forexamplt, when a
user observes that the network performance is slow, we need to define what slowness is, and which segment ofthe
·network is slow. On the other hand, it couid be that the appucatioo, which could be running on a server, is

behaving slowly. We discuss performance maoagemem in Section 11.3. We will discuss perfOrmance metrlcs and
learn how 10 monitor 8 network fur performance. Performance Slatlstics play a very important pan in network
management, and se~eral system tools available fur gathering statistics will be covered.
When a fauk occurs in a netwo[k, eitber due to milure ofa component or due 10 perfOrmance, it may manifest itself
in marty places. Thus, from a centmlized management system, we observe alanns coming from multiple locations.
Correlating these alarm even.ts and fmding the root cause ofthe problem is a challenge. We wiU discuss the various
correlation technologies inSection 11.4.
Security in network is concerned with preventing illegal access to infOrmation by unauthorized personnel It
involves not only technical issues, but also establishment ofwell-defined policies and procedures. We will discuss
the various issues associated with autbentiCillion and authorization in Section 11.5. We will also deal with the
establishment ofsecure (ie., without illegal monkoring and manipulalion) communication between the source and
U1e receiver.
The business healt:h of an institution or corporation depends on weU.malntained accounting management and
reponing. Reports for management have a different purpose from that ofrepons generated fur day-In-day network
operation. There are also reports needed fur the user to measure tbe quality of service 1
0 be provided by service
level agreement (SLA). TI1ese arecovered in Sections 1.1.6 and 11.7
We have addressed.tbe five layers of management with network elements being at tbe lowest level and business
management being a1 tbe top. Element management a1 the second layer maintains 1he network. Network
management at thethird level and service management 111 the fourth level are based not just on technical issues but
alo;o on policy iSsues. Once policies are established, some of them could be implemented in the system. For
example; ifa network is congested due to heavy traffic, should the network parameters be automatically adjusted to
increase bandwidth, or sbould traffic into the network be decreased. A policy decision that has been made on th.is
can be implemented as partofthe management system. We will discuss this in Section 11.8.
Service level management is an important aspect of network and system management. II goes beyond managing
resources. It Is concerned with tile SLA between t:he customer and the service provider regarding the qualily of
service ofnetwork, systems, and business applications. Tlus is covered in Secrion 11.9.
IJ. I. Configuration Management
Configuration management in network management Is normally used in the context of discovering oetwotk
topology, mapping the network. and setting up tbe configuration parameters in management agents and
management sys1ems. However, as discussed in Section 1.9 and shownin Figure 1.21, network management in the
broad sense also includes network provisioning. Network provisioning includes network planning and design and
is considered part ofconfiguration management.
11..1 .1. Network Provisioning
Network provisioning. also called circuit provisioning in the telephone industry. is an automated process. The
design of 8 trunk (circuit from Ihe originating switching center to the destination switching center) and 11 special
service circuil (customized for customer specifications) is done by application programs wriHeo in operation
systems. Planning S)'1!iems and inventory systems are integrated with design systems to build a system ofsystems.
Thus, a cirouit designed for the future automatically derives its tum-up date from tbe planning system and ensures
that tbe compone.nts are available in the inventory system. Likewise, when a circuit is to be discoruiCCted, it is
coordinated with tbe planning system and the freed-up co.mpollents are added to the Inventory system. Thus, Ihe
design syslem is made aware of1he availability ofcomponenls far future des'igns.
An exnmpleofa circui1·provisioning system is 11 system of systems developed by Bell System (before it was split),
called Trun.k Integrated Record Keeping System (nRKS). TIRKS is used i.n automated circuit provisioning of

trunks. A trunk is a logical circuit between two switchingoffices and iltraverses overmany facilities. 11.RKS is an
oper::rtions system In lhe conleXI ofTelecommunical.ions Management Ne1work (TMN) that we dealt with in
Chapter 10. Given the requirements of a trunk, such as transmission loss and noise, type of circuit, availability
date, etc., as input to the system, the system automatically designs lhe components of lhe lrunk. The designed
circuit will identify transmission facilities beiween switching offices and equipment in intermediate 8J)d end
offices, The equipment will be selected based on what would be available in the future when lhe circuit needs to be
installed.
Network provisioning in a compuler communications network has different requirements. Instead of cirouii·
switcbed connections, we have packer-switcbed palhs fur information to be transmitted from lhe source to tbe
destination. In a connectionless packet-switched circuit, each pacltet takes an independent path, and the routers at
various nodes swit.ch each packet based. on the load in lhe links. The links are provisioned. based.on average and
peak demands. In store-and-forward communication, excess packets can be stored in buffers in routers or
retransmitted in !be event the packets are lost or discarded. In the connection-oriented circuit requirements,
permanent and switched vinuaJ circuit demands need to be accommodated fOr end-to-end demands on tbe various
links. Network provisioning for pacltet-switched network is.based on perfOrmance statistics and quality ofservice
requirements.
Network provisioning in broadband wireless area network (WAN) communication using ATM technology is mo~e
complex. The virtual-circuit concept is always used and has to be taken into account in the provisioning process.
The switches are cell-based, in contrast to frame-based packet switching. Each ATM switch has knowledge oflhe
virtual path-virtual circuit (VP-VC) ofeach session connection onlylo the neighboring nodes and not end-t~rend.
Bach ATM switch vendor has buib their proprieblry ass·ignment ofVP-VC for end-t~rend design into the ATM
switch. The arehitectuni ofeod-to-cnd provisioning ofATM circuits could be eithercentralized or distributed, and
is based on whether the circuit is a permanent virtual circuit (PVC) or a switched virtual circuit (SVC).
Commercial products, which provision PVCs across multiple vendor products, have recently been introduced in lhe
market.
11.1.2. Inventory Man:tgement
We have addressed the importance ofinventory management in circuit provisioning. A:n efficient database system
is an essential part of the inventory management system. We need to be aware of all the delllils associated with
components, which should be accessible using different indices. Some of the obvious access keys are the
component description or part number, components that match a set ofcharacteristics, components in use and in
spare, and components to be freed-up fOr future use.
In Section 11.1.1 we cited the example ofTIRKS, which is a system ofsyst.ems. Two of the systems lhat TIRKS
uses are equipment inventory (El) and fiscilities inventory (Fl). TheE I system has an inventory of all equipment
identil}dng what is ·currently available and what will become available in the future with dates of availability.
Similar infurmation is maintained on facilities by the Fl system. With such a detailed inveutory system, TIRKS
can anticipate circuit provisioning for the future wilh compooent·s that would be available.
Legacy inventory management systems use hierarchical and scalar-based database systems. Such databases limit
the addition of new components or extend the properties of existing components by adding new fields. These
limitations can be rc.moved by using relati011al database technology. Further; new NMSs, such as in OSI CMIP and
Web-based management, use object-oriented technology. These manage object-oriented managed objects. An
object-oriented relational database is helpful in configuration and inventory managementin such an environment.
JJ .t.J. Network Topology
Neh,;>rk managemenl is based on knowledge of network topol.ogy. As a network grows. shrinks, or otherwise
changes, the network topology needs to be updated automatically. This is done by lbe discovery application in the
NMS as discussed in Section 9.4.4. The discovery process needs to be constrained as io lhe scope of the network

that it discovers. For example, the arp command can discover any network component tbat responds with an 1P
address, which can then be mapped by the NMS. Jfthls lnclude.s workstations that are rumed on only when they are
in use, the NMS would indicate failure whenever they are off. Obviously, that is not desirable. In addition, some
hosts should not be discovered for security reasons. These should be filtered out during the discovery process so
the discovery application should bavethe capability to set filter parameters to Implement these conStraints.
Autodiscoverycan be done using the broadcast ping on ea.ch segmen.t and following up with further SNMP queries
to gather more details on the system. The more efficient method is to look at the ARP cache in the local router. The
ARP caehe !ableis large and conlains the addresses of all the recently communicated hosts and nodes. Using tbls
table, subsequent ARP queries could 'be sent io other routers. TI1is process is continued until information is
obtained on all 1P addresses defmed by the scope of the autodiscovery procedure. A map, showing network
topology, is presented by the autodiscovery procedure after the addresses of the network eutiiles bave been
discovered.
The autodiscovery procedure becomes more complex in the virtual local area network (LAN) configuration. Figure
11.2 shows the physical configuration of a conventional LAN. The router in the figure can be.visuali:r.ed as part of
a backbone (oot shown). There are two LAN segments connected lo the rooter, Segment A and Segment B. They
are physically connected to two physical ports in the router (i.e., there is one port for each segment used on the
Interface card). They are Identified as Port A and Port B, corresponding to Segment A and Segmenl B,
respectively. Botll LANs are Ethernet LANs and use bub configuration. Two hosts, Al and A2, are connected to
Hub 1 on LAN segment A and ·two hosts, B l and 82, are connected to Hub 2 on L.AN Segment B.
r-------..=.~
Ro or
A:J.
POIIB~~
~IB ...~
Hub2
82
Figure 11.3 shows the logical configuration for Figure 11.2. The logical configuration is wbat the autod.iscovery
process detects. Lt is very similar to the physical configuration. Segment A corresponds to LAN on Hub I with the
hosts AI and A2. Ills easy to conceptually visualize this and easy to configure.
Flgurt ti.J.Loglral Configuration ofT"o LAN S.gmtuiS

Q ~
AI A2
() L::= ~Aitluo I =-=:J
~
ROI.Ief
0 F Sew<!<!• B/1-tub ~
~
-,
81 B2
Let us .now contrast Figure 11.2 wid1 Figure 11.4, which shows the physical configuration of two vinual LANs
(VLAN). We notice that only one physical port, Por1 A, is used in lhe router, not two as in the case ofa trnditionaJ
LAN. Hosts A I and A2 are configured to be on VLAN I, and hosts 8 I and 8 2 are configured to be on VLAN 2.
Although VLAN grouping can be done on different criteria, let us assume thnt it is done on port: basis on the
switch. Thus, the two ports marked Segment. A on the switch are grouped ns VLAN I. The other tVO ports, marked
Segment B. are grouped as VLAN 2. Thus, Segment A corresponds to VLAN I and Segment 8 corresponds to
VLAN 2. We observe that VLAN I and VLAN 2 are spread across the two physical.hubs, Bub I and Bub 2. With
a layer-2 brilgcd network. the VLAN network is efficient. As IEEE 802.3 standards are established and widely
adopted, 'this configuration hns been deployed more and more, a.Jong with a backbone network.
Figurt tl.4. VLAN Physic~! Configurution
The logical view ofthe physical VLAN configuration shown in Figure 11.4 is presented in Figure 11.5. We see
that Hosts A I and A2 still belong to Segment A, but are on different hub$. Likewise, Hosts 8 I and 82 belong IO
Segment B. The autodlseovery process would not detect the physical hubs thai are Identified in Figure 11.5. lo
many silual'ions, the switch would a.lso be t.ronsparent, ns there are no IP addresses assodated with switch pons.
Cons;:quently, it would be harder to associate the logical configuration with the physical configuration.
Figul'f t LS. Logi<lll Cnnfigurotion orTwo VLAN ~IOLII!S

AI (Hib I) A2 (Hull2)
0 I SogoiiOHI AIH<I!>a 1>n<l2 :::J )
ROtJIIIr
()
This makes Ute network management taska·complex one. First, two sepamre maps must be maintained on an on-
going basis as changes to t.be network are made. Second, when a new oomponent is ooded and autodiscovered by
the system, a manual procedure is needed to follow up on the physical configuration.
In the example above, we talked about grouping ofVLAN based on the ports onUte switches. Wecould also group
VLAN based on MAC a.ddress, lP address, or protocol type. Grouping by lP address bas some benefits in tbe
m:Ulagement ofVLAN network. Tb.e logical grouping ofcomponents based on lP netvork segments makes se.nse.
ln addition, as a policy the sysLoeation entity in a system group should be filled in for easi.er management.
11.2."F11ult M.aoagcmcot
Fauh in a ·network is normaHy as50ei11ted with failure ofa network componentand.subsequent loss ofconnectivity.
FauJt management involves a five-step process: (I) mult detection, (2) fault location, (3) restoration ofservice, (4)
identification ofroot cause ofthe problem, and (5) problem resolution. l'be fauk should be detected as quickly as
possib.
le by the centralized management system, preferably before or at abotn the same· time as when the users
ootice it. Fault location involves identuying where the problem is located. We distinguish this from problem
isolation, although in practice it could be the same. The reason for doing tllis is tbat it is important to re;iore
service to the users as quickly as possible, using alternative means. 1l1e restoration of servioe takes a higher
priority over diagnosing tl1e problem and fixing it. However, it may not always be possible to do this. ldemification
of the root cause of the problem could be a complex process, which we will go into greater depth soon. After
identifYing the source ofthe problem, a trouble ticket can be generated to resolve the problem. ln an a111omated
netwoik operotions oenter, theirouble ticket could be genemted automatically by the NMS.
U..2.1. F1tult Dctcdion
Fauh detection is ncoomplished using either n polling scheme (the NMS polling management agents periodically
for status) or by the generation of traps (management agents based on information from the network elementS
sending unsolicited al.arms to the NMS). An application progmm in NMS genemtes the ping command periodicaJiy
and waits for response. Connectivity is declared broken when a pre-set number of consecutive responses are not
received. The frequency of pinging nnd the preset number for failure detection may be optimized for balance
between traffic overhead and the rapidity with which failure is to be dete<.ted.
The nllemative detection scheme is to use traps. For example,. the generic trap messages linkDown and
egpNeighborLoss in SNMPvl can be set in the agents giving them the capability to report events to the NMS with
the legilimat.e COIJimunity name. One ofthe advantages oftraps is that failure detection is accomplished mster with
less traffic overhead.
1.1 .2.2. Fault Location and Isolation TccllllitJues

Fault lo<:ation using a ~imple approach (we will look at 1he compte)( approach using the correlation technology in
Section 11.4) would be to detect all the network components that have failed. The origin of the problem could then
be traced by walking down the topology tree where the problem starts. llms, ifan interfitce card on a router bas
failed, all managed components connected to that interface would indicate failure.
After having located where 1he fault is, the ne~~,-t step is to iso late the fault (i.e., determine the source of the
problem). First, we should de-lineate the problem between failure of the component and the physical link. Thus, in
the above example, the interfa.cecard may be functioo.ing well, but tbe l.ink to tbe .interfu.ce may be down. We need
to use various diagno.stic tools to isolate thecause.
Let us assume for 1he momem that the link is not the problem bm that the interface card is. We then proceed to
isolate the problem to the layer that is causing il.lt is possib.
le tbat excessive packet loss is causing disconnect ion.
We can measure packet loss by pinging, if ping.ing can be used. We can query the various Management
Information Base (MlB) parnmeters on the node itself or other related nodes to further localize tbe cause of the
problem. For example, error ra1es calculated from the interface group parameters, lfinDiscards, lfinE.rrors,
i!OutDlscards, and itOutErrors with respect to the input and outpul packet rates, could help us isolate the problem
in lhe interfitce card.
The ideal solution to locating and isolating the fault is ro have an artificial intelligence solution. By observing aU
the symptoms, we mighl be able to identify the source ofthe problem. There are seveml teGhniques to accomplish
this, which we will address in Section 11.4.
U.3. .Pcrfomumce Maoagcmcol
We have already addressed performance management applications directly and indirectly under the various
headings. We discussed two popular protocol analyzers, Sniffer and NetMetrix, in Chapter 9. In Section 9.2, we
used the protocolanaly.t.er as a ~stem tool to measure traffic monii·oriog on Ethernet LANs, which is in lhe realm
of perfi:>rmance management. We looked a1 load monitoring based on various parameters such as source and
destination addresses, protocols at differenl layers, etc. We addressed traffic slati.stics collected over n period of
from hours to a year using the Mulil Router Traffic Grapber (MRTG) tool in Sectklo 9.2.4. Tbe sratistics obtained
using a protocol nnnlyz.er as a·remote monitnring (RMON) tool was detailed in the case study in Sec1ion 8.6. We
noticed how we were able to obtain tbe ovemJJ trend in lnte.met-rclated traffic and the type oftraffic.
Performance of a network is a nebulous term, which is hard to define or quantify in terms ofglobal metrics. The
purpose of 1he network is to carry infOrmation and thus performance management is really (data) traffic
management It involves the fOllowing: dara monitoring, problem isolation, perfOrmance tuning, analysis of
statistical data fOr recognizing trends, and resource planning.
lJ .J.J. J'erforomuce Metrics
The parameters that can be attributed to defining network performance on a global level are throughput, response
time, network availability, and network reliability. The mctrics on these are depende.nt 011 what, wh•:m, and where
the measurements are made. Real-time traffic performance metrics are latency (i.e., delay) and jitter, which are
addressed inSection I I 3.4.
These macro-level parameters can be defined in terms of micro-level parameters. Some of the parameters that
impae1 network throughput are bandwidth or capacity of the transmission media. its utilization, error rate ofthe
channel. peak load, and avemge load oftbe traffic. Tbese can be measured at specific points in the network. For
example, bandwidth or capacity will be different in dif!erent segments of the network. An Ethemet LAN with a
capacity of 10 Mbps can.function to full capacily with a.single workstation on it, but reaches full capacity wiib a
u1ilization factor of 30-40% when densely popula1ed wilb workst:rtions. This utilization factor can further be
defined in terms of collision rate, which is mensurable. ln contrast, in a WAN, the bandwidth is fully utiliz.ed
except for the packet overhead.

The response time ofa network not on.ly depends on the throughput ofthe network, but also on 1he application; in
other words, it depends on both the network and system performance. Thus, in a clieo~~rver environmeol, the
response time as seen by the client could be slow either due to the server being heavily used, or the network traffic
being overiQaded, or a combination of both. According to Feklmeir [1997]. '~he application responsive.ness on the
network, more than any other measure, reflects whether the network is meeting the end use.
rs' expectations and
requirements." He defines three lypes of metrics to measure application responsiveness; application availability,
response time between Lhe user and Lhe server, Wld the burst frame rate, which is Lhe rate at which the requested
data arrive at Lhc user sration.
IETF Net1~rk Work:ing Group has developed several Request for Commems (RPCs) on i raffic flow measurement.
RFC 2063 deftnes the architecture for the measurement and reporting of.network traffic flows. The network is
characterized as traffic passing through four representative .levels.. as shown in Figure I L6. Backbone networks are
those that are lypically connected to other networks, and do not have individual hosts connected to them. A
regional network is similar to a backbone, but smaller. lt may have individual hosts connected 10 it. Regional hosts
are subscribers to a backbone network. Stub/enterprise networks connect. hosts and LANs and are subscribers to
regional and backbone networks. End systems or hosts ore subscribers to aU ofthe above.
Figure 11.6.Tr.tffk Flow Mra:surtmtnC Nttwork Otaracttriz.Rtion
lntomntlonaf
Ba<*borws.'Na'~nal
Stub/Enlorprise
The nrcbitecrure defmes three entities for traffic flow measurements: meters, meter renders, and managers. Meters
observe network traffic flows and build up a table offlow data records for them. Meter readers collect traffic flow
dat.a from meters. Managers ove,rsee the operation ofmeters nncl meter rende.rs. RFC 2064 defines the MlB for the
meter. RFC 2123 describes NeTraMet, an implementation offlow meterbascd on RFC 2063 and RFC 2064.
U .3.2. Data Monitoring
Data monitoring in i!Je network for abnormal performance behavior. such as high collision rate in Ethernet LAN,
excessive packet drop due to overload, etc.. are detected by t raps generated.by agents and RMON. Performance-
related issues ore detected primarily using Imp messages generat.ed by RMON probes. Thresholds are set for
important SNMP parameters in the RMON. which then generate alarms when the pre-set thresholds are crossed.
For example, the parameters in the alarm group and tiJe event group in RMON MIB [RFC 1757] may be set for the
object identifier 10 be monitored. l11e time interval over which the data are to be coUected for calculation and i!Je

rising and falling thresholds are specified. In addition, the community names are set fur who would receive lhe
alarm. Ak·bougb we classi.fY such alarms under perfOrmance category, they could also be defmed under fault
category as is done in Section 9.4.6.
NMSs generally report all events selected lor display including alarms. Alnnns are set lor criticality and lhe ioon
ch&nges color based on the criticality. Depe.nding on the implement!llion, the alarm is either automatically cleared
when the alarm condition clears or is manually cleared by an operator. The latter case is useful for alerting the
operations personnel as to what happened.
11 .3.3. Pr'Oblem lsol:u ion
Problem isolation fur performance-related issues depends on the type of-problem. As we 113'e indicated befure, a
high percentage of packet loss will cause loss of connectivity, which oould be inlermillent. In Ibis situntion,
monitoring the packet loss over an extended period will isolate the problem. Another example is the perfurmance
problem associated with large delay. This may be altributabl.e to an excessive drop ofpackets. We can identilY the
source ofthe packet delay from a route-troc·ing procedure and then probe fur t.he packet discards at t:l.at node. Refer
10 [Rose and McCloghrie, 1995] for a detailed analysis of the performance degradation cases in various
components and media.
As in fauh management, problems could occur at multiple locations simultaneously. Tbese could be reponed to lhe
central management system as multiple independent events although they may be correlated. For example, an
excessive drop in pncket.s in one of the links may switch the trafii.c to an alternate route. This could cause an
overload in that link, which will be reported as an alarm. A more sophisticated approach using the correlation
technology is again required here, which we will discuss in Section 11.4.
11.3.4. l'er10rmllltce Stflti•tiO<
Performance st.atistics are used in tuning a network., validating of SLA, which will be covered in Section 11.9,
analyzing use trends, planning facilities, and functional accounting. Data are gathered by means of an RMON
probe 11nd RMON MIS fur statistics. Statistics, to be accurate. requiJ:e· large amounts of data sampling. which
create overhead traffic on the network and thus impact its performance.. One of the enormous benefits of using
RMON probe forcollecting sllltistics Is that it can be done locally without degra~ing theoverall performanceofthe
network. An RMON MID contllins the history and statistics groups (see Section 8.4) for various media and c.an be
used efficienily to collect the relevant dilta and store them fur current or fuiure analysis.
One application of lhe results oblllined from performance Sllltistics is to tune the network for better perfOrmance.
For example, two segments of the netvork may be connected by a gateway and excessive iotersegment traffic
could produce excessive performance delay. Error statistics on dropped packets on the gateway interfaces would
manifest this problem. The solution to resolve this problem is to increase the bandwidth ofthe gateway by either
increasing its capacity or by adding a second gateway between the segments. Of course, adding the eldra gateway
coukl cause configuration-related problems and hence reconfigumtion oftraffic may be needed.
Various error statistics at different layers are gathered to measure the quality of service and to do perfurmance
improvement, if needed. Some of the odter .Performance parameters tl.at can be tuned by monitoring network
statistics are bandwidth oflinks, utilization oflinks, and controlling peak-to-average ratio of inherently bursty data
traffic. In addition, uaffic utilization can be improved by redistributing lhe load during lhe day, with essential
traffic occupying the busy hours and non-essential traffic the slack hours, with the latter being store and forward.
An impo11ant performance criterion in real-time traffic in broadband .service is the latency or delay caused by
dispersion in large bandwidthsignal This affects lhe quality ofservice due to perfonnance degradation.
Anolher important sunistiC; especiaUy in real-rime broadband services, is the variation in network delay, otherwise
known asjitter. Titis impacts the qualityofse.rvice (QoS) guaranteed to the customer by the SLA. Forexample, in

a cable modem, a managed objec1 docsQoSServiceClassM;l.x.lirter (see 1be DOCSIS Qunlily of Service M1B i.o
Table 13.3) is used 10 moni10rtbejiuer.
Another performance apl?lkaiion is validation ofSLA bet~veen tbe.service user and tbe service provider. The SLA
may require limiting input io lhe service provider network. If tbe packet rate is lending toward tbe tbresbold of
SLA, one moy hove 1o·controllhe bandwidth ofiheaccess to the service provider network. Tliis can be achi.eved by
implementing application interfa.ces th.at use algorithm$ such as the le<Jky bucket or the token bucket [Tanenbaum,
1996].Tbe leaky bucket algorillun Limits the maximum outpUI data role, and the token bucket algorithm colllrols its
average value. Combining the two. we can tune lhe peak-to-avemgc ratio oftbe output. Some ATM switches have
such ioierfuces built into lhem, which are easiJy tunable. This would be desirable ifa service provider's pricing is
based on peak data rate usage instead ofaverage rate.
Performance statistics are also used to project traffic use trends on traffic use and to plan future resource
requirements. Statistical data on traffic are collected and periodic reports are generated to study use trends and
projec1 needs. Thus, trend analysis is helpful for future resource plwming.
Statistics can be gathered, as we saw inSection 9.2, on the nelvork load created by various users and applications.
These can be used to do functional accounting so tba1 the cost ofoperation ofa network can be charged to the users
ofthe network or ru leas! bejustified.
11.4. Event Corrclalion Techniques
We.have illustra1ed some simple methods 10 diagnoseand isolate 1be sourceofa problem in faul1 and perfonnance
management. When a centra_
Uzed NMS receives a trap or a notificafion, it is called receiving an evem. A single
problem source may cause multiple symptoms, and each symptom detected is reported as an independeni eveoi to
tbe monagernent system. Obviously, VC· do not want to ttea1 each event independently and actio resolve it. Thus, it
is important Ibat the management system correlates all these events and isolates lhe root C
·ause ofthe problem. The
techniques used for ~Wcomplishing this are called event correlation toohniques.
lbere are severalcorrelation techniques used to isolate and localize fault in networks. All are based on(I) detecting
and filtering of ev-ents, (2) correlating observed events to isolate and localize lhe fault either topologically or
functionally, and (3) identizying lhe cause of the problem. ln aU three Cl1Se5, tbere is intelligence or reasoning
behind tbe methods. The reasoning melhods distinguish one technique from another.
We will discuss six approaches to correlation teclmiques. They are (I) rule-bliSOO rellsoning. (2) model-based
reasoning, (3) c&se>-base.d re!lS()ning, (4) codebook, (5) state trnnsiti.on graph mode~ and (6) finite state machine
model. See Lewis [1999] for a detaiJed comparison ofthe various methods.
Jl.4.1.ltulc-.BIISetl Reasoning
Rul~basoo reasoning (RBR) is the earliest form ofcorrelation technique. It is also known by many otbenmmes
such as rult>bascd expert sy~em, expert system, production sysu:m, and blackboard system. It has a knowledge
base, working memory. and an inference engine, as shown in Figure 11.7 [Cronk £U.j., 1988; Lewis, 1994]. The
tbree levels representing tbe three components are tbe knowledge leve~ the data !eve~ and the coUlrol level,
respectively. Cronk et nl. are also a good source for review of nerwodt applications ofRBR. The knowledge base
colllains expert knowledge as to (I) definition ofa problem in the network and (2) action that needs to be taken ifa
particular condition occurs. The knowledge base infOrmation is rule-based in lhe !Orm of if-then or conditio~
action, containing rules that indicate wllicb operations arc to be performed when. The working memorycontains-
as working memory elements-tbe topological and staie iltformatlon of the network being moni1ored. When the
IJCIWodt goes into afimlty state, it is recognized by tbe working memory. Tile inference engine, In coopemtion with
tbe knowledge base, compares tbe curre01 ~ate with tbe left side of tbe rule.base and finds tbe closes! match to
output lhe rightside ofthe rule. The knowledge base then executes an action on the working memory element.

Figurt II.7. Bui< Rulr-Baud Rtaronlng Parodigm
03talevol
Col'lli'Oilevo
In Figure ll.7, the rul&-based paradigm is interactive between the three compone.ots and is iterative. There are
se-
veral strategies for lhe rul&-based paradigm. A specific strategy is implemented in the inference engine.
Choosing a ~-pecific rul.e, an action is performed no the working memory element, wblcb could then initiate another
event. This process continues until the correct state is achieved in the workirlg memory.
Rules are made up in the knowledge base from the expertise of the experts in the field. The rule is an exact match
and tbe action is very specific. lf the antecedent in the rule does not match, the paradigm breaks and it is called
"brinle." However, it can be fixed by adding more rules, which would increa.o;c the database si7.e and degrade the
perforlll3Dcc, referred to as knowledgeacquisition bottleneck. There is an exponential growth in ~izeas the number
ofworking memory elements grows.
In addition. the action is·specific, which could cause unwanted behavior. For example, we can define. the alarm
condition for packet Joss.as follows:
If packet loss < 10
I:f packet loss •> 10' < 1St
If packet l oss => 15%
ala.rm gree.n
ala D!I yellow
alarm red
The left side conditions are the working memory elemen1s, which if detected would execute the appropriate ru.Je
defined in the rule-base. As we can see, tbjs could c~use the alarm condition to flip back and forth in boundary
cases. An application offitzzy logic Is used 10 remedy this problem [Lewi<>, 1994], but il is harder to implement.
The RBR is used in Hewlett-Packa.rd OpenView Element Manageme.nt Framework [Hajela, 1996]. Figure 11.8 is
an adaptal'ion of the scenario from [Hajela, 1996] to Illustrate an implemenwtioo of RBR. It shows a. rour-layer
oetwol'k.. Backbone Router Alinks to Router B. Hub C, connected to Router B. has four servers, Dl through D4, in
it!l LAN. Without a correllltio.n eog_ine, failure in ibe inlermce ofRouter A will ge-nerate an alarm. This mull U1en

propagates 1.0 Router B, HubC, and finally 1.0 Servers DI through 04.11 is importrun to realize thai. !here·is a time
delay involved in the generation ofalarms. In general, propagation of faults and time delay assoeias.ed with them
need to be rccogni7..ed as such in fuult managemen1.
Flgw·t 11.8. RBR-Bo,.cl Cbrrtlolion Exanlplo Sc•nBrlo
Four correlation rulc·S are specified in Figure 11.9. Rule 0 bas no condition associated with it. Rules 1-3 are
conditional rules. In order t<l allow for the propagation time, a correlation window of20 seconds is set.
flgurt I L9. Rnlts Spt<ificatioos for lht Examplt in Fil;urtll.8
rtuloO
Rulo1
Rule2
AlarmA.
NarmB
A'armC
Send 1001C8UI5e Alam1 A,
RuJ
e 3 Natm Ox
Correlabonv.indow; 20 seoorlds..
lt.NarmAp....,nl
If AlarmB preseri
1
f A'arm C present
RulotodiOA and i!Jnorv
Relalod toBard ignOf!l
Related loC and o
gnore
The inference engineatthe control level interprets lhe above roles and tokes the ac6ons shown in Figure I1.10.
Flgurt 11.10. Conlo'UI Actions for lbt RBR Exampit orFlgurt 11.8
Correlallon Winllo'.Y: 20 SllOOf1ds
Amvl'llollllotm"
Arriv~l ollllarm B
l llhrmlaonl
I
(Correialed byRule I)
AmvaJ Olllarmc
(Conalat<d byRul<>2)
Amval olAlarms Ox
!Colrelata1byR1Ae3)
End ofCO<nl!allon WIIIClDW

ln the above example. i1 can be observed thai only alru:m A is sent aod others fire ignored as long as they arrive
within the correla1ion window. The alarms could even be genera1ed ou1 of seq1ence. However, because of the
specification ofcorrelation wiodow size, !he inference engine waits before seoding alarm.~ B, C, and Dx.
Se<-eml commercial systems have been buih using RBR. Some examples are Computer Associates1NG nod Tivoll
TME.
11.4.1. Mot.lel-Bliset.l Reasoning
An event correlator based on model-based reasoning is built on an object-orienled model associlued with each
managed objecl. A model is a representation of !he component i1· models. 1l1e mode~ in the traditional object-
oriented representation, has attributes, relations -.o other models, aod behaviors. The relationship between objects is
reflected in a similar relationship between models.
Let us picture a network of hubs 1hnt are connected to a-rotrter, as shown in the left halfofFigure II. II. The right
halfshows tbe correspooding model .in the event correlator in the NMS. The NMS pings every hub and the router
(real~ a router interfa.ce to the backbooo network) periodically to check whether each componem is working. We
can nssociaie communication between the NMS aod a managed component as between a model (software object)
in the NMS/co.rrelator aod its counterpart of managed object. Thus, in our example, the model of each bub
periodically pings its hub aod the model ofthe router pings the router. As long as all the components are working,
no additional operation is needed.
Flgur• tl.JI.Mod<I·B.,ed R~asoulngEvr.oi Corrolutor
Physical Not.vork Equwatent Model
If Hub I falls. it is recognized by the H I model. Let us assume thatthe HI model is programmedio wait fur lack of
response in three consec:ulive pings. After tlu-ee pings with no response, Lbe 1:11 model suspects a fililure ofHubl.
However, before it declares a failure and displays an alarm, it analyses its relation to other models and recognizes
that it should query the router model. If the ronter model responds thnt the roilier is working, only tben Lhe HubI
alarm is triggered. Iflhe router model respoods Lhnt il. is not reeeiving a response from 1be ronter, then the Hubl
model deduces that the problem is with the router aod 001 Hub l. At leas1, it cannot definitively dete.
rmloe a Hub I
failure as long as it cannot communicate with Hub I because ofthe router failure.

The above example is modeled after [Lewis, 1999], who presents an intereSLing seeoario of a classroom with
teacher. Outside the classroom is a computer network wil:b a router aod workstations. Each &udent is a modeI
(software mirror) ofthe workstation. The teacher is a model oftbe router. Each student commuoicates with hi-s or
her real-world counte,rpart, which is the workstation outside the classroom. The teacher communicates with the
router. Ifa student fails to commuoicate with his or her workstation, heor sbe querie,s the teacher as to whether the
teacher could,communicate with U1e teacher's,router. Depending on the yes or no answer ofthe teacher, the student
declares a "fail" (yes) or "no-fail'' (no) condition, respectively. Model-based reasoning is implemented i,n
Cabletron Spectrum.
11 .4.3. Casr-Basro n easoning
Case-based reasoning (CBR) overcomes many ofthe deficiencies ofRBR. In RBR. the unil ofknowle<lge is a rule;
whereas in CBR, the unit of knowledge Is a case [Lewis, 1995]. The intuition ofCBR is that situations repeat
U1emselves in the real world; and that what was done in one situation is applicable to others in a simllar; but not
necessarily identical situation. Thus, when we try to resolve a trouble, we start with the case that we have
experienced before (Kolodner, 1997; Lewis, 1995]. Kolodner treats CBR from an infOrmation management
viewpoint; and Lewis applies it specificallylo network management.
The general CBR architecture is shown in Figure 11.12 [Lewis, 1995]. It consists offour modules: input; retrieve,
adapt; and process, along with nease library. The CBR approach uses the knowledge gained befOre and extends it
to the current situation. The former episodes are stored in a case library. Ifthe current s,ituation, as received by the
input tnodule, matches one that is present in the case library (as compared by the retrieve tnodule), it is applied. lf
it docs not, the closest situation is chosen by the adapt module, and adapted to !hecurrent episode io resolve the
problem. The process module takes the appropriate action(s). Once the problem ls resolved, the newly adapted case
is added to the case library.
fllgm.. tl.ll. Grnrra.l CBRArrhilrc1m·•
Levis also describes the application ofCBR in a troubkHmcldngsystem, CRITTER [Lewis, 19%]. The CRITfER
application has evolved into a CBR application for network management named SpectroRx built by Cablctron.
When a trouble ticket is c.reated on a network problem, it is compared to similar cases in the case,library containing
previous trouble tickets with resolutions. The current trouble is resolved by ooapting the previous case in one of
three ways: (1) parametedzed adaptation, (2) abstmction/respecializntion adaptation, and (3) critic-based
adaptlltion. The resolved trouble ticket is then added to the case library. We will use the examples given in the
reference to illustrate the thnie adaptation methods.
Parameteriz.ed Adaptation. Parame,terized.adaptation is used when a similar case e>tists in the case library, but the
parameters may have to be scaled to resolve the current situati:Jn. Consider the, current trouble with
tile_transfer_throughpu~ which matches !hefolbwing trouble ticket in the case library,shown in Figure 11.13.
fllgurrtt.t3.MAIChingTruubkTltktl fori he CBR ExMmt•k

Trouble: file_transfer_throughput=F
Additional data: none
Resoluuoo: A=f(F). adjust_networl<_IOad=A
RllsoiUUon sla1Us: good
ln the parameter:lzed adaptationoft·he irouble ticket sbown in Figure 11.14, variable F has been modiJied to F? and
the relationship between network loa4 &4justme.nt variable A? and F? remainllle same as between A and F. ln the
default siluation, where there is an exact match, F? and A? are F and A.
Flg•tr<ll.t4. P•rat~~tlerlud Adat>l•llou for lhe (]JR E:l.Rlllt>le
Troullfe: file_tr.msfer
_lhroughpo.t=f'
Mdtbonaldala: none
Resolubon: A'=f(F j, adjusLJletWOII<.)oaii•A
R!!SOiubonstatJs: good
Abstraction/RespeciaHz.ation Adapmtion. Figure 11.15 shows three trouble tickets. The first two are two cases from
the case library !hnt matclled the current problem we have been discussing. l11e first option adjusts the network
load, and the seoood option adjusts the bandwichb ofthe network. The user orthesystem has the option ofadapting
either of the 1:vo based on restrlctklns to be placed on adjusting the workload or adjusting the bandwidth. Let us
choose the optkln of not restricting the network load, which implies that we have to incrense the bandwidth. We
can add this as additional data. to the trouble ticket that chooses the bandwidth option and create a new trouble
ticket, whioh is shown as the U1ird trouble ticket in Figure 11.15. This is now added to U1e case library.
l'igure tl.t5. Abstroclion/Rosprrialization Ad11p1atiou for lbt CBR Example
Trouble· file_transfer_throughput=F
Add1bonal data: none
Resoh.rt1on: A=f(F), adjust_netwoikjoad.,A
Resolution status: good
Trouble: file_transfer_throughput=F
Additional data. none
Resolution: B=g(F). adjust,_network_bandwldh=B
Troublo: filo_lransfor_lhroughput=F
Addl~onal data: adjust_network_load=no
Resolution: l3=g(F), adjust_network_bandw!dlh=B

This CBR adaptation is referred to as ab.stracilinlrespecialization adaptation. ChoosinglO adjust bandwidth and not
load is a.policy decision, wbicb we will diSQUSS in Section 11.8.
Critic-Based Adaptation. The third adaptati:>n, critic-based adaplation, is one where a critic or a craft perSon
decides to add, remove, reorder, or replace an existing solution. Figure 11.16 shows an example where the
network_load has been added as an additional parameter in adjusting the network load, and reSQiution A is a
function oftwo variables, F and N. This is added as a new case to the case library.
Flgur• ll.t6. Cridr-Bast'd AdaptatiOJI for tbt CBR E.<amph!
Trwble· file_tramteutvoughput=F
Alk!JIIOmt dala: ntiWOfk_Joa(r-r.
ResokJI.bo·A=f(FN~ adlu~ ner~ load=A
Resolution status:good
CBR-Based CRJlTER. The architecture ofCRllTER i.s shown in Figure 11.17 [Lewis, 1996]. II is integrated with
the NMS, Spectrum. The core modules of CRIT!'ER are the four basic modules of the CB.R system shown in
Figure 11.12: input, retrieve, adapt, and precess. There is a fifth additional module, propose, which displays
potential solutions found by the reasoning module and allows the user to inspect and maouaUy adapt these
solutions.
Flg•tr• 1 1.17. CR11TER ArcW.teelun

CRITTER
The input module receives its input from the mull detection module of Spectrum. The process module updates the
ticket library with the new experience. The retrieve module uses detenninators to retrieve a group of tickets from
the library that are similar to an outstanding ticket. The initial set of determination rules is based on expertise
knowledge and is built into the determioators module. The application technique is the strategy used by the adapt
module.. User-based adaptation is the lnterfuce module for the user to propose critic-based adaptation.
Comparing RBR and CBR [Kolodner, 1997] distinguishes the differences between RBR and CBR. ln RBR, the
retrieval is done on exact match, whereas in CBR the match is done on a partial basis. RBR is applied to an
iterative cycle ofmicroeveots. CBR is nppued ns a total solution to the trouble and then adapted to the situation on
hand.
11.4.4. Codebook Correlation Model
AlgoriLbms have been developed to correlate events that are generated in networks based on modeling of the
network and the behavior ofnetworkcomponents, Because they are based on algorithms, claims are made that they
do not require expert knowledge to nssociate the events with problems, Although this is true, we still need expert
knowledge in selecting the right ldods ofinput that are 10 be fed to the correlator to develop an efficient system.

Figure I 1.18 [Kliger llM·· 1995) shows the arcb.itecture of a model-based evem correlation system. We should
caution that !he "model-based event con:elatJon" should not be confused with the term "model-based reasoning
approach" that we di.scussed in Section 11 .4.2. As ·!he heading states, we will refer to this as codebook correlation.
Flgw·• ll.I.S. Grnork: Arrbil« luro oran Evrnl Correlation S~>l rm
Monitors capture alarm events and input them to thecorrelator. The configuralion model conmins lhe configuration
ofthe network. Ibe event model represents the various events and their causal relationships (we will soon define
the causality relationship). The correlaior correlates !he alarm evems wilh the eveni model and determines the
common problems that caused the alarm event
One of the correlation algorithms based on generic modeling is a coding approach to event correlation [Kiiger ~
.!!l, .1995]. ln this approach, problem events are viewed as messages generated by a system and ''encoded" in sets of
alarms that they cause. The function of the correlator is to "decode" those problem messages to identify the
problems. Thus, the cooing technique comprises two phases. In the· first phase, caHed lhe codebook selection
phase, problems to be monitored are identified and the symploms or alarms that each of them generates are
aSS<X:iatcd with the problem. (As we stated at !he beginning of this approach, this is where cx.per1 knowledge is
needed.) Tbls produces n problem-symptom matrix. In the second phase, the correlator compares the stream of
alarmevents with the codebook and identifies the problem.
In order to generate the codebook matrix of problem-symptom, let us first consider a causality graph, which
represents symptom evenlS caused by other events. An ex.ample ofsuch n causality graph is shown in Figure. IJ .19.
Each node in the graph represents nn event. Nodes are connected by directed edges. withedges starting at a causing
event and terminating at a resulting event For example, event El causes events E4 and ES. Notice that events El,
E2, and E3 have the directed edges only going out from them and none coming into tbem. We can identify these
nodes as problem nodes and !he rest as symptom nodes, as r.hey all have at least one directed edge pointing inward.
With problems labeled as Ps and symptoms as Ss, the newly labeled causality graph of Figure 11.19 is shown in
Figure 11.20. Tbere are three problem nodes, PI, P2, and P3, and fOur symptom nodes S I, S2, S3, and S4. We
have eliminated those directed arrows where one symptom causes another symptom, as it does not add any
additional infOrmation to the overall causality graph. ·
Flgort 11.19. CRusaUty Gnot>h

flguro 11.10. Labeled Ca1uallly Gr111
1h for Flgurt 11.19
We can now genero1e a codebool) of problem-symptom matrix for the ca.usality graph of Figure 11.20 (we will
drop the qualifier "labeled" from now on). This is shown in Figw-e II.21 with three columns as problems and four
rows liS symptoms.
Flgurt lLll. Codrbouk for Flgun IL20
1>1 1>2 P3
S1 1 1 0
S2 1 1 I
:>3 0 1 I
S4 0 0 I
In general, the number of symptoms will exceed the number ofproblems and hence, the codebook can be reduced
10 a minimal set of symptoms needed to uniqncly identifY the problems. It is easy to show that two rows are
adequate to uniquely identi:fytbethree problems inthecodebook shown in Figure 11.21. We will keep row Sl and
uy 10 eliminate subseqncnl rows, one a1 a time. AJ each step, we waru to make sure that the remaining codebook
distinguishes between the problems. You can prove to yoUrselfthat eliminating rows S2 and S3 does not prescrve
the unique.ness, whereas eliminating either S2 and S4 does, The reduced codebook, called the correlation matrix, is
shown in Figure 11.22.
Flg~trc JJ.22. Corr·rlllUon M~tril for Flgurr IJ .10
Drawing the causality graph base-d on the correlation matrix of Figure 11.20_
, we derive the correlation graph
shown in Figure 1
.1.23, whicb is called the correlation graph.
Figure I1.23. CoJTtlllllon GrAilh for flgurr 11.20

We will apply the above knowledge io a more general situation of the causality graph shown fn Figure 11.24
[Kliger eta t., 1995]. Figure 11.24{a) depicts the causality graph of II events. Figure 11.24(b) shows theequivalent
problem~mptom causality graph. Nodes I, 2, and II show only outgoing directed arrows and are bc:noe
identified as problems and the rest ofthe nodes assymptoms.
Fi~urt t 1.24. Gentroliud CoU!IIHiy Gr>t>h
p p
(b)P~~IyGr.lph

We will now reduce the causal.ity graph to a correlation graph. Symptoms 3, 4, and 5 fonn a cycle of causal
cqui>;alencc aod can be replaced by a single symptom, 3. Symptoms 7 aod 10 are caused, respectively, by
symptoms 3 and 5 and hence can be ignored. Likewise, symptom 8 can be elimi.nated as it is an intermediate
symptom node between problem node I aod symptom node 9, which is also directly related to problem node II.
We thus arrive at the correlation graph shown in Figure 11.25 and the ~-orrelation matrix shown in Figure 11.26.
Notice that in the particular example Ute model is unable to distinguish between problems I and II as they produce
identical symptoms in the correlation graph based on the.event model.
FlgurcJJ.2.5. Corr·tblUon Crapb ror F'igurt LL.24
Figut't I1.26. COJTtlatiou M•lrlx for Flgurt 11.24
PI P2 P11
~ 1 I 1
ss 0 1 0
sg 1 0 1
Funher refinements can be made in the codebook approach to event correlation in terms of tolerance io spurious
noises and probability relations'hip in the causality graph. We have derived the correlation.matrix to be the minimal
causal matrix. Thus, each column in the code matrix is differentiated from other columns by at· least one bit (i.e.,
value in one cell). From coding theory. this corresponds to a Hamming d.istance ofone. Any spurious noise in the
event detection could change one ofthe bits and ·thus a codeword would identify a pair ofproblems. This could be
avoided by Increasing the Hamming distance to two or more, which would increase the number ofsymptoms in Ibe
correlation matrix. Also, the relationship between a problem and symptoms could be defined in terms of
probability ofoccun:ence, and the correlation matrix would bea probabiiLo;tic matrix..
The codebook correlation technique has been implemented inlnCharge system developed by System Management
ARTS (SMARTS) LYemini ct at., 1996].
11.4.5. State Transition Graph Model
A state trnnsition graph model is used by Seagate's NerveCenter correlation system. This could be uSed as a stand-
alone system or integrated with an NMS, which HP OpenView and some other vendors have done.
A simple state diagram wilb two states fOr a ping/response process is shown in Figure IL.27. The two states are
ping node and receive response. When an NMS sends a ping, it transitions from the ping node state to the receive
response state. When it receives a response, it transitions back to the ping node state. As you know by now, ibis
method is how the health ofall the components is monitored by the NMS.

Fi~urt tl.27. Stole Tnm>iilunDiagriUD for Ping!Rtsj>Onu
It is besc to illuslrnte with an example of how a stale crnnsition diagram could be used to corre.bte events in the
netwo(k. Let us cboose the same examp.
le as in model-based reasoning, Figure II.II. An NMS is pinging tb.e hubs
that arc accessed via o router. Let us follow through the scenario of the NMS pinging a hub. When the bub is
working and the connectivity to the NMS is good. a response is received fur each ping .sent, say every minute, by
theNMS. This is represented by the top two stales, ping hub rutd receive response, on the left side ofFigure 11.28.
Let us now consider the sit13tion when a response for a ping is not received be!Ore Ill<} next ping is ready to be
sent. NMS typically expects a response in 300 milliseconds (we are not pinging some obscure host in a fureign
country!). An acti:>n is taken by the NMS and the state transitions from receive response to pinged twice (referred
to as ground state by NerveCenter). lt ls possible that a response is received for Ute second ping and in that
situation the state 1ransitions back to the normal ping hub state.
Figure 11.28. St•t• Transition Gr•pb Examt>lt

NoResponse
IIOI!IRoolot.
Nolctlcn
NoR011ponse
--. ·Ro•ponso·····
However, ifthere is no response for the second ping, NMS pings a third time. The state lransition is now pinged
three times. The response for this ping will cause a.u:ansition to the ping hub state. However, let us consider the
situation ofno-response for the ·third ping. Let us assume that the NMS is configured to ping threetimes before it
declares thlll there Is a communication failure between iland the hub. Withow any correlation, an alarm will be
triggered and the icon representing the hub would tum red.
However. the bub may actually be working and the workstations on it may all be communicating with e<tch other.
From the topology database, the correlntor in theNMS is aware that the path to the bub is via the router. Hence, on
failure ofthe third ping. an action is Ioken and Ihe system transitions to the ping router state. The router is pinged
and the system i ransitions to the receive response from router state.
There are two possible outcomes now. The connectivity to the router is lost and no response is received from the-
router. The system takes no action, which is indiO<tt.ed by the closed loop in the ping router state. (How does the
router icon tum red in this case?)
The second possibility Is that a response is received &om the rower. This means thai the connection 10 the bub is
lost. Now, the correlntor in theNMS triggers an alarm that turns the hub icon red.

We notice that in tbe scenario of a router connectivity fallure, only the router icon turns red and none oftl~e hubs
connected to it tum red. thus identifYing the roo! cause ofthe problem.
1'1.4.6. Finite State Machine Model
Another model-based filuh deJection scheme uses !he communicating fini1
e sl8te macbioe [Mlllcr, 1998]. Tile main
claim of this process is mat it is a passive testing system. It is assumed that an observer agent is present in each
node and reports abnormality to ncentral point. We cnn visualize '!be node observer as a Web agent nnd the central
point as the Web ilerver. An application on the server correlates the evenl.s. A failure in a node or aJink is indicated
bythe state machine nssocialed with the component entering an illegal stale.
A simple communicating fmile state machine for a client- server system is shown in Figure 1129. It presents
communication between a client and se,rver via a communicution cbnno.el. For simplicity, both the client and the
server are a<;Sume.d to have 1wo slates epch. The client, which is in send request state., sends a request message to
the server, and transitions to receive the response state. The :>e.rver is currently in the receive request slate. The
server receives the request and 1ransitioos to the send response staJe. After processing the request, it sends the
response and transitions back to the receive request state. The client then receives the response from the server and
transitions to the send request state.
Flgurt I 1.29. Commurliratlug Fluilr St•c• MAdliut
Communicatlon
onannec
Ifeither !he client or ihe-server enters an illegal state during thetrnnsilions, !he system has encountered a fuulL For
example, after :>endinga response, ifthe serverdoes not transition to receive a request slate, it is in a tailed state. A
message is sent to a central loc81ion under a fault condition either by the component itself or by tbe one
communicating with the·failed component. This is a passive detection scheme similar to ·the trnp mechanism.
We cnn observe a similarit.y between the finite siate machine model and tbe state lrnnsition graph model with
regard to state transitlons. However, !he main difference is that the furmer is a passive sys1em and the latter is an
active one.
11.5. Security M an:tgemenI
Security management is hath a technical and an administrative issue in information management. It involves
securing access to !he network and information flowing in dte network, access to data stored in !he network, and

manipulating the data that fire stored and flowing across the network. TI1e scope of network and access to 1 noI
onlycovers enterprise imraoet network, bu1 also the Internet that il is connected 1
0.
Another area of grea1 concern in secure communication is communication with mobile stalions. 1l1ere was an
embarrassing case of n voice conversation from the car-phone of a politician being intercepted by a third party
traveling in an automobile. Ofcourse, this was an onnlog signal. However, this could also happen in the·case of a
mobile digital station such as a hand-held stock trading device. An intruder could intercept messages and alter trade
lf8l)S8Ctions eitber 10 benefit by it or to burt the person sending or receiving them.
In Chapler 7 we covered several of the security issues IISSOciated with SNMP management as pari of SNMPv3
specifications and discussed possible security threatS. Four types of security threaiS to network management were
identified: modification of infOrmation. masquerade, message stream modification, and disclosure. They are
applicable t·o security in the implementation ofsecurity subsystems in the agent (authoritative engine) and in the
manager (non-authorillltive engine). The SNMPv3 security subsystem is the User-Based Security Model (USM). It
has two modules-an authentication module and a privacy module. The· former addresses data integrity and data
origin; the latter 5 concerned with data confidentiality, message timeliness, and limited message protection. The
basic concep1S discussed in Chapter 7 are partofgeneralized security managemenr in data communication.~.
Security management goes beyond tbe realm ofSNMP management. In this section, we will address pol.icies and
procedures, resources to prevent security breaches, !!lid network proteot~n from software allacks. Policies and
procedures should. cover preventive me<~Sures, steps to be taken during the occurrence of a security breach, and
post-incident measures. Because the Internet is so pervasive and everybody's network is pan of it, all government
and private organizations in the world are concerned wit.h security and privacy ofinformation traversing it:.
1n this introductory Iextbook, we will nol be going into the depth of security managemenl that it deserves. For
additional infOrmation, you are advised 10 pursue lhe innumerable·refere.nces available on tbe subject [Cooper ~
!!!., 1995; Kaufman et al., 1995; Leinwand and Conroy, 1996; RFC 2196; Wack and Carnahan, 1994].
11.5. 1. J'olicies 11otl J'rocedu res
The IETF workgroup that. generated RFC 2196 defines a security policy as "a fOrmal statemenr of the rules by
which people who are given access to an organizntion's tec.hnology and information assets must abide." Corporate
policy sboukl address both access and security breaches. Access policy is concerned w.
ith who has access to wbal
information and from what source. SNMP management addressed this in terms of a community access policy fOr
network. management information. An example of access policy in an enterprise network could be that all
employees have full access to the network. However, no1 everyone should have access to all corporate information,
and thus accounts are established fi:>r appropriate.employees 10 have access to appropria1e hosts and applications in
those hosts. These pol.icies should be written so lhat all employees.are fully aware ofthem.
However, illegal entry into systems and accessing of networks must be protected against. The policies and
procedures for site security management on lbe Jnte.met are dealt with in detail elsewhere [RFC 2196; NIST,
1994]. The National Computer Security Center (NCSC) bas published what is known as the Omnge Book, which
de.fmes a rating scheme for computers. It is based on the securil.y design features of the computer. 'Tile issues for
corporatesite security using the intranet are the same as for the Internet and are applicable to them equally.. It 5 a
framework ror setting security policies and procedures.
The basicguide to setting up policies and procedures is:
1. Identify what you are trylflt!to protect
2. Determine whatyou are trylflt! to protect it from

3. Determi(le how likely the threats are
4. Implement measures, whloh will protectyour assets In a cost-effective man(ler
5. Review the process continuously and make improvements to each item if a weakness is found
The asseiS that need to be protected should be listed including hardware, sof,lware, data, documentalion, supplies,
and people who have responsibility fur all of the above. The classic threats are &om unauthori7..ed a.ccess to
resources and/or information, unintended andlor unauthorized disclosure of information, and denial of service.
Denial of service is a serious attack on the n.etwork. 1l1e nel~vork is brought to a sUite in which it can no longer
carry legitimate users' dam. This is done eithe·r by attacking therouters or by flooding the network with extraneous
trnffic.
11.5.2. J~esourcc.~ to Prev~nt Seeuri.ty Hreocbes
We addressed tbe policies and procedures in the last section. ln this section, we will discuss various security
breache~ that are attempted to access data and systems, and the resources available to protect them.
Figure 11.30 shows a secure commun1cation network, wh1ch is actually a misnomer. There is no fully secure
system in the real world; the.
re are only systems which are hard and time..:-onsuming to break into, as we shall
describe. Figure 11.30 shows two networks communicating with each other via a WAN, which hasjust one router.
Server A and Client A shown in Network A are communicating with each other; and Cuent 8 in Network 8 is al.so
communicating (or trying to communicate) with Server A in Network A.
Flgw·• ll.JO. S«urt Cununmll<lltlon Ne~worl<
Let us look at the securit.y breach points in this scenario. Hosts in Network B may not have the privilege to access
Network A. The firewall gateway shown in Figure 11.30 is used to screen traffic going in and out of seoore
Network A Even if Network 8 has access permission to Nehurk A, some inlntder, for example one who has
access to the router in the path, may intercept the message. The contents oflhe message, as well as source and
des1inai"
ion identifications, can he monitored and manipulated, which are se~urity breaches.
Security breaches can occur in the lntemet and intranet environment in numerous ways. ln most corporate
environments, security is limited to user identification and password. Even the password is not changed often
enough. This is the extent ofauthentication. Authorization is limited to the establishment ofa.ccounts, i.e., who can
log into an application on a host. Besides noonal act"iviries of breach, we have to protect against special situations,
suc:h as when a disgruntled employee could embed virus programs in company programs and produciS.
11.~.3. Firewalls

The main purpose ofa firewall is to protect a network from external attacks. Jt monilors and controls traffic into
and out of a secure network. h can be implemenled in a router, or a gllteway. or a special host. A fu:ewall is
normally located !It the gateway to a network, bui it may also be implemented at host access points.
There are nwnerous 'benefits in implementing a firewall to a network. It reduces the risk ofaccess to hosts from an
eXIemal network by filrering insecure services. It can provide controlled access to the network in ibat only
specified hosts or network segments oouJd access some hosts. Since security protection from external threats is
centralized and transparent, it reduces the annoyance to iDlcmal users while controlling the e.xtellllll users. A
firewall could also be used to protect the privacy ofa corporation. For example. services such as !be utility finger,
which provides information about employees to outsiders, can be prevented from accessing the network.
When the security policy ofa company is implemented in a firewall, it is a concatenalion ofa higher-level access
service policy, where a total service is filtered (lUI. For example, !be dial-in service can be t(ltally denied at !be
service policy !eve~ and ihe firewall can filter out selected services. such as the utiliiy .finger, which is used to
obtain infonnation on personnel.
Flrewalls use packet filtering or application-level gateways as the two primary techniques ofcolllrolling u.odeslred
traffic.
Packet Filters. Packet ftltering is the ability to filter packets based on protocol-specific criteria. It isdone at the OS!
data link, network. and. transport layers. Packet filters are implemented in some commercial fOUters, called
screening ro1rters orpacket-filtering routers. We will use thegenerictenn ofpacket·filtering routers here. Although
routers do not look at the transport layers, S:Ome vendors have implememed this additional feature to sell them as
firewall route.rs. The fdtering is done on the following parameters: source IP address, destination fP address, source
TCP/UDP port, and destination TCP/IP port. The filtering is implemented in each port of the router and can be
progranlOled independently.
Packet-filtering routers can either drop packets or red.irect !hem to specific hOSts for further screening, as shown in
Figure 11.31. Some ofr.he packets never reacb tlte local network as they are trashed. For example, all packets from
network segment a.b.c.O are programmed to be rejected, as well as File Transfer Protocol (FTP) packets from
d.e.f.0:21 (note that Port 2.
1 is a standard FTP port). The SMTP (email) and FTP packets are redirected to their
respective gateways for further screening. It may oo observed from the figure that the firewall is aS)'mmetric. All
incoming SMTP and FTP packets are parsed to check whether they should be dropped or forwarded. Howeve.r,
outgoing SMTP and FTP packets have already been screened by the gateways and do not have to be checked by
the packet-filtering router.
Flgur< lJ.31. Packoi·I'Uiorlng Router
Setured Network
Packe1-Alterl119
Rortor
A packet-filtering firewall works well when !be rules to be .implemented are simple. However, the more rules we
introduce, the more difficult it is to implement. The rules have to be implemented in the right order or they may
-produce adverse effects. Testing and debuggingare also difficult in packet filtering [Chapman, 1992].

Application-Level Gateway. An application-level g;neway is used to overcome some of the problems idenlified in
packet filtering. Figure 11.32 shows the appliccatioo g::rteway architecmre. Firewalls Fl nod F2 will only forward if
data are to or from the applicat.,n gateway. Thus, the secured LAN is a gateway LAN. The application gateway
be-
haves differently for each application, aod filtering is handled by the proxy services In the application gateway.
For example, for FTP service, the file is stored first in the application gateway and then forwarded. Fo.
r TELNET
service, the application gateway ve.rifies U1e authentication ofthe foreign host, the legitimacy to communicate with
·the local host, aod then makes the connection between the gateway 11od tbe local host. It keeps a log of all
transactions.
f!lgur• tl.32. Appllcotiou-U:v•l Cat<way
PtOX)'
Stmc;.e•
Apj>llc:n:on
GlliOWiy
Firewalls protect a secure-site by checking addresses (such as IP address), rranspor1 parameters (s.uoh as FTP,
NNTP), aod applications. However, how do we protect access from an extemal source based on the user. who is
using a false identification? Moreover, how do we protect again.~i an intruder manipulating the data while they are
traversing the network between the source aod tbe destination? These concerns are addressed by secure
communication.
U .5.4. Cryptography
For secure communication, we nocd to eosure integrity protection and authentication validation. Integrity
protection makes sure that the infom~ation has not been tampered with as it tmverses between U1e source sod the
destination. Autbentication validation validates the originator ifentification. l.n other words, wben lao receives a
message that identifies it coming from Rita, is it reaUy Rita who sent the message? These two important aspects
address the four security threats--modification of infOrmation. masquerade, message stream modification. aod
di<iclosure-mentioned nt ihe beginning of Section 11.5. Besides the actual message, eonrrol and protocol
l~andshakes need to be secure.
There are hardware solut.,ns to authentication. However, it is noi a complete solution, since the information could
be intercepted aod tampered wilh as it tmverses from the source to tbe destination, including tbe user identification
aod password.
The technology that is best suited to achie.ving secure communication is software-based. Its foundation li.es in
cryptography. Hashing or message digest, and digital sigoature, whlch we will address soon, are built on top of it to
achieve integrity protection aod soun:e authentication.
Cryptographic Communication. Cryptogmphy means secret (crypto) writing (graphy). It deals with techniqueJ> of
transmitting informatiOJL for example a letter from a seodcr to a receiver without any intermediary being able to
decjpher it. You may view this as the information (letter) being translated to a special language that only thesender
aod receiver can interpret. Now, Cl)-ptogrsphy should also detect if somebody was able to intercept the

infonnation. Again extending our analogy, if the letter written in a secret language were 10 be mailed in a sealed
(we mean reallysealed) envelope, ifsomebody Ulmpers with it, the receiverwould detect it.
The basic model ofcryptographic communication is shown in Figure 11.33. The input message, called plaintext, is
encrypted by tbe encryption module using a seer1.1 (encryption) key. The encrypted message is called ciphertext,
whi.ch u:averses through an unsecure commuo.ication ·channe~ the Internet for example. The ciphertext is
unintelligible information. At the receivi11g end, the decryption module deciphers the message with a decryption
key to retrieve the plaintext
flguro 11.33. Boslt Cr)1Jiographlc Communleotion
The first known example of cryptography is the Caesar cipher. Lo this scheme, each letter is replaced by another
letter, which is three. letters later in the alphabet (i.e... key of3). Thus, the plaintel1; network management. wlll read
as qhwzrun pdqdjhphqw in cipher1ext. Of course, the receiver ·knew ahead of time the secret key (3) for
successfully decrypting the message back to the plaintext network management by moving e~h letter back three
positions.
Secret Key Cryptography. l11e Caesar cipher was later enhanced by the makers of Ovaltine and distributed as
Captain Midnight Secret Decoder rings. Each letter is replaced by another letter n letters later in the alphabet (i.e.,
key of n). Of course, the sender and the receiver have to ~ ahead on the secret key for successful
oommun.ication. lt is the same key that is used for encryption and decryption and is called secret key cryptography.
The encryption and decryption modules can be implemented in either hardware or software,
ll is not hard to decode the above ciphertext by an intmder. It would only take a ma:dmum of 26 attempts to
decipher since there are 26 letters in the alphabet. Another encryption scheme, monoalphabet.ic cipher, is to replace
each letter uniquely with another letter that is randomly chosen. Now, the maximum number of attempts for the
intruder to decipher has been increased 261 (261 =26 · 25 · 24 · ... I). However, it really does not iake that many
attempts as there are patterns in a language.
Obviously. the k.ey is the key (no pm1 intended) to the security of messages. Another a.~pect of the key is the
convenience ofusing it. We will illustrate our scenario with lan and Rita (lan for initiator and Rita for responder so
that it is easy to remember) as users at the two ends of a "secure" communication link. lao and Rita could share a
key, their "secret key," for accomplishing secure communication. However, iffan wantsio communicate with Ted
(for third party), they both need to share a secret key. Soon. lao has to remember one secret key fOr each person
wiib whom he wants to communicate, which obviously is impr.actical It is bard enough to remember your own
passwords, ifyou have several ofthem, and which systems they go with.
Two standard algoriduns implement secret key cryptography. They are Daw Encryption Standard (DES) and
lnt.ernationa1 Data Encryption Algorithm (IDeA) [Kaufinan ~-· 1995], They both deal with 64-bit message
blocks and create the same size ciphertext. DES uses a 56-bit key and IDEA uses a 128-bit key. DES is designed

for efficient hardware implement!llion and consequently bas a poor per.fonnance if implemented in software. 1n
contrast to thai, IDEA functions efficiently in software implementation.
Both DES and IDEA are based on the same principle of encryption. The bits in the plainte.Xi block are rearranged
using a predetermined algorithm and the secret keyseveral limes. While decrypting, the process is repeated in tbe
reverse order for DES and is a bit more complicated for IDEA.
A message that is longer than the block length is divided into 64-bil message blocks. There are several algorithms
to break Ute message. One of the more popular ones is the cipher block chaining (CBC) method. We !.earned UJC
use of it in USM in SNMPv3 in Section 7.7. There, the message was broken using CBC rutd then encrypted using
DES. Performing such an operation on till} message. even on identical plainteXl blocks, would resu.lt in dissimilar
ciphertext blocks.
Public Key Cryptography. We observed that epch user has to have a secret key for every user that be/she/it (a
program) wants to commun.icate wit:h. Public key cryptogr:aphy [Diffe and Hellman, 1976; Kaufman S1..!!!, 1995]
overcomes tbe difficulty ofhaving too many keys for usingcryptography. Secret key cryptography is symmetric i.n
that lbe same key is used for encryption and decryption. but public key cryptography is asymmetric with a public
key and a private key (not secret key, remember secret key is symmetric and private key is not). ln Figure 11.34,
the public key of!an is lbe key that R.ita, Ted, and everybody else (that lao wants to communicate with) would
1-"llow and use to encrypt messages to {Wl. Tbe private key, which only ian knows, is the key thatlan would use to
decrypt the messages. With this scheme, there is secure communication between Ian and his communicators.on a
one-to-one basis. Rita's message to Ian can be read only by lao and not by anyone else wbo has his public key,
since the public key C.1MOt be used to decrypt the message.
Flgurt I LJ4. Publk-K•l Cryptographic: Communication
We can oompare tbe use of al;ymmetric public and ·private keys in cryptography to n mailbox (or a bank deposit
box) with two openings. There i·s n mail slot to drop the mail and a collection door to take out mail. Suppose it is a
private mailbox in a club and has restricted.access to members only. AU members can open ibe mail slot with a
public key given by the administration io drop their mail, possibly containing comments on a sensitive issue oflbe
club. Any member's mail carmot be accessed by other members since tbe public key only lets tbe members open
themail slot to drop mail and nottbe collection door. Tbe administrator with a private key can open the collection
door and access the mail ofnJJ the members. Ofcourse, U
lis a<>)'mmetric example bas more to do with access than
cryptography. But. you get the ideal
The Diffe-Rellman public key algorithm is the oldest public key algorithm. h is a hybrid ofsecret and public key.
The commonly used public key cryptography algorithm is RSA, named after its inventors.
• Rivest et al [1978]. It
does both encryption and decryption as well as digital signatures. BQth the message length and ihe key length are
variable. The·commonly used key length is 512 bils. The block size oftiJC plainte~'l.1, which is variable, should be
less than the key size. The cipberte.1 is always the leogtb oft.be key. RSA is less efficient than either ofthe secret

key algorithms, DES or IDEA. l:leoce, in practice, RSA is used to first encrypt lhe secret key. The message is lhen
transmitted in one ofthe secret key algorithms.
Message Digest. Any telecommunicntio.ns engineer is familiar with the.cyclic redundancy check (CRC) detection
oferrors in digital transmission. This involves calculating a chec.
k sum based on lhe data in tbe frame or packet at
the sending end and transmitting it along with the data. The CRC, also known as checksum, is computed at the
receiving end and is matched. against the received. checksum to ensure that the packet is not corrupted. An
analogous principle is used in validating the integrity oflhe message. In order to ensure that tbe message llas oot
been tampered with between the sender and the receiver, a cryptographic CRC is added with tl!C message. This is
derived using a cryptographic hash algorithm, called message digest (MD). There are several versions, one ofthe
most common being MOS. We covered the useofMDS while di,s(;ussing the authenticalion protocol in SNMPv3 in
Chapter 7. We will look at the use ofit in digital signature in the neKt subsection.
1'here are different Implementations of MOS. In particular, the MDS utility is used in PreeBSD 2.x (mdSsum under
LlNUX). The utility 11lkes as input a message ofarbitrary length producing output consisting ofa 128-bit message
digest ofthe input. An example ofMD5 utility use is shown in Figure 11.35.
Flgu•·• 11.35. Exompl• of on ~IDS Mt<!ag• Dig«l
Smd5
The quck 11!0vr~ to~ lumpeel over1he laZy dog
~o
d8e8fca2dc0f896fd7cb4cb0031b<C249
As we can see from theexample. the message digest for thestring that we entered was gimemted based on the data
received from standard input (from the screen). The FreeBSD version alsohas a test mode lhat can be turned on by
specifying "-x" as a parameter, as shown in Figure 11.36.
Flgu•·• 11.36. ~IDS FrttBSD Vrrsion Te.<t MDdt Oulpul
SmdS ·~
MO~ ('") - d.&t.&:d50100b204c!le00999c>cl8427o
M05 ("ll1•Occl75b9c:Oflb6a831c399e269772661
MO!! ("alle:1•900 UI090Jc;QI~d28ol7172
MOS ("rneuagodigfst"): 196b697d7cb7938d525a2t31aa!1&IdO
M05 ("abCCe~Jdl'l'J'lOPCif$11NWXYZ") ~ c3kld3d76192e«l07dlb496cca67e13b
MOS
("A8COEFGHUO..MNOPORS'TlJIWXYZ.aboefg~~012345 6789')
... d1743b96d277d915a5611c2c91419d9f
MDS
("1234567800123450789(}12345678901234567890123456TB901234567gg()t23456
783012345678001 : 57edf4822be3d!55ac49da2e2101ll67a
A second algorithm used to obtain a hash or message digest is the Secure Hash Stand!trd (SHS). This has been
proposed by the National fnstimte for Standards and Teclu10logy (NIST). It is similar to MD5, but can bandle a
maximum message length of26
4
bits in contrast with MD5, which can handle an unlimited input length of32-byte
chunks. l11e SHS produces an output o£160-bit, whereas lhe MOS output is 128-bit long.
Some significant features of the message dige~t are worth mentioning. First, there is a one-to-Q.ne relationship
between ·the input and theoutput messages. Thus, the input is uniquely mapped lo an output digest. It is interesting

to observe that even a one-bit dift'ereuce in a block of 512 bits could produce a message digest lllld looks vastly
different. In addition, the output messnges are completely uncorrelru.ed. Thus, any pattern in r.he input will not be
recognized at theoutput.
Another leatute ofmessage digest is that the output digest is ofoonslantlengtb for a given algorithm with chosen
parameters, irrespective of the input message length. In this respect, it is very similar to CRC in r.hat CRC-32 is
exactly 32 bits long. We saw in SNMPv3 ·r.hat the authKey generated. by the MD5 algorithm is exactly 16-ootet
long.
Lastly, the generation of a message digest is a one·way function. Given a message, we can generate a unique
message digest However, given a message digest, there is no way the original message could be generated. llms,
if a password were transmitted from a client to a server. this. would protect against somebody eavesdropping and
deciphering the password. TbL~ could also be used for storing. the password file in a host without any hu.man being
able to decipher it
We know that the generation of a message digest is a one·way function. We also know that no two messages could
produce identical message digest.s. Could r.hese two combinations ensure Lhatlhe message is not tampered in transit
by an unauthori2ed person? The answer is no. This is becaus-e If t.he interceptor knows which algorithm is being
used, .he or she cou.ld modifY the message (assuming that be/she decrypts the message), generate a new message
digest, and send it alon.g with the modified message. IfJan sent the rne.ssage to Rita, and Ted medified the message
as per the above seenario while in trans.it, Rita would not know the difference. Additional protection is needed to
guard against such a lhret~t, which is achieved by attachinga digital signature to lhe message.
Digital Signature. In public key cryptography, or even in secret key cryptography, if Rita receives a message
claiming that it is from lan, there is no guarantee as to who sent the message. For elalmple, somebody other than
lao who knows Rita's public key could send a message identifying himself or herself as lao. Rita could not be
absolutely sure who sent it. To overcome this problem. a digital signature can be used Signed public-key
cryptographic communication is shown in Figure 11.37.
flgurt 11.37. Signed rublic-KtyCryt>t<>gNpbi< Corumuni<•C
iun
The digital ~ignature works in the reverse direction from that of public key cryptography. Ian can create a digilal
signature using his private key (marked "S" in parentheses in Figure 11.37) and Rita could vnlidrue it by reading it
using Ian's public key. The digital signature depends on tbe message and the key. Let us cons.ider tbat lao is
sending a message by email to Rita. A digital signature, which is a message digest, is generated using any bash
algorithm with t.he combined inputs of t.he plninield message and t.he private key oflao. The digital signature is

concatenated with !he plain!eX! message and is encrypled using Rila's public key (marked "R" in parentheses). AI
the ~elving end, the incoming ciphertext message is decrypted by Rita using her privaJe key. She !hen generates a
message digest with the combined input of the plainteXI message and Jan's public key, and compares it with the
digital signature ~eived. rf!hey match, she concludes thai the message has not been tampered with. Further, she
is assured that the message is from lao, as she used Ian's public key to authenticate the sourceofthe message.
Notice that only the originator can create the digital sign.ature with his or her private key and others can look at it
with the originator's public key and validate it, but cannot create it A real-world analogy to dig.iial signature is
check writing. The bank can Validate tJIC signature as to its originality, but lt is hard to duplicate a signature (at
least manuaUy) ofthe person who signed the chec.
k.
Oigilal signature is valuable in electronic commerce. Suppose Rita wants to place an order with company ABC for
buying !heir router product. She places the order over the Internet with her digital signature atlllched to it. The
dlgi!nl signature using a public key protects both ABC and Ritn regarding the validity oftbe order and who ordered
it. It is even better than using secret key cryptography, since in tbe latter case, Rita could change her mind and
allege that company ABC generated the order using the secret key that they have been using. In public key
cryptography, she could not do thai.
11..5.5. Autbcntic;~lion :mel Authorization
Authentication is the verification of !he user's identification, and authorization is the access privilege to the
information. On the Internet without security. the user's identification and password, wbicb are used fur
authentication, can easily be captured by an intruder snooping on the LAN or WAN. There are several secure
mechanisms for authentication,depending on compleKity and sensit.iviiy. Authorization touse the services could be
a simple read, write, read- write, or no-access for a particular service. The privilege ofusing !he service cot~d be
for an indefinite period, or a fmite period. orjust for one-time use.
There are two main classes of systems, which are of inli:rest to us in the implementation of an authentication
scbeme. The first is the client-serverenvironment in which there is a request-response communication between the
client and the server. The client initiates n request for service to the server. The server responds with the results of
the service perfOrmed. The communication is essentiaUy two-va:y communication. In this environment besides
authentication (and ofcourse, an integrity check), authorization also needs to be addressed.
The second class of service is a one-way·commun.ication environment, such as email or·e-wmmerce transaction.
The message transmitted by the source is receiv.ed by the receiver after a considerable delay-sometimes days ifa.n
intermediate server bo kls up the transaction for a long tin!C.ln such a case botb the authentication and an integrity
check need to be perfurmed atthe receiving end.
We will address client-;;erver ambentication systems in the neXI section and the one-way ~message authentication
and u1tegrity protection SYstem in Section 11.5.7.
11.5.6. Client...Server AuthenticMion Systen~~
We wi.ll consider four types of client-server .environments and the implementation of authentication function in
each: host/user environment, a ticket-granting system, an authentication system, and authentication using
cryptographic function.
Host/User Authentication. We have the traditional best and user vaUdalion for authentication, both ofwhich are not
very secure. They are also not convenient to use. Host authentication involves certain hosts to be validated by the
server providing the service. llte host nantes are administered by the sei'Ver administrator. 1lte server recognizes
tJIC host by the host address. UServerS is aut.ltorizcd to serve aclient Host C, then anybody wbo has an account in
C could access Server S. The server mainrains the list of users associated wiUt Host C and allows access to the
user. [fJohn Smith is one ofthe userll inC, and John wants to access the server from another Workstation W, tbe

workSiation W has 1.0 be authenticated as aclient ofS. Ifnot. John isout ofluck. Further, his name has to be added
to the list of users in W to access S. To make the environment flexible, every client wilh every possible user is
added to the server negating the secure access feature!
Let us consider user authenticalion, which is done 'by the user providing identification nod a password. The main
problem with the password is that i1 is detected easily by eavesdropping, say using a network probe. To prolect
again.st the. threat of eavesdropping, the security is enhanced by enci)'Pting the password. belPre transmission.
Commercial systems are available that generate a one-time password associated wah a password server that
validates it when presented by the service-providing host. The user uses a uniqoo key each time to obtain tbe
password. such as in the ticket-granting syslem (nexi section).
Ticket-Granting SySiem. We will explain Ihe ticket-granting system wi1h Ihe moSI popular examp.le of Kerberos,
whlch was a system developed by MIT as part of their Projecl Athena. Figure 11.38 shows Ihe lickel-granting
system with J<erberos. Kerberos consists ofan authentication server and a liekel-granting server. Tbe user logs into
a clienl workstation and sends a login request to the authentication server. Afier verifying that tbe user is on the
access control list, the authentication server gives an encrypted ticket-granting ticket to the client. The client
workstation requests a password from !heuser, which it ll~es to decrypt tbe message from the authentication server.
The client then lnlemcl~ wilh the tickel-grantlng server and oblains a service-granting ticket and a session key to
use the application server. The client wor.kstation then requests service from the applic-ation server giving the
service-granting ticket and the sess.ion key. The application server, after validation ofthe ticket and the session key,
provides service to tbe user. Of course, this processing happens in the background. lt is transparent to the user,
whose only interaction is with lheclient workstation requesting applic-ation service.
f!lgur• tl.38. Tick.ti·Cntnling S)>ltm
User
rnpul
C~ent
Vo~uon
!
Appi!Qir.on
Saver'
SeMce
I
I+
KOibet'oS I
Aulh81lllcal.lon
~rver
t
Ticl<el-
Granting
Server
Authenticalion Server System. An authentication server system, shown in Figure. 11.39, is somewhat similar to the
ticket·granting sySie.m except that there is no ticket granted. No login identification and password pair is sent out of
the client workstation. The user authenticates to a central authentication server, which has jurisdiction over a
domain ofservers. 11tecentral authentication server, after validation ofthe user, acts as a proxy agent to the client
and authenticates tbe user lo t.he application server. This is lransparenl to tbe user, and the clienl proceeds lo
communicatewith the applicatio.n server. This is the architectureofNovell LAN.
Figure 11.39. tuthtntkation Stn·C'r

Uses _
Input
cuem
WorkslaUon
•
Se111lce
t
Appllcotfon
Server/
Survlce
AuthenllcafiOI
SeiW!
-Aulhel'ticaUon-1------1
-AIAhenlicato n -
Authentication Using Cryptographic Functions. Cryptographic authentication uses cryptographic functions. The
sender can encrypt an nuthentication request to the receiver, who decrypts the message to validate the identification
ofthe user. Algorithms and keys are used to encrypt and decrypt messages, which we will address now.
11..5.7. Message Tr.tnsfer Security
The one-way 1nessagetransfer system is non-iote.
ractive. For example, ifRita receives an email &om a person who
claim~ to be Ian, she needs to authenticate Ian as the originator of the mess.~ge, as well as to ensure that nobody has
tampered with the message. This coukl also be the situation in the case where Ian sends a sell order from his
mobile station in his car. Ted could intercept themessage and alter the number ofshares or the price. We will treat
all these under thecaiegory ofsecure mail systems.
There are three secure mail systems-privacy-enhanced mail (PEM), pretty good privacy (PGP), and X.400-based
mail system [Kaufman et al., 1995). All three schemes are var.
iations of the signed public-key cryptographic
communication discussed in Section 11.5.4 and shown in Figure 1137. We will describe PEM and POP in lhis
section. X-400 ls a set ofspecitlcations for an emru1 system defined by the lTU Standards Committee and adopted
by OSI. It is a fi'amework rather than implcr.nentalion-ready specification. We will also review SNMPv.l secure
communication that we covered in C hapter 7as it bears a close resemblance to the message lronsfer security.
Privacy-Enhanced Mail (PEM). Privacy-enhanced mail (PEM) was developed by IETF, and specifications are
documemed in RFC 1421-RFC 1424. H is intended to provide PEM using cod-to-end cryptography between
originator and recipient processes [R.FC 1421]. The PEM provides privacy enhancement services (whar else!),
which are defined as (1) con.fidenl'iality, (2) authentication, (3) message integrity assurance, and (4) non-
repudiation oforigin. Tho crypt.ographlc key, called the data encryption key (DEK), coukl be either a secret key or
a public key based on the specific implementation and is ihus tlellible. l:lowever, ihe originnting and terminating
ends must have common agreement (obviously!).
Figure 11.40 shows three PEM processes defined by rETF: MIG-CLEAR, MIC-ONLY, and ENCRYPTED based
on message integrity and encryption scheme. Only the originating end is shown. In all three procedures, reverse·
procedures are used to extract the message and validate the originator10 and message integrity. The differences
between tbe three procedures are dependent on the extent of cryptography used and message eocodlng. The
message integrity code (MlC) is generated as discussed in Section 11 .5.4 on digital signature and inclnded as part
ofemaiI in all three procedures.
Figur• IlA(). PEJ1 Prows..

~
r-=-='~.l.~_,.~~
~
~T"'9 "'" -
a ~
l~•oc<a<.o><•- ) ,_!... I
.._...
,.,.,.
~~·~" I~ r.::::--l
~r.., ~ I~
.
! ~YC~"'l'rf,.t"r-
The specification provides two types of keys-a dat.a-encrypting key (DEK) and an inte.reKchange key (IK). The
DEK is a random number generated on a per message basis. l 'heDEK is used to encrypt the message text and also
to generate an MIC, if needed. The lK, which is a long-rangekey agreed upon bctween the sender and the receiver,
is used to encrypt DEK fur transmission within the message, The fK is either a public or a secret key based on the
type ofcryptographic eKCbange used.
Ifan 83)111lmelric public key is used to encrypt the meso;age. then the sender cannot repudiate ownership ofthe
IJle'ssage. Legal evidence of message transactions is stored in the da111, which ore used in applications such as e-
comme.roe. Another common duu:
acteristi.c of these procedures is the first step in converting the user-supplied
plaintext to a canonical message text representation, defined as equivalent to the inter-SMTP representation of
message text. l11e final output in each procedure is used as. the text portion of the email in ihe electronic mail
system.
Figure I1.40(a) shows the MlCCLEAR procedure and is. the simplest of the three. The M!C generated is
concmenated with the SMfP ieKt and is inserted as the text portion in theemail.
In the MIC-ONLY procedure, shown in Figure 11.40(b), the SMTP telo:t is encoded into a printable character set,
The printable character set consists ofa limited set ofcharacters that is assured to be present at all sites and thus
make Lbe intermediate sites transparent ro l.he message. The MIC is concatenated witb the encoded message and is
fed to the email system.
Figure 11.40(c) is the most sophisticated of the three procedures. Tite SMTP text is padded, if needed, and
enerypted. A public key is the best choke here, because it guarantees the originator ID. The encrypted message,
encrypted MIC. and the·DEK are all encoded in printable code tl pass through the mail system as ordinary teKt.
They are concatenated and fed to the email >)'Stem.
Preny Good Privacy (POP). Pretty good privacy (POP) is a secure mall pacj(age developed by Phil Zimmerman
thai is available in the public domain. Figure I I.41 shows the various modules in the POP process ai the
originating end. The reverse proceM occurs at the receiving end and is not shown in the figure. POP is n package in

the sense tbat it does not reinvent the wheel. lt defines a clever procedure th:u utilizes various available modules to
pcrl'orm the fuoctions needed to u:ansmit·nsecure message. such as email.
The signamre generntion module uses MDS to genernte a hash code of the message and encrypts it with the
sender's private key using an RSA algorithm. Either IDEA or RSA is employed to generate the encrypted message.
IDEA is more efF.:ient than RSA, but secret key maintenance is necessary in contrast to RSA's use ofa public key.
The enorypted message is compressed using ZIP. The signature is concatenated with the encrypted message and
converted to ASCII furmat using the Radix-64 conversion module to make it compatiblewith the email system.
PGP is similar to ENCRYPTED PEM with additional compression capability. The main difference between I'GP
and PEM is bow the public key is administered. In I'GP, it is up to the owner. In PEM, it is furrnally done· by a
certification authority (the Internet Policy Certification Antbority (PCA) Registration Antbority). In practice, POP
is used more than PEM. Bodt POP and PEM provide more than a secure mail service. We can send any message or
frle.
SNMPv3 Security. We dealtwith secure transmLo;sion in SNMPv3 in Chapter 7. Althougll an NMS -management
agent behaves like a client-server sys1em, Ihe security feawres are similar to the message transtcr oryptograpby.
We will compare the processes studied in Section 7.7 to message transfer cryptography. Figure I1.42 shows a
conceptualized representation ofFigure 7.13 for an outgoing message.
Flgur• 11.42. SNMPStc:uro Commuoicfltlon

1n an NMS, the user password and autboriative SNMP engine lD (network mll03gemem agent ill) are u!led to
generate an authent'ication key by the USM. This is equivalent 10 !he DEK in PEM or the priva1e key in PGP.
Either the authenticutio.n key or preferably a different encryption key is used to generate all encrypted scopedPDU
bythe privacy module. This is similar (but not identical) to encryption ofthe message in PEM and PGP.
The USM module prepares tbe who Je. message with the encrypted scopedPDU and other parameters. The
authentication key and the wbole message ore used as inputs to generate HMAC. which i.s equivalent to !he
signature in PEM and PGP. The aulhentication module combines t!Je signature and the whole DJessage to output !he
autl~entic8led whole message. In an incoming message, the authenticati.on module is provided the whole message,
autlJentication key, and tiJe HMAC as input to validate the authentication.
1'1..5.8. Network 1
•rotcction from Virus Attacks
In the curre.nt Internet environment, we cannot leave U1e subject ofsecurity withour n~entioniog tl~e undesired and
unexpected virus attack on networks and bosts.lt is usually a program l.hut, whenexecuted, causes harm by making
copies and inserting them into olhcr programs. lt comaminates a network by imponing an infected program from
outside soun:es, either online or via disks.
The impact ofvirus infection manifests itselfin many ways. Among !he serious ones are preventing access to your
hurd disk by infecting the boot track. compromising your processor (an outs.ide source controlling your compu!er),
flooding your network wilh extraneous traffic !hat prevents your hosts from using it, etc.
Generally, viruses are recognized by patterns and virus checkers do just that. Apan from the common sense of
preventive measures, it is wise to have tiJe latest virus ciJeCkers installed on all your hosts. It should be scheduled to
run periodically. It also checks the inputs and outputs ofthe processor fur possible virus infection.
11.6. Accounting Mnn:tgcmcnt
Accounting management i.s probably the least developed function of network management application. We have
dio;cussed the gathering of statistics using RMON probes in Chapter 8 and in Section 11.3.4. Accounting
managemenl could also include the use of individual hosts, administ:rative segments, and external traffic.
Accounting of individual hosts is useful fur identifying some hidden costs. For example, the library function in
universities and large corporations consumes significant resources and may need to be accounted for functionally.
This can be doneby using the RMON statistics on hosts,
The cost ofoperations for an information management services department is based.on Lhe service that it provides
to !he rest ofthe organization. For planning and budget purposes, this may need to be broken into administrative
group costs. ll1e network needs to be configured so that all traffic generated by a department can be gathered from
monitoringsegments dedicated to thatdepartment.
Externallraffic for all institution is handled by service providers. The tariffis negotiated with the service provider
based on !he volume oft:raffic and traffic patterns, such as peak traffic and average traffic. Internal validation of!he
service provider's billing is a good management pmctice.
11.7. Rcp011 Management
We have elected to treat repon maoageOJent as a special category, although it is not assigned a special functionality
in the OSI classification. Reports for various application functions-configuration, fuult, performance, security,
and accounting-could normaUy be a

Network Management Principles and Practice - 2nd Edition (2010)_2.pdf

Network Management Principles and Practice - 2nd Edition (2010)_2.pdf

More Related Content

What's hot (20)

Similar to Network Management Principles and Practice - 2nd Edition (2010)_2.pdf (20)

More from Smt. Indira Gandhi College of Engineering, Navi Mumbai, Mumbai (20)

Recently uploaded (20)

Network Management Principles and Practice - 2nd Edition (2010)_2.pdf