Sie sind auf Seite 1von 724

Network

Management
Principles and Practice

Mani Subramanian
Get~'!ia lns1iMe ojTWrt!o/Qgy
Jndiall hmit~~~e q]Thdtnoloo Madras
~lo Software PrlYale Umittd

With conbibudon.rfrom
11molhy A. 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< Management Overview

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 Management Architecture 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 .- r k 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. Major Changes 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 Too II, s,.tom., and Engineering

section 9.1. System Utilities for Management

section 9.2. Network Statistics Measurement Systems


section 9.3. MIB Engineering
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

Part IV: Broadband Networl< Management

Chapter 12. Broadband Network Management: 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 MlnlgiiiMnt Topics

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. Fourier Transformation

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 that it shall not, by way of trade or otherwise, be lent, resold hired out, or
othimvise circulated without the publisher 's prior written consent in any form of binding 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 of this book.

First Impression

Publlshed by Dorllng Kindersley (lndia) Pvt Ltd, licensees of Pearson 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

Dedicatio n

In loving memory of Appa Mahadevan Amma Kalyani

Affectionately dedicated 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 t opics discussedtherein 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 Il lustrate 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 of minute details on Network Management
ram sure it will be a ready handbook for the student/professional communities.

My sincere thanks for your time and effort in bringing out the second edition of the textbook."

- Seetharaman, V.
Head, ITMC & Cable NOC, Bharti Airtel Limited, Chennni, India
" Pro lessor Subramanian has a remarkable ability to set oomplex network engineering and associated
network maJiagement problems in context with well-written explanat ions and real-work! examp les
1hat deal with 1he varied demand~ placed on converging telecommunications netwo rks and the
design and operation of the underpinning management systems and protocols.

This book will be extremely useful resource for g raduate· and postgraduate students on CSIEE
courses including those studying in their first year of PhD in Telecommunications Engineering, as it
prov ides a fantastic coverage of a 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 Informatio n E ngineering, 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 Enginee ring" 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 l 0 covers the classic model of tl!C Telecommunications
Management Network, indispensoble for understanding network management. C hapte r II covers
other impo rtant aspects of network management, including fimll management, performance
management, security management, policy-based manageme nt, and service level management.
Further, C hapter II includes a sectio n on event correlation methods, typically notfound in book~ on
network management, and this is refreshing. T hese 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 of the 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 of detail in this area, which is important
fur pract it iooers as well as students.

This book give·s comprehensive details of aU aspects of network 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~ I odin

"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 I orientatio.n in the jungle of Mills available in
all kinds of equipment.

The new edition kept the spiril oft·he first edition, but enhanced it significanllywith new and helpful
visualisalions, exa mples and contempomry management scenarios.

The presentation is interspersed with the author's long-standing experience with Network
Management and its tools, which be Ips lhe reader to gain a deC~> understanding of the reasoning
'behind Network Management models, protocols, services nod tools."

- Markus Fiedler
Blekinge lnstituteofTechnology, Karlskrooa, Sweden

"This editio n takes off from the previous one with a renewed perspective on network management,
incorporating relevant developments over the pas! decade. The ueatment of the 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 Communicailins Ltd., Mumbai, lodia
Preface
Network-centric Wo rld 11nd Role o f Network Ma nagement

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,
maiota in, and provision on an on-going basis. That is our cballenge.

Areas of management ofnetworks, systems, and appiJcations in data and telecommunication services are not only
the responsibility of telecommunicat ions and networking industries and standards bodies but also of the academic
world. Snadents gradual ing from technical Colleges nod universities are eltpected to be prepared to use a network
and also to design and to manage one . The eltisting procedur e to design and. test some key networks is heuristic.
Personnel with e1tperience, nod sometimes without, design networks and test ·t hem 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 of the internet and Web technology, Lhe subject of networking nod network managemenl
has become part of the academic curriculum. This tClttbook. introduced ten years ago, has been part of this
evolution. This new edition brings new technologies and services to undergraduate and graduate classrooms in the
broad arena of what is known as network management.

Justificntioo fo r a Textbook on Network Man age ment


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 of this book by coUeges and universities across the world has
partially fiU.e d lltal void. Just as networking education has been brought from the graduate to the undergraduate
level. thiseditim oft he textbook has been upgraded so that early parts of the 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 of network 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 of this 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 of wide area network
(WAN), access networks to home, and home distribution networks includingLANs. Multimedia communications
is covered from the aspects of wired transmission media of cable. digital subscriber line, and optical fiber as well
as tilted and mobile wireless.

This book exposes the student to current network management technology. At the completion of a 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 n addresses 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 of broadband networks and the latest trends in management technology.

Pan Lconsists of Chapters I and 2. C hapter 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 rud itne.nts of components of
LAN and WAN networks in such a co ur.se. Not much techno logy can be covere<l, and network rna nagement
depends strongly on managing oerwork components that are based on an ever-evolving technology, hence the
presence of Chapter 2. It can be either skipped or covered in parts by ihe· instructor. Relevant sections 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 so me
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 of some ofthe widely used network and system management 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 12 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 of Chapter 14. Having brought voice, video, and data
of broadband 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 fur Course 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 of the instructor.
The complete contents of the book are more than can be covered in a quarler o r !!Yeo a semes1er course. The
instructor may do a "mi.x and matc h" 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 a pplications (Chapter II).

Iftelecommunications is ·emphasizcd (this is more likely in co mpute r engineering sthools), !hen it would be good
to include Telecommunications MlUlagement Network (ChaptQr I 0).

If broadband services are taught at the schoo~ then Part IV (Chapters 12- 16) could be included.

Fi nally, if the school has a research program on network management, il is suggested that in addition to the special
areas of interest, management applicutions in Chapter .I I be dealt with in depth. ln addilie n, adequate treatment o f
Advanced Management Topics (Cbapter 16) is strongly suggested.

To the JnMructo r

This 1extbook is designed as a dual-level book. It can be used for undergraduate courses at the j unior or the senior
level or for graduate-level courses. H assumes that the st udent bas t.akeo a prerequisite co urse 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 of network management.

With the prolific growth of networking, nel:\vork management is expected to become part of the academic
curriculum, and. this book will be usef\tl fur both Computer Science and Elec trical and C omputer Engineering
schools that specialize in networking.

Online Supplements: Solutions to exercises are available to instructors from the Pearson representative. Visual aids
in the format o f PowerPoint sf ides 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 if you are leaching a Continuing Education course o n network
management. lloe PowerPoint slides will come in handy as classroo m 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 Stud e nt

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 of the bands-on e xercises could be practiced.
At the minimum. it would provide enough tools and know ledge for tbe frustrated worker when he or she eaMoi
access the network resources and does not know why.

Grateiitl Acknowledgemen ts
Tbe major impetus for tbe contents ofthis book bas come from students over tbe course offerings since 1996. lt bas
been reviewod a.t various levels and LO various depths by rna ny 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 of the 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· co mments and suggestions have contributed to the richness of the contents of the 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
some interesting practical exercises 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 being production manager of manuscripts. Thank you again, Ruth.
About The Author
Mani Subramanian

Mani Subramanian is a Chair Professor at Indian {nstitut e 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 progra m 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 C hinese for Higher E ducation 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 of networking 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
.b as revolutionized computer communlCIItion. The lnier.n et is a worldwide fabric and you willleam
to appreciate bow infOrmation travels across it around the globe. Basics of communication protocols
and architecture are presenred along with various standard~. Select equivalent applications are used
as illustrations comparing the Internet and OSI protocols.

Components of net work llUIJl8gemeot are described and complemented by interviews witll net work
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 of service 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 on future trends in network management
technology.

Chapter 2 !Oc:uses on net\vork techoology. You may skip this chapter if you are familiar with the
practical aspects of networking. If you are knowledgeable on principles of data 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 of view. 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 of broadband networks and services.
1. Data Communications and Ne twork Ma nagement Overview

Objccth'es

Teleoommunications overview
Data oom.municalions overview
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 of network managemenl
• Network ma11agemeli/ :r."-">tem
Look-ahead of network 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 of various aspecls of network 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 of early
computer communication networks is dealt with in Section 1.2.

Computer communicalion technology radically changed with the advent of desktop computing power and
distributed computing environments (DCEs) using local area net\vorks (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 of IT 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 of Section L 13. As with all chapters in the
book. a sun:unary section and exercises conclude this chapter.

1.1. Analogy ofTclcph on e Networ k Management

The need. for data or computer communication network management is best illustrated. by an analogy of telephone
·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 of connection 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 of service 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 reliabil ity,
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 net work 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
Digital Network (B-ISON). B-ISON is now being replaced by Internet and Broadband Service.

The ar.chitecntre of a 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 of transmission, 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


To Oliler
R egional Centers
Sedional Cenlers
Primal)' Centers
ToUCenteB
EndOff.a;s

Primary Centers
Toft Centers
EndOiftee$

Cia$$ 4 Toll Polnls


EndOtr,._

End Cllfoee EndOfflc<>


Class 5 SwiiCh Class 5 Switch
Logond;

• t -
.... I..OQP
Olrecl Trunk

6> Voire
0 Voice
-
-
- 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 oft he year in the United 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, o perations 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 qua lily 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, if the SIN ral.io of a
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.nito red.
Traffic patterns are constant.ly observed and corrective operations are taken, if needed, in real time. The NOC is t:he
nerve center of telephone 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 of service and then the qualiiy and economy of
service. Thus, isolation of t he 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 no1 m3tured 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.echno logies emerge. Furlher, the telephone industry all over the world had been monopolistic and 1hus singlt>
vendor oriented. Thi s 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 elecomm unication 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 informal ion 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 a connection 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 any equipment 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 of liok.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" after completion of transmission.

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 the two ends may change during the transmission of a 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
classiftcation 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 is called 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 net works 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.A notog•nd Data Ttltrommunlu rlon Nttwor ks

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 Ntt\VOI'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. There can be a large oumber ofworkstatioDS and bosts depending on the type of LAN. D1Es
connected to different LANs that are gcogrnpbically far apari can communi cate 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

w-..
(•1-ondVI-ool-"CCOIAo'l
1i-·
Q~
/ =
:=-'6 LANC

-%-- WNI

The first aspect is the question of whether 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. Fo r example, Bell System, a
monopo listic 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 co nfiguration is termed a client- Saver environment.
Allhough the terminology of clieru and server is commonly associated with t.he pro cessors, 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 cl ient. 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 processes can coexist in the same processor or in different processors.

We will now go into some detail on ·the salient characteristics and features of client-server architecture and models,
as they are very pertinent to nct\\~:>rk management applications and architecture. A simple client-server model is
s hown in Fig ure 1.6. There is apt to be confusion between wh.ich is a c lient and which is a server in distributed
computing architedure. The 'best way to distinguish 'between the two is to remember that the client initiat es 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
serv ice and sends the resuk$ to the client. lt is worth noting that the client cannot initiate a process in thu server.
Thus. t be p rocess should have already been started in the server and be waiting for request.s to be processed.

A rea.l-world analogy to the c l ieot-server operation is a post offioe. The clerk behind the counter is ready and
waiting for a cl ient. She is a server. When a customer walks in and initiates a transaction, for example, ordering
stamps, the clerk responds. The c ustomer 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 mode until 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 of requests 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 s hould be programmed to take care of sllCh deficiencies in communication.

Fi~ur< 1.7. Clitni-Strvt r In Discrlbused Cumt>ulio.g.Environmeuc


g . .~. .

'
..
·
~,
..f
'\ ··....
··•., ......~.~. ... ..... ..__.......... .•'
...,-
...~. ............__ ,.,.. _.,.~·····
··.................. ________, .........................

_ ........-.....--~ - ~
........- ····
.•
..· ..··...
.~

: ...~
.. i

'\.... ·.

·..

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 of this 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 (Sa lly 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
netwo rk !!ddress of sally.jones, which is dest.com. Therefore, it makes a request to the domain name server (DNS)
on the network for routing information for the address of dest.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 (o r 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 o n 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 .In tranet

Transmission Control Prot.ocoVlmemCI Prot.ocol (TCPIIP) Js a suile o f protocols that enable networks to be
interconnected. It forms the basic foundation oft he 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, if a packet is lost by LP, the acknowledgement process ofTCP ensures successful retrans mission of the
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 of data transmission. For example, email and management messages are
carried by connection less transmission.

lbe Internet is a net work 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 the computer
network via email. We looked at the example of Joe St.o ne 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 of Technology, 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.r s 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 of bridges and routers. lbe link between LAN A and
LAN C could be a 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.i es 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 of each 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
of protocols.

Thus, via the 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 a Iso 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 of the 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

USER PLANE

~~ GatowiiY IOb<icl

( ] SWitchlno lab<lc
MACiob1C

The user' s workstation intermces to a LAN via a MAC. which will be explained 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 of lnternet teclmology has spawned Intranet h::chnology. The main distin~1 ion between lhe two is
s imilar to 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 Internet is public.

The impaot of ihe Internet in nel\vorking is enormous. How do we manage the Inte.met? For example, if an 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 machine and attacl-.ed modem were manufuctured by local
vendors. Likewise, isn't it a technological miracle thatt\\OJ 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 of their 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 of Joe 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 hi s comprrter terminal and
sends it to llis colleague (yoho@jtc.com.jp). Joe's message with his user id (joe@cc.gatech.edu) and IP address
(169. I 11.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. A II 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 co mponents 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 of both 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 I ntemet standard Simple Mai l Transport Pm10eol (SMTP) in ·!heir software. 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 of communication architecture.

1.5.1. Comm m1ication A•·ch itectures

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.1 O(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.

Sytto,.z

t•l OOiet CoMmunl<a!M BMw..,. EI\C!Sy<l...,.


SVaollnA '"*"'-••)'11om
[ uwA J
}ljlpiOOim~-- ~001\ l.t)U/1

- -
Tr•l\llpol1 la)'llt
lflnOI>GrlL"Y',.
-
CGftWtc.Mwt
T_Loy. .

I Pllytlc:aii.IO<II'--1 I I Pl1l<oea1Moclillm I
This can be illustrated w.itb a real-life example. A bearing-impaired pers~n, accompanied by an interpreter,
arteoded one of my classes. As llecmred, the interpreter t.ranslated to the student using sign .language. If the 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 co uld 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, o r
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 transpo rt system protocol layers and layers 5-7 aro application support
protocol layers.

Figur t 1. 11. 051 Protocol Laytrs

l~7
t
Aj>f>li<ooon

layet& Pr~

"-5 ~"

-
TIMspo<t

""""'
~2 0."'-"'k

L#)'tlrl f'nyu:al

T ablt 1. 1. OS I Lay•l"5 and Strvi<ts


Layer Layer Name· Salient Services Provided by the·Layer
No.

1 Physical -Transfers to and gathers from the physical medium raw bit data
Tabl t 1.1.. OSI LAy<rs Rnd Strvkes

Layer Layer Name Salient Services Provided by the layer


No.

-llandles physical and el ectrical Interfaces to the transmission medl um

2 Data nnk -Consists of two sublayers: logical link control (llC) and Media access control (MAC)

- llC: Formats the data togo on the medium; performs error control and flow control

-MAC: Controls data transfer to and from LAN; resolves conflicts with other data on LAN

3 Network Forms the·swltchlng/routll'lg layer ofthe network

4 Transport - Multlplexll'lg and de-multlplexll'lg of messages from applications

-Acts as a transparent layer to applications and thus isolates t hem from the transport system
layers

-Makes and breaks connections for connectlo,...oriented communications

-Data flow control In both directions

s Session -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 protocol s 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 invo lved 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 of intermediate 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
- ~-
-
-
--
,..._.,_

~-
_..._~fro~!_
... ~

$o......

T!a<UP!>'I
........,.
o-Ln< Datal lnlt

Pilylotol ~

I I

'*'"
I

--
~

r-
H-.rt<

DINII.iniL

The message in each layer is contained in message units called protoool data unit ( PDU). h consists of two 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 transmits 10 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 s ingle 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

Nttwof~
-
-~·
fr~tnftJOI1
-..........
-
Dtlln Uno O<tto L~o~
-f>tol"lddi
(D}POU Oo1a SL~ltil~ ""~
~
~

l.5.2.1> rotocol La ye t'S :1n c.l Set·vices

We will OO\v go into some detail re~ding services provided by the seven layers of OSI protocols.

Layer I, physical layer, is responsible fur physically p.l acing the electrical sigonl on the physical medium and
picking up the signal from it. It controls and manages the physical and electrical interfu.c e.s to the physical medium
including the connector or the transceiver. The physical medium could be copper in the form of a twisted pair or
coaxial cable, optical fiber, or wireless media such as radio. microwave, or infi'ared. The signal could be either
analog or digital. 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 s hort. 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 contro l 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 e nvironment 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 of data 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 of LAN is a ring type U1lld 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)

l\led1um 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
sub layer.

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 of appropriate size based on
transmission parameters. The destinalbn address of each 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 of a network perforras the function of routing and switching data. Any
subnetwork oftl~e node is under the control of that router. The subnetwork(s) can be anything &om a 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 the subnetwork 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 (SND AP). 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. I 6(a) depicts network
configuratbn in which DT£..A connected to end node A communicates with DTE-N I connected to subnetwork
Mde·Nl via ·the intermediate system gateway node N. Figure 1.1 6(b) describes the path of communication 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. Sublayu Struclurt 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 co Privoct Subnecwork

---1@

A-lh! s!Mda-d Nll!wcirl<


N· U1-N2-N3Sotlne!wor\ UI\Oef NOde N

ll'iln~ r- Trilf11!0f'll'1

SNICP

SNOOP
I~
SNDCP
SNJCP

OP-SN
SNJC
- SNIC?

SNOCP-sN

SNO~P SNDN' SNOA1'-S« SNCAP·SN

tataLmlti

1>11)""""
1- Dlll8Lnl<

rn,.~<a~
DO!> L111k·SI'l

PhyS)cllloSN
- t.la.Q LWI't •~

J J 1 1
N9twuu; Meot.tm S l.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 of implementing 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 as NAT, 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 by application 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 if they 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 of the session. H is very strongly nilatcd to the presentation layer, which is the medium of
prese.:ttation of the context of the 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 of the
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 of syntax. data encryption and data oompressio n 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 of application
layers (session and presenration), it is strongly coupled with the rest of the 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.

Frgu o•r t.t7. Conoroartson qfOSI anollnltmtll'roloc:ot l,ayrr M<>oltl(


OSI INTERNET

Appllca ~oo

Appllcati.,.,.Spa:lfiCl
Pro~ rttnt.on
Prorocals

$<>10$000

TtlltllJIUO

fron!li>Ort ConOOCI...,.. I Conoll':lian·


le!!il: UOP orit~tlld. TCP

SNICP

N~l""'r~

I~
No!WC!1( IP
SNOCP

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 the transport layer. The boxes on the right-hand side of Figure 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 thi s
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


~ ~
m - _J
{~I
,.--1---:c'--,.,.--'--~
( '::'I

1.6. Network~, Syste ms, alitl SL•n•ices

We described a network comprising nodes and links in Section 1.2. The phys.ical embodiment of a 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. 1m d Sl'n'ices

A broadband communication system can be defined as one that provides broadband service to homes and
enterprises. The common interpretation of this 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-fof\vard,
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 or jitter.

Broadband services are provided using broadband nehvo(ks. There are nume.rous types of networks 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---oone orcup, hard or soft; size smaJJ/mediwn/large. choice of flavor, choice of topping, 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 Ttcbn ul ~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 oft be 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 if it does, it is a part ofCPE
network.

1.6.2. Wid e 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. netwo rk: ATM network is ideally suited for WAN or core network. It has fast. layer 2 sw itches 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 of service. 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, AB R.

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·o riented 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 of routers and other transmission devices is not as efficient as in an ATM network.

Quality of service 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 efficient scheme for
establishing quality of service 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 of reservation capabilities of RSVP.

MPLS network: MPLS attempts to oombine the benefits of ATM quality of service with feature benefds of the IP-
based Internet. Conventional routers examine the packet headers and classify them into forwarding equivalence·
classes (FE C). 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 Switching Router (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 of the 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. AU hough cable network is more commonly used in the United Smtes by a
ratio of approx.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 of the frequency spectrum (0-4 ld:lz) and the digital dam over the higher
band of 1he spectrum. It is termed asymmetric as 1he downstream data rate (from the centra I 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 etwo rks


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 of both. Horne network provides the opportunity to uti.l ize mulliple
technologies besides Etbernet LAN and WiFi. HomePN A 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. Fire Wire is also a wired medium and is based on IEEE 1394 protoco l to trans mit 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 of Sc!"icC in Broadb"Jul Syst ems

Q uality of service 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.r vicc. 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 Broud bund Systems

With universal 10 and multiple service providers delivering multiple services on shared media to multiple
subsCribers, the security and privaey of information 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.r s that the information link is secure.

1.7. C nse Hisfo-rics on Netwo rk, System, and Service M:1nagc ment
Network Management is more than just managing the network. In standards bodies it i.s referred to as Operations,
Administration, Maintenance, and Provision ing (OAMP). Of course, 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 of servi.c e. As one IT manager commented, the configuration and use
of a 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 too ls) could
presenl a challenge to IT managers.

J.7.J. Case History 1: lJUr)Ort:wce of ToJ}Ology ("Case o ft be Footprint}

A saable corporate n~'lwork consisting of several minicomputers arJd about 100 desktop wo rkstations and personal
computers suddenly started "crashing" freque.ntly (a legacy network·e x.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.

Part ofthe 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 If anyone
bad just been doing anything o ul of the 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 its global network. As simple as this sounds, its imple.ment;ltion could be
extremely complex. Let us consider a si,mple real-world s ituatioo 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.

Flgur t 1.2t. cas·t History 2: C<nlr olly 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 of the input port of the lNMS? ls it due to I/O output port of EMS? ls it in the software of either EMS or
INMS or both? lH is in the INMS software, sbould the filtering of unnecessary events at the input take care of the
problem? The answers io most of these 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 of unnecessary alarms also causes a stress on tbe network and networks have gone
down due to uncontrolled generations.of network management messages.
I.7.3. T r ansaction Delays in Client-Ser ve r Netwo rk

In cumru oational and global enterprise organizations, application servers serve thousands of clierus over
international nelwork.~. In a study of banking industry, lrnnsaction del11ys were measured and analyzed to determine
the root cause ofthe de illy 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
appro priate actions were initiated to resolve the problem. This case illustrates the need tor management of end-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 of CustOmers

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. In an optical fiber transport network
using TDM SOH network element that carries thousands of cbnnnels, 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 thi s happens. all downstream
systems from that interface are ioaccessible. Such tailures are associated with fuilure of the 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 we shall learn in Chapter 9 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 prob lem in a shared medium can bring the entire segment down, somet imes
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 equipment or 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 off and 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 nct\vork with common modes and media of transportation and
distribution. As in the ca;;e of broadband networks, the IT-manager needs to maintain both types of networks. 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's job. 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 of Ethernet 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 of Network Managers ln order to appreciate challenges t:bntlT nutnagers face, several of them were
interviewed by the author. They face net\VO(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 most corporate networks run 24/7-i.e,, available
24 hours 11 day 7 days a. week! The questions Uta! were posed, wiU1 n summary of t: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 net\vork and network
management protocols. The author'·s recem.in-deptb study of service 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 than the 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 too ls
o Anticipate customer demands
o Acquire and retain human resources
o Manage client~rver environment in converged networks
o Networking with eme.r ging 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 o r 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 of the 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., Multi Router Traffic Grapher (MRTG)
o Rely on consultant advice and technical informal ion for growtb decisions
4. Do you need an NMS? Wby?
o Por proactive management of network
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 To see theirend in growth
5. What problems would you expect the NMS 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 of problems
o Gather statistics and predict trends for planning purposes
o Do curnent 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 of network management funetionsand system in the following ;ections.
1.9. Network Ma nagement : 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
network Administration 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 IT services.

1.9 .1. Goal of Networ k Management

The goal of network management is to ensure Lhattbe user.> of network 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 overa U cost. There needs to be a well-established interaction between the various groups performing
these funct ioos.

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 of network planning and design and is the responsibility of the Engineering group.
The Engineering group keeps track of new technologies and introduces them as needed. What is needed and when
it is needed are determined from analysis of traffic and pedilrrnance data provided by the netwo.ck operations. New
or modifications to network provi sioning may also be initiated by management decisions. Planning and efficienl
use ofequipment can be acbieved w.itb good inventory management of current and fitture modification~ of network
configuration by tbe Network 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 of circuits and measuring
the performance tune-up.

1.9.3. Network O twmtintli 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 of the problem caus.ing the failure. and restoration
of service. 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 of the 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 of the 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 of a trouble ticket by an NMS to the resolution of the 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 stored by NMSs. NOC has a display that reflects the dynamic oonfigurat bn of the network. and its stows.

The status of the network is displayed by a NMS and indicates any fitilure of components of the network, as well as
·the traffic pattern and performance. Any configuration changes needed to relieve temporary congestiln in t ra ffic
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 re Uabil ity and to improve its response time.

Security Management can cover a very broad range of security. 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 of resources and services provided.

Since the network consists of compo.nents manufactured by muliiple vendors, commonality in the definition and
relationship of component 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 of implementing 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 kee p them infunned abo nl the activilies and performance of NOC and the network. User
reports are distributed to users an a periodic basis o r 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 of all activities oflll$tallation and mainie08Jice of equipment 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 orgait ization ofan NMS.

1.10. Nclwork 1\hnagcmcnl 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 o r mare clients or due to a.lrnnsport pro blem.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. T he 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 al so 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 o r set of products. T his invo lves getting data from each instance of tbat. compo nent in the
network to one o r more ·centralized locat ions and displayi ng their status on an NMS; for example, failure of a
bridge . This would set up an alarm in the NMS to alert operat ions 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 net\vork. 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 of all vendor components. 1ltis mi~ht require
the installation of multiple NMSs fur an e nterprise o r an NMS tbat can manage multiple vendor components of a
network. Thus, common management system, as well as the integration of different management systen\s 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 of managed 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 of the 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 net\mrk 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>Onrn ll!


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 of the 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 I 0.

1.11. Network Ma nagement 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. Software products have since· been developed to address such system- wide so lotions.
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 of other support functions. These are required to run an IT opemtion efficiently and in a
cost-effective manne r.

Another area of system mnnageme.nt is logging and archiving ofevents. This is illustrated by a·case history when
the system performance during 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 oft he book. We will present here a high-level
view of some of the aJternale perspeclives of1 he broad aspects of net work mnnagemenL

I. U. I. Network Mllnll~eruent J'crspccti••c

Domains: ll1e ·network managemenl overvi.e w given so mr in the chapter can be perceived as managemem of a
domain. The domain can ·be any of a selected group of parameters having common attributes. Thus, a geographical
domain refers 10 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 ·p roducts such as SDH cot~d each define a domain managed by a
sepamte NMS, as well as a different administrative group.

Protocols: Netwo rk management can be perceived from the protocol used 1omanage the network such as lotemel-
based SNMP and OS!-based Co mmon Mnnagemenl lnfurmation ProtocoVCommoo Management information
Service Element (CM!P/CMJSE). Tmffic nse of various 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 of a circuit that deploys multivcndor and multitcchnology network ele.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 of service providers is more about seme management. Providing quality of service to satisfY the
customers' needs requires network managemem. However, while network management. focuses on the physica.l
network, se.r vlce management focuses on services offured over I he network and those services meeting customer
needs and satisfaction. Various qual icy of service (QoS) parameters u.re defined and an SLA is reached between tbe
service provider and the cuslomer. There are several OSSs that provide different types of service 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 of equipment 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 C\L~tomers.
A proactive approach to CRM is the service 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 acli vi ties, ns well as bllJlking automated ieller machines.

I.J 2. NMS P la t form

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 e ither 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 us ing 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 Ma nagl'mcot


Current NMSs are based on SNMP protoool. Most commercial network components have embedded SNMP
agents. Because of the universality of the IP, transport of management 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 of specifications 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 of transactions is initiated by a managemem agent to
an NMS as alarms. To detect a mult quickly. o r to obtain. good. statistics, more frequent polling of agents needs to
be done by the NMS, which adds to network traffic overhead. There is an alternative solution to this problem,
which is deployment of remote monitors as discussed in Chapter 8.

Some of the 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 po tential 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, methodo logy, 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 nel\vork 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
netwo rks 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 of voice, 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. T his is being widely
deployed for WAN, mobile. broadband access. and home networks. Much work on standardization of management
ofthis technology needs to be done in this area.

S umma ry
We presented in this chapter an overview of data and telecommunication netwo rk;, 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 of dam communication. We briefly talked aboutlhc lnternel and intranel in
t01lay's environment. Adoption of standards 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 of network 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 of the chapter.

Exercises

Note for Problems 1--4: n is important that a network administrator be familiar 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 o f their usage by logging into a UNIX
system and accessing the 011-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 d oing 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 your state or province are networked. Discover that network by tracing the route from
your Institute or organization to other II'IStltlttes or organizations.

3. Draw the route diagram Identifying each node for the foll owing 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.l v 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 determined your conclusion.

a Measure the percent packet loss between a host at y()ur sit.e and the machine nsl.bangla. net, and
record ihe t ime o f your measurement.
b. Then cletennine where along the route to ns l.bangla.netlhe pac·kets are getting lost.

6. For each 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 what you 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 the subnetwork that you are logged on.

8. In Problem 5, Identify the gateway 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 a wrong user id, bu t correct node address. Explain the error message(s) that
you get and the servers that you get them from. ·

1.2. Explain the decimal notation In representing the clas.ses of 1Pv4 addresses. Give an example for each class.

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
configure your 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
II'
1-
IPX
--
1-
t(O~ J
-
~'!J

l'lly
1-
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~ mn l l

- -
.
~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 client machine lsronnected to the
Internet with Ethernet as the physical medium.

a. Draw the delllils of the CXlmmuniClltions oel\vork 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
t:tJ iW,\N~-----~
Notwork ~
Cl ..-nl S<n<:r
(a) L·oumuUltCdlh.m NUt,\•cuk. Uetwccnt.ll\111 ttnd .S..·I\-cr

ICal~>n U)'<:~ i\pp:1c:mon 1-ll)'l'f<

>po<l Luy•l\l
-
lnt o1nl.!c~n t <11111!\\ll)'

C~II\'Ct)ii.:!
i-
'Ll:•y~n
1'11lMpon U)<t<

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. Give an example for each of these causes.

18. ~a network engineer in a Network Operations Center, you are followl"'! up on two troubl e tid<ets. You do not
have a network management system and you have to 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 i t woul d validate the
customer compl aint

a. Trouble Ticket 100: C ustomer says tbat when be receives messages, the message is periodicaU y
missing soroe cbarncters.
b. Trouble Ticket 10 I: 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<>lleague in ber New York office "''POrtS that he is able 10 access the system.
2. Review ofl nfo rmation 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 I 0 and I 00 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 (W ANs), Access Networks. or
Customer Premises Equipment (CPE)/Horne Network~. In this chapter we will review these oomponents &om the
perspective.s of concept, 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 topo logies ofl..ANs and WANs. ln Section 2.2 we start with basic Ethernet
and then traverse the development of Ethernet, 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.n 2.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 of remote. 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 of Section 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.e r
(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
Section 2.6 fOr oompleteness and is discussed in detail in Part IV.

2. I. Netwo rk Top ology

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 of the other two and is known as a hub. A hub plays an important role in
11etworking as we will soo.n team.

LAN topology depicts the configuration of how 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 is also 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

Flgur t l.t. LAN Topologlu


lol Bus Topotugy

(t)J Ring 1opo10gy

(c) S!nr ToPQI<lgy

Ethatn&t Hub To~an-Ring f'iub


(d) Hub Configurations

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 l nformalion to anoiher DTE in the ring, which may be
either a receiving bost o 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-rob in) after its tum is finished. Thus, ihe process in
thls topology is detenninistic and LAN o perates at almost full bandwidth·efficiency. IEEE 802.5 StliJldard s pecifies
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 o ne of two modes. They can he connected in a broadcas t 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. lf DlEs 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 up of switches, 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 N I-
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 of service. 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 of packets, 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-N J-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 hierarchies I 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 N I 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 most widely 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 of the 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

D
1(). 1. 12
~
10.1.1.S
~ ~
10,1. 14 10.1 .1.5
~._, r I
0 t:=::::er,emet 10,1.1.0 }
I
r-1
10.1. 1.1
8 rldga I·

10. i.2.6

10.1.2.1

Rau~er
I
Q ATM 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 I 0. 1.2.0 Ethernet LAN. I 0.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 half routers. 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. E thernet

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, if a 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 collisio n phenomenon is to env1s 1on a hollow pipe with boles all along
represent·ing surt ions. There is a person at each ho.le represe nc·ing a stat ion. The ends of the pipe are sealed aod do
not reflect sound. Let us suppose Joe smns speaking at a bole near one end oft be pipe. He makes sure that be does
not bear anybody speaking before be smns (carrier sensing). Once he st.a ns 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. I fhe bears somebody else, then hi s
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 speaking at a hole near the other end of the pipe; and that
persOn starts speaking jDSt heforeJoe' s voice reac.bes him. From this ana.logy, we can ca.lculnte that the minimum
duration of time 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 of the 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 obey the above rule.

The daUI rate on an Ethernet bus is nonnally 10 Mbps (millio n bits per second). When traffic on the bus reaches
about, 40% to 700/o of the maximum duta rate of 10 Mbps, depending on the packet size, perfo[((laoce degrades
significantly due to an increased collision rate. The bus medium can either be tbi ck (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 I 0Base5 determined the minimum ·packet size of 64 bytes. However, with different configurations
sbo,vn in the table ( I 0Base2. 10Base5, IOBase-T, nod I OBase-F), segmerrt lengths and drop lengths Vlll)' baSed on
thelOedium. However, the minimum packet ~ize is still maintained at 64 bytes.

Tabltl.t. Etb<rntl LAN Topology Limits


Type Oesc:.r lptlon 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·kilom eter 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 pro blem 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 likel y 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 cou ld 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 10 a port in
this configuration aod resolved in a much easier fashion.

2.2.1. Fast Eth ernet

The hub te<:boology described above led to the development of Fast Ethernet technology. Fasl Ethernet operates at
a speed of I 00 Mbps data rate on an unshielded twisted pair ( UTP) cable and is c~lled I OOBasc-T. The maximum
length from I be hub to the DTE is specified as 11 I 00-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 I 0 Mbps to I 00 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 of Category 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. I OOBasr-T F0$1 Ethtrnet Pr·oroool Archlleclu,..

Notwor~

LLC
Datalm~

MAC Subiayer

ConvorgcnC4 Layer
Ptlysical
PMD Sub!ayer
LLC' LO!)lcal L1nk Control
MAC. Medium AccCM Co111rol
PMO: P hyslc~ l Medium Dependent

2.2.3. Gig;lbit Etlr en~ et

With the successes of Ethernet and fiber-optic communications, tbe logical evo lution 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 have so 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 of Ethernet 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 the media access control (MAC) 1he same, and modifies the pbysica I
layer. Physical layer archit~ture combines the physical interface of the 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. I f.Ef. 802.37. G lg~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
1Serlallze110<1seriai<Ler)

PMD Sub!ay<tt

LLC: Logle<i lin~ Colrtrol


MAC; Medium Access Conttoi
PMA; F~)'Sitlll M<!<l1um Allachmenl
PMO. Physical Medl<L'Il Oepencent

Gigabit Ethernet specification initially penn its use of three 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. I OOOBaso-T.

Both shon-wave (780 nanomeier, light frequency) and long-wave (1300 nanometer, near-infra-red frequency)
lasers are spec ified 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 range of 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 Micron Balance Shielded UTP
Mode Mode Multimode Multimode Cable

l OOOBase- 10 km 3km SSOm 440m


LX

lOOOBase- 550m 260m


SX
TAble 22. Glgobll Echtrntl Topology Lhnils

9 Mkron Single so Micron Sl~~&le SO Micron 62.5 Mlaon Balance Shielded UTP
Mode Mode Multlmode Multlmode Cable

lOOOBasf>- 25m
CX

100
m

In Figure 2.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 of the
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 I 0-
Mbps data .ane, required a minimum of n 64-b)te fmme, shown in Figure 2.6(a) to detect any collision. The time to
accommodate the 64-byte frame is defined as the slot time, which is 5 1.2 microseconds. An idle time of 96 bits
was allowed between frames, as shown in Figure 2.6(b). Fast Ethernet with a I OO"meter drop, I 00-Mbps data mt.e,
and one repeater (minimum time each packet needs to traverse in a hub configumtioo) would take a little over five
microseconds. Thus, a slot time of 5.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
Figure 2.6(d), to increase the number of bytes 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


(54 Bytes M in 1 Idle I
Slolllme~S12M~
(64 B)'lco)

(b) 10 Mbol Ell-.enlel Frat.,

' Idle
802.3 Frame
(64 Byles MW> I Idle I
Slot lime 1 5 12 MlaOSetOndt
(648ytes)

(c) Fast Elhomet Frorre

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 was made to Gigabit Ethernet specifications to permit bursts of frames 10 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 of transmission, especially in the backbone configuration.

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 of multimedia service. ffiEE 802. 1p spwifYing the class of service (CoS)
meets this requirement in a limited way. In add it ion, Resource Reservation Protoool (RSVP) can be used for
advance reservatk>n of bandwidth 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 no\v discuss how dalll rates of
Ethernet, Fasl Ethernet. and Gigabit Ethernet could be doubled by migrating from a half-dupl e.'< 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 co llision with another signal ln
Section 2.2.1, we gave the analogy of speaking into a hollow pipe 10 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 o 1her 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 of a 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 so phistication 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 genera lly used
in po,int-to-point co mmunication 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 of congestion.
Figure 2. 7. 1EEE 8 02.J J l'rotocot Arehittc:tur.

Nerwlrt

LLC
Oato Unk
MAC Sv~layor
CSMAICO or l'ui-Ouplex
Alys!Ci;ll

Because of the 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 optio n 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 of just 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 I 0-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 I 0 Mbps.

Figuro. l .9. Swil<h<d Hub iu • Cl itnt-S.n·~r Cuufigumliou

1!
5enrer

I
IOOMbpe
I

Switohod Hub

WorkstaU«!
s '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 I 0
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 of different 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. Us ing 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 S\vitch 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 LAN s, each being defined as a Virtual LAN (VLAN).

Flgurt 2.10. Vb1u11l LAN$

~ 'L.J=I
- ~~-~
~lot \ Swltthe~ HuD
Poll for Subnels
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 of LAN 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 of a 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 oft he 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. [f the message was not accepted by OTE 3 for any
rellSOn. such as a corrupt message. then tbe message trailer is so marked and appropriate action 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 to ken; otherwise. the ioken starts wrapping itself aro und and all the stations are in an idle
mode.

Because oft he 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 fill lure 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 of the lights continue to be lit.

lf there i's a break in the link segment of the ring. the d ownsi'ream DTE sends a beacon to ihe others indicating a
failure. For eNample, if the 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 o n
the inner ring and forwards it on the o uter ring to DTE 3. DTE 2 receives tbe token on the o uter ring ruld fOrwards
it on the inner ring.
Figurt 2. U. Tok•n-Ring Dulii-Ring Configurotion>

(a) To~on·Rina Ouai·Rino t.lnn~emcnl

(b) TOkCIJI·Rina ore laolpilon

1c) Tilllon·lllng Sogrn•nt lsola!Ol

Figure 2.12( c) shOW$ the situation where the sectbn of the 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. FOO l

Fiber Distn'blned Data Interface (FDD!) LAN came into being to take advamage of fiber-optic lnlDSrrussion media
for LAN technology. It operates ala drua rotc of 100 Mbps and can include up to 500 DTBs in a single segment of
l 00-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 oongieA!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 of stations.

2 .2. 10. Winllcss LAN

Wire.l ess 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. 11 b 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, provisionin g, 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 over a 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: Hitrorchiroi Topology

SUitions I, 2, nod 3 in Figure 2.14 can be e ither 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 of U1e stations acting a.s the controller, or a beacon as
it is called.

2.3. Netwo rk 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) oonnecting lo 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 techno logy that includes an
ATM switch. Other network nodes are smart switches with buflt-in intelligence ofvnrious degrees.

ln 11 simplistic view. 11 node can be looked at as a switch, a bridge. a router, or a !lllteway. The basic concepts oft be
four primary oodal components are shown in Figure 2. 15. Figure 2.15(8) shows a switch, where inputs and outputs
are of the 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 (connection through the switch is made) and then the analog signa l is passed through. The switch
is insensitive to lhe information content. When il is used in tbe digital mode, it is used as a packet switch. 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
Etflemel
P•ck,_r.
-- I I•
Flltor l ou ,
Brldgo
'"' ' 'lROJUng - e xto«iol 1..1\W
Elllemol
p~~L5

(D)!OriUI)o:
Loco N otWO(~
IPI'llci<•LI l'lltUt ~ ~ l"""u•vJ
El<IOmAI Notv.ori.
IPPetlutll
R<Mot
(e)l\outtt
IP X26
Notwollc
Poclots I· AY1 1:=~1 NOI\\Oric
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 w hicb 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 of a switch aod a bridge bw also route packets to the appropriate port in
the correct direction ofits destinat ion. 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 protocoL ln this case, a gateway is used to oonvert one protocol fOrmat to another
protocol.format. lnFigure 2.15(d),a gateway is shown belwee n 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
network components in this section.

filgu.rcl.L6. N<lWo.r ktd 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 will co~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 of stations 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 of other 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 of ports 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 of switching 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 is done 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 of the neighboring node responsible fOr that destination address.

The transparent bridge learns routing information by a backward leuming process. That is, when a packet arrives ut
a port. it·notes the source address of the 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 a closed loop, Ethernet 3-transparent bridge B-Et hemet 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.b alit be way up
the tree to the header bridge A, and then traverses down the other balfofthe t'ree to LAN 4. Thus, the header bridge
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 aware o ftbe entire path to the dest inaJion. ln add it lo o
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.outin g 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 fill lures, 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 nel\vorks and bave several limitations. Due to dissimilarity in the rout.ing
algorithm, communication between media using different protocols bocomes dlffioul~ for examp le 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 of routers in networking.

2.3.6. Rout~rs
Routers and gateways fonn the backbone of net working. Although we bave shown alternative ways of networking
with bddges in the previous se<:tioo-sometimes cheaper and a short cut to es18blish enterprise ne1working.-t.be
clean approach to establishing computer networks is with the use of routers.

A router, as the .nrune indicates, routes pockets through the n~1work. Each router in a computer network has some
knowledge of possible ·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 Resol\11 ion Protoco l (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 del ermine its source
and destination address, as well as what type of data 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 mull least type of packet. 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 well as 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 of a 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 10 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


A gateway connoots two autonomous networks. Eacl18utonomous network is se.lf-contained in all aspects-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 Conflgun\llon

NP - NP
- - Nf f-
OP - tip
-, or -
Phy
'
Phy P~l'
T I
Phyaloal M~lum

Since protocol conversion for a gateway is done at tb.e network layer. il cou ld 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 N I, 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, butt his is no longer tho case. Gateway is the generic term that
is currently in vogue. An exrunple o f this would be a protocol converter that would be used between two email
systems. Let us consider 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 Configura lion


AP
pp
AP

~
- _ AP

~
AP
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. Mu ltipr otocol Uoutcn; Jllld Tu nn~ling

An alternative to ihe use of gareway to communicate between autonomous networks is runneli ng using
multiprotocol router. Tunneling is generally used when the source and 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.

Figure 2.25 shows communications between two Ethernet LANs on IP networks. One of them 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 through Europe behaves very simllnrto a serial Link.

··igur< 2.2.'1. Tunntling Ul<lug M tdllJli'Ui bt'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 of the United States. The initial message is routed to the serve.r of the LAN that the station belongs
to, in I his 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 F romtben on,
the sender "tunnels" the packets directly to the user via the fOreign ageni.

2.3.9. 1-l~tiJ-Brid gc Configuration of ltout eJ"

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 a standard 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 of the 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 of proprietary Jfpp protoco ls 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 a method to connect 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, if Lbe 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

Sooal
n.tpU!


Router 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. Ed ge 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 of an MPLS edge router, which we will learn more about in Chapter 12.

2.3. 11. Switches


lt would bave been logical for us to s uut 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 W ANs.

Switches opemte ru the physical layer o f 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 switching function when
they route packets.

Mo51 switching technology is based on solid-state technology, and the s peed. 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 mull iplex data using switches (and consequently in routers and bridges).
More importantly, end-to-end perlbrmance of the netwo rk depend~ on the~. lat.eocy, and lateocy variation in
tnlllSpo rting data fro m the source to the destination. Voice, video, and data. have different quality-o f-service
requirements.. Based on these requirements, different types of end-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 c ircuit 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 of the-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 itself more to packet switching. It wot~d be a waste of bandwidth to
use cirouit ~-witching for computer data nei\\l:lrks. Packet ~-witching utilizes the fucilities and, hence, the bandwidth
available more effic iently. 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 of the 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 .h ave to 'be reassembled in the correct order.

Figurc 1.27. Packcr Switch Configurations


(o) Oalagfam Confi!J.!ratlt>rl

JP~I3 j Pkt2jP~I1! ~~~


~~
~t3jPktZjPI<lt j
r.;;

(bl VIrtual Circuit Cot1f9urntiQn

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 a given source to a given destination take the same path. This is analogous to circuit switching in that
U1e path is fixed for the entire session. The concept of session 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 c ircuit 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 the correct order at DTE Z in this situation. Although the initial 0211 semp
is an overhead, subsequent data troosmissio n is fasler than in daLagram service. We will discuss more how the
virtual path- virtual circuit configuration is used in Asynchronous Transfer Mode (ATM) service in 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.
If the ·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 Sect ion 1.2. computer communication network rides on top of telecommunication 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 of traffic. Otherwise, SVC service Is used more
often. Public teleoommunicat!on service providers offer these services. However, private corporations, using their
own S\vitches 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 of wires 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 loop transmiss.ion line.

1'he trarunnission section consists of link t:ransmlssion fucilities and nodal components. These are between central
offices in lhe case of a public sw.ilcbed network, Md between the routers of service 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 Tech nology

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 point to 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 oft he transceiver play an important part in LAN, as they determine 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 of Ethernet 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 of Ethernet 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 of the medium is also detennined by the type
of swtions on l.he medium and I heir access control mechanism. We listed the limitations and capabilities of various
LAN media for Ethernet LAN in Tables 2.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 Ia Iter 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 be extended from I 00 to 150 meters at I 00 Mbps. cat-6a cable e.xtends the data
mte to I0 Gbps.

The fiber-optic medium provides the· best quality transmission. Of course, 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 kilo meters.

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 of cabling 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 of a remote hub would take much longer for service restoration.

Wired WAN media comprises b1mdles of twisted pairs (such as in Tl and loop fucilities), coaxial cable for analog
transmission (for example, N I), and optical fiber (underwater sea cable).

2.5.3. Wireless TratL.~mission Media

Wireless medium is used in WLAN as well as in mobile 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 movi ng 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 of these 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 are separated 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
transmissio n. 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> of end users is coded to share the same medium. They should be
multiplexed and de mull iplexed 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!;. 11te T 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 bon om 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 avai lable for eaeh channel is 64 kHz., but it is all available during a complete session.
A session Is deftned as the duration from establishment of a connection to tearing it down between a pair of users.
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 of data and quality of servioe required), occupies more channels.

Figu•·• 2..28, TOM, Plirktl, ond Ce11 Tran.smlsshtnl\1od ..

Channel l

Channel24
nne
5

If Uset1 User 2

TJme
u .... 3 User4

(at T 1 Time Oivlllon "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 oft be medium Is available to it.
This is in con!nist to TOM, where only a fraci"ion of ihe medium bandwidth is available to any user. ft can also be
not iced that Lbe size of all 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 S\vitch Ill each .n ode looks at the address ofihe destination and routes it using ihe appropriate path. Each
packet can take a different route depending on the availability of links and bandwidth based on different algorithms
used. The packets may arrive out of sequence 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 of transmission. 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 I concepts of ATM 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 of them. 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 of ATM

t'lgw·•l.19. MPLS Transmission Mod•

ATMCeti Header Da1a


8

tP H OI>Cior MAC H oi>Cior LllbeiHDOdOr IPHoo.aor

GFC: 4·811 Gonone Flow Hoador VPI. Vinunl Pmh ldenlifler


VCI· VIrtual Clrtvl!ldont~lor PT1: 3·Btl Payload Typo
Cl.P· Congostlon Pnorfly HI:C· Heador Emlf Cooltol

An !P-based network is feature rich because of its 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 I P, 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 usage at 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 lOr broadband 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 of either 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 of digital 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 of tmnsmissio n at the basic or atomic level (although not
quite true). Eacb oftbe modes-TOM, ATM cell 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 signa I 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 DS liE I, 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
of digital daia is synchronized using a SONET basic signal rate of 5 1.84 Mbps called synchronous transport s ignal
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 of input signals ihat need to be multiplexed.

Flgttr<lJO. SONET Trans-wi.ulou MOlle


OS1

1.544 Mbps
E1

6.312 Mboa
053 44 736 Mbt»
SfS.1 (N)
ATM4.384

Af M 140.760 M>po 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 of the 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.3 1. 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_,___,- Channell
Channoi2

Trmo

i UHf I Usor 2 Usor3 Usor$

2.6. l nteg rnted Scn•ices: ISDN, Fr11 m e 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 s ignaling 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. The T I interfa.ce carries 24 channels and the· El interface 32 channels.

Witb the improved quality ofrra.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 of a 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 have contributed sign ificantly 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) tec hnology 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)'n chronous 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. BroJKIIJa nd Strvleu Nri\\Ot'k

OCnl
STS...
lJnk

Summary

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
ofthe star 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 of the lntemet. Tree topology is used wben a network is made up of bridges.

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 I 00 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 of workStations with VLANs.

Token Ring and FDDJ both use deterministic MAC and hence are mere efficienl over mndom access Ethernet.
I BEE 802.5 defines the speed of the Token Ring as eilher 4 Mbps o r t 6 Mbps.

FDDr is based on IEEE 802.5 protocol and operales at t 00 Mbps. lt is typically used for backbone LAN. Because
oftbe ·n eed 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 in the 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 at 1he network layer. Routers and gateways form the backbone of the Internet. The
difference between a router and a. gateway is !hat the former just routes, whereas the latter does protocol
conversion. If protocol 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 of a 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 ca \led 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 of gigahertz 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 techno logy.

Exercises

1. The maximum all owed 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 the sum 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
that the minimum frame size (number of bits per frame) of an Ethernet frame Is 64 bytes.

Note: Tbe maximum frame size .i s 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 of 512 bytes to detect collision. Assume a repeater delay of two m lcroseconds.

3. The Engineering Department of 12 persons In a small 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 of the corparation and have to resolve the problem technically,

a. Describe fuur choices for resolving tbe problem, maintaining tbe LAN liS Etbemet LAN.
b. State the advantages and disadvantages of each approach.

4. In Exercise 3, you are told by the IT Manager that 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 of traffic between any two.statlons being the same. What would your new configuration be?

5. Design an Ethernet LAN using a 10/100 Mbps switched Ethernet hub to handle the following specifications:

Number of clients = 16 operating at I 0 Mbps

Number of server = I

5()0(o of the tm.ffic is directed to the server

Draw the oonfigu.rtltion and indieale tbe transmission modes (half..duplex or duplex) on the ports.

6. Repeat Exercise 4 If the traffic to 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 Fi gure 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 of Exercise 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 of the IP address Is allocated to subnet designation.

N etwork T able

N etwor~ Subnet Host

145.50 50 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
operatfl\g at regular 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 the same time) percentage utilization Improvement of a
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-rll\g
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), as the duration of the me,ssage is short compared 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 throug h 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 if a virtual circuit is established along the shortest path?
18. How many (a) El channels and (b) 051 (Tl) channels comprl se·anSTM·lSOH signal?
Part II: SNMP and Network Management
Part ll, comprising C hapters 3-9, is devoted to unders tanding the principles o f net work and syste m
management. Chapters 3- 7 discuss the management of a TCPIIP netwock using Simple Net\~ork
Ma.nagement System (SNM i>) versions I, 2, !!lid 3. Remote monitoring. wh.ich is also part of SNMP
management, is discussed in Chapter 8.

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

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

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

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


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

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

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

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

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

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

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

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

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

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

3.1. NeiworkM;magc mcnt Standards

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

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

Tobit J.t. Network ManRgernent Stondords

Standard Salient Points

OSI/CMIP lntematioual standard (ISO'OSO


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

SNMP/Internet Industry standard (lETF)


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

TMN lntemational stllndard (ITU-T)


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

Standard Salient Points

Addresses both netwotk and administrative aspects of management


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

IEEE IEEE standards adopted internationally


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

Emerging Wei>-B85Cd. Enterprise Management ( WBEM)


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

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

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

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

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

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

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

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

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

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

3.2. NctworkM.Il nagcment M.odcls


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

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

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

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

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

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

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

3.3. Organization Mode l

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

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


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

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

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

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

MOB MMDQemont Oalabas<!


C=:J ~nt Pmc:esa

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

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


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

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

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

Agent NMS Mf.lnagerNMS

ManagerNMS Agent NMS

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

3.4. Information Model


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

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

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

MOB. Managanonl Oal.tbase


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

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

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

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

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

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

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

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

3.4. 1. M11n>•gement [nformlltion Tree

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

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

Root

Lov<>f 1

Level 2

Level 3

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

Flgurt 3.8. OSI Managtmtnl lnformaiion Trt'f


3.'1.2. Mnnugcd O bject Perspective

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

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

Figure 3.9. Omctt)lltat Vltws or M IUiaged Object


Access:
ACcess
P<IVII(lge

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

8
qBehaviGr

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

(b)OSI Perspecllw

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

objectlde11tifwr and descriptor unique 10 and name for !he object


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

implemenialion requiremenls

textual desert ptlon of the semantics of object type


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

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

object class managed object


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

behavior exhibited by it in response to an operation

notifications emitted by the·object

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

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

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

(a) Internet Perspective

Characterlstks Example

Object type PktCounter


~yntax P>unter

f'\ccess Read-only

~tatus Mandatory

Description P,unts number of packets

(b) OSl Perspective

haract.erlstics Example

p bject dass Packet Counter

f'\ttrlbutes ~h'lgle-valued

pperatlons ~et,set

Behavior Retrieves or resets values

Notifications ~erates notifications on new value

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

3.5. Communication M'odcl

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

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

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

Flgurt 3.11. Management Communication Model

- 0p&IBII6M/ReqllliSIS_.

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

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

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

Phy.llcnl Mo<tluln

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

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

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

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

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

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

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

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

<name> : : = <defini t ion>

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

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

We can define an entity <digit> as

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

Secuflly -Type ::= SET


{

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

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

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

t itle Tit le: : • GraphioStdng


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

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

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


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

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

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

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

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

(p~oduc t-based [ OJ troLL,


basic [1) NULL }

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

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

'TnbloJ.l. ASN. t Symbols


Symbol Meaning

::: Deflned as or assignment

Or, alternatives, options of a list


TRblt 3.2. ASN.I Symbols

Symbol Meaning

Signed number

Following the·symbol are comments

{) Start and end ofa list

('] Start and end ofa tag

() Start and end of a subtype

Range

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

Table J.l . ASN.I Keywords

Keyword Brief Description

BEGIN Start of an ASN.l module

CHOICE list of alternatives

DEFINITIONS Definition of a data type or managed object

END End of an ASN.l module

EXPORTS Data types that can be exported to other modules

IDENllFIER A sequence of non-negative·numbers

IMPORTS Data types defined In external modules

INTEGER Any negative or non-negative number

NUll A placeholder

OBJECT Used with IDENTIFIER to uniquely Identify an object

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

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

SEQUENCE Ordered list maker

SEQUENCE OF Ordered arrayofrepetltivediJta

SET Unordered list maker

SET OF Unordered list of repetitive data

STRING Used wit h OCTET for denotlne a string of octets

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

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


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

For example, a MID definition module will look like:

RFC1213-MIB DEFINITIONS : :• BEG IN

END

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

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

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


Data Types Convention E>eample

Object name Initial lowercase letter sysOescr, ethe.rStatspkts

Applicat ion data type Initial uppercase letter Counter. lpAddress

Module Initial uppercase·tett.er PersonneiRecord


TAble 3.4. ASN.I D•IATy~ Conventions

Data TYpes Convention Example

Macro, MIB module All uppercase letters RMON- MIB

Keywords All uppercase letters INTEGER, BEGIN

3.6.2. Objects a nd Oa111 Types

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

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

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

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

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

PaqeNumber : :- ! NTEGER

Similarly, we can define the chapter number ofthe book as


Cttapt erl.'wnber : : • !.NTEGER

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

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

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

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

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

We could defme the same in an altcmative manner ns

Boo kl?ages :: = SEI,lOENCE OF


(
SEQUENCE
(ChapterNumber, Sep arator , PaqeNumberl
I

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

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

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

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

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


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

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

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

resea rch Research : : • CHOICE


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

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

Rese arch : : • CHOICE


r
p roduc t -basad ANY,
BASIC ANY
I

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

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

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

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

Tag Type Name Set of Values


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

Universal 1 BOOLEAN TRUE or FALSE

Universal 2 INTEGER 0, Posltlve·and negative numbers

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

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

UniversalS NULL Null, single-valued

Universal 6 OBJECT IDENTIFIER Set of values assodated wlth the object

Universal 7 Object description Human readable text describing the object

Universal S EXTERNAL The type is extemal to the standard

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

Unlversal lO ENUMERATED Specified list of Integers

llniversal l l ENCRYPTED Encrypted Inform atlon

Universal 12- Reserved for future use


15

Untversall6 SEQUENCE and SEQUENCE Ordered list of types


OF

Universal 17 SET and SET OF Unordered list of types

Unlversal 18 NumerlcStrlng Digits o-9, space

Untversal19 Prl ntableStrl ng Prl ntable characters

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

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

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

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


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

Tag 'TYPe Name Set of Values

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


standard time)

Unlversal 25 GraphicStrlng Graphic character set specified by ISO 8824

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

Unlversal 27 GeneralString General character strl ng

Universal 28 CharacterStrl ng Character set

Universal 2!1- Reserved for future use

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

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

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


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

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

Pageid : :• [APPLICATION 11 SEOCEIICE (


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

personnel- name Name

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

N3mo: Jcton P Smlh


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

PersooneiRecord ::=(APPLICATION OJ IMPliCIT SET {


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

Date :• [APPLICATION 3) IMPLICIT VlslbloSirlng - YYYYMMDO


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

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


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

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

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

3.7. Encoding Sc·ructure

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

F·lgurt 3.18. TLV Eucodiug Structurr

Lnngth

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


Valuo
J
fag Humber
(Hih bits)

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

Tablr 3.6. Valur ofClas.< in Tyt>t


Class B'"Blt 7v. Bit

Universal 0 0

Application 0

Context-spedflc 1 0

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

10000001 10000000

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

00001100 00011011

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

00000100 00000010 00001100 00011011

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

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

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

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

<macroname> MAC~O ."


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

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

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

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

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

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

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

3.9. F unctionul Model

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

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

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

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

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

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

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

S ummary

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

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

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

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

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

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

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

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

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

Exercises

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

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

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

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

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

a. for the structure and


b. for I he value

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

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

Name Manl M . Subramanian

Address 1652 Harts Mill Road

City Adanta

State GA

Zip Code 30319

Write for your record:

a. the infurmal record structure


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

9. Given the definition

olass : : • SET t
name Vi&ibleString
size INTEGER
gr aduat e BOOLEAN
I

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

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

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


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

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

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

a. A random Iist· of the students


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

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

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

4. SN MPvl Network Management: Organjzation and Informa tion


Models

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

flgurt 4.1. Man•ged LAN Ntlwork

~
NMS
192.168.252.110

0 ---112.U2521-- )

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

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

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

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


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

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

(a) System Information on 172.16.46.2 Htb

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


Name or IP Address: 172.16.48.3

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

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

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


I N~ or IP Adaoss 172 16 2521

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

(c) System lfilormat!Oil on ROUier

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

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

rruo Aaaresses 172.1& 41!2


Nl11'8 oriPAddrt.a 172. 10.482

(a) Addresses on 172.16.46.2 Hub Ports


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

(b) Addresses oh 172.16.46 3 Hub Ports

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


Tllkr
Name or IP Address 172.10 2$2 I

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

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


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

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

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

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

4.2. H istory ofSNMJ' Ma nagement

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

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

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

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

4.3. L. Orgaui7Jltions

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

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

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

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

~.3.2. Internet Documen t~

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

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

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


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

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

Flgut•t 4.4, SNMP Do<wntul Evohniou


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

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

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

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

4.4. S.N.l\tP Model

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

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

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

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

4.5. Orga nization Model

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

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

SNMP
MAnllgor
I
SNMPAgent Noiwo!k Agorrt

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

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

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

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


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

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

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

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

t t
SNMP Agent SNMPAgeol

Network Nei\Mtrk
Element Element

4.6. System 0 \•ervicw

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

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

Figurr 4.9. SNMP Network Mllu~tgementArchitrctnre


SNMP Manage· SN MP A,gent

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

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

~
~
i
SNMP SttMP

UOP
--- LOP

IP IP

Dl.C Cl.C

PHY PHY

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

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

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

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

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

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

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

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

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

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

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

-t7. lnform ntiOn Mollet


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

-1.7. 1. Int roduction

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

directory OBJECT IDENTIFIER : : • (internet 1)


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

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

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


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

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

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

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

ent erprises OBJECT IDENTIFIER :: • (private 1}

or

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

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

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


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

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

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

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

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

Strutture Dat~Type· Comments

Primitive types INTEGER Subtype INTEGER (nl.. nN)

Special case: Enumerated INTEGER type

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

Subtypes can be specified by either range orflxed

OBJECT IDENTIFIER 0bject position In MIB

NUll Placeholder

Defined types NetworkAddress Not used

I pAd dress Dotted declmaiiP address

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

Gauge Capped, non-negative Integer, Increase or decrease

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

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

Constructor types SEQUENCE SEQUENCE OF list maker Table maker

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

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

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

error- status LNT~GER


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

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

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

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


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

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

Tablt 4.2. SNMPvl Ktywonh


ACCESS

BEGIN

CHOICE

Counter

DEFINrrtONS

DEFVAl

DESCRIPTION

END

ENTERPRISE

FROM

Gauge

IDENTIFIER

IMPOR15

INDEX
TRblt 4.2. SN~1Pvl Ktywortls
ACCESS

INTEGER

lpAddress

NetworkAddress

OBJECT

OBJECT-1YPE

OCTET

OF

Opaque

REFERENCE

SEQUENCE

SIZE

STATUS

STRING

SYNTAX

TRAP-lYPE

TimeTicks

VARIABLES

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

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

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

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

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

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

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

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

The syntax for list is

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

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

The syntax.fortabie ls

SEQUENCE Oli' <entry>

where <entry> is a list constructor.

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

Ob!e<:t OBJECT IDElmAER ObjoetSyntax


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

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

(e) Managed Object lpAddrEntry as a Ust

OOJECT IDEHTIFlER

[ TB!II&: lpA<klrTabie ""


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

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

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

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

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


TYpe Tag

OBJECf IDENTIFIER UNtVERSAL6

SEQUENCE UNIVERSAL16

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

Type Tag

Counter APPLICATION 1

Gauge APPliCATION 2

TimeTicks APPliCATION 3

Opaque APPLICATION 4

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

00000 llO 00000011 00 l 01011 00000110 0000000 l

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

4.7.3. i" l amlged Objects

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

ta)An OBJECT·TYPt: Macro lRFC 11551

sysOescr OBJECT -TYPE


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

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

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

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

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


( OfJJECr 1

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

rC3d..,..'Y
mant.alorl

(~/2)

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

n:ertoce ~-,. wrt•~ The


t>t•-......

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

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

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

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

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

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


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

- oe.'ldo0111y

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

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

Synlal< rpAocfrEtay : seoueHce 1


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

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

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

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


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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

TABLE
T

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

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

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

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


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

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

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

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

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

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


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

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


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

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

ColumoarCbiect l'lowtln (b) Dbj6Ct ldanufief


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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

Figurt 4.25. M IB Modult S tructur<

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


<;mpons>

ENJ

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

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


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

system mib-2 1 System description and administrative Information

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

at mib-23 Address translation between IP and physical address

lp mlb-24 Information on IP protocol

temp mlb-25 Information on lCMP protocol

tcp mlb-26 Information on TCP protocol

udp mlb-2 7 Information on lJOP protocol

egp mib-2 8 Information on EGP protocol

cmot mfb-29 Placeholder for OSI protocol

transmission mlb-2 10 Placeholder for t ransmission Information


TRbl• 4.4, M IB·U Groull'J

Group OlD Description (Briel)

snmp mib·211 Information on SNMP protocol

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

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

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

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

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

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

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


Entity OlD Description (Brief)

sysDescr system 1 Textual description

sysObjectiD system 2 OBJECT IDENTIFIER of the entity

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

sySContact system4 Contact person for the·noM

sysName system S Administrative name of the system

syslocatlon system 6 Physlcallocatlonofthe node

sysServices system 7 Value designating the layerservlces provided by the entity

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

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

~
LJU

Legend: lNOEX io bold

Table 4.6. lnter(••u Croup


Entity OlD Descrfptfon (Brfef)

lfNumber Interfaces 1 Total number of network Interfaces fn the system

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

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

iflndex ffEntry 1 A unique Integer value for each Interface

lfDescr ifEntry 2 Textual data on product name and verslcm

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

lfMtu ifEntry4 Largest size of the datagram for the Interface

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

Entity OlD Description (Brief)

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

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

ifOperStatus ifEntry 8 Current operational status of the Interface

iflastchange ifEntry 9 Value ofsysUpTime atthe current operatiOnal status

iflnOctets ifEntry 10 Total number of input octets receive<!

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

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

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

iflnErrors lfEntry 14 Number of Inbound packets with errors

lflnUnknownProtos lfEntry 15 Number of unsupported protocol packets discarded

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Flgurt .u9. l ulert"ace Subbtytr~


Networi< lay~

Interlace Stblayer 1

Interlace Stblayer 2

ln~ce Soblayor 3

(a ) lntorfO<:<> Stackod loyoro

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

(b) lntO<faee Multplexe<llayers

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

fllgu.-. 4.30. lnttrfoct< Groups


IIRcvAddressTable (4)

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

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

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

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

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

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

Flgure .a.3 I. TP Crnu1)

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

Table 4. 7. II' Group


Entity OlD Description (Brief)

ipforwarding ip 1 Node acting as a gateway or not

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

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

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

iplnAddrErrors lp 5 Number of datagrams discarded due to address errors

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

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

Entity OlD Desaiptlon (Brief)

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

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

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


10

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

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

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

lpReasmReqds lp Number of IP datagrams recei ved needing reassembly


14

lpReasmOKs lp Number of succes$full y reassembled datagrams


15

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

lpFragOKs lp Number of successfully fragmented datagrams


17

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

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


19

lpAdddrTable ip Table of !Pad dresses


20

lpRouteTable tp IP routing table containing an entry


21

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


22

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

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

Figurr 4.32. fP AddrrssTIIblt

opAddrfable
(lp 20)

Flgur•'i.33. JP Roodiug Tablr

Figurr-1.34. fP AddrrssTran.slaliou Tablt


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

Tobit 4.8.1P Add.n!SS Tabl e

Entity OlD Description (,Brief)

lpAddrTable lp20 Tabl e of IP addresses

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

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

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

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

lpAdEntBc.astAddr lpAddrEntry4 Broadcast address indicator bit

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

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

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

T able 4.9. IP Routin g T able


Entity OlD Desalptlon (Brief)

lpRouteTable lp21 tP routi~ table


Tablo 4.9.1P Rou1iog Tablt
Entity OlD Description (Brief)

lpRouteEntry lpRouteTable 1 Route to a particul ar des11nation

lpRouteDest lpRouteEntry 1 Destination IP address ofthls route

lpRoutelflndex lpRouteEntry 2 Index of Interface, same aslfln~x

lpRouteMetrlcl lpRoute Entry 3 Primary routing metric for this route

ipRouteMetrla lpRouteEntry 4 An alternative routing metric for this route

ipRouteMetrid ipRouteEntry S An al ternative routing metric for this route

ipRouteMetri~ ipRouteEntry 6 An alternative routing metric for this route

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

lpRouteType lpRouteEntry 8 Type of route

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

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


10

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

ipRouteMetricS ipRouteEntry An alternative metric for this route


12

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


13

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

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

Entity 010 Desc:riptlon (Brief)

lpNetToMedlaTable ip22 Table mapping IP addresses to ph~ical addresses


TRblt 4.IO. lP AddrtSS TrAnslation Tobit

Entity OlD Desaiption (Brief)

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

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

lpNetToMedlaPhysAddress lpNetToMedlaEntry 2 Media-dependent physical address

lpNetToMedi aNetAddress (pNetToMediaEntry 3 IP address

lpNetToMedlaType lpNetToMedlaEntry 4 Type of mapping; validates with lpNetToMedlaType object

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

Figure 4.35. I P FOtWArdlng Tobit

Tobit 4.11 . IP I'OIWArdlng TAb If


Entity OlD Description (Brief)

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


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

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

ipForwardTabie· ipForward 2 Routing tabie·ofthls enttty

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

ipforwardOest lpForwardEntry 1 Oesti nation IP 'oute of this address

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

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

ipForwardNextHop lpForwardEntry4 Address ofthe next system

ipforwardlflndex lpforwardEntry S iflndex value of the Interface

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

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

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

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

lpForwardNextHopAS lpForwardEntry Autonomous system number of Next Hop


10

lpForwardMetrlcl lpForwardEntry Primary routing metrl c for this route


11

ipforwardMetricl lpForwardEntry An alternative routing metrlcfor this route


12

lpForwardMetric3 lpForwardEntry An alternative routing metric for this route


13

lpForwardMetrlc4 lpForwardEntry An alternative routing metric for this route


14

lpForwardMetrlcS lpForwardEntry An alternative routing metric for thi s route


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

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

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

Figut.. 4.36. ICMI' Group

TRbl• 4. tl. ICMP Groutl

Entity OlD Description (Brief)

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

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

icmplnDestUnreachs icmp 3 Number of ICMP Destination Unreachable messages received

icmplnTimeExals icmp 4 Number ofiCMPTime Exceeded messases rea.ived

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

icmptnSrcQuenches icmp 6 Number of ICMP Source Quench messages received


Tablt 4.12. I CMP Croup

Entity OlD Description (Brief)

icmplnRedirecls i cmp 7 Number ofiCMP Redirect messages received

icmplnEchos icmp 8 NumberofiCMP Echo (request) messages received

kmp lnEchoReps lcmp 9 Number of ICMP Echo Reply messages received

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

icmplnTimestampReps icmp 11 Number of ICMP Timestamp Reply messages received

icmplnAddrMasks icmp 12 Number of ICMP Address Mask Request messages received

icmplnAddrMaskReps icmp 13 Number of ICMP Address Mask Reply messages received

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

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

lcmpOutDestUnreachs lonp 16 Number of ICMp Destination Unreachable messages sent

lcmpOutTimeEl<cds lcmp17 Number of ICMP lime Exceeded messages sent

lcmpOutParmProbs lcmp18 Number of ICMP Parameter Problem messages sent

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

lcmpOutRedlrects lcmp20 Number of ICMP Redirect messages.sent

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

lcmpOutEchoReps lcmp22 Number of ICM P Echo Reply messages sent

lonp0ut11mestam ps lcmp23 NumberofiCMP11mestamp (request) messages sent

lcmpOutTimestampReps icmp24 Number of ICM P 11mestamp Reply messages sent

ltmpOutAddrMasks lcmp 25 Number ofiCMPAddress Mask Request messages rent

icmpOutAddrMaskReps icmp 26 Number of ICMP Address Mask Reply messages sent


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

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

Figurr -1.37. TCI' Grout>

Table 4.1 J. TCP Grout>


Entity OlD Description (Brief)

tq~RtoAigorlthm tcpl n meout algortthm for retransmission of octets


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

tc.pRtoMax tcp3 Maximum value for timeout in milliseconds retransmission

tc.pMaxConJl tcp4 Maxi mum number ofTCP conJlections

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

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

tcpAttem ptFalls tcp 7 Number of failed attempts to make connection

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


Tablt 4.13. TCP Grourl
Entity 010 Description (Brief)

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

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

tcpOutSegs tcp 11 Total number of segments sent excludl~ retransmission

tcpRetransSegs tcp 12 Total number of segments retransmitted

tcpConnTable tcp 13 TCO connection table

tcplnErrs tcp 14 Total number of segments received in error

tcpOutRsts tcp lS Numberofsegmentsentcontaining RSTflag

Agurt 4.38. T CP Conntclion Tobl<

tCI)ConnTable
(top 13)

Tablt 4.14. TCP C ~nntdion Tabl<


Entity 010 Description (Brief)

tcpConnTable tcpU TCO connection table

tcpconnEntry TcpConnTable 1 Information about a partlo:ularTCP connection

tcpConnState TcpConnEntry 1 Stille of the TCP connection

tcpConnlocaiAddress TcpConnEntry 2 !Dcai iP address

tcpConnloc:aiPort TcpConnEntry 3 !Deal port number


TAble 4. 14. TC P Connection Tobit

Entity OlD Description (Brief}

tcpConnRemAddress TcpConnEntry 4 Remote IP address

tcpConnRemPort TcpConnEntry 5 Remote port number

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

l'igu•·• 4.39. liDP Cruup

Table4.15. UDPGrnup
Entity OlD Description (Brief)

udplnDatagrams udp 1 Total number of damgramsnallvered to the users

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

udplnErrors udp3 Number of received datagrams with errors

udpOutDatagrams udp4 Total number of datagrams sent

udpTable udpS UDP listener table

udpEntry udpTable 1 Information about a particular connection or UDP listener


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

udplocaiAddress udpEntry 1 locaiiP address

udplocaiPort udpEntry 2 local UDP port

Summnry

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

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

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

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

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

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

Exe rcises

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

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


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

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

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

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


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

s. Encode IP Address 10.2030.40 In TLV formaL

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

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


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

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

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

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

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

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

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


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

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

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


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

Each branch has two types of produc1s whose irwen tory are

ha:t s
j a.o ket s

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

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

jacketsize \index )
j acket Quantity

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

a. Dmw a MIB subtree.


b. Write a MIS module.

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

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

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

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

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

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

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

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

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

5. SNMPv l Network Management: Communjcation and FunctionaJ


Models

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

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

5.1 . SNM P Com mun ication Model

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

5.1.1. SNM I> Arcbii~'Ciure

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

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

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

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

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

5..1.2. Adminlst nu ive Model

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

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

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

Figurt S.t. SNMP Community


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

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

Flaur e 5.2. SNMP Communlly Profile

=
SNW'Agent

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

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

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

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

flgur t S.J. SNMP Acct"' Polity

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

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

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

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

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

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

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

DalaPOU

Applcatoon POU

TI8!\SpOfl POU
Aflplieallon PDU

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

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

RFC1151 SNMP DEFINITIONS :• BEGIN

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

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

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

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

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

Requestld ::=
INTEGER

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

Errodndex : :
INTEGER

- variable bindings

VatBind :;=
SEQUENCE !
name ObjeclName
vatue ObjectSyntax

VarBfndUsl ::=
SEQUENCE OF
VatBind

Figurt ~ 8. Gel ond S tt Ty110 POlls

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

get-request [0]

get-next-request (lj

set-request [2]

get-response [3]

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

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

Fi~urt ~ .9. Trftt> PDll

T•blt S.t. Cmtri< T rops


Generic-Trap Type Desaiption (Brief)

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

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

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

llnkUp(3) One oft he links has come up

authentfcatfonFallure(4) Authet~tlcatlon failure

egpNelghborloss(S) loss of EGP neighbor

enterpriseSpedflc(6) Enterprise-specific trap

S..l A. SNMP Operations

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


Numerical Order lexkographlc Order

1 1

2 1118

3 115

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

Numerical Order lexicographic Order

15 15

22 2

34 22

115 250

126 2509

250 3

321 321

1118 34

2509 9

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

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


1

1.1

1.15

1.1.18

1.2

1.2.6

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

2.2

2.10

2.10.9

3.4

3.21

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

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

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


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

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

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

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

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


I.,.__.-

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

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

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

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

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


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

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

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


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

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


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

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

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

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


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

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


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

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

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


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

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


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

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

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

5.1.5. SNMP MlB G1·oup

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

Flgw·• 5.21. SNMP Grout>

Tabl• S.4. SNMP Group


Entity OlD Description (Brief)

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

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

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

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

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

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

snmp (7) Not used

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

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

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

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

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

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

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

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


(15)

snmplnGetNexts snmp Total numberofGet-Next PDUs accepted and processed


(16)

snmplnSetRequests snmp Total number ofSet-Request PDUs accepted and processed


(17)

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


(18)

snmplnTraps snmp Total numberofTrap PDUs accepted and processed


(19)

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


(20)

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

Entity OlD ~criptlon (Brief)

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

sn mp Not used
(23)

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

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


(25)

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


(26)

snmp0u1SetRequests snmp Total number of SNMP Set-Request POUs generated


(27)

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


(28)

snmpOutTraps snmp Tolal number of SNMP Trap POUs generated


(29)

snmpEnableAuthenTraps snmp Override option to generate aU1bentl<atlon failure traps


(30)

5.2 F un ctio n n l Model

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

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

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

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

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

The accounting function is not addressed by the SNMP model.

Summ;try

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

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

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

Ex.erci.~es

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

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

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

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

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

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

a. the get-reques1 PDU, and


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

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

a. !he get-request PDU, and


b. the get-response PDU

Objeet Value

Error Status Too big

Error lnc!ex udplnErrors

udplnDatagrams 500,000

udpNoPorts 1,000

udplnErrors 5000

udpOutDatagrams 300,000

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

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

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

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

lpNetToMedla lflndex lpNetToMedlaPhys Address lpNetToMedlaNet Address lpNetTo MedlaType


25 OOOOOC392084 192.68.252.15 4

16 OOOOOC3920AF 172.16.49.1 4

9 OOOOOC3920A6 172.1655.1 4

2 OOOOOC39209D 172.16.56.1 4

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

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


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

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

Versi on = 0
Communi t y ~ netma n

Object Value Units

Request 10 100

Error Status Too big udplnErrors too high

Error Index udplnErrors

sysUplime 1, 000,000 hundredths ofa seamd

udplnDatagrams 500,000 datagrams.

udpNoPortS 1,000 datagrams

udplnErrors 5000 datagrams

udpOutDatagrams 300,000 dataigrams

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

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


b. Get Response from lhe managed object to lhe manager.
6. SNMP Manageme nt: 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. Butt he "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 referred 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 l\igni:ficant eflilrt, due to lack of consensus, 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 the community 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 of the 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 of the lack of security enhancements, major improvements to the architecture have
been m~~de in SNMPv2. We will list some of the highlights that would motivate the reader!s interest in SN MPv2.

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 of Management 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, the decision was made to use the existing defined class types and apply restrictions to them.

Conformrince Statements help the customer objectively compare features of various products. It also 'keeps vendors
honest in claiming their product as being compatible with a given SNMP version. Compliance defines a minimum
set of capabilities. Additional capabiliiies may be offered as-options in the product by vendors.

Table Enbnnoements: Using a newly defined columnar object willi a Syntax c lause, 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 aggregate object.

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 of version I. There are changes 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 . SN Ml'v2 ln ltrtlfl 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 the subject of RFC 1906.

6.2. SNMPv2 System Architectu re

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
other at. 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 ~bn agtmtnt Arcbi!trturt

~~
l SNMP ~""'a001
l\;>pil<a1.""' } ~ "
·l SNM.P ..i.::tn11gor
AA>Ico""' }~ i l ~
.~ "~ ;a

~~ iHI !II!
,.l~ ! ~
" ~ !! f
.! dJ! !l
• 11
i t t
!~ !; ~ 'I
hl 4I H
~ ~
. ~
f 7 <fj!~ .:.~s
~ ~ ti
"§. i 0 1'. & - [i

~ .......
5/.Ml'

UOP
- 941.!?

UDP
POV 91"1'

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 receiving manager application responds with a response message. This set of
communication messages is a powerful enhancement in SNMPv2. since it makes l\VO network management
systems interoperable.

The message get-bulk-request is generllted by manager application. h is used to transfer large amounts of data from
the agent to the manager, especially If it includes retrieval of table data. The retreval is fas t 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 of the 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 of this is shown in Figure 6.3, in which an SNMPv2 agent riding over a connectionless OSI
tnmsport layer protocol, Co nncctionless-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

AF01J
-L """"'-
(
-""'
!mt.tP...._
J "P!>>ICOI...
r--r-

II f . 'I
! I{ 1I !i i- I i
ll lt 1 ~
l l
'
C>IUP SN.II' 1),jM.P
POIJ
,.._
\lOP Q.NS

IP
"'
Dt.C Dt.C

PHY PHY

Pan.,l..,o
CINSc-·llodoN-'SOrviOo
UOP U w < O . - - l
Dt.C; 01111 l"k CCtliiOI

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 SMI V2 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 of a module in Section 3.6.1. which is a group ofassigrunents that are related to each
other. Module definitions describe the semantics of an 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 Sectio n
4 .7 3 is used to define a managed object. OBJECT-1YPE conveys both synt;lx and semanti cs 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
of OBJECT IDENTIFIER. Even though we have two assignm ents in SMlvl , namely. o bjec t name and trap, they
are not fi>rmally structured. In SM1v2, llJI ASN. I macro, OBJECT-IDENTITY is introduced fi>r the assignment of
object name 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


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
<clauses> ·=<values>
ElllO
- names or objects
obfeotNomo .:• OBJECT IDENTIFIER
noliflmltionNamo : = OBJECT IOE!I.'TIFIER
- syntaJ or objects
<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 ::• { 0 0 ) -a value lor null tdenbfiors
END

6.3. 1. SMl Ocfinitwull for SNMPvZ


Figure 6.4 shows a skeleton of the 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 of macros.

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 SM h 12

6.3.2. lnfonnation Modu les

RFC 1902 defines information module as an ASN.I module defining infOrmation relating to network managemenl.
SMI describes how to use a subset of ASN.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 of managed 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 of the objects of vers·ion I and some new objects and object groups (to be
detmed later). It also bas information on conformaoce requirements. In the·examp le 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 oC ch •SNMP Grouf!lnrluding Conformance ~ nd Cornplianet in SNMPvZ MlB


SNMP\12-t.IIB OEFINm<>NS;,
BEGIN

~MIB MODULE IDENTITY · ~ {srrnpt,locjuVs 11

S!VJ1;1MI80bjecls OBJECT IOENTlFIER ::<" (snmpMIB I)

- ~SN.!Pgtoop
OBJECT ICENllFIE~ ::; (rrnh-2 1I}
OOJ:CT-TYPE • = (snmp 1}
OBJECT-TYPE ={...-.nr')

09.JECT lt::EN'llFIER "7" (SnmpmCObpelsCI)


OBJE<:T-lYPE ~( srmpSel 1)
- CQII-Iolotrnill!on
Sftfr4>MIBCorlOIII"atlCe
OB.ECT IOENTlFIER -,. {<n~MIB 2)
SM1)MIBCompf-
08JEC r IOENllf IE'! :~ (Sl\11\PPoii!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 sUiieiTIInllot SNW'\1 onbues wl!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'OUP ta111811d<1101y I« SNMP\12 •nlll,._ Wlltcll wppon
caniY\WIIIy.OOsed 81AOOI'IICOllon
·:• (!ll'mpt,IIBComDoWICfS 2)
- uri!$ <A corlCINI'OiliU
sn~roup OBJECT-<JROUP
"" {snmpt.ll11Gioupa8}
08JECT-GROUP ~ ("""!'~UB"-111
Cftii'4>CommunotyG<OUp
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. of an "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 of keywords used in the two versions. We will address the new keywords
fur specific applications as we discuss them. ft is worth noting here that some of the general keywords have been
replaced with llmited keywords. lllus, Counter is replaced by Couoter32, Gauge by Gauge32, and INTEGER by
lnteger32. The NetworkAddress is deleted from use and only I pAddress 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
Keyword SNMPvl SNMPv2

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-ACCESS 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
Keyword SNMPvl SNMPv2

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

Keyword SNMPvl SNMPv2

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 of the 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
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-
END

Figure 6.8 shows an example of a 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 or MODULE-IDENTITY Macro


lsiMIBModule MODULE-IDENTITY
LASI-UPOATEO '98021011002'
ORGANlZATION ·rnroTedi Services. Inc."
CONTACT-INFO 'Marn Sl.tlramantan
Tele: 770·111-1111
Fax. 770·1 1 H1222
ema3: m~n•s®bellsouth net •
OESCRJPTION 'Ve~ion 1.1 of the InfoTech Setv100S IMIB 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 cl ause 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 of three values: current, deprecated, or
obsolete. 'The value mandatory in SMJ vl 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. versio n, 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
TVPC NOTAT10H -
"STATUS" Status
"t!ESCRIPTION" Text
R.r.,rPott
VALUE NOTATION -.
value !VALUE OBJECT IOENTIFIER)
StaltJS .:= "current" 1"deprecated" ! "obsolete"
RolcrP0<1 :·• '1lEF£REIIICE'Toxt f empty
Text ::= -~lnng -

END

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 a c lass of router 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 mnd OB.ll!:cr-TYI'E Ma<t'O<

IS!Router OBJECT-IDENTITY
S'TATUS turftnt
OESCRIPl'lON 'An 8-ol<lt IF> tO<.Otor 10\ tho 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 up to
100 million 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 of object. 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 I 0.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 of managed objects when the number of columnar 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 10 Ilowing restrictions: (a) the number of conceptual 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 that of the fll'st table. This is shown in Figure 6.11.

Flgure 6.1 I. AugmentAtion ofTablrs

TotJel

I f1£.1 .CJ. I
I~
ITI.E1.C~2 II TLE1CU
I n.e1.C12 I~ I1U2.eu II T2.&C52

I TI£ 1.CU
II l t.£1 C1.J
II li.Ei.CU I~ I II
)ll2CJ, T2n.C53

IT1.£1.CI.•
II f t.E1C2..4
II T..ELC34
~~~lll'-CH I l=cs•
'""~: Cor~""*fU.(Q
FI'St ...Umnm objed ., T - 1 1. T1.HC11
2. Tl El CIZ
I 11!1 CU
4. f1.!1.C14

Table I is called the aggregate object table I 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 L\\0 tables. The row object for table I is table IEntry, 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 of the 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 of the 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 of the 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. 11te combinati:>n oft he
two tables still provides !bur conceptual rows, Tl.El.C 1.1 through T I.E I.C 1.4 (ideutified by the index), the same
number of rows as in the base wble.

Figure 6 .ll. ASN •.t Construe Is for Augmtnlallon ofTAblts


lablelEnlly 08JECT·TYPE
SYNTAX l (lbleT1 Enlry
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!IQIPl\1~1 row) In l;lliltt Tl"
AUGMENTS {lllblei EJltry)
: • {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 the augmented table. to a practical case, the ipAugAddrTable
could add t\\\:l more columnar objcc1S defining the board and pon number associated with the ipAdEntliTndex.

Flguro 6. 13. Exan11>1< of A ug n~<nt•llon of Toblt s

ipAII<IfTible OBJECT·TYFE
SYNTAX SEOUEI'CE OF lpl\ddtEntrf
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 'The addi8SSing ln'oonallorf
INJEll {lpMEJlWl<llj
::= OoAdd<Table 1)
lj)Ao.gAddrTa!>!e 08JECT·lYPE
SYNTAX SEQUENCE 01' l~..nlly
MAX·ACCESS ool~c
STATUS CUfrEnl
OESCRIP110N 'Theaugonenl!d ll!ble b fP Addti!SS Table c!er111ng

-=ftpAug 1}
- ..no~,.,., """"'""'
lj)Ao.gAddrErtry OBJECT·TYPE
SYNTAX I!)AU'JAMtEnl!y
MAX-ACCESS nol·acx:ei!S>ble
SrAl\JS CUtr4;f11
DESCRIPTION 'Th<t~ orlormobon... '
AUGr.£NTS (lpAddtE"try}
" : (lpAuol\dc!fTallle I)
A table 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 o bjects, 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.o dex. The combined index fOr spec ifYing the aggregate object of Table 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
dependentiableco uld have a maximum of8 conceptual rows ( muHipUcation oft he rows of the two tables).

FlgW't 6.t-l. Combined Indu ing ofTa bits

ToO>o 1

1 1 U I .CU

~~~IIA»ir~

.....
Fbi etli.lmnatobt«Ji:ts In fat.1011 an:f2
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'2aC4 c
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 indices of both tables, namely T I.E I.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 Table1 i:111ty
MAX-ACCESS not-acoossible
STATUS currem
DESCRIPTION "1\n 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 undet r
: =(table 2}
lllble2Entry OBJECT-TYPE
SYNTAX Tu!Jiu2Eulry
MAX-ACCESS not-oaoosslblo
STATUS CtJrrent
OE3CRIPTION 1\11 1110t1y (WIICCpiulOI I<>W) lh Tllbko 2'
INDEX (TLE1.C1. T2.E2.C4!
:• (lr.llle21}

We can visualize the application of augmentation of a dense table with an example of a router with multiple slots,
each slot con1ainlng a particular type of board, 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 with a given port in a given slot.

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
II fiEIC22
II n !1.<:32

, T1,tt.C13
II II.EtC21
II rt!tC"
1~1 !1E7C31
II 1'U2CU

'"F""
""' "''""'"'" oO,od ~­
.Till Cit
In To~• t
ll!EICU
)T1EIC11
~. TlEI.Ct,~

Flgur• 6.17. ASN.I Conslrurts for Augwtuting Sparst Toblo


l
lllblg1 OBJECT-TYPE
SYNTAX SEQUENCE OF table1Ertty
MAX•ACCESS nct·accessible
STATUS curtenl
DESCRIPTION "Table 1 under T
::= {table 1)
WlllelEnll'f OBJECT·TYPE
SYNTAX TEbie 1Entry
MAX-ACCESS not-accessible
STAi\iS currem
DESCRIPTION •Art entry (conoeptuot rOW)1n Tal:>le 1'
INDEX {T1.E1 1)
" . (l<lble 1 1)

toble2 OBJEC'T TYPE


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 (conoeplual row) •n Table 2'
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 designing MIB modul.es. We will return to row creation and delet ion in Section 63.7.

6.3. 6. Te~1ual Conventions

Textual conventions are desigood to help definition of new 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 li miled 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

DiBplayS tring :: • OCTET .STRING


-- 'l'hb da ta t ype l.s used r.o 111odel t exto<1l lnforma d.on tak.en !rom t he NVT
ASCII charac t er set. By convention, ob j ect s with this s yn tax are
declared a s 1\a.v inq
SIZE /0 •• 255) .

The same example o fDisplayStriog in SNMPY2 is defined as:

DisplaySt r .ing : : • TEXTIJAL-<:ONVENTION


DIS PLAY- HINT " 255a ''
STATUS current
DESCRl ~ ICN "Represents t extual informatio n taken from tile· NVTASCII charac t er
set, as defined in pages o, 10- 11 of RFC 854 ..••. •
SYNTAX OCTET STRING (SIZE (0 •• 255 ) )

As we can see from the above example, the TEXTIJAL-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 of it is presented in Figure 6.18. It has the definition of type aod value notal' ions w ilh the
furmalized definition ofdam typeJ>.

Fll(ure6.18. TEXTIJAL-CONVENTION Motl'o)RFC 1.903)

TEXTIJAL.CONVENllONtAACRO -•
8EGIN
TYPE NOTATDN _;
o.spayP<llt
"STATUS" Slalus
1:1£SCRPTION" TO:ld
R4t.~Pan
'SYIITAX' S)ni3X
VALUE NOTATION .•
vlllua (VALUE Syn>.a•}
O:sptayPan ,.. 't>lSPU.Y·HNr Text I empty
Sla~s ::; 'W'Jent'l'doprea!BII'I'ollsolele'
END

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 of an object, with the syntax defined using this tel\'ttlal convention, might be displayed. It is applicable to
U1e situations where 1he 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 of 1234 with DISPLAY-ffiNT "d-2" is displayed as 12.34.

For OCTET-STRING lype, the display hint consists of one or more octet-follllllt specifiCations. A brief description
of each 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 One or more decimal digits spedfying the number of octets

3 Display fOrmat "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
chara.c:ter Octet specification.

5 (Optional) repeat terminator A single character other than a decimal digit or • • • present If display character is present
cnarac:ter Produced after the second and \lllrd part.

Table 6.3 shows the types IDr which textual conventions were specified in SMJv2. A brief description 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 of conceptual rows, which we will discuss next.

Tablr 6.3. S Ml v2 Tutu•t Con.-rntimu for lnitiot 1>atu TYI>es


OisplayStr ing Textual Information from NVT ASCII character set [RFC 854)

PbysAddress Media- or physlca~l evel address

MacAddress IEEE 802 MAC address

TruthValue Boolean value; INTEGER (true (1), false (2))

TestAndi ncr Integer-valued Information used for atomic operations

AutonomousType An lndepender>tlv extensible type identification value

VarlablePolnter Pointer to a specific object instance; 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 the status column of a conceptual row

TimeStamp Value of sysUpnme at which a specific occurrence happened

nmelnterval Period of time, measured In units ofO.Ol seconds

Oateandnme Date-time specifications


Tablt 6.J. SMJVl Ttxl,..l Convtnlions for lnillol D••• Typts
DlsplayString Textual information from NVT ASCII ch;Jracter set (RFC 854]

StorageType Implementation information on the memory reaUzatlon of a conceptual row as to the volatillty and
permanency

Tdomaln Kind of transportservice

Tad dress Transport service address

6.3.7. C reation aml l>eletion of Rows in Table,,

The creation of a row and deletion of a 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 methods to create a row
in a table. The first 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 of the 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 of a conceptual 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 exists and Is operational

notlnService 2 Operation on the rO'II Is suspende<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 Entry Status. 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. If a 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 of read-only and not-a.ccessible. If an index obje<:t of a 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 of the status of the row as
indicated by the enumerated integer syntax ofRowSmtus textual convention. The second columnar object, index, is
the index fur the conceptua I row of entry I; and the third columnar object contains non-indexed. data. We wi.ll
illustrate the cwo types of row-creation and row-deletion operations by adding a third row and then deleting it

flguro 6. 19. Con<tpiual Tab!< for I he Cr ellllon and Oeltllon or. Row

status.2
II lndelC.2
II data 2

StaiUS 3
II oOCIO)x.J
II dalil3

Row to De aeatecl!l:leletecl

As we not~e from Table 6.4, there are t\\Q 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 a message 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 a conceptual row wilh the values given for the three columnar instances of the row. The value for the index
column is spec Wed by the V arBind 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. ~
dMa3 = l)ltrtlpti l
a..""""'
4--- 1- 3 • 1.
..ndflA.J-=-3,
--------y
=
::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 of adding 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.2 I. Cru t..aud-Walt Row Crrallou


R..--
.....---l staiJS.3 • 3;
nii!J..3;l)

r-------_ GotR..,uest
(c:a!a.3) -

t------Se\R&Quo$1
(4111lJ.l~l:letD;r.t)--

Rosponse
1'-faM 'lt2
d4L1-J= O!:!DD I

5eUieQUetl
( 51D.!Jt.3. 1, _
Re.spons4
lllllao.l- I)

A summary of possible 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 to the agent.


2. If other variable bindings included in the same PDU provide value-s for aJ I columns, which are missing but
are required, then return noError and goto D.
3. If other 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 of the 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
inconsistent Value: if tbe supplied value is inconsistent with the state of some other MlB object's value, or
noError; because the agent chooses to create the instance.

lfnoError is returned, then the instance of the 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 oft he set request may result in a response other than noError being rerumed, e.g,,
wrongValue, ooCreation, etc.
Tablt 6.5. Tablt of St Ai r~ fur Row Crt>~ lion And Ddttlon

Action A Status column does 8 Status column C Status column 0 Status column
not exist notReady notlnServlce active

Set status column to noError -> 0 Inconsistent-Value lnconsls~nt-Val ue Inconsistent-Value


createAndGo

Set status column to noError, see 1 or inconsistent-Vallle inconsistent-Val lie Inconsistent-Value


createAndWal t wrongValue·

Set status column to act.i lle Inconsistent-Value Inconsistent-Value or noError ·>O noError ·>0
see 2 ·>0

Set status column to Inconsistent-Value Inconsistent-Value or noError ·>C noError .>( or


notlnServlce see3 ·>C w rongValue

Set status column to noError->A noError->A noError->A noError - >A


destroy

Set anv other column to see 4 noErrorsee 1 noError ->C seeS - >0
some value

The operation of deletion of a row is simple. A set-request with a value of6, which denotes destroy, for status, is
sent by the maDager process to the agent process. independent ofthe current state of the 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

Managed
&ltity

--------set
( $181US.3 '6 l
Request

Oiliel! lni!Utnce

P<M'"" _________
fl .. _ 1n$A>e Oelelad
1
- 1 slatus.3 • 6)

6.3.8. Notification Definitions

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 or NOTIFICATION-TYPE ~1o<ro

~nkUp NOTIFlCATlON-TYPE
OBJECTS fdlndelc)
STATUS c;un-ent
DESCRIPTION
•Afiii\Up 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 CUll IIIII
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 of these, which also discusses the conversion
of a 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. U specifies 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 of defining 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 of an object in an agent implieJ> that it execlfles the get and set operations from a
manager. Lf an agent in SNMPv2 has no! implemented an object, it returns a noSuchObject error message.
Fi~urt 6 .24. OB JECT -GROUP Matru

OB.JECT·GROUP NACRO
BEGIN
TYPE I'DTAnON ~~
OotoctsPan
'STAl\JS" Status
"tlC:SCRIF>TION' Ta•t
Rll!erf'olft

VALUE NOTATION . •
v;tlt.IO tvAWE OBJECT IDENTIFIER)

Objo<:bl'~trt :;- ·oGJC:CTS" ·rcbJcaa1·


ObjeCis : Oojed 1Objoc:ts •• • Object
Objee~ ·~ valuo tName Objed Name)
StDM> - •........,nt•l "d<>p,.,cotod' l•oboototc•
Re!erf'an == •REfEREl'ICE"TelCl I empty

- u~ l'lfl NIIT ASCII r.hilmc:lfil'!alt


Text "" - Slr.ng-
END

The OBJECTS c.lause names each 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 of adding 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 examp le 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-C ROUP ~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 "ThO SY$tern orouo delnosobloels thai are common
to all man&!)~!!! systems •
,• (anmpMiBOroupa 0)
Notific ation 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 {VALUE OBJECT IDEIHIFiERl

NObfocatlonsPilrt . ., "NOTIFICAliONS' "rNo~licatloruT


NOhiiCiiUCns ; ,. NctfiCaiO!I I NO~~CIIllOI'IS ·; NOUrCIIPon
Nollfk:allcn •·• ~mit I' (Nnm• NotlfK:.11101'1NtJrllll)

StaiUS ~,. ·currenr l"depfQCilte<f 1"GtlsO"ete"


Relf:lrPMI ,. "RFFERENCE'" Tutl ~mply

- uses lllB NV I ASCII C71Gractor Sill


To<t ~= - - · atrtng -

END

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
authenticationF ai lure.
Figure 6.27. Eumplt oh NOTIA CAT!Of\1-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
requ red lO ll'q)le.'llellt..
" : !snrrpM!BGroups 7}

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-COi\dPUANCE
macro L~ done during lhe implemenmtion a·nd not during run-time. The MODULE-COMPUANCE macro can be
defined as a.component of tbe 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 NOTI\110 N •
voluo (VALUE OBJECT IDENTIFIER)
"CU"tont') "dop!OQ!tod' 1"ObiiOIOIO'
~ckld'tu1 :·~ -nercntNCE" Teod 1omoty
l.lodUioPo1 "• Medulot Iompty
MOOutot..,. Medulo I MOCIUIOt MOOJie
Modulo .• • nnmaof medule -
"MODUlE ModuiONomo
Mllt!dowtyPort
Ccrnplton..,P.n
MOOuloNwno -. mCCJuloiHoiOIIIIICO MOU.IIOIOI!Inllllll I..,IPIY
- ntusl Ml be empty unli!SJ oartaln..:l rn IAIB modu'o
MoGul<ldontltlor ·" voluu (1.1oduto10 OBJECT IOEI'ITifiER)tumpiY
\l""oo~Pon .,. MI\NOATORV G~OUOS' T Gtoup.1'
I OIIIPty
Ou>tJ~».. OtUUIII Ot"'4'll ' O<wp
Group :• vD~Jo (OIO<lp OB..ECT IDEUT1Fl!!R)
Com~IIMcaPM .:• Co'np41J!nOCIII Of11)1y
C<>l'l1>11~n«'• ... C<mpllnnM 1Cn"'l)ll""""' c:nmnltnnoo
Compllonco • CcrnpltonooGroup 1O~otl
Co«~vll..,.,.a."'"' • 'GROUP" voluo (lion'" OO.CCT I[ICNTirtcn)
'DESCRIPTION" Te•t
Objotl :.• 'OBJEcr -.luo (N~m• Ol>j8CJIN>ITiej
SyntmxPM
WniOSfllrotPnt1
Aoc01111Pa11
' DESCRIPTION" Text
...,.""._1bee fwfha1 ttunt kit ol.l)ol.l'• SYNTAX c:laYM
SynuxPart ::• "SVNTIIX' typo (5YN'fi\Xl1 ompty
- roo II be a ratl<lomontt..- objtc:U SYNINC ol~uw
W<ttoS)'nt•l<PM ~ ·wRtTE·SVNTIIX' IYPfl (VI'nt~NTAXII empty
Accfl&PM ::~ ' MIN-ACCESS" A:c<IH I empty
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 chotOCIOr 3Cl
Tm ··;-r;trlng-
END

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 group specified by the GROUP clause is not mandarory
lOr the MID module, but helps vendors define specifications of the 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 of RFC 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 of the macro are covered here and.are shown in
Figure6.29.

Figur e 6.29. AGENT- CAPABlUTTES M•rro (Skrlrton)

AGENT CAPABILITIES
BEGIN
TYPE NOTATION :::
'PRODUCT-RELEASE:" Text
'STATUS• Status
'DESCRIPllON" Test
ReferPart
MooulePart

VALUE NOTATION ::=


Value (VALUE OBJECT IDENllFIER)

Status ..,. ·currenr l'obsdete•


ReferP.art ::: 'REFERENCE" I empty
ModulePart ::• Modules J-cmp!y
Modules ::: IAO<llle I Modules Wodl.te
Module ;::: - name of module -
'SUPPORT ModlJleNomo
'INCLUDES" "{"GroupsT
Vari<ltlonsPart

ENO

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)
VARt1\T ION coldStart
DESCRIPTION "A <X!!dSiiln trap Js genera teo on au
1ebllots.·
SUPPORTS lF-MlB
INCLUDES ~rGeneraiGroup. IIPac!<etGroup}
SUPPORTS IPMIB
INCLUDES jlpGroup, icmpGroup)
SUPPORTS TCP·MIB
INCLUDES ~Cr>G<OiJP}
SUPPORTS UDP·MIB
INCLUDES {UdpGroup}
SUPPORTS EGP-MIB
INCLUDES {egpGroup}
•• = I lstRouter 1 )

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 other than 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 of now.

There are changes made to the core MIB-ll defined in SNMPv I. 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}. T here
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 coma ins a collection of objects 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 of objects
in r.he System group. Table 6.6 presents tbe entky, OlD, and a briefdeseriplion of each entity lilrtbe System group.

Figurr 6.32. SNM.Pvl SySicm Group


Tnblc 6.6. SNMPv2 System Crou1>
Entity OlD Description (Brief)

sysDescr system 1 Textual description

sysObjectiD system 2 OBJECTIDENTIFIER of the entity

sysUpnme system 3 Time (In hundrecttbs of a second sJnc:e la.st reset)

sysContact system 4 Contact person for the node

sysName sy~tem 5 Administrative name ofthe syste m

syslocatlon 'System 6 Physical location of the node

sysServices system 7 Value designating the layer services provided by the entity

sysORLastChange system 8 Sy$Upllme since last change In state or sysORID change

sysORTable system 9 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 of the resource module


2

sysORDescr sysOREntry Textual description of the resource module


3

sysORUpTime $VsOREntry System up·tlme since the object In this row was last instantiated
4

6.4.2. Clt ungcs 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 s implified SNMP group is shown in Figure 6.33 (oompnre with
Figure 5.21 !). It has only eight entities, s iK old ones (I ,3,4,5.6.,30) and two new ones (31,32). Figure 6.33 also
presems the four groups of all SNMP cotites: snmpGroup, sompCommunit)'Clroup, snmpObsoleteGroup, and the
group of two 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·lgur t.6.33. SNMPv2 SNM P Crour>

SNMP Group Ob.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. SNMP\12 SNMPGroup


Entity 010 Description (Brief)

snmplnPkts snmp Total number of messages deli vered from transportservloo


(1)

snmplnBadVerslons ~nmp Total number of messages from transport servrce that are of unsupported version
(3)

snmplnBadCommunltyNames snmp Total number of messages from transportservlc,e that are of unknown community
(4) name

snmplnBadCommunltyUses snmp Total number of messages from transport service, of not allowed operation by the
(5) sending community

snmplnASNParseErrs snmp Total number of ASN .1 and BER errors


(6)

snmpEnableAulhenTraps snmp Override optfon to generate authentication failure traps


(30)

snmpSilentDrops snmp Total number of the five types of received PO Us that were sflently dropped due to
(31) exceptions In var-blnds or max. message size

snmpProxyOrops snmp Total number of lhe five types of received POUs !hat were srlently dropped due to
(32) Inability to respond to a target proxy

(~4 .3. lnf'onnntion for Notification in SNM I'v2

fnformation o n 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 brief description of the subnodes and
leaf objects under smnpMIBObjects is given in Table 6.8.

Figur• 6.34. MIB Modulu undtr snmpMIOObjtCI$


~
~

'"'kDotm(l)

Tal>l • 6.8. Jlllllt>MlBObj«ls l\118

Entity 010 Description (Brief)

snmpTrap snmpMIBObjects 4 Information group containing trap 10 and enterprise 10

snmpTrapOID snmpTrap 1 OBJECT IDENTIFIER of the notification

snmpTrapEnterprlse snmpTrap 2 OBJECT IDENTIFIER of the enterprise sending the notlftcatloJl

snmpTraps snmpMIBObjects 5 Collection of well -known traps usecllnSNMPYl

coldS tart snmpTraps 1 Trap Informing of a cold start of the object

warmS tart SJlmpTraps 2 Trap Informing of a warm start of the object

linkDown snmpTraps 3 Agent detecting a fail ure of a communication link

linkUp snmpTraps4 Agent detecting coming up of a communication link

authentilicationFailure snmpTraps 5 Agent reporting receipt of an unauthenticated protocol message

snmpSet snmpMIBObjects 6 Manager-to-Manager notification m essaees

SJlm pSetSeriaiNo snmpSetl Advisory lock between managers to coordinate set operation

Tbe snmpTmp group contnins inmrmation on the OBJECT IDENTIFIERs of tbe trap and tbe e nte.rprise
respon~ible to send the trap. A new value, accessible-mr-notifY, has been added to the MAX-ACC ESS c.lause to
define objects under snmpTrap.
The entities under snmpTraps are the well-known traps that are currently in extensive use in SNMPv I. 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. C onformnnn• fufornmtion in SN MPvZ

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 of conformance are defined in terms of0.BJ£CT-GROUPS, mentioned
in Section 6.3.9. Tab le 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 under snmr>MlBConronnanct

Tabl<6.9. SNMl'•'l OBJECf-GROUPs


OBJECT-GROUPs 010 OBJECTS

snmpSetGroup snmpMIBGroups 5 snm pSetSerfaiNo

systemGroup snmpMIBGroups 6 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 techno logy, 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 that we will be addressing in this textbook. Table 6.10 gives a description of each group in the MIB.

Figurr 6.36. Expandtd lolrrotl Mffi·U Group


~
~
I

'rabl t 6.10. E:q>and•d ~118- 11 G•·onp

Group OlD Description (Brief)

ifMIB mib-2 Extension to interf~ces group for new t~hnologies


31

appietaik mlb-2 MIB for appletaik networks


13

ospf mib-2 Open Shortest Path First routing protocol MIB


14

bgp mlb-2 MIB for Border Gateway Protocol for Inter-autonomous networl< routing
lS

rmon mlb-2 MIB for remote monitoring using RMON probe; theA! are MIBs under this for Ethernet and Token Ring
16 networks

bridge mib-2 MIBfor bridges


17

decnet mlb-2 Digital Equipment Corporation DECnet MIB


18
TAble 6.10. Exr>audtd MIB-U Grourl
Group OlD Description (Brief)

character mlb-2 MIB for ports with character stream output for computer peripheral
19

6.5. SNMI>v2 l'rotoco l

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 PO Us

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 s hown 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 either set 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 type oferror 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'P\12 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 Flr kls in SN~1PVl PDU
Field Type Value

7 SN MPv2· Trap·PDU

Error Status 0 noError

1 IOOBig

2 noSu<hName

3 badValue

4 readOnly

5 genErr

6 noAccess

7 wrongType

8 wrong length

9 wrongEncoding

10 wrong\lalue

11 noCreatlon

12 lnconsistentValue

13 resourceUnavarlable

14 commitfailed

15 undoFailed

16 author! zationError

17 no!Writable

18 lnconslsteniName

There is a difference in usage of the 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 erro r-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. If both the error-sunus field and the error-iodexfiekl of the
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 of the 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 of both
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 of get-next request and retrieves daia in bulk efficienUy. This is covered in the next subsection. The
lnfonnRequest is covered 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 bas ic 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 (sca lar) objects to be retrieved The max-repetitions field defmes the maximum number
of instances to be returned in the response message. This would correspond to the number of rows 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 of get-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 of get-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

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£: t U l £ 3 ) - - - --

Tf~~\~~~-- __..
t!U.~'..!J.l,.Tt. .U
I .::.
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 f the 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 of the 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-Rtq urst funltll<


lt~•l~',)',~~~~:~~~.,
~~·~lltn .. ••t·~·~
--~..-t'!.....-....-n,w•o..;,.~,,mo~· •
~------ O..l6u•~• ~lt,J
•u1AJ..r""'
~l! l tl'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 variable bindinw; in positions I and 2 are specified as sysUpTime 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. If the macro conmins an OBJECTS c41use, then the
objects defined by the c lause 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 "n OBJECTS 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 10 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 Bilin guAl M•nagtr

Btlingual M anogcr

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.

Figure 6.-16. SNMPvl ProJ<y Strvtr Configuration

$ NMPv2 M RnAQ!i!r

Proxy
Sgrvor

(
SNMPv1
) - SNM?v2

- Agents (
-~
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 values and then passed on to the SNMPv2 manager as SNMPv2-Trap PDU.

f!lgur• 6.4'7. SN MP vl-vt l'roxy S.n-.r

P,q Ttt"''l'!

~Nnf• ...,...oao -----


1 mA~~·~WON•O

]. ~~"=,.,.?"".:'.o.=:"""'"'....="'----1
r, ~.·lfoM ,f\f'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 of network management systems a.nd agents that are on the market today use SNMP version
I, rererred to as SNMPvl. However, some of the fet~tures that have been added to SNMPvl have been formally
def111ed in SNMPv2 We have learned enhancements in SNMPv2 over that of SNMPv 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 of modules 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 of related 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 additiona l groups
beyond that of mandatory ones.
Two new modules have been added to the lnternet module. They are securily and snmpV2. The securilymodule is,
as of now, 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 obso lete 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 of get-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. Define the OBJECT-IDENTITY module for the following objects mentioned in Exercise 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
card 1. The last two addresses refer to ports 1 and 2 of interface card 2.

a Draw a conceptual bnse mble and an augmented tabJe.(ipAug I).


b. Present the ASN.I constructs for both down to the leaf level o ft he MIB tree. Limit your leaf for
ipTable to ipAdEntAddr object.

4. Table 6.12 snows tile output of a network management 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>rtual conventions.

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 packets to 150.50.53.1 and 150.50.54.1 are connected to port 2.
The second table Is the dependent table, lpDepTabie (ipDep 1).

a. Draw a conneptual base table and a dependent table.


b. Preseni lhe ASN.I constructs for boih down lo ihe leaf level of the 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 of their equipment In the <ll!ent system
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:

Bran chiD (corp 100)

Table name lnvTable

Row name lnvEntry

Columnar object 1 lnVStaws

Columnar object 2 lnvNumber (index)

Columnar object 3 make

Colum.n ar object 4 model

Columnar object 5 serNumber

a. Draw the inventory conceptual table.


b. Write the detailed ASN.l constructs for I be table.
7. In Exercise6, the foll owing equipment is to be added as the lOOth inventory number:

make Sun

model UltraS

serNumber 512345

a. Add lhe conceptual row t o 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 del ete 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 tabl e 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 Physical Addres$

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:.3 S:O:D8

1 172.46.252.1 OO:OO:Oc:3S:Cl:DO

11. Fill in the values for the SNMPv2 Trap PDU shown In Figure 6.43 for a message sent by the hub shown In Figure
4.2(a) one second after it is reset following a failure. (You may want to compare the resul t with that of Exercise 3
In Chapter 5 for SNMPvl.)

7. SNMP Management: SNMPv3

Objectives
SNMPv3 reatures
o Documentation architecture
o Formalized SNMP architecture
o Security
SNM P engine ID and name for network entity
SNMPv 3 applications and primitives
SNMP architecture
o Integrates the three SNMP versions
o Message-processing module
o Dispatcher module
o Future enll!lncement capability
User security mode~ USM
o Derived from user ID 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 of subtrees in MlB views
o VACM process

SNMP>/2 was released after much rontroversy, as a community-based SNMP fi'nlnework, SNMPv2C, wiihout any
enhancement to security. SNMPvJ was subsequent ly 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 Architecture for Describing SNMP Management Frameworks

RFC 3412 Message Processing and Dispatching for SN MP


TRble7.1. SN~1P\'3 RFC.•
RFC 3410 Introduction and Applicability Statements (not STO)

RFC 3413 SNMPv3 Applications

RFC 3414 User-based Security Model (USM) for SNMPv3

RFC 3415 vr ew-based Access Control Model for SN MP

RFC 3416 Version 2 of the Protocol Operations for SN MP

RFC 3417 Transport Mappi ogs for 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 fOr describing the major portions of SNMP 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 of maoogement 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 obso letes RFC 1907 MIB fOr SNMPv2.

.RFC 3 584 describes tbe coex.islence of SNMPv3, SNMPv2, nod SNMPv 1. Lt also describes how to convert MIB
modules from SMlv 1 format to SMl v2 format
7.1. SNM.Pv3 Key Fea tu res

One of the key features of SNMPv3 is tbe modularization of archJtccture and documentation. The design of the
arcbilecture integrated SNMPv I 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 of messages.

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 Docu meot11Cioo Architccl u re

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 of the specifications, but it is another perllpeclive of what is given in RFC [3410].11
can be oorrelaied with what we presented in Figure 4.4. Two sets of documents are of general nature. One of them
is the set of documents on road map, applicability statement, and coexistence and transition.

Agurt 7.t . SNMP Documtnlation (R<'<unllntndtd in SNMPv3)


Tbe otber set of documents, SNMP frameworks, comprises tbe three versions of SNMP. An SNMP framework
represents the integration of a set of subsySiems and models. A model describes a specific design of a subsystem.
The implementation of an 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 cxpl icilly 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 Struci\Jre 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 moni1or 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 of an 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. SN MPvJ 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 of octet 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<'-A irt


(~!hOOa tJ

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 of the method. For a simple entity, it could be just tbe lP address of the entity.

The fifth octet oftl-.e SNMPv3 engine ID indicateJI the fonn~~t used in the re~t of the 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 MAC address (6 octets) lowest IEEE MAC address, canonical order

4 Text, administratively assigned

Maximum remaining l ength 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 remote entity.

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 of the message processor. I fa 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 of an 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 of authemication 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.
1
7.3.2. 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 net work
operations center. It is made non-accessible. It is hidden and is based on !he security 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 of the hub.
The agent would have an snmpEngineiD and each interfuce card would have a 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 of primitives 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 cal ling 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 o nly 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.s uh of the request in terms ofstatuslnformation or result, as shown in Figure 7.4(a). Because
ofthe-execution of primitiveAB, 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
1
IIO'IIfi...C:I
- Olagllldl<lr I l

t -
M\$.Jtlef
-1111>11

s..-
"'"' "lbl'""'"•<ts-b;
"" ~u...t.... tu-....dS'Uu

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 of the 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 of sendPduHandle
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 of simplicity.

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 the se.rvice provided and the user of service.

T ablt 7.3. Lisl of Prirnilivts

Module Primitive Service Provided

Olspa~her senciPdu Processes request from applicatiOn to send a POU to a remote entity

Dispatcher processPdu Processes Incoming message from a remote entity

Dispatcher returnResponsePdu Processes reque.stfrom application to send a response PDU

Dfspa~her processResponsePdo Processes Incoming response from a remote entity

Dispatcher reglsterContextE~IneiD Registers request from a context engine

Dlspa~her unregisterContextEngineiD Unregisters request from a context engine

Message Processing prepareOutgoingMessage Processes request from dispatcher to prepare outgoing message to a
Model remote entity

Message Processing prepareResponseMessage Processes request from dispatcher to prepare outgoing response to a
Model remote entity

Message Processing prepareDataSements Processes request from dispatcher to extract data elements from an
Model lncoml~ message from 'il remote entity

Security Model generateRequestMsg Processes request from message processing model to generate a request
message

Security Model processlncomlngMsg Processes request from message processing model to process security
data In an Incoming message

Security Model ger\erateRespOnseMsg 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 Servl ce Provided

message

Intra-Security Model autnenticatelncomJngMSj! Processes request for authentication scrvlce'to Incorn'lng message

Intra-Security Model encryptData Processes request from security modeI to privacy service to encrypt data

Intra-Security Model decrypt Data Processes request for privacy service to decrypt an Incoming message

Access Control lsAccessAII owed Processes request from application to access and autttorlze service
Model requested

7.4. SNMPv3Applicarions

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 respo nse 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 ou\going
message. The dispatcher also sends a sendPduHandle to the command generator to tmck the request. The details o.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 pam meters. 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 rel\lrned 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 protooo l (UDP) to 'be £mnsmitted
to the agent. The command generstor receives the response from the dispatcher (async lU'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 one that \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 the appropriate action of get or set o n 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 half processes run on two remotc objeds, the top and bottom of Figure
7.6 belong lo 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

Sl!<Jully
Commend Moclol
Respo,der Olspl!cner

ropotoRcsp nooMGg
umRotpomo.Pda

Dl!iP31cher M ene~o
l'roces!lng
Model

Before lhe get-request could be procesSed by the command-responder application, lhe conteld that i!Je SNMP
eogine is responsible for must regist·e r 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 dispatcher in the SN MP 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~ contel\1 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 Originato r·

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 of the 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.a tion 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.set messages.

7.4.5. l' roxy Fonv!u·der

The proxy fOrwarder application performs 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 application tbat 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 of messages: 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. SNM l'v3 Manage me.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.

Flgu r• 7.7. SNI\IPvJ M1B


There are three groups defined under snmpModules for applications. They nrc snmpTargetMJB (node 12),
s nmpNotificationMIB (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 of specillc 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. Torgtt Add rrs' oud Torgtt P•r•mrtrrTnblu

snmpTargetMIB
{srmpModules 12}

snmpTargetObjects
(1)

snmpTargetAddrTable snmpTargetParamsTable
(2) (3)

Tahir 7.4. SNMP TArgtl Add ress T•blt


Entity OlD Description (Brief)

snmpTargetAddrTable snmpTarge!ObjedS 2 Table of transport addresses

snmpTargetAddrEntry ~nmpTargetAddrTable Row In fhe target acldress table


1

snmpTargetAddrName snmpTargetAcldrEntry loe<~llyadmlnlst.ered name assodated wlththls entry


TRble1-'· SN~1P Targot Address Tobk
Entity OlD Description (Brief)

snrnpTargetAddrTOomafn sompTargetAddrEntry Transport type of 1he addn~sses


2

snmpTargetAddrTAddress snmpTargetAddrEntry Transport address


3

snmpTargetAddrllmeOut snmpTargetAddrEntry Reflects the expected maximum ~oun<Hrlp time


4

snmpTargetAddrRetryCount snmpTargetAddrEntry Number of retries


5

snmpTargetAddrTagllst snmpTargetAddrEntry list of tag value~ used to select the target addresses for a particular
6 operation

snmpTargetAddrPararns snmpTargetAddrEntry Value that Identifies an entry In the snmpTargetPararY)S Table


7

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. T be lead into I his labte is by
using the columnar object snmpT argetAddrPanuns 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 Paramtltrs Tablt


Entity OlD Desalptlon (Brief)

snrnpTargetParamsTable snmpTargetOb)ects 3 Table of SNMP target lnfonniitlon to be used

snmpTargetParamsEntry snmpTargetParamsTable 1 A set of SNMP target rnformation

snmpTargetParamsName snmpTargetParamsEntry 1 locally administered name associated with this entry

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!<
Entity OlD Description (Brief)

snmpTargetParamsSewrityName snmpTargetParamsEntry 4 Security name of the principal

snmpTargetParam~Securrtylevel snmpTargetParamsEntry 5 level of security

snmpTargetParamsStorageTvpe snmpTargetParamsEntry 6 Storage type for the row

snmpTargetParamsROWStatus snm pTargetParamsEntry 7 Status of the 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 eolumnar objeclS inLbe group.

flgu r t 7.9. SN~1P Notili .. tion Tablr•

Tablr 7.6. SNMP Notirocation Tablr


Entity OlD Description (Brief)

snmpNotlfvTable snmpNotlfvObjects 1 Ust of targets and notifi,ation types

snmpNotlfyEntry snmpNotifyTable 1 Set of management targets and the type 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
Entity OlD Description (Brief)

snmpNotlfyType snmpNotlfyEntry 3 Selects trap or inform to send

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 are defined 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 oft be main objectives, if not the main objective, in developing SNMPv3 is the addition of secnrity 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 anror
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. Secu ri ty 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 can just be tapped and not intercepted.

Flgur• 7. t0. S.CurltyThrealS tol\boag<m<oi Jufonnatioo


ModifiCOIM ol lnfmmtion
Maflql!lltade
M(assagt! Stroam MDdincaliOn

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 of an 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 mali ciously reorder the data packets to c.hange the meaning ofihe message. For
example, tbe sequence of dalll 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 of seq..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/I P dump 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 of t he 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 protecting against 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 outgoing message 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~uri ty Servi«J

r- ~~=- =JL__-_
-_
·:___: ...J

Authoritative SNMP Engine. When two management entities co mmunicate, the services provided by each are
determined by the role they play. i.e.. whether the entity is authorized to perfo rm the service. This led to the
concept of mrthoritative 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 o ther as a non-authoritative eng ine. There is a well-
defined set of rules as 10 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 o r 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 repo rt messages, the sender o r 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. T he SN MP engine that acts in the role of a 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 of the time-stamp and n unique SNMP engine 10 in
each message. This requires that cwery non-authoritative SNMP engine keep a ta ble oflhetimeand authoritative
engine ID of every SNMP engine that it communicatc:s with.

Security Authentication. Communication between two errtities could satisfY the condition ot authoritative and non-
authoritalive pair. However, it should be the right set of pairs. 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 or iginating 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 module appends 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 of a n 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 snmpEngineT ime is the number of seconds since the snrnpEngineBoots
coumer was lasl initialized or reset.

The timeliness module also checks the message lD of a 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 fie Ids 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 SNMPv 1 and SNMPv2.

Frguo't 7.12. SNMPvJ 1\frSSA!:f Fornllll


Tobit 7.7. SNMP••3 J\fr55ago Form•l
Field Object Name Description

Version mseVerslon SNMP version number of the message fonnat

Message 10 msgiD AdminlstraUve 10 assodated with the message

msgMaXSfze

Message flags msgflags Bit fields Identifying repon, authentication: <1nd privacy of the
message

Message·se(Urtty model msgSecurttyModel Security model used for the·message: concurrent multiple models
allowed

Se(urtty parameters (See msgSecurttyParameters Security parameters used for communication between sending
Table 7.8) and rea!lvlng security modules

Plaintext/encrypted scopedPduOata Choice of plaintext cir encrypted scopedPOU; scopedPOU uniquely


scopedPOU data identifies context and POU

Context engine 10 contextEngineiO Unique 10 of a context (managed entity) with a context name
realized by an SNMP entity ·

Context name context Name Name of the context (managed entity)

POU data 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, if the version is set to snmp\12, the
SNMP\12 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 Section 7.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 fie ld conlains either uneo¢rypted or encrypted seopedPDU. If ihe privacy
flag is set to zero (no priva.cy) in the message 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 engine ID and a context name. Thus. 8 partJcular context name,
in conjunction with a particular context engine ID, identifies the particular context associated with the management
infi.)rmation contained in the PDU portion of t he message. 1be object name for PDU is dam.

7. 7. SNI\'[Pv3 User-B11sed Securit y 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, encrypt Data and decryptDtlla, for tbe encryption of outgoing messages and tbe deeryplion of incoming
messages. These were included in the list of primitives 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 A1rt.IJtnli<allon S.r vk t for an Incomin g l\1t5Sigt


ln Figure 7.13 that shows the process ofWl outgoing message, we will assume 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.r se process of an incoming message going through the authentication validation first,
and then decryption of the· message by the privacy module .

The security parameters use.d in the SM are s hown in Figure 7.12. Table 7.8 lists the parameters and the
correspondi.Qg SNMPvJ MlB objects. The position of the rel.e vant 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 (under snmpEngine Group)

msgAuthoritativeEngineBoots snmpEngineBoot.s (under snmpEngine Group)

msgAuthorltatlveEnglnenme snmpEnglnenme (under snmpEnglne 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 behalf tho 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 of privacy protocol used.

The usmUserSpinLock is an advisory lock that. is used by SNMP command generator applications to ooordinate
their use of the 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) in SS.

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
back to the MPM.

The opcralion !Or an incoming message is shown in Figure 7.14. [npulS 10 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·e y 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
of the 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 of2 20 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 digest I. 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 II 011 0) repeated 64 times

opad = the hexadecimal byte OxSc (0 I OJ II 00) 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 message shown in Figure 7. 13:

H(K2,H(Kl , wboleMsg))
The fust 12 oc1e1S 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 of the authenticated whole
message, authenticatedWholeMsg shown in Figure 7.1 3.

Key Managemenl. A user (NMS) bas only one password and hence one secre1 key digest t 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 of a locaLized key is introduced ro accomplish this instead of storing a 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 e ngine with which the local user is co mmunicating. Thi s 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 of changes 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-authent ication 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 fro m 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 of the message be encrypted. A secret v alue 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 of authentication code using MD-S hashing algorithm.

The first eight octets of the 16-odet privacy key are used 10 create the DES key. The DES key is only 56 bits lo11g
and he nee t.he least significant bit of each octet in the privacy key is di.searded. The 16-octet IV is made up of two
parts, an 8-octet pre-IV concatenated with an 8-octet salt. The pre-1 V 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 salt is the privacy panimeter shown in Figures 7.12. 7.13, and 7.14.

The encryption process first divides the plaintext of scopcd.PDU into 64-bit blocks. The pJainteltl of each block is
XOR-eel with ·me ciphertex't of the 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
SNlviP\13, 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 security considerations need to be introduced. A MlB module
for VACM bas been introduced toward achieving tbis.

7.8. 1. Elements of the Model

five elements comprise V ACM: (I) groups, (2) security leve~ (3) contexts, (4) MIB views and view families, a.nd
(5) access policy. We will define each of lbem 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) with a 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 of mlll18gement 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 locally available 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 si mple 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 of a complex MIB view could be all infunnation relevant to a particular network interface. 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 s ignificant to tbe
family's definition. A fiun ily of view subtrees can e ither 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 of objecl inStances authorl2i!d for lhc group when sending objecls in a noti6cal ion.

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 of an 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 2 275 describes, the VACM process answers tlte six questions related
to access of management i nformalion. They are:

1. Who.areyou (group comprisll18 security model and security name)?

2. Where do :you want 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) do you 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 quest ion regarding why access is needed is used by the "select variable names" process to
select the family of view 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 shown in 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 of the indices. The olhertllree indices from this
table are vacmAccessContex1Prefix, vaomAccessSecudtyModeL and vacmAccessSecurityLevel. The viewName
representing the three views, vacmAceessReadViewName, vacmAceessWriteViewNrune, and
vacmAccessNotifyVie\vName, 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.

flgu r t 7.t8. V ACI\1 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. VACJ\1 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
I DENTLFIER. For example, if the " access allowed?" process in Figure 7. 16 yields three values fur viewN ame. that
would resuh in three conceptual rows in this table. The vacmViewTreeFamilyViewName representing the
vlewName Is ooe oft he 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, if the
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 different subsets 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. If the corresponding bit value is 0 in the film ily mask, it is considered a wild card and any
value of the 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 a cont~1's MIB view.

As an example of the 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 cou ld 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 index added 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 of the two will select all St.b row objects
except i!Mlu.

Summa ry
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, if needed.

The second major feature is the indusion of security. A security subsystem is defined, w bicb 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 of user ID and password.

The access policies of SNMPvl and SNMP~ have been el\1ended 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 of access needed, tbe object
type, and the object instance.

Exe rcises

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. W rite the 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 NMS with the data shown In Figure
4.2(c).

4. Agure 7.20 shows a generalized time-sequenced operation for get-request message going from a manager to an
agent. Complete the primitives in Figure 7.20 e)(plicidy identifying the application 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 detaili ng the elements of procedure for get-
response message from the agent to 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 fi lli ng In the objects In the snmpTargetAddressTable, snmpTargetTable, and
snmpNotlfyTable. Specifications for the two targets are given below. You may use the Appendix of RFC 2273 as a
gul de to answer this exercise.

noel noc2

messageProcesslngModel SNMPv3 SNMPv3

securltyModel 3 (USM) 3(USM)

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

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

secu rltyleve I noAuthNoProv(1) authPrlv(3)

transportDom al n snmpUDPDomaln snmpUDPDom9ln

transportAddress 128.64.32.16:162 128.64.32.8:162

tag list "groupl" "group2"

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

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

11. SpecifY the fam ily name, the family subtree, the family mask, and the family type In vacmVIewTreeFam lyTable
for ah agentto present a view of:

a.. tbe complete lP group


b. IP address table ( ipAddrTable)
c. tbe row in the lP address table correspooding 10 tbe IP address 172.46.62. 1

12. Wrtte the vacmVlewTceeFamllyTable for the three rows th~t present the system group In the IP address table for
the row with IP address 172.46.62.1 without the ipAdEntReasmMaxSize.

8. SNMP Management: RMON


Objectives
• Remote net\mrk monito ring, RMON
RMON I: Monitoring Ethernet LAN and token-ring LAN
RMON2: Monitoring upper protocol layers
• Generates and sends sLalistics clo.se to subnetworks to central NMS
RMON MISs fur RMON group objects

The success of SNMP management resulted in the prevalence of managed network compo nents in the computer
network. SNMPv I set the fuundation for monitoring a network remot.e ly from a centraUzed .network operations
center (NOC) and performing fa1~t and configuration management. However; the extent to which network
performance could be managed was limited The characterization oft he performance ot a computer network is
statistical in nature. This led to the logical ste p of measuring ihe statistics of important pammeters in the network
from the NOC and the development of remote monitoring (RMON) spec ifications.

8.1. W hut is Remote Monitoring?

We saw e xamples of SNMP messages going across the network between a manager and an agent in Section 5.1.4.
We did this using a tool that ··~niffs'' eve.ry packet thai i-1 going aero~ a local area network (LAN), opens it. and
analyzes it. It is a passive operation and does nothing to the packets, which continue ttl proceed to their
destinations. 1l1Js is called monitoring or probing the network and the device that does the function is called the
netwo rk monitor or tlte probe. Let us distinguish between the two components of a probe: ( I) physical object that is
connected to the transmission medium and (2) processor, which analy zes the datn. 1f both are at the s ame place
geogr<~phically, it· is a local probe, which is how sniffers used to function. We will discuss this further in Chapter 9,
when we consider management systems and tools.

The m onitored information gathered and analyzed locaUy ca.n be transmitted to a remote network management
station. In such a case, remotely monitoring the network using a probe is referred to as remote network monitoring
or RMON . Figure 8. 1 shows a fiber-distributed data interfuce (FODI) backbone network with a local Ethernet
LAN. lltere are two remote· LANs, one a token-ring LAN and another, an FOOl LAN, cormec ted to ihe backbone·
network. The network manage ment system (NMS) is on the l.o cal Ethernet LAN. There is either an Ethernet probe
or an RMON on the Ethernet LAN monitoring tbe local LAN. The FODr backbone is monitored by an FOOl probe
via the bridge and Ethernet LAN. A toke!l-'ri.ng probe monitors the token-ring LAN. lt communicates with the
NMS via routers and tbe wide nrea network (WAN) (shown by lhe IJghtening bolt symbol of the
telecommunications link). The remote FOOl is monitored by the built-in probe an the router. The FDD! probe
communic11tes with tbe NMS via the WAN. All fuur probes that monitor the fuur LANs rutd communicate with tbe
NMS u.re RMON devices.

l'igur·• 8.t . Nrework Connguruciou wilh RMONs


The use of RMON devices has several advantages. First; each RMON device monitors the local network segment
and does the necessary analyses. Ll relays the necessary information in both solicited and unsolicited filshion to the
~S. For example, RMON cou.ld be loc41lly polling network e.lements in a segmcni. 1f It detects an abnormal
condition, such as heavy packet loss or excessive collisions, it would send an alarm. Because the polling is local,
the information is more reliable. This example of local monitoring and reporting to a remote NMS significantly
reduces SNMP tra.ffic in the network. This is especially true for the segment in which the NMS resides, as all the
monitoring traffic would otherwise converge there.

The following case history illustrates another advantage. RMON reduces the necessity of agents in the network to
be visible at all times to the NMS. One of the NMSs would frequently indicate that one of the hubs would show
failure, but the !tub recovered itself without any intervention. The perfonnance study of the hub that the LAN was
pan of indicated that the LAN would frequently become overloaded with heavy traffic, and would have a
significant packet loss. That included the ICMP packets tb.at the NMS was using to poll the hub. The NMS was set
to indicate a node failure if three sucoessive ICMP packets did not receive responses. Increasing the number of
packets needed to indicate a failure stopped the failure indication. This demonstrates the third advantage.

There are more chances that the monitoring packets, such as ICMP pings, may get lost in long-distance
communication, especially under heavy traffic conditions. This may wrongly be interpreted by the NMS as the
managed object being down. RMON ping; locally and hence has less chance oflosing packets, thus Increasing the
reliability of monit.oriog.

Another oovantage of local monitoring using RMON is thut individual segments can be monitored on a more
continuous basis. This provides better statistics and greater ability for control. Thus, a tauU could be diagnosed
quicker by the RMON and reported to the NMS. In some situations, a failure could even be prevented by proa.ctive
management.

The overall benefits of implcme.nting RM.ON tecltnology in a network are higher network availability for users and
greater productivity for administrators. A study report [CISCO/RMON] indicates increased productivity of several
times for network administrators using RMON in il~eir network.

8.2. RMON SMI anti MIB


Por a network configuration system. like the one shown in Figure 8.1, to work suocessfuUy, several conditions
need to be met. Network components are made by different vendors. Even the RMON devices may be from
different vendors. Thus, just as in the communication of network management infOrmation, standards need to be
established for commo.n syntax and semantics lOr the use of RMON devices. The syntax used is ASN.I. The
RMON structure of management info[lll8tion is similar to SMiv2 in defining object types. The Remote Net1\0rk
Monitoring Managemenrlnformation Base (RMON MlB) defining RMON groups liaJ; been developed and defined
in three stages. The original RMON MIB, now referred to 3S RMONl was developed fur Ethernet LAN in
November 1991 RFC 1271, but was made obsolete in 1995 RFC 1757. Token-ring extensions to RMON I were
developed in September 1993 fRFC 1513). The use of RMON I for remote monitoring was found to be extremely
beneficial. However, il addressed parameters at the OS! layer 2 level only. Hence, RMON2 [RFC 2021] was
developed and released in January 1997, which addressed the parameters associated with OSI layers 3 through 7.

The RMON group is node 16 under MIB-11 ( mib-2 16), as shown in Figure 6.36. All the groups under the RMON
group are sbown in Figure 8.2. It consists of nine Ethernet RMON I groups (noon I to rmoo 9), one t.oken-riog
extension group to RMONI (rmon 10). and nine RMON2 groups(nnon 11-20) for tlte higher layers.

Figur• 8.1. RMON Croup

t
RM<lHI"'*'-'

.RMONI is covered in Section 8.3 and RMON2 in Section 8.4. We will discuss the applications ofRMON in Part
m when we discuss applicatioos, systems,andtoo1s.
8.J.RMONI

RMONI is covered by RFC 1757 for Ethernet LAN and RFC 1513. There are two data types introduced as textual
conventions, nnd ten MlB groups ( noon I to rmon I 0), as shown in Figure 8.2.

8.3.1. RMON I Textual Conventions


Two new data types thm are defined in RMONI textual conventions are OwnerString and BntryStatus. Both these
data lYJles are eKtremely useful in the operation of RMON devices. RMON devices are used by maoagemen1
systems to measure and produce stati.stics on network elements. We will soon see !hat. this involves setting up
tables that control parameters to be monitored. Typically, there is more than one management system in the
network, which could have permission to crente, use, and delete control parameters in a table. Or, a human network
mnnage.r i.n charge of network operations does such function s. For !his purpose, the owner identification is made
part oftbe control table defined by the OwnerString data lype. The BntryStatus is used to resolve conflicts between
management systems in manipulating control tables.

The OwnerString is specified in the NVf ASCll cbarr~eter set specified by DisplayString. The information content
of OwnerS!ring conlllins in.furmation about the owner: lP address, management slation nnme, network manager's
name, location. or telephone number. If the agent itself is the owner, as for example in the addition of an interface
card, the OwnerString is set to "monitor."

1n order to understand the data 1ype, BntryStatus, we need to understand the concept of creation and deletion of
rows in tables, which was discussed in Section 6.4. 7. For a table to be shared by multiple users, a columnar object
EntryStatus, similar to RowSmtus i.n SNMPv2, is added to the lllble that contains information on the status of the
row. The EntryStatliS data lype can exist in one of four states: (I) valid, (2) createRequest, (3) undciCreation, and
(4) invalid. l 'he four states ofEntryStatus arc shown in Table- 8.1 . Under the valid srate condition, the instantiation
or row of the Lable is operational and is probably measuring the number of input octets in tbe JF group on an
interface. Any mllllagement system, which is authenticated to· use the RMON device, may use this row ofdalll. Of
course, if the owner of the row decides to make it invalid, other systems lose the data. The invalid state is the way
to deleiea row. Based on implementntion, the row may he immediately deleted and the resource claimed, or it may
be done in a batch mode late.r. Iflhe desired row of information does not already exist, the ma.nagement system can
create a row. The EntryStaiUs is then set to oreateRequest. 1lte process of Cl'e8tion may involve more than one
exchange of PDUs between the manager and the agent. t n such a situation, the state of the Entl)iStruus is set to
undcrCreation so that others won't use it. Aller the creation process is complete, it is set to the valid state.

Tabt~S.I. EntryStatus.Tutuat Convention


State Enumeration Description

valid 1 Row exists and Is 11ctlve. It is fully configured and operational

createRequest 2 Create a new row by creating this object

underCreation Row is not fully active

Invalid 4 Delete the row bydlsasscdatlng the mapping of this entry

8.3.2.RMONl Groups and Functions

RMON in general, and RMON I specifically, performs numerous functions at the data liok layer. Figure 8.3 shows
a pictorial representation of RMON I groups and functions. The data-gathering module;;, which are LAN probes,
gather data from the remotely monitored network comprising Ethernet and token-ring LANs. The data can serve as
inputs to five sets of functions. Three of those comprise monitoring of traffic statistics. The host and conversation
statistics group deals with traffic data associated with the hosts, ranking of traffic ror the top N hosts, and
conversation between hosts. The group of statistical data associated wiili Ethernet LAN, namely Ethernet statistics
and Ethernet history statist·ics, is addressed by the groups and functions in the Etbemet statistics box. The history
control table controls the data to be g;ubered from various networks. lt is also used by the token-ring statistics
modules in the token-ring statistics box. Outputs of various modules are analyzed and presented in tabular and
gmphical forms Ill the user by the network manager in 1be NMS.

Figu•·• 8.3. RMONt Groups oud Fuu<lions

The filter group is a cascade of two filters. The packet filter filters incoming packets by perfurming a Boolean
and/or XOR wiH1 a mask specified. This could be quite complex. The filtered packet stream is considered a
channel. We can make further selections based on the channel mask. The filtered outputs may genemte either
alarms or evenls. These are reported to the network manager. The output of the data g&he.rer could also genemte an
alarm directly.

The output of the filter group could be stored in the packet capture module for filrther analysis by the network
manager. This could be associllted with a special study of the traffic pattern or troubleshooting of an abnormality in
tJIC network.

The above functions associated with the various groups are accomplished us ing teo groups associated with the
RMONI MIB, as sbown in Table 8.2. The firsi nine groups are applicable to common dam and to Ethernet LAN,
and the tenth group extends it to token-ring LAN. Most of the groups have one or more tables. The groups liiJI into
three categories. The largest category is the statistics-gathering groups. These are the Statistics groups, the History
groups, the Host group, the Host Top N group, and the Matrix group. The seonnd category deals with the network
event reponing functions. lllese are the Alarm group and the Evenl group. The third cmegory deals with filtering
the input packets according io selec1ed criteria and capturing the data if desired for further analysis. These are the
Filter group and the Packe.f Capture group. We will consider RMON I groups and the token-ring extension to
RMON I in Sections 8.3.4 and 8.3.5, respectively.

Table 8.2. RMONt M ID Grou1>< oud Tab Its


Group 010 Function Tables
Tabl t 8.2. Rli10NI MIB Go'OUf>S nnd TAbi<S

Groop OlD Function Tab~

Statistics rmon 1 Provides link-level statistics -etherStatsTable

-ether5tats2Table

History rmon 2 Coll&ts periodic statistical data and stores for later retrie.val -hlstoryControffable

-etherHistoryTable

-hlstoryControi2Table

-etherHistory2Table

Alarm rmon 3 Generates events when the data sample gathered crosses pre- -alarmTable
estabnshed threshol cis

Host rmon 4 Gathers statistical data on hosts - hostControffable

- hostTable

-host1i meTable

- hostControi2Table

Host Top N rmon 5 Computes the top N hosts on the respective categories of surtlstics -
gathered hostTopNcontroiTable

Matrix rmon 6 Gathers statistics on traffit between palrs.of hosts -matrixControiTable

-matrlxSDTable

- matrlxDSTable

-matrh<Controi2Table

Alter rmon 7 Performslllterfunctiohthatenables capture·of desired parameters - fllterTable

-channeffable

- fllter2Tabfe·

-channei2Table

Packet rmon 8 Provides packet capture capabll ity to gather packets after they flow -buffercontroiTable
TRblt 8.2. RMONI Mffi GrOllllS and Tab los

Group 010 Function Tables

capture through a channel

~pture8uffer'Table

Event rmon9 Control s the generation of events and notiflcatlons -eventTable

Token ring Rmon See Table 8.3 See Table 8.3


10

In Table 8.2, we notice in 1be Tables colunu1 that some of the groups have tables with "2" as part of the name; for
example, etherStats2Tnble in the Statistics group. These are additional tables created during RMON2 specifications
development and are enhancements to RMONI. Hence, 1hey are included here as part o f RMONI. The
enhancements 10 RMONI include the standard La<rtCreateTime te~tual convention fOr all control tables and
Time-Filter textual convention that provides capability for the filter to handle rows to be used for the index to a
table. The LastCreateTime enhancement belps keep track of data with tbe changes in control. Tbe. TimeFilter
enables an application to download o nly those rows that ohang!ld since a particular time. 1l1e agent returns a value
only if ibe time mark is less t.ban the last update time.

As an example, .let us consider a fooTable with two rows and three columnar objects, fooTimeMark (with
TimeFilter as the data !ype), foolndex. and fooonums. The indices defining a row are fuoTimeMnrk and foolndex.
Let the TimeFilrer index start at 0, ibe last· update of fooCounter in row #I occur at time 3, and its value is 5.
Assume 1he update to .r ow #2 occUI'red Ill time 5 and tbe value was updated to 9. This scenario would yield the
following inst11nce offooCounts io the fooTable:

fooCount s . O. l 5
fooCounts . 0 . 2 9
fooCount s . l . l 5
foocounts . 1 . 2 9
fooCoun t s . 2 .1 5
fooCouots. l . 2 9
fooCoun t s . 3 .1 5
fooCount s.3.2 9
fooCounts . L 2 9 {Note that row U does not exist for times 4 ilf\d S since the l ast
update
occurred at timema r k 3 . )
fooCoun t s.5.2 9
(Both rows U and 12 do no t exist for timemark g reater than 5 . )

8.3.3. J{el.atiorL~hip Between Control and Data Tables

Observing the Tables column in Table 8.2, you will notice several of the groups have a datil 1able and a control
table. T he datil table contains rows (instances) of data. The control table· defines the instances ofthe datr rows in
'I he data mble and is seunble to gnther and s tore different instances of data. The relationship between tbe control
table and ibe daia table is illustrated in a generic manner in Figure 8.4. The vahre ofihe datalndex in ihe data table
is the same as the value ofcontronndex in I he comrol table.

Figure 8.4. Rtlotlonsblp Btrwttn Control and O•u• T ables


iKlloltiJII "*-"
~I'Mf\ta11'tltO!Oi«W
Vii!Jt Clf dft!hOOJ •~me n hwl.ltot ClO!IiUtnckt

Let us understrutd how the dat!l tllble and the control t!lble work together using the matrix group in Table 82. We
can ro llect data based on source and destination addresses appearing in the packets on a given interface using the
matrixSDTable (matrix SQurce-<lestination table). The control index is rut integer uniquely identifying the row in
the control table·. II would have a va.Jue of I for the iirst intrice of a managed entity. llte value of the columnar
objecl, controlDatllSource, idenJifJe.s the source of the data that is being collected.ln our example, if the interface
#1 belongs to the imerfaces group, then controlDataSourcc is iflndex.l.

The controJTableSize identifies entries associated with this data source. In our matrix source-<lestinatim table
example, tllis would be the sourc&-destination pair in each row ofUIC table.

The controiOwner columnar object is the entity or person who created the entry. The entity could be either the
ngent or NMS, or a manngement person. The contro IStat·us is one· of the· em·ries listed in Table 8. I. The
controiOther could he any other object.

To uniquely identifY a conceptual row in the data table, we may need to specify more indi.ces th110 the dat;Undex.
This is indicated as dataAddllndex in Figure 8.4. In our matrix source-<lestination example, additional indices are
source and destination address objects. The dataOthcr in the data table indicates data being collected, such as the
number of packet~.

8.3.4.1tMONJ Common and Ethernet G roup~

We. have so fur covered the global picture of RMON I Ethernet MIB and how data and control tables are related to
each other. Let us now address the nine RMON I commo o and Ethernet groups.

Stal'istics Group. llte statistics group contains stntist·ics measured by the probe tOr each monltored Ethernet
interface on a device. The etherStatsTable in tbis group has an entry for each interfilce. Data include statistics on
packet types, sin:, and errors. ll also provides capability to gather statistics on the collision of the Eihemet
segment. The number of collisions is a best estimate, as the numbe.r o(collisions detected depends on where the
pro be is placed on the segment.

lbe statistics group is used to measure live statistics on nodes and segments. Commercial NMSs include features
such as dynamic presentation of various trafflc patterns. 1he number of MlB collisions could also be used for
alarm generation when it exceeds a set high threshold value.
History Group. The history group consists of two s.ubgroups: the history control group and the history (data) group.
The history control group controls the periodic st3listl.cal sampling of data fro m various types of networks. The
control table stores configuration entrie.~ comprising interface, polling period, and other parameters. InfOrmation is
stored in a media-specific table, the history table, which contains o.ne entry for each specific sample.. A short"tenn
and a long-term imef\•al , such as 30-second and 30-rninute intervals. rnay he specified to obtain two diflcrent
sllltistics. The dat;l objecis defined 11re dropped events, numbe.r of octell!· and packets, diffl:rent type of ·errors,
fragments, collisions, and utilization.

The history group is extremely useful in tracking the overall trend in the volumeoftraflic. Since historical data are
accumulated at the data link layer, they include traffic caused by aU higher-layer protocols. Short-!erm history
statistics can also be used to troubleshoot net work performance problems. For example, in one study of traffic
pattern that the author participated in. short-term history statistics revealed that a significant volume of
"transparent" data was contributed by servers in the network, which were functioning as " mirrors"' for a public
news service on ihe Internet. Although the service \vas considered to be desirable, since il was gcoemted and
consumed externally, it behaved sornewltattraospareotly with regard to the local network traffic.

Alarm Group. The alarm group periodically takes statistical samples on specified variables in the prohe and
compares them with the pre-configured threshold stored in the probe. Whenever the monitored variable crosses the
threshold. an event is generated. To avoid excessive generation of events on the threshold border, rising and falling
thresholds are specified. This works in the following manner. Suppose an alarm event is generated w.ben the
variable crosses the faUlng threshold while going down in value. Another.event would be generated only after the
value crosses the rising threshold at lea~t once.

The group contains an alarm table that has a list of entries defining the alarm parameters. The colmnnar objectS
alarm Variable and alarmlnterval are used to select the variable and the sampling interval. The sampling type is
either tbe absolute or delta value.. In the former, the abso ktte value of the variable at the end.of the previous period
is stored as an alarm value. In the· latter type, the absolute value at the end at a period is subtracted from the
beginning of the period and tbe computed value is stored. These values are compared with the rising and falliog
thresholds to generate alarms.

An e.xample of an absolute value would be a new interface card on test fbr infant mortality. The threshold of the
sum ofoutgoing and incoming packets could be set to I gigaoctecl~ and tbe RMON would generate an alarm/event
when the threshold is reached. An example of delta type is threshold set to 10,000 packets in a 10-second interval
for excessive packet loss.

Host Group. The host group cootains information about the basts on the network. It compiles the list of hosts by
looking at the good packets traversing the network and extracting the source and destination MAC addresses. It
maintains statiStics on these hosts. There are three tables in the group: hostControlTable, hostTable, and
hostTimeTable. The hostControlTable controls the interfuceson which data gaUtering is done. The other two tables
depend on this infOrmation. The hostTable contain5 statistics about the host. The bostTimeTable contains the same
data as the host table, but is stored in the time order in which the host entry was discovered. This belps in the .filst
discovery of new hosts in the system. Tbe entries in the two data tables are synchronized with respect to the host in
the hostControlTable. We can obmin statistics on a.host using 1his MIB.

Host Top N Group. The host top N group performs a report-generation function ror ranking the top N hosts in the
category of the selected statistics. For example, we can rank-<:>rder the top ten hosts with maximum outgoing
1mffic. The HostTopNControlTable ls used to initiate generation of such a report.

As an elQl.mp le of the rypc ofda.ta that can be acquired using an RMON probe, Figure 8.5 shows a chart derived
using an RMON probe for the output octets of the top ten hosts in a network. The names of the hosts have been
changed to generic host numbers for security reasons.

Flgurt 8.5. Hosffot>-10 Output O<lrls


H0<1TopN

HO!I!I

H0o12

HOI!I3

HOlt~

HOIU

H01t6

HOII I

HOII6

H"'*9

lloJI10 .,.
ICO :roo 300 •oo
Gign Oote!