network management principles and practice mani subramanian 2nd edition ch6

This Book

Notes

Bookmarks

Search

Contents

NetworkManagement:Principles andPractice

Table of ContentsIndex

Copyright

Endorsements

Preface

About the Author

Pt. I. Background

Pt. II. SNMP and NetworkManagement

Ch. 3. Basic Foundations:Standards, Models, andLanguage

Ch. 4. SNMPv1 NetworkManagement: Organizationand Information Models

Ch. 5. SNMPv1 NetworkManagement:Communication andFunctional Models

Ch. 6. SNMP Management:SNMPv2

Major Changes inSNMPv2SNMPv2 SystemArchitecture

SNMPv2 Structure ofManagementInformation

SNMv2 ManagementInformation Base

SNMPv2 Protocol

Compatibility withSNMPv1

Summary

Exercises


Ch. 8. SNMP Management:RMON

Ch. 9. Network ManagementTools, Systems, andEngineering

Pt. III. TMN and ApplicationsManagement

Pt. IV. Broadband NetworkManagement

Appx. A. OSI Network andSystem Management

Appx. B. Project Suggestions

Appx. C. Laboratory Tutorial

Appx. D. Spread SpectrumTechnology: OFDM

Trademarks

Acronyms

Glossary

References

Index

Chapter 6. SNMP Management: SNMPv2 > Major Changes in SNMPv2

6.1. Major Changes in SNMPv2Several significant changes were introduced in SNMPv2. One of the mostsignificant changes was to improve the security function that SNMPv1lacked. Unfortunately, after significant effort, due to lack of consensus, thiswas dropped from the final specifications, and SNMPv2 was released withthe rest of the changes. The security function continued to be implementedon an administrative framework based on the community name and thesame administrative framework as in SNMPv1 was adopted for SNMPv2.SNMPv2 Working Group has presented a summary of the community-basedAdministrative Framework for the SNMPv2 framework, and referred to it asSNMPv2C in RFC 1901. RFC 1902 through RFC 1907 present the details onthe framework. There are significant differences between the two versions ofSNMP, and unfortunately version 2 is not backward compatible with version1. RFC 1908 presents implementation schemes for the coexistence of thetwo versions.

The basic components of network management in SNMPv2 are the same asversion 1. They are the agent and the manager, both performing the samefunctions. The manager-to-manager communication, shown in Figure 4.8,is formalized in version 2 by adding an additional message. Thus, theorganizational model in version 2 remains essentially the same. In spite ofthe lack of security enhancements, major improvements to the architecturehave been made in SNMPv2. We will list some of the highlights that wouldmotivate the reader’s interest in SNMPv2.

Bulk Data Transfer Message: Two significant messages were added. Thefirst is the ability to request and receive bulk data using the get-bulkmessage. This speeds up the get-next-request process and is especiallyuseful to retrieve data from tables.

Manager-to-Manager Message: The second additional message deals withinteroperability between two network management systems. This extendsthe communication of management messages between managementsystems and thus makes network management systems interoperable.

Structure of Management Information (SMI): In SNMPv1, SMI isdefined as STD 16, which is described in RFCs 1155 and 1212, along withRFC 1215, which describes traps. They have been consolidated and rewrittenin RFCs 1902–1904 for SMI in SNMPv2. RFC 1902 deals with SMIv2, RFC1903 with textual conventions, and RFC 1904 with conformances.

SMIv2 is divided into three parts: module definitions, object definitions, andtrap definitions. An ASN.1 macro, MODULE-IDENTITY, is used to define aninformation module. It concisely conveys the semantics of the informationmodule. The OBJECT-TYPE macro defines the syntax and semantics of amanaged object. The trap is also termed notification and is defined by aNOTIFICATION-TYPE macro.

Textual Conventions are designed to help define new data types. They arealso intended to make the semantics consistent and clear to the humanreader. Although new data types could have been created using new ASN.1class and tag, the decision was made to use the existing defined class types

Network Management: Principles and Practice > Background > Review o... file:///D:/TC Engg/8th Semester/TMN/Book Network Management Princ...

1 of 2 23-Sep-15 7:26 PM

and apply restrictions to them.

Conformance Statements help the customer objectively compare featuresof various products. It also keeps vendors honest in claiming their productas being compatible with a given SNMP version. Compliance defines aminimum set of capabilities. Additional capabilities may be offered as optionsin the product by vendors.

Table Enhancements: Using a newly defined columnar object with aSyntax clause, RowStatus, conceptual rows could be added to or deletedfrom an aggregate object table. Further, a table can be expanded byaugmenting another table to it, which is helpful in adding additionalcolumnar objects to an existing aggregate object.

MIB Enhancements: In SNMPv2, the Internet node in the MIB has two newsubgroups: security and snmpV2, as shown in Figure 6.1. There aresignificant changes to System and SNMP groups of version 1. There arechanges to the System group made under mib-2 node in the MIB. The SNMPentities in version 2 are a hybrid, with some entities from the SNMP group,and the rest from the groups under the newly created snmpV2 node.

Figure 6.1. SNMPv2 Internet Group

[View full size image]

Transport Mappings: There are several changes to the communicationmodel in SNMPv2. Although use of UDP is the preferred transport protocolmechanism for SNMP management, other transport protocols could be usedwith SNMPv2. The mappings needed to define other protocols on to UDP arethe subject of RFC 1906.


2 of 2 23-Sep-15 7:26 PM

This Book

Notes

Bookmarks

Search

Contents



Copyright

Endorsements

Preface

About the Author

Pt. I. Background






Major Changes inSNMPv2

SNMPv2 SystemArchitectureSNMPv2 Structure ofManagementInformation


SNMPv2 Protocol


Summary

Exercises










Trademarks

Acronyms

Glossary

References

Index

Chapter 6. SNMP Management: SNMPv2 > SNMPv2 System Architecture

6.2. SNMPv2 System ArchitectureSNMPv2 system architecture looks essentially the same as that of version 1,as shown in Figure 4.9. However, there are two significant enhancements inSNMPv2 architecture, which are shown in Figure 6.2. First, there are sevenmessages instead of five as in Figure 4.9. Second, two managerapplications can communicate with each other at the peer level. Anothermessage, report message, is missing from Figure 6.2. This is because eventhough it has been defined as a message, SNMPv2 Working Group did notspecify its details. It is left for the implementers to generate thespecifications. It is not currently being used and is hence omitted from thefigure.

Figure 6.2. SNMPv2 Network Management Architecture


The messages get-request, get-next request, and set-request are thesame as in version 1 and are generated by the manager application. Themessage, response, is also the same as get-response in version 1, and isnow generated by both agent and manager applications. It is generated bythe agent application in response to a get or set message from the managerapplication. It is also generated by the manager application in response toan inform-request message from another manager application.

An inform-request message is generated by a manager application and istransmitted to another manager application. As mentioned above, thereceiving manager application responds with a response message. This setof communication messages is a powerful enhancement in SNMPv2, since itmakes two network management systems interoperable.

The message get-bulk-request is generated by manager application. It isused to transfer large amounts of data from the agent to the manager,especially if it includes retrieval of table data. The retrieval is fast andefficient. The receiving entity generates and fills data for each entry in therequest and transmits all the data as a response message back to the


1 of 2 23-Sep-15 7:26 PM

originator of the request.

An SNMPv2-trap event, known as trap in version 1, is generated andtransmitted by an agent process when an exceptional situation occurs. Thedestination to which it is sent is implementation-dependent. The PDUstructure has been modified to be consistent with other PDUs.

Another enhancement in SNMPv2 over version 1 is the mapping of the SNMPlayer over multiple transport domains. An example of this is shown inFigure 6.3, in which an SNMPv2 agent riding over a connectionless OSItransport layer protocol, Connectionless-Mode Network Service (CLNS),communicates with an SNMPv2 manager over the UDP transport layer. RFC1906, which describes transport mappings, addresses a few well-knowntransport layer mappings; others can be added using a similar structure.

Figure 6.3. SNMPv2 Network Management Architecture onMultiple Transport Domains


Details on the MIB relating to SNMPv2 are covered in Section 6.4 andcommunication protocol aspects of messages in Section 6.5. Although not astandard, RFC 1283 specifies SNMP over Connection-Oriented TransportService (COTS), a connection-oriented OSI transport protocol. However,SNMP is not specified over connection-oriented Internet protocol, TCP.


2 of 2 23-Sep-15 7:26 PM

This Book

Notes

Bookmarks

Search

Contents



CopyrightEndorsementsPrefaceAbout the AuthorPt. I. BackgroundPt. II. SNMP and NetworkManagement

Ch. 3. Basic Foundations:Standards, Models, andLanguageCh. 4. SNMPv1 NetworkManagement: Organizationand Information ModelsCh. 5. SNMPv1 NetworkManagement:Communication andFunctional ModelsCh. 6. SNMP Management:SNMPv2

Major Changes inSNMPv2SNMPv2 SystemArchitectureSNMPv2 Structure ofManagementInformationSNMv2 ManagementInformation BaseSNMPv2 ProtocolCompatibility withSNMPv1SummaryExercises

Ch. 7. SNMP Management:SNMPv3Ch. 8. SNMP Management:RMONCh. 9. Network ManagementTools, Systems, andEngineering

Pt. III. TMN and ApplicationsManagementPt. IV. Broadband NetworkManagementAppx. A. OSI Network andSystem ManagementAppx. B. Project SuggestionsAppx. C. Laboratory TutorialAppx. D. Spread SpectrumTechnology: OFDMTrademarksAcronymsGlossaryReferencesIndex

Chapter 6. SNMP Management: SNMPv2 > SNMPv2 Structure of Management Information

6.3. SNMPv2 Structure of Management InformationThere are several changes to SMI in version 2, as well as enhancements to SMIv2over that of SMIv1. As stated earlier, SMIv2 [RFC 1902] is divided into three parts:module definitions, object definitions, and notification definitions.

We introduced the concept of a module in Section 3.6.1, which is a group ofassignments that are related to each other. Module definitions describe thesemantics of an information module and are formally defined by an ASN.1 macro,MODULE-IDENTITY.

Object definitions are used to describe managed objects. The OBJECT-TYPE macrothat we discussed in Section 4.7.3 is used to define a managed object.OBJECT-TYPE conveys both syntax and semantics of the managed object.

Notification in SMIv2 is equivalent to trap in SMIv1. In SMIv1, trap is formallyspecified by an ASN.1 macro, TRAP-TYPE. In SMIv2, notification is specified by anASN.1 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 twoassignments in SMIv1, namely, object name and trap, they are not formallystructured. In SMIv2, an ASN.1 macro, OBJECT-IDENTITY is introduced for theassignment of object name and notification to OBJECT IDENTIFIER, as shown inFigure 6.4.

Figure 6.4. Definitions of SMI for SNMPv2 (Skeleton)


1 of 23 23-Sep-15 7:27 PM

6.3.1. SMI Definitions for SNMPv2Figure 6.4 shows a skeleton of the SMIv2 and the reader is referred to RFC 1902for a complete set of definitions. We have taken the liberty of presenting thedefinitions with some additional comments (marked by *) and structuralindentations to bring out clearly the BEGIN and END of macros.

Definitions begin with the high-level nodes under the Internet MIB. Two additionalnodes, security and SNMPv2, are introduced. The security node is just aplaceholder and is reserved for the future. The snmpV2 node has three subnodes:snmpDomains, snmpProxys, and snmpModules. The MIB tree showing all thesenodes defined in SMIv2 is presented in Figure 6.5.

Figure 6.5. SNMPv2 Internet Nodes Defined in SMIv2



2 of 23 23-Sep-15 7:27 PM

6.3.2. Information ModulesRFC 1902 defines information module as an ASN.1 module defining informationrelating to network management. SMI describes how to use a subset of ASN.1 todefine an information module.

There are three kinds of information modules that are defined in SNMPv2. They areMIB modules, compliance statements for MIB modules, and capability statementsfor agent implementations. This classification scheme does not impose rigidtaxonomy in the definition of managed objects. Figure 6.6 shows an examplewhere conformance information and compliance statements are part of the SNMPgroup of SNMPv2 MIB. As we shall see later, the SNMP group in SNMPv2 containssome of the objects of version 1 and some new objects and object groups (to bedefined later). It also has information on conformance requirements. In theexample shown, the mandatory groups in implementing SNMPv2 are snmpGroup,snmpSetGroup, systemGroup, and snmpBasicNotificationsGroup. Thus, if anetwork component vendor claims that its management agent is SNMPv2compliant, these groups as they are defined in SNMPv2 should be implemented.

Figure 6.6. Example of the SNMP Group including Conformance andCompliance in SNMPv2 MIB


3 of 23 23-Sep-15 7:27 PM

MIB specifications contain only compliant statements in them. The agent-capabilitystatements are part of implementation in the agent by the vendor. It might beincluded as part of an “enterprisespecific” module.

The information on SMIv2 has been split into three parts in the documentation.MIB modules for SMIv2 are covered in RFC 1902. The textual conventions to beused to describe MIB modules have been formalized in RFC 1903. Theconformance information, which encompasses both compliance and agentcapabilities, is covered in RFC 1904.

6.3.3. SNMP KeywordsKeywords used in the specifications of SMIv2 are a subset of ASN.1. But it is adifferent subset from that of SMIv1. Table 6.1 shows the comparison of keywordsused in the two versions. We will address the new keywords for specificapplications as we discuss them. It is worth noting here that some of the generalkeywords have been replaced with limited keywords. Thus, Counter is replaced byCounter32, Gauge by Gauge32, and INTEGER by Integer32. The NetworkAddressis deleted from use and only IpAddress is used.

Table 6.1. SNMP Keywords

Keyword SNMPv1 SNMPv2

ACCESS Y Y

AGENT-CAPABILITIES N Y

AUGMENTS N Y

BEGIN Y Y


4 of 23 23-Sep-15 7:27 PM


BITS N Y

CONTACT-INFO N Y

CREATION-REQUIRES N Y

Counter Y N

Counter32 N Y

Counter64 N Y

DEFINITIONS Y Y

DEFVAL Y Y

DESCRIPTION Y Y

DISPLAY-HINT N Y

END Y Y

ENTERPRISE Y N

FROM Y Y

GROUP N Y

Gauge Y N

Gauge32 N Y

IDENTIFIER Y Y

IMPLIED N Y

IMPORTS Y Y

INCLUDES N Y

INDEX Y Y

INTEGER Y Y

Integer32 N Y

IpAddress Y Y

LAST-UPDATED N Y

MANDATORY-GROUPS N Y

MAX-ACCESS N Y

MIN-ACCESS N Y

MODULE N Y

MODULE-COMPLIANCE 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

OBJECT-TYPE Y Y

OBJECTS N Y

OCTET Y Y

OF Y Y

ORGANIZATION N Y

Opaque Y Y

PRODUCT-RELEASE N Y

REFERENCE Y Y

REVISION N Y

SEQUENCE Y Y


5 of 23 23-Sep-15 7:27 PM


SIZE Y Y

STATUS Y Y

STRING Y Y

SUPPORTS N Y

SYNTAX Y Y

TEXTUAL-CONVENTION N Y

TRAP-TYPE Y N

TimeTicks Y Y

UNITS N Y

Unsigned32 N Y

VARIABLES Y N

VARIATION N Y

WRITE-SYNTAX N Y

It is also to be noted that reference in IMPORTS clause or in clauses of SNMPv2macros to an informational module is not through “descriptor” as it was in version1. It is referenced through specifying its module name, an enhancement inSNMPv2.

It should be observed that the expansion of the ASN.1 module macro occursduring the implementation phase of a product, and not at run-time.

6.3.4. Module DefinitionsThe MODULE-IDENTITY macro is added to SMIv2 specifying an informationalmodule. It provides administrative information regarding the informational moduleas well as revision history. SMIv2 MODULE-IDENTITY macro is presented in Figure6.7.

Figure 6.7. MODULE-IDENTITY Macro

Figure 6.8 shows an example of a MODULE-IDENTITY macro (a real-worldexample of a non-existent module) for a network component vendor, InfoTechServices, Inc. (isi), which is updating their private-enterprises-isi MIB module{private.enterprises.isi}.

Figure 6.8. Example of MODULE-IDENTITY Macro


6 of 23 23-Sep-15 7:27 PM

The last updated clause is mandatory and contains the date and time in UTC timeformat [RFC 1902]. “Z” refers to Greenwich Mean Time. The Text clause uses theNVT ASCII character set [RFC 854], which is a printable set. All clauses, exceptthe Revision clause, must be present in the macro.

6.3.5. Object DefinitionsThe OBJECT-IDENTITY macro has been added in SMIv2 and is used to defineinformation about an OBJECT-IDENTIFIER. It is presented in Figure 6.9. TheSTATUS clause has one of three values: current, deprecated, or obsolete. Thevalue mandatory in SMIv1 is replaced with the value current in SMIv2. The valueoptional is not used in SMIv2. The new value, deprecated, has been added todefine objects that are required to be implemented in the current version, but maynot exist in future versions of SNMP. This allows for backward compatibility duringthe transition between versions.

Figure 6.9. OBJECT-IDENTITY Macro

Although the REFERENCE clause was used only in an OBJECT-TYPE construct inSMIv1, it is used in many constructs in version 2.

Let us extend our hypothetical example of InfoTech Services and suppose that ISImakes a class of router products. It is given an OBJECT IDENTIFIER as isiRouterOBJECT IDENTIFIER ::= {private.enterprises.isi 1}. The class of router productscan be specified at a high level using the OBJECT-IDENTITY macro as shown inFigure 6.10(a). The status of the isiRouter is current and is described as an8-slot IP router. A reference is given for obtaining the details.

Figure 6.10. Example of OBJECT-IDENTITY and OBJECT-TYPE Macros


7 of 23 23-Sep-15 7:27 PM

A specific implementation of the router in isiRouter class of products isrouterIsi123. This is a managed object specified by the OBJECT-TYPE macro shownin Figure 6.10(b). We are already familiar with the OBJECT-TYPE macro by now.

Let us make sure that we clearly understand the terminology used with the termOBJECT. OBJECT IDENTIFIER defines the administrative identification of a node inthe MIB. The OBJECT IDENTITY macro is used to assign an object identifier valueto the object node in the MIB. The OBJECT-TYPE is a macro that defines the type ofa managed object. It is also used to describe a new type of object. As we havelearned in the previous chapters, an object instance is a specific instance of theobject (type). Thus, a specific instance of the routerIsi123 could be identified by itsIP address 10.1.2.3.

Comparing Figure 6.10(a) with Figure 6.10(b) we observe the differencebetween OBJECT-IDENTITY and OBJECT-TYPE. The status clause appears in both.The description clause that also appears in both describes different aspects of theobject. The OBJECT-IDENTITY describes the high-level description; whereas theOBJECT-TYPE description focuses on the details needed for implementation.

Let us now visualize the router in Figure 6.10 with several slots for interfacecards. We want to define the parameters associated with each interface. Theparameters that are managed objects (or entities) are defined by an aggregateobject, IfTable. For example, the ifNumber for our router example could be 32 ifthe router has eight slots and each card has four ports.

SMIv2 extends the concept table for an aggregate object from a single table tomultiple tables. This allows for expansion of managed objects when the number ofcolumnar objects needs to be increased, or when the objects are best organized bygrouping them hierarchically. Let us first consider the case of adding columnarobjects to an existing table with the following restrictions: (a) the number ofconceptual rows is not affected by the addition; (b) there is one-to-onecorrespondence between the rows of the two tables; and (c) the INDEX of thesecond table is the same as that of the first table. This is shown in Figure 6.11.

Figure 6.11. Augmentation of Tables



8 of 23 23-Sep-15 7:27 PM

Table 1 is called the aggregate object table1 and has three columns and four rows;and Table 2 is called the aggregate object table2 and has two columns and fourrows. There is a one-to-one correspondence in rows between the two tables. Therow object for table1 is table1Entry, and the row object for table 2 is table2Entry.The INDEX is defined in Table 1 for both tables and it is the columnar objectT1.E1.C1. We are using the notations T1, E1, C1, etc., for easier visualconceptualization of the instance of an object in a table using the prefixes of tableID (e.g., T1) and entry (e.g., E1). The columnar object notation starts with C (e.g.,C1). The value or values suffixed with the columnar object identifier uniquelyidentifies the row. Thus, the list of objects identified by the index T1.E1.C1.2 is theones in the second rows of Tables 1 and 2. The value of the columnar objectT2.E2.C4 in Table T2 corresponding to index T1.E1.C1.2 is T2.E2.C4.2. Table 1 iscalled the base table, and Table 2 is the augmented table. The indexing schemecomprises two clauses, the INDEX clause and the AUGMENTS clause. Theconstructs for the rows of the two tables in Figure 6.11 are shown in Figure6.12. The object table1Entry has the INDEX clause and table2Entry has theAUGMENTS clause that refers to table1Entry. The combination of the two tablesstill provides four conceptual rows, T1.E1.C1.1 through T1.E1.C1.4 (identified bythe index), the same number of rows as in the base table.

Figure 6.12. ASN.1 Constructs for Augmentation of Tables

Figure 6.13 shows an example of augmentation of tables. We have augmentedipAddrTable in the standard MIB with a proprietary table, IpAugAddrTable thatcould add additional information to the rows of the table. IpAddrTable is the basetable and ipAugAddrTable is the augmented table. In a practical case, theipAugAddrTable could add two more columnar objects defining the board and portnumber associated with the ipAdEntIfIndex.

Figure 6.13. Example of Augmentation of Tables


9 of 23 23-Sep-15 7:27 PM

A table with a larger number of rows (dense table) can be augmented to the basetable with combined indices of both, as shown in Figure 6.14. The INDEX clausefor combining unequal-sized tables is the combined indices; i.e., combinedcolumnar objects as the INDEX clause for the added aggregate object. In Figure6.14, Table 1 consists of two rows and three columnar objects, T1.E1.C1,T1.E1.C2, and T1.E1.C3, with the first columnar object T1.E1.C1 being the index.Table 2 has four rows and two columnar objects, T2.E2.C4 and T2.E2.C5, with itsfirst columnar object, T2.E2.C4, being the index. The combined index forspecifying the aggregate object of Table 2 appended to Table 1 is the set of bothfirst columnar objects, T1.E1.C1 and T2.E2.C4. Table 1 is called the base tableand Table 2 is called the dependent table. As we see in Figure 6.14, thecombined base table and the dependent table could have a maximum of 8conceptual rows (multiplication of the rows of the two tables).

Figure 6.14. Combined Indexing of Tables


Figure 6.15 shows the constructs for augmenting a dense table to a base table.The two table objects, table1 and table2, are nodes under the node table. The


10 of 23 23-Sep-15 7:27 PM

table1Entry defines a row in table1 with the columnar object T1.E1.C1 as theindex. The table2Entry is a row in table2. Its index is defined by the indices of bothtables, namely T1.E1.C1 and T2.E2.C3.

Figure 6.15. ASN.1 Constructs for Augmenting Dense Table

We can visualize the application of augmentation of a dense table with an exampleof a router with multiple slots, each slot containing a particular type of board, forexample, LEC and Ethernet shown in Figure 4.3(c). The slot and the board typewill be defined in Table 1. Each board may have a different number of physicalports. The port configuration is defined by Table 2. By using the combination of thetwo tables, we can specify the details associated with a given port in a given slot.

The third possible scenario in appending an aggregate object to an existingaggregate object is the case where the augmented table has fewer rows than thatof the base table. This is called a sparse dependent table case and is shown inFigure 6.16. In this example, the index for the second table is the same as thatfor the base table and the constructs are similar to the ones shown in Figure 6.12except that the AUGMENTS clause is substituted with the INDEX clause fortable2Entry. This is shown in Figure 6.17.

Figure 6.16. Addition of a Sparse Table to a Base Table



11 of 23 23-Sep-15 7:27 PM

Figure 6.17. ASN.1 Constructs for Augmenting Sparse Table

In SNMPv2, operational procedures were introduced for the creation and deletionof a row in a table. However, prior to discussing these procedures, let us first lookat the textual convention that was specified to create a new object type indesigning MIB modules. We will return to row creation and deletion in Section6.3.7.

6.3.6. Textual ConventionsTextual conventions are designed to help definition of new data types following thestructure defined in SMIv2. It is also intended to make the semantics consistentand clear to the human reader. Although new data types could have been createdusing new ASN.1 class and tag, the decision was made to use the existing definedclass types and apply restrictions to them. This is accomplished by defining anASN.1 macro, TEXTUAL-CONVENTION, in SMIv2.

The TEXTUAL-CONVENTION macro concisely conveys the syntax and semanticsassociated with a textual convention. SNMP-based management objects defined


12 of 23 23-Sep-15 7:27 PM

using a textual convention are encoded by the same Basic Encoding Rules thatdefine their primitive types. However, they do have the special semantics asdefined in the macro. For all textual conventions defined in an information module,the name shall be unique and mnemonic, similar to the data type and shall notexceed 64 characters. However, it is usually limited to 32 characters.

Let us now compare the definition of a type in SMIv1 with SMIv2. The textualconvention was defined in SNMPv1 as an ASN.1 type assignment. For example, thetextual convention for data type DisplayString in SNMPv1, from RFC 1213, is

DisplayString ::= OCTET STRING-- This data type is used to model textual information taken from the NVT-- ASCII character set. By convention, objects with this syntax are-- declared as having-- SIZE (0..255).

The same example of DisplayString in SNMPv2 is defined as:

Code View: Scroll / Show All

DisplayString ::= TEXTUAL-CONVENTIONDISPLAY-HINT "255a"STATUS currentDESCRIPTION "Represents textual information taken from the NVTASCII character

set, as defined in pages 4, 10-11 of RFC 854. ...."SYNTAX OCTET STRING (SIZE (0..255) )

As we can see from the above example, the TEXTUAL-CONVENTION in SNMPv2 isdefined as data type, and is used to convey the syntax and semantics of a textualconvention. The macro for textual conventions is defined in RFC 1903, and askeleton of it is presented in Figure 6.18. It has the definition of type and valuenotations with the formalized definition of data types.

Figure 6.18. TEXTUAL-CONVENTION Macro [RFC 1903]

All clauses except DisplayPart in the TEXTUAL-CONVENTION macro areself-explanatory and represent similar clauses as in SMIv1. The DISPLAY-HINTclause, which is optional, gives a hint as to how the value of an instance of anobject, with the syntax defined using this textual convention, might be displayed.It is applicable to the situations where the underlying primitive type is eitherINTEGER or OCTET STRING.

For INTEGER type, the display consists of two parts. The first part is a singlecharacter denoting the display format: “a” for ASCII, “b” for binary, “d” fordecimal, “o” for octal, and “x” for hexadecimal. It is followed by a hyphen and aninteger in the case of decimal display indicating the number of decimal points. Forexample, a hundredths value of 1234 with DISPLAY-HINT “d-2” is displayed as12.34.

For OCTET-STRING type, the display hint consists of one or more octet-format


13 of 23 23-Sep-15 7:27 PM

specifications. A brief description of each part is shown in Table 6.2. For example,the DISPLAY-HINT “255a” indicates that the DisplayString is an ASCII string of upto a maximum of 255 characters.

Table 6.2. DISPLAY-HINT for Octet-Format

1 (Optional) repeatindicator “*””

An integer, indicated by *, which specifieshow many times the remainder of thisoctet-format should be repeated

2 Octet length One or more decimal digits specifying thenumber of octets

3 Display format “b” for binary, “x” for hexadecimal, “d” fordecimal, “o” for octal, and “a” for ASCII fordisplay

4 (Optional) displayseparator character

A single character other than a decimaldigit or “*” produced after each applicationof the octet specification.

5 (Optional) repeatterminator character

A single character other than a decimaldigit or “*” present if display character ispresent. Produced after the second andthird part.

Table 6.3 shows the types for which textual conventions were specified in SMIv2.A brief description for each type is also given. They are applicable to all MIBmodules. Only those textual conventions whose status is current are given in thetable. One of the important textual conventions is RowStatus, which is used for thecreation and deletion of conceptual rows, which we will discuss next.

Table 6.3. SMIv2 Textual Conventions for Initial Data Types

DisplayString Textual information from NVT ASCII character set [RFC854]

PhysAddress Media- or physical-level address

MacAddress IEEE 802 MAC address

TruthValue Boolean value; INTEGER {true (1), false (2)}

TestAndIncr Integer-valued information used for atomic operations

AutonomousType An independently extensible type identification value

VariablePointer Pointer to a specific object instance; e.g., syscontact.0,ifInOctets.3

RowPointer Pointer to a conceptual row

RowStatus Used to manage the creation and deletion ofconceptual rows and is used as the value of theSYNTAX clause for the status column of a conceptualrow

TimeStamp Value of sysUpTime at which a specific occurrencehappened

TimeInterval Period of time, measured in units of 0.01 seconds

DateandTime Date–time specifications

StorageType Implementation information on the memory realizationof a conceptual row as to the volatility and permanency

Tdomain Kind of transport service

Taddress Transport service address

6.3.7. Creation and Deletion of Rows in TablesThe creation of a row and deletion of a row are significant new features in SMIv2.


14 of 23 23-Sep-15 7:27 PM

This is patterned after a similar procedure that was developed for RMON, which wewill cover in Chapter 8. There are two methods to create a row in a table. Thefirst is to create a row and make it active, which is available immediately. Thesecond method is to create the row and make it available at a later time. Thismeans that we need to know the status of the row as to its availability.

The information on the status of the row is accomplished by introducing a newcolumn, called the status column. In Table 6.3, we observe that for the textualconvention, RowStatus is used as the value of the SYNTAX clause for the statuscolumn of a conceptual row. Table 6.4 shows the status with enumerated integersyntax for the six states associated with the row status. The last three states,along with the first one (1, 4, 5, and 6), are those that the manager uses to createor delete rows on the agent. The first three states (1, 2, and 3) are those that areused by the agent to send responses to the manager.

Table 6.4. RowStatus Textual Convention

State Enumeration Description

active 1 Row exists and is operational

notInService 2 Operation on the row is suspended

notReady 3 Row does not have all the columnarobjects needed

createAndGo 4 This is a one-step process ofcreation of a row, immediately goesinto the active state

createAndWait 5 Row is under creation and shouldnot be commissioned into service

destroy 6 Same as Invalid in EntryStatus. Rowshould be deleted

The MAX-ACCESS clause is extended to include “read-create” for the status object,which includes read, write, and create privileges. It is a superset of read-write. If astatus columnar object is present, then no other columnar object of the sameconceptual row may have a maximal access of “read-write.” But it can have objectswith maximum access of read-only and not-accessible. If an index object of aconceptual row is also a columnar object (it does not always have to be), it iscalled auxiliary object and its maximum access is made non-accessible. Therecould be more than one index object to define a conceptual row in a table.

Let us now analyze the create and delete operations using the conceptual tableshown in Figure 6.19. The table, table1, originally has two rows and threecolumns. The first column, status, has the value of the status of the row asindicated by the enumerated integer syntax of RowStatus textual convention. Thesecond columnar object, index, is the index for the conceptual row of entry1; andthe third columnar object contains non-indexed data. We will illustrate the twotypes of row-creation and row-deletion operations by adding a third row and thendeleting it.

Figure 6.19. Conceptual Table for the Creation and Deletion of a Row


15 of 23 23-Sep-15 7:27 PM

As we notice from Table 6.4, there are two states for RowStatus, createAndGoand createAndWait, which are action operations. In the former, the manager sendsa message to the agent to create a row and make the status active immediately.In the latter operation, the manager sends a message to create a row, but not tomake it active immediately. Figure 6.20 shows the Create-and-Go operation. Themanager process initiates a Set-Request-PDU to create a conceptual row with thevalues given for the three columnar instances of the row. The value for the indexcolumn is specified by the VarBind index = 3. This is suffixed to the other twocolumnar objects in the new row to be created. The value of status is specified as4, which is the createAndGo state as seen in Table 6.4. The set-requestmessage also specifies the default value DefData for data.3, and thus all theinformation needed to establish the row and turn it into an active state iscomplete. The agent process interacts with the managed entity, creates theinstance successfully, and then transmits a response to the manager process. Thevalue of the status is 1, which denotes that the row is in an active state. Theresponse also contains the values of the other columnar object instances.

Figure 6.20. Create-and-Go Row Creation


Figure 6.21 presents a scenario for operational sequence in the creation of a rowusing the Create-and-Wait method. Again, this illustration takes the same scenarioof adding the third row to the table shown in Figure 6.17. Only the manager andthe agent are shown and not the managed entity in this figure. The managerprocess sends a Set-Request-PDU to the agent process. The value for status is 5,which is to create and wait. The third columnar object expects a default value,which is not in the set-request message. Hence, the agent process responds with astatus value of 3, which is notReady. The manager sends a get-request to get thedata for the row. The agent responds with noSuchInstance message, indicatingthat the data value is missing. The manager subsequently sends the value for dataand receives a response of notInService (2) from the agent. The fourth and finalexchange of messages in the figure is to activate the row with a status value of 1.


16 of 23 23-Sep-15 7:27 PM

With each message received from the manager, the agent either validates or setsthe instance value on the managed entity.

Figure 6.21. Create-and-Wait Row Creation

A summary of possible state transitions is given in Table 6.5. The first columnlists the action; and the transitions based on the present state are listed in thenext four columns.

goto B or C, depending on information available to the agent.1.

If other variable bindings included in the same PDU provide values for allcolumns, which are missing but are required, then return noError andgoto D.

2.

If other variable bindings included in the same PDU provide values for allcolumns, which are missing but are required, then return noError andgoto C.

3.

At the discretion of the agent, the return value may be either:inconsistentName: because the agent does not choose to create such aninstance when the corresponding RowStatus instance does not exist, orinconsistentValue: if the supplied value is inconsistent with the state ofsome other MIB object’s value, or noError; because the agent chooses tocreate the instance.

If noError is returned, then the instance of the status column must also becreated, and the new state is B or C, depending on the informationavailable to the agent. If inconsistentName or inconsistent Value isreturned, the row remains in state A.

4.

Depending on the MIB definition for the column/table, either noError orinconsistentValue may be returned.

NOTE: Other processing of the set request may result in a response otherthan noError being returned, e.g., wrongValue, noCreation, etc.

5.

Table 6.5. Table of States for Row Creation and Deletion

Action A Status B Status column C Status column D Status


17 of 23 23-Sep-15 7:27 PM

column doesnot exist

notReady notInService column active

Set statuscolumn tocreateAndGo

noError -> D inconsistent-Value inconsistent-Value inconsistent-Value

Set statuscolumn tocreateAndWait

noError, see 1 orwrongValue

inconsistent-Value inconsistent-Value inconsistent-Value

Set statuscolumn toactive

inconsistent-Value inconsistent-Valueor see 2 ->D

noError ->D noError ->D

Set statuscolumn tonotInService

inconsistent-Value inconsistent-Valueor see 3 -> C

noError ->C noError ->C orwrongValue

Set statuscolumn todestroy

noError ->A noError ->A noError ->A noError ->A

Set any othercolumn tosome value

see 4 noError see 1 noError ->C see 5 ->D

The operation of deletion of a row is simple. A set-request with a value of 6,which denotes destroy, for status, is sent by the manager process to the agentprocess. Independent of the current state of the row, the row is deleted and theresponse sent back by the agent. The instance in the managed entity is deleted inthe process. This is shown in Figure 6.22.

Figure 6.22. Row Deletion

6.3.8. Notification DefinitionsThe trap information in SMIv1 has been redefined using the NOTIFICATION-TYPEmacro in SMIv2. As we will see in Section 6.5, the PDU associated with the trapinformation is made consistent with other PDUs. The NOTIFICATION-TYPE macrocontains unsolicited information that is generated on an exception basis, forexample, when set thresholds are crossed. It can be transmitted within either aSNMP-Trap-PDU from an agent or an InformRequest-PDU from a manager. Twoexamples of a NOTIFICATION-TYPE macro, drawn from RFC 1902 and RFC 1907are shown in Figure 6.23. The first example, linkUp, is generated by an agentwhen a link that has been down comes up.

Figure 6.23. Examples of NOTIFICATION-TYPE Macro


18 of 23 23-Sep-15 7:27 PM

The OBJECTS clause defines the ordered sequence of MIB objects, which areincluded in the notification. It may or may not be present. The second example,coldStart, in Figure 6.23, has the OBJECTS clause missing and is not needed.

The other two clauses, STATUS and DESCRIPTION, have the usual mappings.

We have not presented here discussions on refined syntax in some of the macros,as well as extension to informational modules. You are referred to RFC 1902 for atreatment of these, which also discusses the conversion of a managed object fromthe OSI to the SNMP version.

6.3.9. Conformance StatementsRFC 1904 defines SNMPv2 conformance statements for the implementation ofnetwork management standards. A product, generally, is considered to be incompliance with a particular standard when it meets the minimum set of featuresin its implementation. Minimum requirements for SNMPv2 compliance are calledmodule compliance and are defined by an ASN.1 macro, MODULE-COMPLIANCE. Itspecifies the minimum MIB modules or a subset of modules that should beimplemented. The actual MIB modules that are implemented in an agent arespecified by another ASN.1 module, AGENT-CAPABILITIES. For the convenience ofdefining module compliance and agent capabilities, objects and traps have beencombined into groups, which are subsets of MIB modules. Object grouping isdefined by an ASN.1 macro, OBJECT-GROUP, and the group of traps is defined bythe NOTIFICATION-GROUP macro.

Object Group. The OBJECT-GROUP macro defines a group of related objects in aMIB module and is used to define conformance specifications. It is compiled duringimplementation, not at run-time. The macro is shown in Figure 6.24. Theimplementation of an object in an agent implies that it executes the get and setoperations from a manager. If an agent in SNMPv2 has not implemented an object,it returns a noSuchObject error message.

Figure 6.24. OBJECT-GROUP Macro


19 of 23 23-Sep-15 7:27 PM

The OBJECTS clause names each object contained in the conformance group. Eachof the named objects is defined in the same informational module as theOBJECT-GROUP macro and has a MAX-ACCESS clause of “accessible-for-notify,”“read-only,” “read-write,” or “read-create.” Every object that is defined in aninformational module with a MAX-ACCESS clause other than “not-accessible” ispresent in at least one object group. This prevents the mistake of adding an objectto an information module, but forgetting to add it to a group.

The STATUS, DESCRIPTION, and REFERENCE clauses have the usualinterpretations.

An example of an OBJECT-GROUP, systemGroup in SNMPv2, is shown in Figure6.25. The system group defines the objects, which pertain to overall informationabout the system. Since it is so basic, it is implemented in all agent andmanagement systems. All seven entities defined as values for OBJECTS should beimplemented. There are some new entities, such as sysORLastChange, in thegroup that were not in SNMPv1. These will be addressed when we discuss SMPv2MIB in the next section.

Figure 6.25. Example of an OBJECT-GROUP Macro

Notification Group. The notification group contains notification entities, or whatwas defined as traps in SMIv1. The NOTIFICATION-GROUP macro is shown inFigure 6.26. The macro is compiled during implementation, not during run-time.The value of an invocation of the NOTIFICATION-GROUP macro is the name of thegroup, which is an OBJECT IDENTIFIER.

Figure 6.26. NOTIFICATION-GROUP Macro


20 of 23 23-Sep-15 7:27 PM

An example of NOTIFICATION-GROUP, snmpBasicNotificationsGroup, is shown inFigure 6.27. According to this invocation, the conformance group,snmpBasicNotificationsGroup, has two notifications: coldStart andauthenticationFailure.

Figure 6.27. Example of a NOTIFICATION-GROUP Macro

Module Compliance. The MODULE-COMPLIANCE macro, shown in Figure 6.28,defines the minimum set of requirements for implementation of one or more MIBmodules. The expansion of the MODULE-COMPLIANCE macro is done during theimplementation and not during run-time. The MODULE-COMPLIANCE macro can bedefined as a component of the information module or as a companion module.

Figure 6.28. MODULE-COMPLIANCE Macro


21 of 23 23-Sep-15 7:27 PM

The STATUS, DESCRIPTION, and REFERENCE clauses are self-explanatory.

The MODULE clause is used to name each module for which compliancerequirements are specified. Modules are identified by the module name and itsOBJECT IDENTIFIER. The latter can be dropped if the MODULE-COMPLIANCE isinvoked within an MIB module and refers to the encompassing MIB module.

There are two CLAUSES of groups that are specified by the MODULE-COMPLIANCEmacro. They are MANDATORY-GROUPS and GROUP. As the name implies, theMANDATORY-CLAUSE modules have to be implemented for the system to beSNMPv2 compliant. The group specified by the GROUP clause is not mandatory forthe MIB module, but helps vendors define specifications of the features that havebeen implemented.

When both WRITE-SYNTAX and SYNTAX clauses are present, restrictions areplaced on the syntax for the object mentioned in the OBJECT clause. Theserestrictions are tabulated in Section 9 of RFC 1902.

The snmpBasicCompliance macro is an example of a MODULE-COMPLIANCE macroand is part of the SNMPv2 MIB presented in Figure 6.6. A system is defined asSNMPv2 compliant if and only if snmpGroup, snmpSetGroup, systemGroup, andsnmpBasicNotificationsGroup are implemented. The GROUP,snmpCommunityGroup, is optional.

Agent Capabilities. The AGENT-CAPABILITIES macro is lengthy and the reader isreferred to RFC 1904 for exact specifications. A skeleton of the macro andsignificant points of the macro are covered here and are shown in Figure 6.29.

Figure 6.29. AGENT-CAPABILITIES Macro (Skeleton)


22 of 23 23-Sep-15 7:27 PM

Related Content

The AGENT-CAPABILITIES macro for the router example given in Figure 6.10 isshown in Figure 6.30. Note that snmpMIB model, which is SNMPv2-MIB, includessystem and snmp MIBs. Those MIBs and the associated groups are supported bythe router. Other standard MIBs and groups supported by the router are indicatedin Figure 6.30.

Figure 6.30. Example of an AGENT-CAPABILITIES Macro


23 of 23 23-Sep-15 7:27 PM

This Book

Notes

Bookmarks

Search

Contents



Copyright

Endorsements

Preface

About the Author

Pt. I. Background







SNMPv2 SystemArchitecture


SNMv2 ManagementInformation BaseSNMPv2 Protocol


Summary

Exercises










Trademarks

Acronyms

Glossary

References

Index

Chapter 6. SNMP Management: SNMPv2 > SNMv2 Management Information Base

6.4. SNMv2 Management Information BaseAs mentioned in Section 6.2 and shown in Figure 6.5 two new MIBmodules, security and SNMPv2, have been added to the Internet MIB. TheSNMPv2 module has three submodules: snmpDomains, snmpProxys, andsnmpModules. snmpDomains extends the SNMP standards to sendmanagement messages over transmission protocols other than UDP, which isthe predominant and preferred way of transportation [RFC 1906]. SinceUDP is the preferred protocol, systems that use another protocol need aproxy service to map on to UDP. Not much work has been done onsnmpProxys, as of now.

There are changes made to the core MIB-II defined in SNMPv1. Figure 6.31presents an overview of the changes to the Internet MIB and theirrelationship. The system module and the snmp module under mib-2 havesignificant changes as defined in RFC 1907. A new module snmpMIB hasbeen defined, which is {snmpModules 1}. There are two modules undersnmpMIB: snmpMIBObjects and snmpMIBConformance.

Figure 6.31. SNMPv2 Internet Group

The MIB module snmpMIBObjects addresses the new objects introduced inSNMPv2, as well as those that are obsolete. This is primarily concerned withtrap, which has been brought into the same format as other PDUs. Also,many of the unneeded objects in the SNMP group have been made obsolete.

We discussed conformance specifications and object groups in the previoussection. These are specified under the snmpMIBconformance module. AsSNMPv2 is currently defined, there is a strong coupling between system,snmp, snmpMIBObjects, and snmpMIBconformance modules. With thispicture in mind, it will be a lot easier to follow RFC 1907, which discusses allthese modules.

6.4.1. Changes to the System Group in SNMPv2


1 of 7 23-Sep-15 7:28 PM

There are seven entities or objects in SNMPv2, which are common to asystem. Additional information is added to the System group in SNMPv2,which contains a collection of objects that support various MIB modules.These are called object resources and are configurable both statically anddynamically. Figure 6.32 shows the MIB tree for the System group inSNMPv2. The sysORLastChange entity and sysORTable have been added tothe set of objects in the System group. Table 6.6 presents the entity, OID,and a brief description of each entity for the System group.

Figure 6.32. SNMPv2 System Group

Table 6.6. SNMPv2 System Group

Entity OID Description (Brief)

sysDescr system 1 Textual description

sysObjectID system 2 OBJECT IDENTIFIER of the entity

sysUpTime system 3 Time (in hundredths of a secondsince last reset)

sysContact system 4 Contact person for the node

sysName system 5 Administrative name of the system

sysLocation system 6 Physical location of the node

sysServices system 7 Value designating the layer servicesprovided by the entity

sysORLastChange system 8 SysUpTime since last change instate or sysORID change

sysORTable system 9 Table listing system resources thatthe agent controls; manager canconfigure these resources throughthe agent.

sysOREntry sysORTable 1 An entry in the sysORTable

sysORIndex sysOREntry 1 Row index, also index for the table

sysORID sysOREntry 2 ID of the resource module


2 of 7 23-Sep-15 7:28 PM


sysORDescr sysOREntry 3 Textual description of the resourcemodule

sysORUpTime sysOREntry 4 System up-time since the object inthis row was last instantiated

6.4.2. Changes to the SNMP Group in SNMPv2The SNMP group in SNMPv2 has been considerably simplified from SNMPv1by eliminating a large number of entities that were considered unnecessary.The simplified SNMP group is shown in Figure 6.33 (compare with Figure5.21!). It has only eight entities, six old ones (1,3,4,5,6,30) and two newones (31,32). Figure 6.33 also presents the four groups of all SNMPentities: snmpGroup, snmpCommunityGroup, snmpObsoleteGroup, and thegroup of two objects, 7 and 23, not used even in version 1. We will soon seethat the snmpGroup is mandatory to implement for compliance of SNMPv2and the snmpCommunityGroup is optional. The snmpObsoleteGroup isself-explanatory.

Figure 6.33. SNMPv2 SNMP Group

The SNMPv2 SNMP group table is shown in Table 6.7. All the unused andobsolete entities have been omitted for clarity.

Table 6.7. SNMPv2 SNMP Group


snmpInPkts snmp (1) Total number of messagesdelivered from transport service

snmpInBadVersions snmp (3) Total number of messages fromtransport service that are ofunsupported version

snmpInBadCommunityNames snmp (4) Total number of messages fromtransport service that are ofunknown community name

snmpInBadCommunityUses snmp (5) Total number of messages fromtransport service, of not allowedoperation by the sendingcommunity


3 of 7 23-Sep-15 7:28 PM


snmpInASNParseErrs snmp (6) Total number of ASN.1 and BERerrors

snmpEnableAuthenTraps snmp (30) Override option to generateauthentication failure traps

snmpSilentDrops snmp (31) Total number of the five types ofreceived PDUs that were silentlydropped due to exceptions invar-binds or max. message size

snmpProxyDrops snmp (32) Total number of the five types ofreceived PDUs that were silentlydropped due to inability torespond to a target proxy

6.4.3. Information for Notification in SNMPv2Information on traps in SNMPv1 has been restructured in version 2 toconform to the rest of the PDUs. The macro TRAP-TYPE, used in version 1and described in RFC 1215, has been made obsolete in SNMPv2. At thesame time, enhancement to specifications has been made, and theterminology has been generalized to “notification,” as the subheadingindicates.

The information on notifications is defined under snmpMIBObjects and isshown in Figure 6.34. There are three modules under the snmpMIBObjectsnode: snmpTrap (4), snmpTraps (5), and snmpSet (6). The subnodedesignations 1, 2, and 3 under snmpMIBObjects have been made obsolete.A brief description of the subnodes and leaf objects under snmpMIBObjectsis given in Table 6.8.

Figure 6.34. MIB Modules under snmpMIBObjects

Table 6.8. snmpMIBObjects MIB


snmpTrap snmpMIBObjects4

Information group containing trapID and enterprise ID

snmpTrapOID snmpTrap 1 OBJECT IDENTIFIER of thenotification

snmpTrapEnterprise snmpTrap 2 OBJECT IDENTIFIER of theenterprise sending the notification


4 of 7 23-Sep-15 7:28 PM


snmpTraps snmpMIBObjects5

Collection of well-known trapsused in SNMPv1

coldStart snmpTraps 1 Trap informing of a cold start ofthe object

warmStart snmpTraps 2 Trap informing of a warm start ofthe object

linkDown snmpTraps 3 Agent detecting a failure of acommunication link

linkUp snmpTraps 4 Agent detecting coming up of acommunication link

authentificationFailure snmpTraps 5 Agent reporting receipt of anunauthenticated protocol message

snmpSet snmpMIBObjects6

Manager-to-Manager notificationmessages

snmpSetSerialNo snmpSet 1 Advisory lock between managersto coordinate set operation

The snmpTrap group contains information on the OBJECT IDENTIFIERs ofthe trap and the enterprise responsible to send the trap. A new value,accessible-for-notify, has been added to the MAX-ACCESS clause to defineobjects under snmpTrap.

The entities under snmpTraps are the well-known traps that are currently inextensive use in SNMPv1. The snmpSetSerialNo is a single entity undersnmpSet and is used by coordinating manager objects to perform the setoperation. This is intended as coarse coordination only; fine-graincoordination may require more MIB objects in appropriate groups.

6.4.4. Conformance Information in SNMPv2Conformance information is defined by the snmpMIBConformance module,as shown in Figure 6.35. It consists of two submodules,snmpMIBcompliances and snmpMIBGroups. The snmpMIBCompliancesmodule has been extensively covered in Section 6.3.9. Units ofconformance are defined in terms of OBJECT-GROUPS, mentioned inSection 6.3.9. Table 6.9 presents the various OBJECT-GROUPs defined inSNMPv2 and associated OBJECTS for all but snmpObsoleteGroup, which isshown in Figure 6.33.

Figure 6.35. MIB Modules under snmpMIBConformance



5 of 7 23-Sep-15 7:28 PM

Table 6.9. SNMPv2 OBJECT-GROUPs

OBJECT-GROUPs OID OBJECTS

snmpSetGroup snmpMIBGroups 5 snmpSetSerialNo

systemGroup snmpMIBGroups 6 sysDescr

sysObjectID

sysUpTime

sysContact

sysName

sysLocation

sysServices

sysORLastChange

sysORID

sysORUpTime

sysORDescr

snmpBasicNotificationGroup

snmpMIBGroups 7 coldStart

authenticationFailure

snmpGroup snmpMIBGroups 8 snmpInPkts

snmpInBadVersions

snmpInASNParseErrs

snmpSilentDrops

snmpProxyDrops

snmpEnableAuthenTraps

snmpCommunityGroup snmpMIBGroups 9 snmpInBadCommunityNames

snmpInBadCommunityUses

snmpObsoleteGroup snmpMIBGroups 10 Please see Figure 6.33

6.4.5. Expanded Internet MIB-IIAs SNMP network management expands covering legacy as well as newtechnology, MIB modules are continuously increasing. Figure 6.36 showsan expanded MIB-II when SNMPv2 was released and has more modulesthan those covered in RFC 1213. It is not intended to be an exhaustive listbut includes RMON MIB module that we will be addressing in this textbook.Table 6.10 gives a description of each group in the MIB.

Figure 6.36. Expanded Internet MIB-II Group


6 of 7 23-Sep-15 7:28 PM

Related Content

Table 6.10. Expanded MIB-II Group

Group OID Description (Brief)

ifMIB mib-2 31 Extension to interfaces groupfor new technologies

appletalk mib-2 13 MIB for appletalk networks

ospf mib-2 14 Open Shortest Path Firstrouting protocol MIB

bgp mib-2 15 MIB for Border GatewayProtocol for inter-autonomousnetwork routing

rmon mib-2 16 MIB for remote monitoringusing RMON probe; there areMIBs under this for Ethernetand Token Ring networks

bridge mib-2 17 MIB for bridges

decnet mib-2 18 Digital Equipment CorporationDECnet MIB

character mib-2 19 MIB for ports with characterstream output for computerperipheral


7 of 7 23-Sep-15 7:28 PM

This Book

Notes

Bookmarks

Search

Contents



Copyright

Endorsements

Preface

About the Author

Pt. I. Background










SNMPv2 ProtocolCompatibility withSNMPv1

Summary

Exercises










Trademarks

Acronyms

Glossary

References

Index

Chapter 6. SNMP Management: SNMPv2 > SNMPv2 Protocol

6.5. SNMPv2 ProtocolSNMPv2 protocol operations are based on a community administrativemodel, which is the same as in SNMPv1. This was discussed in Section5.2.2. We presented SNMPv2 protocol operations from a system architectureview in Section 6.2. In this section we will discuss details of PDU datastructures and protocol operations.

6.5.1. Data Structure of SNMPv2 PDUsThe PDU data structure in SNMPv2 has been standardized to a commonformat for all messages. This improves the efficiency and performance ofmessage exchange between systems. The significant improvement isbringing the trap data structure in the same format as the rest. The genericPDU message structure is shown in Figure 6.37 and is the same as Figure5.8 of SNMPv1. The PDU type is indicated by an INTEGER. The error-statusand 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 theget-response message if there is no error; otherwise the type of error isindicated. The PDU and error-status are listed in Table 6.11. Theerror-index is set to zero if there is no error. If there is an error, it identifiesthe first variable binding in the variable-binding list that caused the errormessage. The first variable binding in a request’s variable-binding list isindex one, the second is index two, etc.

Figure 6.37. SNMPv2 PDU (all but bulk)

Table 6.11. Values for Types of PDU andError-status Fields in SNMPv2 PDU

Field Type Value

PDU 0 Get-Request-PDU

1 GetNextRequest-PDU

2 Response-PDU

3 Set-Request-PDU

4 obsolete

5 GetBulkRequest-PDU

6 InformRequest-PDU

7 SNMPv2-Trap-PDU

ErrorStatus

0 noError

1 tooBig


1 of 6 23-Sep-15 7:28 PM

Field Type Value

2 noSuchName

3 badValue

4 readOnly

5 genErr

6 noAccess

7 wrongType

8 wrongLength

9 wrongEncoding

10 wrongValue

11 noCreation

12 inconsistentValue

13 resourceUnavailable

14 commitFailed

15 undoFailed

16 authorizationError

17 notWritable

18 inconsistentName

There is a difference in usage of the error-status and error-index fieldsbetween SNMPv1 and SNMPv2. In version 1, any error encountered by theagent in responding to requests from the manager generates a non-zerovalue in either the error-status field or in both the error-status anderror-index fields. Values in variable bindings are returned only undernon-error conditions.

However, in SNMPv2, if only the error-status field of the Response-PDU isnon-zero, the value fields of the variable binding in the variable-binding listare ignored. If both the error-status field and the error-index field of theResponse-PDU are non-zero, then the value of the error-index field is theindex of the variable binding (in the variable-binding list of thecorresponding request) for which the request failed. Values in other variablebindings in the variable-binding list are returned with valid values andprocessed by the manager.

The generic PDU format is applicable to all SNMPv2 messages except theGet-Bulk-Request PDU, for which the format is shown in Figure 6.38. It canbe seen that the format of the structure is the same in both cases, exceptthat in the get-bulk-request message, the third and fourth fields aredifferent. The third field, the error-status field, is replaced by non-repeaters;and the fourth field, the error-index field, is replaced by max-repetitions. Aswe mentioned in Section 6.2, the get-bulk-request enables us to retrievedata in bulk. We can retrieve a number of both non-repetitive scalar valuesand repetitive tabular values with a single message. Non-repeaters indicatethe number of non-repetitive field values requested; and themax-repetitions field designates the maximum number of table rowsrequested. We will next look at the SNMPv2 operations using PDUs.

Figure 6.38. SNMPv2 GetBulkRequest PDU

6.5.2. SNMPv2 Protocol Operations


2 of 6 23-Sep-15 7:28 PM

There are seven protocol operations in SNMPv2, as discussed in Section6.2. We will ignore the report operation, which is not used. The messages,get-request, get-next-request, set-request, and get-response, are inboth SNMPv1 and SNMPv2 versions and operate in a similar fashion. Thetwo additional messages that are in SNMPv2, which are not in version 1, arethe GetBulkRequest and InformRequest. The command, get-bulk-request,is an enhancement of get-next request and retrieves data in bulk efficiently.This is covered in the next subsection. The InformRequest is covered in asubsequent section along with SNMPv2-Trap, which has been modified inversion 2.

GetBulkRequest PDU Operation. The get-bulk-request operation isadded in SNMPv2 to retrieve bulk data from a remote entity. Its greatestbenefit is in retrieving multiple rows of data from a table. The basicoperation of get-bulk-request is the same as get-next-request. The third andfourth field positions are used in get-bulk-request message PDU asnon-repeaters and max-repetitions, as shown in Figure 6.38. Thenon-repeaters field indicates the number of non-repetitive (scalar) objects tobe retrieved. The max-repetitions field defines the maximum number ofinstances to be returned in the response message. This would correspond tothe number of rows in an aggregate object. The value for themax-repetitions field is operation-dependent and is determined by suchfactors as the maximum size of the SNMP message, or the buffer size inimplementation, or the expected size of the aggregate object table.

The data structure of the response for the get-bulk-request operation differsfrom other get and set operations. Successful processing of the get-bulk-request produces variable bindings (larger array of VarBindList) in theresponse PDU, which is larger than that contained in the correspondingrequest. Thus, there is no one-to-one relationship between the VarBindListof the request and response messages.

Figure 6.39 shows a conceptual MIB to illustrate the operation of get-next-request and get-bulk-request shown in Figure 6.40 and Figure 6.41. It issimilar to Figure 5.12 with two additional rows added to the table. Tonotice the difference in improvement of get-bulk-request over get-next-request, let us look at Figure 6.40, which shows the sequence of operationsfor get-next-request for the MIB shown in Figure 6.39. The sequence startswith a get-request message from the manager process with a VarBindListarray of two scalar variables A and B. It is subsequently followed by theget-next-request message with three columnar OBJECT IDENTIFIERS T.E.1,T.E.2, and T.E.3. The get-response returns the first instance values T.E.1.1,T.E.2.1, and T.E.3.1. The sequence of operation continues until the fourthinstance is retrieved. The last get-next-request message with the OBJECTIDENTIFIERS T.E.1.4, T.E.2.4, and T.E.3.4 generates the values T.E.2.1,T.E.3.1, and Z. This is because there are no more instances of the table. Itretrieves the three objects, which are logically the next lexicographicallyhigher objects—namely T.E.2.1 (next to T.E.1.4), T.E.3.1 (next to T.E.2.4),and Z (next to T.E.3.4). The manager would stop the sequence at thismessage. However, if it continues the operation, it would receive anoSuchName error message.

Figure 6.39. MIB for Operation Sequences in Figures 6.40 and6.41


3 of 6 23-Sep-15 7:28 PM

Figure 6.40. Get-Next-Request Operation for MIB in Figure 6.39


Figure 6.41. Get-Bulk-Request Operation for MIB in Figure 6.39



4 of 6 23-Sep-15 7:28 PM

Figure 6.41 shows the sequence of operations to retrieve the MIB shown inFigure 6.39 using the get-bulk message. The entire MIB data are retrievedin two requests. The first message GetBulkRequest (2, 3, A, B, T.E.1, T.E.2,T.E.3) is a request for receiving two non-repetitive objects (the first variable(2) in the request command) and three repetitive instances (the secondoperand (3) in the command) of the columnar objects (T.E.1, T.E.2, andT.E.3). The response returns values of A and B for the non-repetitiveobjects, and the first three rows of the aggregate object table. The secondrequest is for three more rows of the table. Since there is only one more rowleft to send, the response message contains the information in the last row,the next lexicographic entity, Z, and the error message endOfMibView. Themanager interprets this as end of the table.

Figure 6.42 shows the retrieval of the Address Translation table shown inFigure 5.16 using the get-bulk-request operation. Instead of four sets ofget-next-request and get-response messages, only two get-bulk-request andresponse messages are needed in the get-bulk-request operation.

Figure 6.42. Get-Bulk-Request Example


SNMPv2-Trap and InformRequest PDU Operations. The SNMPv2-TrapPDU performs the same function as in version 1. As we notice, the name hasbeen changed, as well as its data structure to the generic format shown inFigure 6.37. The variable bindings in positions 1 and 2 are specified assysUpTime and snmpTrapOID, as shown in Figure 6.43. The destination(s)to which a trap is sent is implementation-dependent.

Figure 6.43. SNMPv2 Trap PDU


A trap is defined by using a NOTIFICATION-TYPE macro. If the macrocontains an OBJECTS clause, then the objects defined by the clause are inthe variable bindings in the order defined in the clause. For example, wemay want to know what interface is associated with a linkUp trap. In thiscase the linkUp NOTIFICATION-TYPE would have ifIndex as an object in itsOBJECTS clause, as shown in Figure 6.44.

Figure 6.44. Example of an OBJECTS Clause in aNOTIFICATION-TYPE Macro


5 of 6 23-Sep-15 7:28 PM

An InformRequest PDU is generated by a manager (in contrast to a trapgenerated by an agent) to inform another manager of information in its MIBview. While a trap is received passively by a manager, an InformRequestgenerates a response in the receiving manager to send to the sendingmanager.


6 of 6 23-Sep-15 7:28 PM

This Book

Notes

Bookmarks

Search

Contents



Copyright

Endorsements

Preface

About the Author

Pt. I. Background










SNMPv2 Protocol

Compatibility withSNMPv1Summary

Exercises










Trademarks

Acronyms

Glossary

References

Index

Chapter 6. SNMP Management: SNMPv2 > Compatibility with SNMPv1

6.6. Compatibility with SNMPv1An SNMP proxy server, in general, converts a set of non-SNMP entities into aset of SNMP-defined MIB entities. Unfortunately, SNMPv2 MIB is notbackward compatible with SNMPv1 and hence requires conversion ofmessages. SNMPv2 IETF Working Group has proposed [RFC 1908] twoschemes for migration from SNMPv1 to SNMPv2: bilingual manager andSNMP proxy server.

6.6.1. Bilingual ManagerOne of the migration paths to transition to SNMPv2 from version 1 is toimplement both SNMPv1 and SNMPv2 interpreter modules in the managerwith a database that has profiles of the agents’ version. The interpretermodules do all the conversions of MIB variables and SNMP protocoloperations in both directions. The bilingual manager does the commonfunctions needed for a management system. The SNMP PDU contains theversion number field to identify the version (see Figure 5.5). Thisarrangement is shown in Figure 6.45. This is expensive to implement andmaintain. The alternative scheme is to use a proxy server.

Figure 6.45. SNMP Bilingual Manager

6.6.2. SNMP Proxy ServerThe SNMPv2 proxy server configuration is shown in Figure 6.46. Therequests to and responses from, as well as traps from, SNMPv2 agents areprocessed by the SNMPv2 manager with no changes. A proxy server isimplemented as a front-end module to the SNMPv2 manager forcommunication with SNMPv1 agents.

Figure 6.46. SNMPv2 Proxy Server Configuration


1 of 2 23-Sep-15 7:29 PM

Figure 6.47 details the conversions that are done by an SNMP v2–v1 proxyserver. The get-Request, GetNextRequest-PDU, and Set-Request-PDU fromthe SNMPv2 manager are passed through unaltered by the proxy server.There are two modifications done to the GetBulkRequest PDU. The values forthe two fields, non-repeaters and max-repetitions, are set to zero andtransmitted as GetNextRequest PDU. The GetResponse from SNMPv1 ispassed through unaltered by the proxy server to the SNMPv2 manager,unless a response has a tooBigError value. In the exception case, thecontents of the variable-binding field are removed before propagating theresponse. The trap from the SNMPv1 agent is prepended with two VarBindfields, sysUpTime.0 and snmpTrapOID.0, with their associated values andthen passed on to the SNMPv2 manager as SNMPv2-Trap PDU.

Figure 6.47. SNMP v2–v1 Proxy Server



2 of 2 23-Sep-15 7:29 PM

This Book

Notes

Bookmarks

Search

Contents



Copyright

Endorsements

Preface

About the Author

Pt. I. Background










SNMPv2 Protocol


Summary

Chapter 6. SNMP Management: SNMPv2 > Summary

SummaryA significant number of network management systems and agents that areon the market today use SNMP version 1, referred to as SNMPv1. However,some of the features that have been added to SNMPv1 have been formallydefined in SNMPv2. We have learned enhancements in SNMPv2 over that ofSNMPv1 in this chapter.

The enhancements to SNMP architecture are the formalization of manager-to-manager communication and the inclusion of traps as part of the SMI andmessages, instead of as an appendix to SMI as in SNMPv1. Three additionalmessages have been added. They are get-bulk-request, inform-request, andreport. Only get-bulk-request and inform-request details have been definedand the report is left to the implementers of a system. The report is notused in practice at present.

There are several changes to SMI in SMIv2. Modules are formally introducedusing the MODULE-IDENTITY macro. An OBJECT-IDENTITY macro definesthe MIB objects; and a NOTIFICATION-TYPE macro defines traps andnotifications. SMIv2 has been split into three parts, each being defined in aseparate RFC. They are module definitions, textual conventions, andconformance specifications. Module definitions specify the rules for definingnew modules. Textual conventions help define precise descriptions ofmodules for human understanding. Conformance specifications are intendedto interpret what the vendor is specifying in the network component withregard to compliance with SNMP management. Object groups are introducedto group a number of related entities. Conformance specifications detail themandatory groups that should be implemented to be SNMP conformant. Theobject groups also help vendors define the capabilities of the system whenthey implement additional groups beyond that of mandatory ones.

Two new modules have been added to the Internet module. They aresecurity and snmpV2. The security module is, as of now, a placeholder in theMIB tree as no consensus could be reached within the working group indefining it. It is specified in SNMPv3, which is covered in Chapter 7. TheSystem and SNMP groups have been modified in the Internet MIB.Additional objects have been added to the System group that supportsvarious MIB modules. A large number of entities have been made obsoletein the SNMP module. Obsolete entities are defined as an obsolete group inthe SNMPv2 module. The SNMPv2 module also defines the MIB definition forcompliance groups. Object groups defining a collection of related entities aredefined to specify vendor compliance and capabilities.

All protocol PDUs, including trap, have been unified into a common dataformat. The newly introduced get-bulk-request is intended to improve theefficiency of get-next request in SNMPv1 by retrieving data in largequantities. The get-next-request is still maintained in this version.Interoperability between management systems has been facilitated by a newmessage, inform-request. We have given a conceptual presentation of tablemanagement, as this has become important when multiple managementsystems try to set configuration on an agent at the same time.

The unfortunate part of SNMPv2 is that it is not backward compatible with


1 of 2 23-Sep-15 7:29 PM

SNMPv1. Two schemes have been recommended for migrating from version1 to version 2. Proxy server is the preferred approach over that of abilingual manager. Proxy server can also be developed for managingnon-SNMP agents with an SNMP manager.


2 of 2 23-Sep-15 7:29 PM

network management principles and practice mani subramanian 2nd edition ch6

Documents

snmp management

snmpv2 framework

snmpv2 major changes

manager message

manager communication

mostsignificant changes

network managementtools

snmpv1 networkmanagement