Speciﬁcation and Implementation of a Network Management ...€¦ · te bieden aan applicatie...

J.W. TogtemaEnschede, 1993

doctoraalverslag

Faculteit der Informatica

Universiteit Twente

for SNMPv2

Specification and

Implementation of a

Network Management

Service

based on SNMPv2

Specification and Implementation of aNetwork Management Service based on

SNMPv2

M.Sc. Thesisby

J.W. Togtema

january 1993 - november 1993

&Tele-Informatics

Open Systems

T I O S Graduation committee:

Prof. ir. E. F. MichielsDr. I. A. WidyaIr. A. PrasIr. H. H. C. KremerIng. F. P. H. van Hengstum

“Experience is the Father of Wisdom”

Dr. SNMP

Samenvatting

Computer netwerken kunnen worden bestuurd met behulp van netwerk managementapplicaties. Deze applicaties maken gebruik van operaties die geleverd worden door eenonderliggende service, bijv. een service gebaseerd op versie 2 van het Simple NetworkManagement Protocol (SNMPv2) of de Common Management Information Service (CMIS).

In dit verslag wordt een netwerk management service gebaseerd op SNMPv2 beschouwd. Dezeservice is afgeleid van de SNMPv2 standaards (voorstellen) van de Internet Engineering TaskForce (IETF), waarin SNMPv2 in protocol termen beschreven staat. Een ApplicationProgramming Interface (API) is gedefinieerd en geimplementeerd om de SNMPv2 Service aante bieden aan applicatie programmeurs. Met behulp van deze API moeten netwerk managementapplicaties eenvoudig te bouwen zijn.

Het grootste gedeelte van dit doctoraalverslag gaat over de implementatie van deze netwerkmanagement service, d.w.z. de SNMPv2 functionaliteit, op basis van de bovengenoemdestandaards. Het beschrijft hoe SNMPv2 in software is geimplementeerd, daarbij devoorwaarden, ontwerp overwegingen en tegengekomen problemen in ogenschouw nemend.Ook wordt ingegaan op de ervaring die is opgedaan met betrekking tot de implementatie van deRFCs.

Implementatie vond plaats in een UNIX omgeving waarbij ANSI C is gebruikt alsprogrammeertaal. Een implementatie structuur is gekozen waarbij meerdere applicatieprocessen gebruik kunnen maken van dezelfde SNMPv2 protocol machine.

Verder besteedt dit verslag aandacht aan twee eenvoudige netwerk applicaties die gemaakt zijnom de bruikbaarheid van de API te demonstreren en om de geimplementeerde SNMPv2functionaliteit te testen. Ook zijn deze applicaties gebruikt om de samenwerking met andereSNMPv2 pakketten te testen.

Abstract

Computer networks can be observed and controlled by means of network managementapplications. These applications use the management operations as supported by a service, e.g.a network management service based on version 2 of the Simple Network ManagementProtocol (SNMPv2) or the Common Management Information Service (CMIS).

In this report a network management service based on SNMPv2 is considered. This service isderived from the SNMPv2 proposed standards of the Internet Engineering Task Force (IETF),in which SNMPv2 is described in protocol terms. An Application Programming Interface (API)is defined and implemented to enable programmers of network management applications to usethe SNMPv2 service. By means of this API it should be easy to program manager and agentapplications.

The main part of this thesis constitutes the implementation of this network management service.It describes how SNMPv2 is implemented in software, describing the constraints, the designdecisions and the problems that were encountered. It also describes the experience that weobtained implementing the RFCs.

Implementation took place in a UNIX environment using ANSI C as the programminglanguage. An implementation structure was chosen that allows multiple applications to use thesame SNMPv2 Engine.

Further, this report considers two simple network management application applications thatwere written to demonstrate the usability of the API and to test the implemented SNMPv2functionality. These applications were also used to test inter-operability with other SNMPv2packages.

Table of Contents

Preface 1

Chapter 1: Introduction 31.1 Network management 31.2 Standardization of network management 31.3 SNMPv2 Project 41.4 Subject of this Assignment 41.5 Structure of the text 5

Chapter 2: An Overview of SNMP 72.1 History 72.2 The Managed Network 72.3 The Internet-standard Network Management Framework 82.4 Philosophy behind SNMP 10

Chapter 3: Specification of a SNMPv2 Service 133.1 The Network Management System 133.2 The SNMPv2 Service 15

Chapter 4: SNMPv2 Protocol 274.1 SNMPv2 Protocol Functions 274.2 Protocol Operations 294.3 Administrative Model 304.4 Basic Encoding Rules 324.5 Security Protocols 344.6 Transport Service 34

Chapter 5: Definition of the SNMPv2 API 355.1 Mapping of Service Primitives and Parameters 355.2 SNMPv2 API functions 375.3 Parameters 435.4 Application Programming Guidelines 47

Chapter 6: Choosing an Implementation Structure 516.1 Server Model vs. Activity-thread Model 516.2 Applied Implementation Structure 526.3 Inter Process Communication 536.4 Implementation Structure of SNMPv2 Protocol Machine 54

Chapter 7: Implementation of SNMPv2 Layer 597.1 Implementation Strategy 59

7.2 Access to UDP 627.3 Implementation of Basic Encoding Rules 647.4 Implementation of the Administrative Model 667.5 Implementation of Security Protocols 687.6 Implementation of the API functions 707.7 Implementation of the SNMPv2 Protocol Machine 73

Chapter 8: UT-SNMPv2 package 79

Chapter 9: Conclusions 839.1 Evaluation of Assignment and developed Implementation 839.2 Future work 84

References 87

Appendix A: List of Abbreviations 91

Preface

In January 1993, I started working on my M. Sc. project to conclude my study in the ComputerScience at the University of Twente. This assignment was carried out as part of a researchproject of the Tele-Informatics and Open Systems (TIOS) group, which implements version 2of the Simple Network Management Protocol (SNMPv2). The assignment which I carried outin this project comprised the specification and implementation of a Network ManagementService based on SNMPv2. By means of this M.Sc. thesis the results of this work are presented.As not all parts of the framework, especially the network management service, could beimplemented during this assignment (e.g. manager to manager communication),implementation of the complete framework continues.

This thesis is intended for people interested in network management, and SNMPv2 specifically.It is especially intended for the people working on this project and the users of the implementedSNMPv2 package. It is assumed that the reader has some prior knowledge of SNMP. OtherwiseThe Simple Book of Marshall Rose is a good introduction to SNMP.

During this period a lot of people supported me to finish this project successfully. I like to thankIng Widya, Aiko Pras, Harro Kremer and Eric Schekkerman for their constructive criticism andthe many discussions related to the definition of the SNMPv2 service, the API and thearchitectural design of the SNMPv2 Protocol Machine. Eric van Hengstum deserves to bementioned for his great help, support and suggestions for the implementation of the SNMPv2Protocol Machine. For doing part of this implementation, I wish to thank Hans Scholtes andMartin Toet of the Polytechnics in Enschede. Credits are due to all people that reviewed thisM.Sc. thesis. Good luck to Eric van Hengstum and Vincent Berkhout, who are extending andimproving the current SNMPv2 package. Finally, I wish all members of the project successcontinuing the implementation of the complete framework.

Enschede, November 1993

J.W. Togtema

1 Introduction

1.1 Network management

Nowadays we are living in an information society in which the availability of information, anytime and anywhere, becomes more and more important for companies, institutions, as well asfor the individual. Large networks of interconnected computers are used to gather, exchange,interpret and store information. Continuously, new computers are connected to these networks,which in their turn are linked together, forming a worldwide web. Because of the growth andexpansion, new resources and services evolve at a fast rate. One is already used to applicationslike electronic mail, file-transfer or electronic news. And applications like video-conferencingand other multi-media things become more and more popular. These applications are to a largeextent distributed. In practically every organization, the importance and the extent ofcommunication services for speech, data, text and images grow.

Today computer networks are of vital importance to an organization. That is one of the reasonswhy network management is a hot topic at the moment. Network management comprises thetasks which care for the proper functioning of a network. Network management tools are usedto perform these tasks. They are used to monitor and control the behaviour of the network at anymoment, to guarantee a proper functioning, e.g. with respect to availability, reliability andperformance).

Because of the multitude of resources (e.g. routers, communication links) supplied by differentvendors that are connected in these networks, network management becomes a complex task.To reduce the costs of management and to make management of these heterogeneous networkseasier, efforts were made to develop management applications and managementcommunication services which access and exchange management information in a uniformway.

1.2 Standardization of network management

Different standards have been developed by different standardization bodies to get a uniformstructuring of management information and a uniform way of exchanging this information. TheInternational Organization for Standardization (ISO) defined as a part of the Open SystemsInterconnection Basic Reference Model (OSI RM) a Network Management Framework with itsCommon Management Information Service and Protocol (CMIS & CMIP). Otherstandardization efforts are made by the International Telecommunication Union (ITU) with itsTelecommunications Management Network (TMN). The Simple Network ManagementProtocol (SNMP), to which this thesis will be devoted, was developed by the Internet society.Information about OSI RM’s Network Management Framework and related CMIS and CMIP

4 1. Introduction

can be found in [ISO 7498-4], [ISO 9595], [ISO 9596], [Yem93] or [Ram93]. For moreinformation about ITU’s TMN see [M.3010].

Nowadays SNMP is by far the most applied standardized network management protocol [Jan92]. And the market for SNMP still grows, with the increasing popularity of the Internet suiteof protocols and the expansion of the Internet. This popularity originates from the practicalapproach advocated by the Internet society. Standards are developed on an evolutionary basisbuilt on simple, proven functionality. Therefore largely based on implementation andoperational experience. Most of the standards of its counterpart ISO are typically very general,often complex, and hardly proven in practice.

1.3 SNMPv2 Project

As mentioned in section 1.2 this thesis concentrates on SNMP and it especially covers the trajectof specification and implementation of a network management service based on version 2 ofSNMP (SNMPv2). This assignment was carried out as part of a research project of the Tele-Informatics and Open Systems group. The aims of the project were to gain knowledge andexperience about the SNMPv2 protocol and its associated framework. It has been recognizedthat thorough insight in the protocol and its framework could best be obtained by implementingthe complete framework. To encounter all possible problems that arise with the implementationof the complete framework, implementation started from scratch. No existing public domaintools were used. Another goal of the project is to contribute to the process of standardization ofSNMPv2, since SNMPv2 is still on the standardization track of the Internet Activities Board(IAB).

The SNMPv2 implementation is mainly developed for educational purposes. To reducecomplexity the framework is decomposed in three parts, viz. a network management service, amanager and an agent. One can concentrate on one’s specific area, e.g. writing an agentapplication. The software is developed based on the proposed standards for SNMPv2 asspecified in [RFC 1440] up to and including [RFC 1452] and should conform to these standards.Making the implementation easier to understand, the structure of the RFCs and the namingconventions are used as much as possible.

1.4 Subject of this Assignment

This assignment covers the specification and implementation of a network management service.The network management service offers network management applications the means toexchange management information. Later on, a number of network management applicationswill be written that make use of this management information communication service. Becausea specification of the network management service did not exist, this service was defined first.The network management service should as much as possible hide its users from the details ofthe management information exchange. Based on this constraint the service has been derivedfrom the SNMPv2 proposed standards in which SNMPv2 is described in protocol terms.

An implementation of this service is made available to programmers of managementapplications via an Application Programming Interface (API). By means of this proceduralinterface it should be easy to program manager and agent applications. The API separates theSNMPv2 functionality from the application functionality. It allows the independentimplementation of both the API and the management applications. Further, one can easily

5

extend or change these parts without affecting the other part, as long as the interface is notchanged. In this work also the differences between this API and other available APIs wereconsidered.

The main part of this assignment comprised the implementation of this network managementservice, i.e. the SNMPv2 functionality, based on the afore mentioned standards. It considershow SNMPv2 is implemented in software, describing the constraints, the design decisions andthe problems that were encountered. It also describes the experience that we obtainedimplementing the RFCs.

The SNMPv2 software has been developed on SUN workstations running SunOS 4.1.1, whichis an extension of Berkeley UNIX release 4.3. Programming was done using standard ANSI C(GNU). An implementation structure was chosen that allows multiple applications to use thesame protocol machine. As the implementation was mainly developed for educational purposespriority was given to comprehensibility and a clear structure above performance. Performancewas considered to be of minor importance in a first implementation. In future releases attentionwill be paid to those aspects, e.g. the solution of experienced bottlenecks.

To demonstrate the usability of the API (i.e. SNMPv2 functionality) two simple networkmanagement application programs have been written. Inherent to a correct implementation isthat it can inter-operate with other SNMPv2 implementations. Inter-operability has been testedwith a publicly available SNMPv2 package of Carnegie Mellon University (CMU). This packetwas retrieved via anonymous FTP (file transfer protocol).

During this design and implementation traject the concepts for protocol design and protocolimplementation will be used as described in [Sco 91] and [Eijk 91].

1.5 Structure of the text

This thesis starts with an overview of SNMP in chapter 2. It introduces SNMP, its history anddescribes the Internet-standard Network Management Framework on which the structuring ofthe implementation will be based. The remaining text of this report is structured in accordanceto the approach which is in most cases applied by the Tele-Informatics and Open Systems(TIOS) group for the development of a distributed system. This approach is illustrated in figure1.

First, chapter 3 specifies the network management service which has been derived from theRFCs 1440 up to and including 1452 in which the SNMPv2 protocol is described. As theprotocol is already specified in these RFCs, chapter 4 only considers the additional functionalitywhich is needed to offer the service and as such not defined in the standards. Then, chapter 5covers the definition of the API which is based on the specified service of chapter 3. Chapters6, 7 and 8 consider the implementation of SNMPv2 in software. Chapter 6 deals with theimplementation structure. It mainly discusses the design choices. Chapter 7 presents how theSNMPv2 functionality is implemented. The structure of the resulting package is described inchapter 8. Finally, chapter 9 concludes with an evaluation of this assignment. Besides theconclusions it will provide some recommendations for future work.

6 1. Introduction

Service Specification

Interface Definition

Implementation

step 1:

step 3:

step 4:

(chapter 3)

(chapter 5)

(chapters 6, 7 and 8)

Protocol Specificationstep 2: (chapter 4)

figure 1: Approach (TIOS)

2 An Overview of SNMP

In this chapter an overview of SNMP is given. First, the history behind SNMP is given. Thensection 2.2 identifies the general configuration of networks which have to be managed. Insection 2.3 the Internet-standard Network Management Framework will be explained. Thisframework describes how a network management system can be modelled. Implementation willbe based on this model. Finally, the philosophy behind SNMP is given in section 2.4. Thisphilosophy will be described in terms of the framework of section 2.3. This philosophy willguide and affect the design of the API defined in chapter 5 and the implementation of theSNMPv2 layer described in the chapter 6 and 7.

2.1 History

SNMP came into existence in 1988 as the successor of the Simple Gateway Monitoring Protocol(SGMP) that was used to monitor the gateways in the internet. In April of 1989 the InternetAcitivities Board (IAB), which is responsible for the development of the Internet suite ofprotocols, declared SNMP to be a recommended standard. SNMP became thede facto standardfor management of TCP/IP1 based networks. The original Internet-standard NetworkManagement Framework, is described in [RFC 1155], [RFC 1157] and [RFC 1212]. Becauseof the still on going evolution of SNMP this framework is termed the SNMP version 1framework (SNMPv1)2.

Through the years of world wide deployment of SNMP, a desire arose to solve the experienceddeficiencies, and to extend and improve it to meet new requirements. The main problem ofSNMP was the lack of a proper security. Other problems and improvements were related,among other things, to performance issues. In [Sch93] an extensive description of thesedeficiencies, extensions and improvements is given. In July 1992 it was decided that SNMPv1should be replaced by a successor that could solve these problems. In April 1993, the frameworkas described in [RFC 1441 - 1452] became the follow-up of SNMPv1 and has been named theSNMP version 2 framework (SNMPv2). For a more detailed description of the evolution ofSNMP see for instance [Rose91], [Rose93], [Sta93], or [Com91].

2.2 The Managed Network

In a network, which must be managed, one usually distinguishes the following components:

1. Note that TCP/IP is used either to refer to the family of protocols of the Internet suite or to denote both the TCPprotocol and IP protocol. In this case the suite of protocols is meant.

2. Similar to the meaning of TCP/IP, SNMPv1 either denotes the complete framework or specifically the protocol.

8 2. An Overview of SNMP

• subnetworks,

• backbone,

• managed nodes (MN),

• one ore more network management stations (NMS).

An example of a possible network configuration is given in Figure 2. An internet usuallyconsists of many interconnected networks. A backbone connects the different subnetworks toone big network. The managed nodes, represented by MNi (with i = 1,.., 12) in the figure, denotethe devices that are to be managed. These nodes can be of various types like for instance routers,bridges or host systems. On the managed nodes one or more network management applicationsare running that monitor and control the specific devices. Another type of application runs on anetwork management station, denoted by NMSi (with i = 1,..,4). By means of these networkmanagement applications the network operator monitors and controls the network and its thedevices.

Figure 2: Example of a possible network configuration.

2.3 The Internet-standard Network Management Framework

The network management system which is shown in Figure 2 can be modelled by the genericstructure presented in Figure 3. A network management application which is running on anetwork management system, is modelled by a manager entity. An application which is runningon a managed node, is modelled by an agent entity. The manager entity initiates managementoperations to an agent entity. The agent entity responds to these management operations. Toexchange management operations between the entities an SNMPv2 service provider is used.The service which is offered by the provider, is based on the SNMPv2 protocol. Networkmanagement operations are performed on managed objects which are used to control andmonitor the network. These objects reside in a Management Information Base (MIB).

In this way the entity specific functionality (e.g. variable access) can be separated from thecommon functionality. Structure and storage of management information are separated from thetransport of this information between the network management entities. This approach allowsthe addition of new information or the use of another management protocol, without having tochange the complete implementation. In this project this layered1 approach will be adopted tostructure and implement the complete SNMPv2 framework. Evenmeta-management, i.e.

1. Layered w.r.t. functionality.

NMS2 MN5

NMS1

NMS3

backbone

subnetwork 3subnetwork 1

subnetwork 2

MN12

MN11MN10

MN3

MN2

MN1

MN6

MN9MN8

MN7

MN4

NMS4

MNx

9

management of the SNMPv2 related MIBs (PartyMIB, SNMPv2 MIB and manager to managerMIB) using SNMPv2 itself, will be handled in this way.

It should be noted that this framework could be structured in several other ways. Several otherSNMPv2 implementations do not separate the variable access and variable exchange.

In the following paragraphs 2.3.1 up to and including 2.3.3 the different parts, as depicted inFigure 3, will be described in more detail.

2.3.1 The Storage of Management Information

The management information is kept in a data repository, called Management Information Base(MIB). The MIB is organized as a hierarchical, lexicographically ordered tree of objects. Anobject in this tree resembles a specific piece of management information, e.g. the number ofpackets received by a device. Collections of related objects are grouped together in modules.Each of these modules forms a subtree, e.g. the objects related to remote network monitoringare grouped together in the Remote Network MONitoring MIB (RMON-MIB). An object isidentified by a sequence of non-negative integer values, i.e. the object identifier. These valuesare used to traverse a tree. Besides the object identifier, an object contains the meaning of theobject, the type of the data, the data itself, information related to access control (i.e. read andwrite access), and so on. In Figure 4 an example of such a tree is given. In this figure MIB-IIrepresents a module of related objects and the object identifier of MIB-II is 1.3.6.1.2.1.

It should be noted that not all objects need to be present in the MIB of a specific managed node.Usually only the objects directly related to primary functions of a device are present.

2.3.2 The Structure of Management Information

The managed objects are defined in a machine independent way by means of a subset of theAbstract Syntax Notation One (ASN.1) [ISO 8824]. ASN.1 is a notational language whichassures that no ambiguities arise in the representation and meaning of the objects, necessary toobtain inter-operability. The subset of ASN.1 used in SNMPv2 is specified in theStructure of

MIBManager Agent

SNMPv2

Connectionless Transport Service

SNMPv2ProtocolEntity


Figure 3: Structure of Internet-standard Network Management Framework.

Entity Entity

= SNMPv2 Service Provider


Management Information document [RFC 1442]. Identification of the objects is also describedin this document. Information about ASN.1 can be found in [Rose 89].

Additional semantics can be added to the objects by means of textual conventions, see also[RFC 1443].

2.3.3 The Exchange of Management Information

As mentioned in the introduction, this thesis is devoted to the part that handles the managementinformation exchange between different entities, viz. the SNMPv2 Service Provider. Thisprovider comprises a number of protocol entities (PEs) and a Connection-Less TransportService (CLTS) combined together offering the network management service. This service isdescribed in detail in chapter 3. In order to provide this service the (peer) entities communicatewith each other using version 2 of the Simple Network Management Protocol (SNMPv2).Communication based on version 1 of SNMP, as specified in [RFC 1155], [RFC 1157] and[RFC 1212] will not be considered in this thesis.

The SNMPv2 protocol defines the messages that need to be exchanged between the remotelylocated entities. The SNMPv2 messages are also defined by means of ASN.1. Further, theprotocol specifies how the messages need to be coded in a machine independent manner toassure inter-operability. An administrative framework is defined within the SNMPv2framework to enable secure communication. This framework takes care of authorization,authentication, privacy and so on. SNMPv2 in turn makes use of a CLTS. SNMPv2 is able touse several CLTSs [RFC 1449], e.g. a transport service based on the User Datagram Protocol(UDP), OSI’s ConnectionLess Network Service (CLNS) or AppleTalk. However, UDP basedservices are considered the preferred services for SNMPv2. Accordingly, this report onlyconsiders the UDP service [RFC 768] as the underlying service for SNMPv2.

2.4 Philosophy behind SNMP

As last part of this chapter the principles on which the Internet-standard Network ManagementFramework is based, are summarized. These principles must be kept in mind when defining aservice, API and when implementing it.

One guiding principle that minimizes the cost and complexity of network management agentsand puts as much of the network management as possible in centralized stations is the

internet { 1 3 6 1 }

directory(1) mgmt (2)

MIB-II [RFC 1213] (1)

system interfaces at ip icmp tcp udp egp transmission snmp

Figure 4: Example of a hierarchical object identifier tree.

11

Fundamental Axiom of the Internet-standard Network Management Framework. ThisFundamental Axiom says:"The impact of adding network management to managed nodes mustbe minimal, reflecting a lowest common denominator". The burden of network management isshifted as much as possible to the management station. This is based on the fact that there aremany more managed nodes than network management stations.

A paradigm that contributes to a simple protocol is the ‘remote debugging’ paradigm [Rose91,p.73]: "A managed node is viewed as having several ‘variables’. By reading the value of thesevariables, the managed node is monitored. By changing the value of these variables, themanaged node is controlled".The control operations occur as side-effect of storing (setting)values into a variable. Because SNMP is not built around commands, new objects can easily beadded or new operations (with its side-effects) defined.

Another important principle is that:"Network management must continue to function, when allfails, if at all possible". This implies that the functionality of the transport service and networkmanagement service should only be used if really necessary. For instance, retransmission whichis usually performed by the service provider need to be handled by the management applicationsthemselves. These management applications are in the best position to decide the retransmissionpolicy because these applications have the best knowledge about the functioning of the network.

3 Specification of a SNMPv2 Service

This chapter provides a description of a SNMPv2 network management service that will beprovided to the network management applications. The SNMPv2 service is used to exchangemanagement information between network management applications. This SNMPv2 servicehas been derived from the proposed SNMPv2 standards [RFC 1440],..,[RFC 1452], whichdescribes SNMPv2 in protocol terms. The derived SNMPv2 service should hide (as much aspossible) the details of the SNMPv2 Protocol. It should be easy to use for the networkmanagement applications. In accordance to the model described in section 2.3 the service hasbeen deduced. If another model than the model of section 2.3 had been used to structure thecomplete SNMPv2 framework, probably another service definition would have been the result.

First, a more elaborated model of a network management system is given compared to thegeneric model of section 2.3. This model is used to explain the different types of users,hierarchical relations and the interactions between the users and the service provider. In thisoverview, the operations which must be supported by the service, are identified. Then, section3.2 specifies the different service elements of the SNMPv2 network management service. Eachof these service elements is then described in more detail.

3.1 The Network Management System

According to the generic model, shown in Figure 3 of section 2.3, part of the networkmanagement configuration of Figure 2 is depicted by the refined model of Figure 5. Thenetwork management system contains an SNMPv2 Service Provider and a number of possiblydistributed users of this service. The users of the service are the agent and manager networkmanagement application entities of chapter 2. The manager and agent entities use the SNMPv2service provider to exchange management operations.

agentmanager

SNMPv2-Service Provider

agent agentmanager

SAP

MIBMIBMIB

Figure 5: Example of a Network Management System

14 3. Specification of a SNMPv2 Service

Conceptually, there are only four kind of management operations defined for the interactionbetween different entities. These are:

• a retrieval operation

• a traversal operation

• a set operation

• a notify operation

Via the retrieval operation a manager entity requests an agent entity to fetch the requestedobjects from the MIB. The traversal operation is used by the manager entity to walk through thehierarchically structured MIB. The agent entity responds with the successors of the objects thatwere provided by the manager entity. By means of the set operation a manager entity denotesthat the agent entity must change the values of the specified objects to the provided values. Inthese operations the initiative comes from the manager entity. An agent entity takes only theinitiative when it issues a notification operation. This operation is used to report to a managerentity the occurrence of an extra-ordinary event (e.g. a link went down). Still it is the managerthat determines whether it wants to receive traps. If a manager entity wants to be notified it usesa set-operation to install its address in the list of managers to be notified. A manager entity isalso able to send a notification to another manager. This operation can be used if a managerwants to delegate responsibility to another manager. Now, this and the other hierarchicalrelations between managers and agents, and among managers are explained.

In a network management system there is usually at least one manager. This manager is able tocontrol a large number of agents. An agent is able to handle requests from more than onemanager. So, depending on the configuration an agent can be controlled by more than onemanager.

In a large network there are usually several managers that control and monitor the network orjust a part of it. Based on the example presented in Figure 2, the hierarchical relations will beexplained. In Figure 6 just a part of the network of Figure 2 is considered, viz. the backbone andsubnetwork1. It shows a possible hierarchy among the managers and agents.

The manager on NMS2 controls the agents on MN4, MN5 and MN6. Further, one can noticethat the manager on NMS1 as well as the manager on NMS2 control the agent on MN6. Besides

managerNMS1

NMS2

agentMN2

agentMN4

agentMN5

agentMN6

agentMN3

agentMN1

agentmanager

Figure 6: Management hierarchy among managers and agents

subnetwork 1

backbone

15

these manager-agent relationships the picture expresses a possible hierarchy among managers.The manager on NMS1 is responsible for the control of the overall network. The manager onNMS2 assists this manager by handling part of the network (subnet1). The application runningon NMS2 operates in a dual role. With respect to the agents (MN4 up to MN6) it acts as amanager and with respect to the manager (NMS1) as an agent. By means of the manager-agentinteraction the manager on NMS1 instructs the subnet manager on NMS2. It specifies when itwishes to be notified about the functioning of subnet1. For this purpose the manager-to-managerMIB is used. The manager on NMS2 directly reports via a notify operation to the manager onNMS1 in case of e.g. extra-ordinary events. This manager-manager interaction provides themeans for distributed management. It minimizes the network traffic which is caused by networkmanagement and accommodates to the fact that in practice there are several organizationsresponsible for the management of (part of) the network.

A specific kind of an agent is the proxy agent. This agent is used to manage objects which arenot directly accessible via a SNMPv2 management service. For example, if one wants tomanage systems using SNMPv2 that do not support SNMPv2 to exchange managementinformation. In that case the proxy translates the different protocols. The proxy behaviour of anagent is invisible to a manager. Therefore, in my opinion a proxy agent can be handled like anormal agent.

Figure 7: Proxy Agent

3.2 The SNMPv2 Service

This section considers the provided services. The service description which is specified in thissection, defines the external behaviour of the SNMPv2 Service Provider. It doesn’t describehow the mandated behaviour is realized. In this way, irrelevant details of the exchange ofmanagement information between applications are hidden for these applications.

The description of the provided service is derived from the proposed SNMPv2 standards [RFC1440] .. [RFC1452] which describes SNMPv2 in protocol terms. This SNMPv2 service musthide as much as possible the details which are related to the communication of managementinformation, such as authentication, privacy and encoding, respectively decoding of messages.It should be easy to use for the network management applications. In accordance to the modeldescribed in section 2.3 and the philosophy of SNMP, the service has been deduced. Thedefinition that is presented in this section is the result of several iterations. It was almostimpossible to derive the service from the protocol definition in one step. Many details of theprotocol became clear, when the protocol was implemented. Therefore this approach has notproved to be the most suitable for this assignment.

The SNMPv2 service facilities can be directly deduced from the defined protocol. Thefollowing SNMPv2 service elements have a direct implementation counterpart in the protocol:

• Get-service

agentMN3

managermanagerNMS1

agentMNx

SNMPv2-service provider other Network Mgmt.service provider


• Getnext-service

• Getbulk-service

• Set-service

• Inform-service

• Trap-service

Before describing the above summarized service elements in more detail first the generalcharacteristics of the service elements will be considered.

3.2.1 General characteristicsThe general characteristics of this Network Management Service (and its corresponding serviceelements) can be enumerated by:

• Connectionless Service

The offered network management service is a connectionless service. The users of theservice exchange management information without first setting up a connection. SNMPv2uses a connection-less mode transport service because network management must alsofunction in a unreliable environment in which connections may be lost. Networkmanagement must continue to function as long as possible (see section 2.4). For example,in case of a heavily loaded network, the set up of connections can fail or connections canbe aborted during a session.

• Multiple Requests

A manager may successively issue several requests before the corresponding responses arereceived. In Figure 8 this is illustrated for a manager that issues several get-requests toretrieve multiple objects from the MIB of an agent.

Figure 8: possible ordering of service primitives

get-request

time

manager provider agent

get-indication

get-responseget-confirm

get-request

get-indicationget-request

get-indication



17

• Unreliable service

The provided SNMPv2 services are all unreliable because it is considered that themanagement applications are in the best position to judge the reliability that can be reached.Thus, it is not guaranteed that a request will result in an indication or that a response willresult in a confirm. Both requests and responses can be lost (as depicted in Figure 9).

Figure 9: unreliability of provider

The unreliability of the provider can also result in duplication and out of order delivery ofthe data (not depicted in the figures). It is up to the management applications to implementand choose the appropriate level of reliability (e.g. retransmission policy).

• Error indication from provider

It is possible that a request cannot be transmitted for example due to the fact that therequired quality of service cannot be met. In that case, the provider generates an errorindication and denotes the reason of the failure (see Figure 10).

Figure 10: provider generated error indication

The error indication service primitive has besides the ‘request-id’ parameter (identifyingthe request) another parameter to denote the type of error:

Now, the provided service elements will be described into more detail. The above describedcharacteristics apply for all services described in the remaining part of this section.

parameters indication

request-id M

error type M

Table 1: parameters of error indication SP

request

manager prov. agent

request

manager prov. agent

indicationresponse

request

manager prov. agent

error indication


3.2.2 Get-serviceThis service element is used to retrieve specific management information. By means of the get-service the manager1 fetches values from one or more managed objects residing in the MIB ofthe agent. The get-service is a user confirmed service (see Figure 11). Note that only the usual

ordering is specified in Figure 11, section 3.2.1 considered the loss of SPs.

In Table 2 the parameters are shown which are conveyed by the service primitives. Further itshows the parameter-value dependencies. In this table a capital M denotes that a parameter ismandatory and M(=) denotes that a parameter is mandatory and should have the same value asin the previous primitive. A blank means that the corresponding parameter is not present in theprimitive. The capital ‘C’ denotes that it depends on another parameter (conditional).

A get-request takes as parameters the hostname of the system (agent) to be managed, a request-id, the required quality of service and a variable list. This list conveys the variable names of theobjects a manager wishes to retrieve.

1. Note when is spoken from a manager or agent a network management entity operating in a manager or agentrole is meant.

parameters request indication response confirm

agent hostname M

request-id M M(=)

reply-id M M(=)

quality of service M

context name M

view/timedomain/entity M

error-status M M(=)

error-index M M(=)

variable-names M M(=)

variable-bindings C C(=)

Table 2: Parameters and parameter value dependencies of get-service

get-request

time


get-indication


Figure 11: Temporal ordering of get-service primitives

19

The hostname is a symbolic name which is used to denote the system to be managed. By meansof the hostname, the address of the managed device will be obtained. A request-id is used by themanager to identify a request among several other outstanding requests and correlatesoutstanding requests with incoming responses. Furthermore, it is used to check on duplicationof messages. The request-id is locally unique. The quality of service specifies whetherauthentication and/or privacy is needed for the exchange of data. The context name provides asymbolic name used to specify the objects one wants to manage (i.e. which set of objects arevisible to the specified operation). By means of this name the appropriate view, timedomain,and entity that accesses the objects are selected. The view specifies which set of objects arevisible to the operation. The timedomain parameter is used to specify the period or moment ofretrieval. The entity specifies to which local entity the objects one wants to retrieve, belong (e.g.a particular repeater). For more information about context and related view, timedomain andentity see for instance [Sch93] or [Rose93]. Finally, the variable names are used to access theindividual objects.

The get-indication conveys besides the view, the timedomain, the entity and the variable namesas specified in the request, a reply-id which is generated by the provider to enable the agent torelate the response to an indication. Because multiple managers can send a request to an agentthe used request-ids are mapped onto unique reply-ids. In this way an agent provides service toa number of managers (possibly using the same request-ids) as if it only deals with one manager.Further, the reply-id is used to administer information about addresses and security modes, etc.necessary for sending the response back to the manager. That is, information from the requestwill be used for the transmission of the subsequent response.

The agent is expected to respond to every request. It must generate a get-response using thereply-id which was supplied by the get-indication. The other parameters are an error-status, anerror-index and a list of variable names with their related values (variable bindings). The error-status indicates whether an exception occurred which prevented the processing of the variables.If an exception occurred then the value of the error-index field provides additional informationby identifying which variable in the list caused the exception. In case of an error it is possiblethat the list of variable bindings is absent in the response and confirm primitives, due to theerror. A variable binding is the pairwise combination of an objectname, identifying the object,and an objectvalue.

The get-confirm conveys the same information as in the response, except that a request-id isused in stead of a reply-id. The above given description is summarized in Table 2.

To guarantee an unambiguous representation and meaning the parameters are described usingthe notation language Abstract Syntax Notation One (ASN.1) [ISO 8824]:

agent hostnameOCTET STRING -- e.g. utis93

request-idInteger32, -- IMPLICIT INTEGER (-2147483648..2147483647)

reply-idInteger32, -- IMPLICIT INTEGER (-2147483648..2147483647)

quality-of-serviceInteger{

none (1), -- no authentication, no privacyAuth (2), -- authentication only,


Priv (3), -- authentication and privacy.},

contextnameOCTET STRING -- e.g. Repeater2Objects (i.e. a symbolic name).

viewOBJECT IDENTIFIER, -- e.g. objects from system part of MIB-II.

entityOCTET STRING, -- port1, repeater2,...

timedomainOBJECT IDENTIFIER, -- e.g. currentTime, restartTime, cacheTime.

error-status -- the meaning of the error-status value is given as comment.INTEGER {

noError(0), -- the results are correct.tooBig(1), -- the amount of variables is too big.genErr(5), -- if processing failed due to a reason other than summarized in this list.authorizationError(16), -- the user is not authorized to execute/perform the requested operation.

},

error-indexINTEGER(0..max-bindings),

max-bindings -- denotes the maximum number of variablesINTEGER::= 2147483647,

variable-names ::=SEQUENCE (SIZE(0..max-bindings)) OF ObjectName,

variable-bindings ::=SEQUENCE (SIZE(0..max-bindings)) OF VarBind,

VarBind ::=SEQUENCE {

nameObjectName,

CHOICE {value

ObjectSyntax,noSuchObject[0]

IMPLICIT NULL,noSuchInstance[1]

IMPLICIT NULL,endOfMibView[2]

IMPLICIT NULL}

}

Note that in case of an exception which does not prevent the processing of other variables, thevariable binding indicates the kind of exception (noSuchObject or noSuchInstance).

The syntaxes of ObjectName, ObjectSyntax and Integer32 are described in [RFC 1442].

21

3.2.3 Getnext-serviceThe getnext-service is an unreliable, user confirmed service which is used to retrieve, viatraversal, management information from the lexicographic ordered variable tree, i.e. the MIB.The getnext-service retrieves the names and the corresponding values from the variables thatare lexicographically next to the variables of which the names are given in the getnext-requestservice primitive (SP). The getnext operation is especially useful if one does not know thenames of one or more variables. Similar to the get-service, the getnext-service could bedescribed. The same temporal orderings and parameter value dependencies apply. The onlydifference with the get-service (except the different kind of behaviour) is that the errorstatusparameter of the getnext response SP or the getnext confirm SP besides the noSuchObject ornoSuchInstance values also can contain the endOfMibView-value (denoting the end of thevisible object-tree).

3.2.4 Getbulk-serviceThe getbulk-service is an unreliable, user confirmed service which is used to retrieve apotentially large amount of data, including, but not limited to, the efficient and rapid retrievalof large tables. By means of a getbulk operation a manager can retrieve in one request as manyvariables as will fit in a maximum-sized message without knowing the names of the particularvariables it wants to retrieve. The getbulk contributes to minimizing the network interactions.Compared to SNMPv1 one doesn’t need to send several getnexts if one wants to obtain a table.

Compared to the get-service two additional parameters, i.e. ‘non-repeaters’ and ‘max-repetitions’ are contained by the request and indication SPs (Table 4).

These variables are used to denote the requested processing of variables. The max-repetitionsparameter specifies the maximum number of repeated executions for the requested variables.The non-repeaters parameter specifies how many of the variables in the request are not subjectto repeated executions [Sch93], [Rose93]. The parameters have the following syntax:

max-repetitionsINTEGER (0..max-bindings),

non-repeatersINTEGER (0..max-bindings),

The definition of the service element which corresponds to the getbulk in the protocol, posedthe most problems, because in our case the variable access has been separated from the variableexchange. At first instance, a getbulk indication and response service primitive were defined.This solution can not be implemented efficiently because both provider and agent do not knowhow many variables can be used in advance.

Thus, the provider needs to interact one or more times with an agent entity, using the getnextindication service primitive, to construct a maximum sized message. The provider keeps trackof the construction and size of the response which will be returned and determines if anothervariable can be added. This approach makes the getbulk invisible to an agent. The getbulk


max-repetitions M M(=)

non-repeaters M M(=)

Table 3: Additional parameters of the getbulk-service


request results in a sequence of getnext indications and responses (see Figure 12). This approachis also described in [Clo93]

In the first step the variables are retrieved that are only needed once which is denoted by ‘non-repeaters’. Then, the getnext is used to retrieve the values of the remaining variables in the list.This process is repeated N times (with N equal to max-repetitions). Each time the results of theprevious request are used. This process can terminate due to insufficient available space, theoccurrence of an error or if the end of the MIB is reached. Note that only the generic error(genErr) can occur and not a ‘tooBig’ error.

3.2.5 Set-serviceThe set-service is used to change management information. This unreliable user-confirmedservice can be used by a manager to modify the values of the objects which are contained in thevariable binding list of the set-request. The unreliability of the service can result in duplicationof messages, causing the generation of the same service primitive one or more times.

The set service takes a variable bindings list as one of its parameters in the set request-SP. Inthis list each variable name is combined with a value. The other parameters are the same as withthe get-service.


variable-bindings M M(=) C(=) C(=)

Table 4: variable-binding parameter of set service

getbulk-request

time


getnext-indication

getnext-response

getbulk-confirm

SAP

getnext-indication

getnext-response

getnext-indication

getnext-responsestep 2

Figure 12: Temporal ordering of getbulk service primitives

23

Modification is done on an all or nothing basis: if one or more of the variables cannot bemodified, none will be modified. For the set operation additional errorstatus values are defined(see also [Rose 93]). The error-status parameter can take the following error-values:

error-status -- The meaning of the error-status values is given as comment.INTEGER {

noError(0), -- the results are correct.tooBig(1), -- the amount of variables is too big.genErr(5), -- If processing failed due to a reason other than summarized in this list.noAccess(6), -- the variable is not accessible.wrongType(7), -- the type is inconsistent, according to the ASN.1 language, with that

-- required for the variable.wrongLength(8), -- to indicate that the length of the specified value is not supported.wrongEncoding(9), -- ASN.1 encoding is inconsistent with tag.wrongValue(10), -- the specified value could under no circumstances be assigned to the

-- variable.noCreation(11), -- the variable does not exist and could not ever be created.inconsistentValue(12), -- the specified value could under other circumstances be assigned to the

-- variable, but is presently inconsistent.resourceUnavailable(13), -- the assignment of a value to a variable requires the allocation of a

-- resource, which is presently not available.commitFailed(14), -- one or more of the assignments of values to variables failed.undoFailed(15), -- it was not possible to undo all the assignments.authorizationError(16), -- the user is not authorized to execute/perform the requested operation.notWritable(17), -- the variable cannot be modified, no matter what value is specified.inconsistentName(18) -- the variable doesn’t exist, but the agent is able to create instances of

-- the corresponding object type, but the provided name is presently-- inconsistent.

}

3.2.6 Inform-serviceThe inform-service is an unreliable, provider confirmed service between two managers, see alsoFigure 13. The inform-service is used to notify another manager of some particular managementinformation. This service is provider confirmed because the manager which receives thenotification will not send information back to the informing manager.

Using the set service a higher-level manager (i.e. manager2) can delegate responsibility to alower-level manager (i.e. manager1). The latter acts in a dual role, as described in 3.1. The lowerlevel manager polls a number of agents and if something extraordinary happens it notifies, usingthe inform, the higher-level manager which is responsible for taking the required actions. In thisway a hierarchy among managers can be realized.

Figure 13: temporal ordering of inform service primitives

manager 2provider

inform-indication

inform-request

manager 1

inform-confirm


In Table 4 the parameters and their dependencies are described. Contrary to the variable

binding list of the other service elements, the first two variable bindings of this list aredetermined. This first one provides the system time and the second one denotes the type ofinform notification. Depending on the type of notification the other variable bindings should beprovided. The values of the error-status parameter can be a ‘tooBig’, ‘authorizationError’ or a‘genErr’.

It should be noted that the provided unreliable service can result in the loss of notifications (see3.2.1). This requires that the notified manager (i.e. manager 2) should periodically poll thenotifying manager (i.e. manager1).

3.2.7 Trap-serviceThe trap-service is an unreliable unconfirmed service between an agent and a manager onrequest of the former (see Figure 14).With the trap an agent takes the initiative in reporting themanager that some extraordinary event happened. The following table (Table 6) shows theparameters of the SPs and the parameter value dependencies between these SPs.

Figure 14: temporal ordering of trap service primitives

The provider determines the managers to which the traps must be sent. The addresses of thesemanagers are stored in a table in the provider. A manager which wants to receive particular trapsfrom an agent can append his address to this table and denote the specific traps it wants toreceive by using the set-operation. The request-id in the indication contains the total number oftraps that are sent to the specific manager. Like the variable bindings list of the inform service,the variable bindings list of the trap service is partially determined at forehand. The first variablebinding must be the system time, the second one denotes the type of the trap, and dependent on

parameters request indication confirm

manager1 name M

manager2 name M

quality of service M

request-id M M(=)

error-status M

error-index M

variable-bindings M M(=) C(=)

Table 5: parameters and parameter value dependencies of the inform-service

managerprovideragent

trap-indication

trap-request

25

this type one needs to provide a number of objects as specified in the Object Clause of the trapdefinition. Beside these objects an agent can provide additional objects allowing a manager toget a better view of the reason of the trap. Finally, the agentname specifies the agent thatgenerated the notification.

Similar to the inform notification the trap is an unreliable service. The manager shouldperiodically poll the agents which can generate trap notifications.

parameters request indication

agent hostname M

nmbr-of-traps M

variable-bindings M M(=)

Table 6: parameter value dependencies of the trap-service

4 SNMPv2 Protocol

The previous chapter described the external behaviour of the SNMPv2 service provider, thischapter describes how the service can be realized. The service provider comprises a number ofSNMPv2 protocol entities (SNMPv2 PEs) and a connectionless mode transport service. ThesePEs combine together to provide the service defined in the previous chapter. The PEs use atransport service which is based on the UDP protocol. PEs communicate with each other usingthe SNMPv2 protocol (see figure 15).

figure 15: Decomposition of the Service Provider

As the SNMPv2 protocol is already specified1, this chapter will mainly consider themechanisms which are not described by the proposed standards for SNMPv2 specified in RFC1440 up to and including RFC 1452. These mechanisms provide the additional functionalitywhich is necessary to hide the details of the SNMPv2 protocol for the user entities. Thisfunctionality mainly comprises the mapping of service primitives and associated parametersupon the protocol counter parts, i.e. the mapping upon SNMPv2 messages. For example, aselection mechanism is needed to determine, by means of e.g. the quality of service parameter,which parties are needed. More information about SNMPv2 itself can be found in e.g. [Rose 93]or [Sta 93].

Section 4.1 describes the different tasks which a SNMPv2 PEs has to perform. Based on thisdescription, the following sections will elaborate on these different tasks.

4.1 SNMPv2 Protocol Functions

In figure 16 the different functions a SNMPv2 PE takes care of, are shown. To offer thespecified service the SNMPv2 PE needs to exchange SNMPv2 messages with other SNMPv2PEs, as specified in [RFC 1448] and [RFC 1446]. A message is constructed based on the

1. The service was derived from the protocol specification afterwards.


ProtocolEntity

Transport Service

SNMPv2 Service Provider

28 4. SNMPv2 Protocol

received service primitive (SP) and its associated parameters. An SP and its parameters aremapped upon an SNMPv2 message. Part of the parameters are mapped upon the PDU by theProtocol Operation functions and part of the parameters are used by the Administrative Modelto construct the SNMPv2 message headers. By means of the Administrative Model isdetermined which security protocols, e.g. authentication and privacy protocol, need to be used.The authentication protocol uses among others MD5. The privacy protocol is based on the DataEncryption Standard (DES). The Administrative Model is supported by a PartyMIB and aSNMPv2 MIB. In these MIBs the information is stored that is needed for the communicationamong peer PEs, e.g. privacy keys. And finally, the Basic Encoding Rules (BER) are used tomap the SNMPv2 messages onto a byte stream which will be transmitted over UDP. Thefollowing sections elaborate on these functions. Note that the reverse sequence will be appliedif a SNMPv2 message is received.

octet sequence

BER

Admin. Model

MD5

DES

dstParty srcParty Context PDU

BER

authInfo

snmpAuthMsg

dstParty privData

dest.Addr.

PartyMIB

figure 16: Protocol Functions

Auth.Protocol

Protocol Oper.

Priv. Protocol

to UDP

from user entity

29

4.2 Protocol Operations

SNMPv2 messages are used to exchange management information between two SNMPv2protocol entities. A message consists of a PDU and a message wrapper that encapsulates thePDU. The construction of the message wrapper is considered in section 4.3. Now, theconstruction of a PDU is explained. The service primitives and part of the parameters need tobe mapped upon the several PDUs that exist.

For the exchange of management information between two peer SNMPv2 PEs, seven PDUs aredefined in the Protocol Operations document [RFC 1448], viz. a:

• GetRequestPDU,• GetNext-PDU,• GetBulk-PDU,• Set-PDU,• Inform-PDU,• Trap-PDU and• Response-PDU.

All PDUs possess the same structure. Its serialized form, i.e. its BER encoded form, is shownin figure 19. Besides the structure of the PDU, this document also describes the rules for theexchange of PDUs between each other.

By means of the Get-service the mapping of SPs and associated parameters upon PDUs andsequences of PDUs will be described. To implement the Get-service element, depicted in figure17, one successively need to use a GetRequest-PDU and a Response-PDU. To relate theResponse-PDU to the corresponding GetRequest-PDU a request-id is used.

In general, each request service primitive(SP) is mapped upon a corresponding request PDU.The reception of a request PDU causes the generation of the related indication service primitiveat the peer entity. Contrary to the mapping of request SPs upon corresponding request PDUs,all response SPs need to be mapped upon one Response-PDU. To generate a confirm serviceprimitive one needs to use the request-id of the Response-PDU to determine the operation.

Implementation of the inform and getbulk service is slightly different. In case of the Informservice, the peer SNMPv2 PE immediately returns a corresponding Response-PDU uponreceiving an InformRequest-PDU, i.e. the service element is provider confirmed.

The implementation of the Getbulk service is more difficult due to the separation of informationaccess and information exchange (e.g. BER encoding). Upon reception of a GetBulk-PDU thepeer PE needs to construct a Response-PDU which should be as large as possible. Regretfullyone cannot determine how many variables will fit in maximum-sized Response-PDU inadvance. The SNMPv2 PE must repeatedly obtain variable bindings from the agent by means

GetRequest-PDU

Response-PDUPE PE

GetReq-SP Cnf. Rsp.Ind.

figure 17: Mapping onto PDUs


of the getnext indication and response SPs. As long as variable bindings can be appended newvariables are retrieved. The results of the retrieval operation will be used in the next operation.If another object needs to be appended to the list depends on the remaining size in the packetand the size of the BER-encoded variable binding. The SNMPv2 PE computes this size andcompares it with the available space. If it fits it is added to the variablebindings field, otherwisethe construction stops. Mind that processing also can be terminated if no more objects areavailable (e.g. endOfMibView). This approach is also described in [Clo 93].

4.3 Administrative Model

The wrapper that encapsulates the PDU, provides control information used to guarantee aproper message1 exchange between two SNMPv2 entities. The Administrative Model [RFC1445] describes how the message headers which encapsulate the PDUs must be constructed andprocessed. These headers contain control information to regulate the processing, e.g. theinformation to determine what kind of privacy protocol is used. Besides providing the rules forthe exchange of management information in a variety of security modes, the administrativemodel also handles access control.

The construction and processing of these headers is based upon parties. By means of a party isdefined for instance which transport domain is used or which authentication protocol isrequired. Besides parties, contexts are used to denote which management information will beaccessed. As mentioned in previous chapters the use of parties and contexts is to the serviceuser. By means of QoS parameters, symbolic hostnames and symbolic contextnames one couldspecify e.g. the security requirements. Now, the procedure to select parties and contexts isdescribed. Subsequently, an example will be given to illustrate the use of this procedure.

Parties are selected using the parameters of a request SP, viz. the QoS, agentname,contextidentifier and the type of SP. Further, the party, context and access control tables of thepartyMIB are used. Parties and contexts are selected based on the following steps (see also thetables 7, 8 and 9):

(1). First, determine the index of the context (i.e. ContextIndex) using the symboliccontextidentifier (see also chapter 3). Based on the ideas of [RFC 1503] one can use acontext resolver to obtain a context identifier out of a symbolic name.

(2). Determine the internet address of the system that needs to be managed by means of thesymbolic ‘system name’ parameter, e.g. by means of gethostbyname(). If the systemname does not exist the selection fails.

(3). Determine the required authentication and privacy protocol from the QoS parameter.QOS = NONE : partyAuthProtocol = noAuth, partyPrivProtocol = noPriv.QOS = AUTH : partyAuthProt. = v2md5AuthProtocol, partyPrivProt. = noPriv.QOS = PRIV: partyAuthProt. = v2md5AuthProtocol, partyPrivProt. = noPriv.

(4). Determine by means of the party table a partyIndex of a destination party that fulfils therequirements. That is:

partyTaddress == IPaddress from step (2).;partyLocal == FALSE; (I.e. the party corresponds to remote system)partyAuthProtocol == authentication protocol of step (3);partyPrivProtocol == privacy protocol determined in step (3);

1. Proper with respect to authentication requirements, privacy requirements, and authorization.

31

(5). Then, the access control table is consulted for a destination party and a context that isallowed to perform the operation denote SP type. If such a combination exist one hasfound a combination of parties that may perform the operation w.r.t. the objects that arecontained in the provided context. Note that in the access control table the dstpartyIndexand contextIndex correspond with the aclTarget and aclResources indices (like foreignkeys).

Now an example is given to illustrate this procedure. This example is based on the tablesdepicted below.

A manager wants to change (i.e. Set operation) values of particular objects belonging tosystem ‘utis93’. These objects are contained in the context identified by ‘Utis93Objects’. Asnot every one is allowed to change these objects one needs to use authentication (QOS =AUTH).First, the symbolic contextname ‘Utis93Objects’ is mapped onto a contextidentifier‘InitialContextId.130.89.16.43.1’ using a context resolver. The context table is consulted todetermine a context which contextIdentity is equal to the contextIdentifier. As one can seethis will result in contextIndex 1 (step 1). The internet address of system name ‘utis93’ isretrieved e.g. by means of a system call, resulting in address 130.89.16.43 (step 2).The quality of service requirements implied the use of the ‘v2md5Auth’ and ‘noPriv’protocols (step 3). Walking through the party table one finds the party identified by‘InitialPartyId.130.89.16.43.3’ (step 4). This destination party corresponds to partyIndex 3.The (destination) partyIndex together with the contextIndex are used to determine a sourceparty out of the access control table (step 5). The third row allows a set-operation on theobjects identified by aclResources. The corresponding sourceParty has a partyIndex of 4.This party is identified by ‘InitialPartyId.130.89.16.43.4’.

partyIndex partyIdentity partyLocal partyTaddress partyAuthProt. partyPrivProt.

1 InitialPartyId.130.89.16.43.1

FALSE 130.89.16.43161

noAuth noPriv


TRUE arbitrary noAuth noPriv


FALSE 130.89.16.43161

v2md5AuthProtocol

noPriv


TRUE arbitrary v2md5AuthProtocol

noPriv

.. .. .. .. .. ..

Table 7: part of PartyTable (at manager side)


4.4 Basic Encoding Rules

The Basic Encoding Rules (B.E.R.) [ISO 8825] take care of the mapping of abstract datanotations onto an unambiguous sequence of octets and vice versa1. This sequence may then betransmitted over the network by means of one UDP datagram. The BER are used to achieveinter-operability between different communicating machines. The exchanged representationshould be independent of machine characteristics such as word length and byte order. In [RFC1449] some additional constraints are defined to make inter-operability easier.

The BER uses a tag-length-value (TLV) encoding to map an ASN.1 type onto a sequence ofoctets (figure 18).

figure 18: TLV-encoding

The tag denotes the ASN.1 type. The length field provides the size of the encoded ASN.1 value.The value-field comprises the encoded ASN.1 value. This value on its turn can be a TLV-encoding or a sequence of TLV-encodings. For more detailed information see for instancechapter 8 of [Rose89].

1. These processes are called serialization and extraction.

contextIndex contextIdenty contextLocal

1 InitialContextId130.89.16.43.1

FALSE

2 InitialContextId130.89.16.43.2

FALSE

.. .. ..

Table 8: part of ContextTable (at manager side)

aclTarget aclSubject aclResources aclPrivileges

1 2 1 Get, GetNext,Getbulk

2 1 1 Response,Trap

3 4 1 Get, GetNext,Getbulk, Set

4 3 1 Response,Trap

.. .. .. ..

Table 9: Part of Access control Table (at manager side)

TAG LENGTH VALUE

33

In [RFC 1445], [RFC 1448] and [RFC 1442] the structure of message headers, PDUs, as wellas the syntax of managed objects are defined by means of Abstract Syntax Notation One(ASN.1)[ISO 8824]. These abstract notations are transferred to a transfer syntax by the BER. Infigure 19 the complete structure of a SNMPv2 message is shown in its serialized form.

0xA2 LEN srcParty dstParty context pdu

0xA1 LEN authInfo authData

0x81 LEN

0xA1 LEN privDst privDataSnmpPrivMsg :

0x06 LEN OID-value SnmpAuthMsg

0x06 LEN OID-value 0x06 LEN OID-value 0x06 LEN OID-value

SnmpMgmtCom :

type LEN requestid errorstat. errorind. varbs

0x02 LEN int-value0x47 LEN Uint32-val

0x30 LEN VarBind VarBind.....................

0x30 LEN name value

0x06 LEN OID-value type LEN value

0x02 LEN int-value

PDU :

VarBindList:

0x04 0

figure 19: SNMPv2 Message structure (no authentication)


4.5 Security Protocols

Messages can be exchanged in various security modes, e.g. authenticated and encrypted. Tosupport the various modes SNMPv2 currently uses two security protocols [RFC 1446], viz. anauthentication protocol based on a Message-Digest algorithm and a privacy protocol based ona symmetric privacy algorithm.

The authentication protocol is based on the inclusion of time-stamps, the computation of adigest and the inclusion of a shared secret. Data origin authentication is provided by means ofa shared secret between the sender and receiver of a message, i.e. the private authentication key.A message digest algorithm based on MD5 [RFC 1321] is used to provide data-integrity. Bymeans of the inclusion of timestamps in the message, one can verify that a message wasgenerated recently. All the information necessary for authentication, is stored in theauthentication information field (authInfo) of a message (see Figure 39) [RFC 1446].

The privacy protocol is based on the Data Encryption Standard (DES) algorithm [FIPSpublication 46-1]. This algorithm is used to encrypt and decrypt a message.

4.6 Transport Service

The transport service that is considered in this report is the unreliable connectionless transportservice based on UDP [RFC 768]. This service is the preferred transport service for SNMPv2[RFC 1449]. The UDP based transport service offers a data transfer facility (see figure 21).

figure 21: Temporal ordering of the data transfer service

The unreliability of this service is not expressed in this picture. The offered data transfer serviceis an unconfirmed service, represented by a sequence of DataRequest and DataIndicationservice primitives. The parameters of these primitives are a ‘data’ parameter that conveys theuser data, and two addresses to identify the receiver and the sender (see table 10).

parameters request indication

destination address M

source address M

data M M(=)

table 10 : Parameters and parameter value dependencies of DataTransfer-service

Data-request

provider service user

Data-indication

service user

5 Definition of the SNMPv2 API

The service specified in chapter 3 is made available to programmers of managementapplications by means of an Application Programming Interface (API). The API provides a Cprogramming interface for network management applications running in a Unix environment,enabling those applications to make use of the communication service defined in chapter 3. TheAPI consists of a number of functions which can be used as building blocks for the constructionof SNMPv2 based manager and agent applications. In this chapter the API is described.

During my assignment other SNMPv2 APIs have been defined elsewhere. A Windows API1 hasbeen developed for the Microsoft Windows environment. In the UNIX environment anotherAPI has been defined within the SNMPv2 package2 of Carnegie Mellon University (CMU). Thedifference between these APIs and the API described in this chapter, is that the latter hides (asmuch as possible) details of the SNMPv2 protocol. In our API it is for instance not necessary tounderstand the party concept; it is sufficient to specify the requested quality of service (i.e.authentication and/or encryption). Our API is thus defined at a higher level, which makesdevelopment of management applications easier.

Section 5.1 describes how the API has been derived from the service specification of chapter 3.It shows the way service primitives and parameters are mapped onto procedure calls and datastructures. Next, section 5.2 shows API functions. This section describes the external behaviourof these functions and how these functions can be invoked. For sake of completeness section5.3 specifies the data structures. Finally, section 5.4 explains how these functions can becombined to construct an application. This will be illustrated by two examples.

5.1 Mapping of Service Primitives and Parameters

The purpose of this section is to motivate the choices made concerning the mapping of serviceprimitives and parameters to procedure calls and data structures. This mapping can be done inseveral ways:

• One to one mapping of service primitive (SP) and procedure call

• Mapping all incoming3 SPs, irrespective of the type of SP, upon a single procedure call.Also all outgoing SPs are mapped upon a single procedure call.

• Mapping of incoming SP and its associated outgoing SP upon one procedure call.

1. This specification can be retrieved via anonymous FTP from host microdyne.com (directory /pub/winsnmp).2. This package can also be retrieved via anonymous FTP from lancaster.andrew.cmu.edu (directory /pub/snmp-

dist).3. An incoming or received SP denotes a SP that is generated by the provider. An outgoing SP is generated by the

application.

36 5. Definition of the SNMPv2 API

Now these mappings will be described together with their advantages and disadvantages.

One to one mapping

If one uses a one to one mapping, each service primitive type is mapped upon a dedicatedprocedure call. For example a GetRequest SP is mapped onto the following C-procedure call:

snmp_GetRequest( agentname, request_id, qos, contextname, variable_names );

char *agentname;

INTEGER32 request_id;

QOS qos; /* e.g. authentication */

char *contextname;

VARNAMELIST *variable_names;

Similarly, the other service primitives of chapter 3 are mapped upon dedicated procedure calls.Note that the parameters of the service primitive are mapped upon the arguments of the call.

For incoming SPs an additional procedure call is necessary to identify the event, prior to theinvocation of the specific procedure calls. In case of an event this procedure, calledsnmp_Look,returns the kind of the service primitive by means of itstype parameter:

snmp_Look( .., type);

Mapping of incoming, respectively outgoing SPs upon one procedure call.

One can also map incoming, respectively outgoing, service primitives onto a single procedurecall. For example, all outgoing SPs are mapped upon:

snmp_OutgoingSP( type, genericParameterStruct );

Thetype parameter is used to denote the kind of service primitive it resembles (e.g. GetRequest,GetResponse or SetResponse). A generic data structuregenericParameterStruct is used to carry theparameters of the service primitive. This structure needs to contain all parameters which maybe used in the different outgoing SPs. Depending on the type of SP the invoker needs to providethe specific parameter values related to that SP.

Such a generic structure could be defined as:

typedef struct {

char *agentname; /* or manager name in case of an Inform Req SP */

INTEGER32 request_id; /* or replyid in case of Rsp SPs */

QOS qos;

INTEGER max_repetitions; /* or errorstatus in case of Rsp SPs */

INTEGER non_repeaters; /* or errorindex in case of Rsp SPs */

char *contextname;

VARNAMELIST *variable_names; /* for a GetReq, a GetnextReq and a GetbulkReq */

VARBINDLIST *variablebindings; /* for a SetReq, an InformReq and Rsp SPs */

} genericParameterStruct;

Note that in this case it is not necessary to introduce an additional call to identify the type ofincoming SP.

Mapping of incoming plus its associated outgoing SP upon a single procedure call.

One could also map an outgoing SP and its associated incoming SP upon one procedure call.Contrary to the previous mappings, this mapping results in blocking calls, i.e. one blocks until

37

a request has been confirmed or a time-out occurred. For example, a GetRequest SP and aGetConfirm SP could be mapped onto:

snmp_GetReqCnf( agentname, request_id, qos, contextname, variable_names, errorstatus, errorindex,

variablebindings );

char *agentname;


QOS qos;

char *contextname;


INTEGER errorstatus;

INTEGER errorindex;

VARBINDLIST *variablebindings;

The mapping of Indication SP and associated Response SP is more difficult because the codewhich implements the operations, needs to be included. The user needs to provide the functionswhich must be called to retrieve or modify objects, like:

snmp_GetIndRsp( GetObjectsFunc, ... )

void (*GetObjectsFunc)( );

...

The GetObjectsFunc() allows the application developer to supply its own code to perform aspecific operation.

Deciding upon a mapping

It was decided to map each primitive upon a dedicated procedure call because it correspondsbest with the service description of chapter 3. A disadvantage of this mapping is the largenumber of calls that are necessary, which results in a less compact program. An advantage ofthis approach is that it shields the user from having to know which parameters need to besupplied. This additional shield may be superfluous. Actually the first kind of mapping providesadditional functionality compared to the second one. In practice the first one will beimplemented using the second kind of mapping underneath. So, in principle the two proceduresof the second mapping are sufficient to build all kinds of manager and agent applications. Thethird approach was considered to be less clear compared to both other mappings and lesssuitable because of the blocking calls. To be able to send multiple requests successively,multiple threads need to be used.

5.2 SNMPv2 API functions

This section describes the functions of the API. It also shows how these functions can beinvoked. The functions are defined using the C programming language. These functions aredivided into five categories:

• general functions• manager specific send functions• manager specific receive functions• agent specific send functions• agent specific receive functions

The data structures on which the parameters are mapped are specified in detail in section 5.3.


5.2.1 General functions

The general functions are used in the manager application as well as in the agent application.These functions are internal functions that do not result in related packets over the wire. Twofunctions are used to attach applications to, respectively detach applications from the SNMPv2Engine. Another function is used to determine the type of event, i.e. thesnmp_Look() functionmentioned above. And the fourth is used to determine the reason of an error, if something failed.

• snmp_OpenStatus snmp_Open( type )

ROLE type;

The snmp_Open function is used to attach an application to the SNMPv2 Engine. This callshould be issued before any other function call. In case the SNMPv2 Engine is not runningyet, it will be started. Atype parameter is used to specify the role of the application entity:

MANAGER denotes that an application runs in a manager role,MANAGER_AGENT denotes that an application runs in a manager and agent role,AGENT denotes that an application runs in an agent role1.

The function returns a value of type Status to denote the result of the call. The status is definedby the following data structure:

typedef enum{

SUCCESS = 0,

FAILURE = 1

} Status;

• snmp_CloseStatus snmp_Close( how )

HOW how;

This function detaches from the SNMPv2 Engine. One should use this call before terminatingthe application. It is the counterpart ofsnmp_Open(). Thehow parameter is used to specify thepost processing of pending requests:

GRACEFULL to perform a graceful termination of the application, pendingrequests will be serviced.

DISCARD to detach immediately.

• snmp_LookStatus snmp_Look( userset, timeout, type )

fd_set *userset;

struct timeval *timeout;

SPTYPE *type;

Thesnmp_Look() function is used to identify the type of incoming event (e.g. TrapIndicationSP, GetConfirm SP). It is usually followed by a dedicated call (see sections 5.2.3 and 5.2.5)to handle the specific event. Further, it provides the possibility to check other file-descriptorswhich are used for other purposes (e.g. standard input). By means of theuserset parameterthese file descriptors can be provided. Upon return this set provides the descriptors on whichan event is received. Thetimeout parameter can be used to specify the time the call will beblocking. If the specified time expires and no event occurs, control is given back to theapplication. If one supplies a zero value, this function returns immediately. If one provides a

1. proxy agents should also be started in this mode.

39

NULL pointer for thetimeout parameter this call will block indefinitely. Upon return thetypeparameter denotes the kind of event that occurred:

GET_REQ to denote that a get request needs to be processed. The followingparameters can be described similarly:GET_IND, GET_RSP, GET_CNF, GETNEXT_REQ, GETNEXT_IND,GETNEXT_RSP, GETNEXT_CNF, GETBULK_REQ, GETBULK_CNF,SET_REQ, SET_IND, SET_RSP, SET_CNF, INFORM_REQ,INFORM_IND, INFORM_CNF, TRAP_REQ and TRAP_IND.1

TIMEOUT to denote that no event happened in the specified period,NONSNMP to denote that an event occurred at a non SNMP file descriptor,

used for other purposes,ERROR_IND to denote the SNMPv2 Engine generated an error indication.

• snmp_ErrorIndicationStatus snmp_ErrorIndication( requestid, errortype );

INTEGER32 *requestid;

ERRTYPE *errortype;

If the snmp_Look() function returns ERROR_IND this function can be invoked to getinformation about the reason of the failure. This Error indication SP is generated when arequest SP could not be sent e.g. due to Quality of Service (QoS) requirements which couldnot be fulfilled. Therequest-idprovides the identification, theerrortype denotes one of thefollowing currently defined reasons2:

TIMEOUT request identified by request-id timed out (i.e. a negativeconfirm),

GENERR to denote an general error,NOSUCHCONTEXT if the supplied context didn’t exist,NOSUCHHOST if specified host did not exist,QOSFAILED if the QoS requirements cannot be fulfilled,TOOMANYVBS to many variable bindings requested.

The functions which are defined in the remaining part of this section, will be given the samenames as used in chapter 3 to denote the SNMPv2 SPs.

5.2.2 Manager specific send functions

Thesnmp_GetRequest function is used to describe the manager specific send functions.

• snmp_GetRequestStatus snmp_GetRequest( agentname, request_id, qos, contextname, variable_names)

char *agentname;


QOS qos;

char *contextname;


This function constructs an appropriate request, which is sent to the agent that is identified bythe agentname parameter. Theagentname is a symbolic name, like ‘utis93’, that denotes the

1. Note that, as explained in section 3.2.4, the Getbulk Ind and Rsp SPs are simulated via Getnext Ind and Rsp SPs.In section 3.2.6 was explained that the Inform is provider-confirmed.

2. This list needs to be extended to provide a more precise image of the failure.


system to be managed. Therequest_id is used to identify the request among several otheroutstanding requests. Thequality of service (qos) parameter specifies the required securityprecaution. Thecontextname denotes the set of objects one wants to manage. Finally, thevariable_names are used to select the individual objects. The data types used above (e.g.QOS

andINTEGER32) are specified in section 5.3.

• snmp_GetNextRequestStatus snmp_GetNextRequest( agentname, request_id, qos, contextname, variable_names );

char *agentname;


QOS qos;

char *contextname;


The snmp_GetNextRequest is used to retrieve the successors of the objects as specified byvariable names.

• snmp_GetBulkRequestStatus snmp_GetBulkRequest ( agentname, request_id, qos, contextname, max_repetitions,

non_repeaters, variable_names);

char *agentname;


QOS qos;

char *contextname;

INTEGER max_repetitions;

INTEGER non_repeaters;


Snmp_GetBulkRequest retrieves as much data as possible. Themax-repetitions andnon-repeaters

parameters provide additional information used to retrieve this data (see also section 3.2.4).

• snmp_SetRequestStatus snmp_SetRequest ( agentname, request_id, qos, contextname, variable_bindings );

char *agentname;


QOS qos;

char *contextname;

VARNAMELIST *variable_bindings;

This function is used to change the values of the objects as specified by thevariable_bindings

parameter.

• snmp_InformRequestStatus snmp_InformRequest ( managername, request_id, qos, variable_bindings );

char *managername;


QOS qos;

VARBINDLIST *variable_bindings

With a snmp_InformRequest() a manager notifies another manager of the occurrence of anextraordinary event e.g. if a counter exceeds a specific value.

41

5.2.3 Manager specific receive functions

The manager related receive functions comprise indication and confirm functions. Prior to theinvocation of these functions, thesnmp_Look() function is used to identify the received event. Ifit indicates that the type of operation is an indication or confirm one of these functions can beused to retrieve the corresponding data.

• snmp_GetConfirmStatus snmp_GetConfirm( request_id, errorstatus, errorindex, variable_bindings )

INTEGER32 *request_id;

ERRORSTAT *errorstatus;

INTEGER *errorindex;

VARBINDLIST *variable_bindings;

This function can be used to retrieve the results of a Get service element. Therequest-id

parameter denotes to which request this confirm belongs.Errorindex anderrrorstatus provideinformation about the success of the operation and thevariable binding listcontains themanagement information.A similar description can be given for the other receive functions.

• snmp_GetNextConfirmStatus snmp_GetNextConfirm ( request_id, errorstatus, errorindex, variable_bindings )





• snmp_GetBulkConfirmStatus snmp_GetBulkConfirm (request_id, errorstatus, errorindex, variable_bindings)





• snmp_SetConfirmStatus snmp_SetConfirm( request_id, errorstatus, errorindex, variable_bindings )





• snmp_InformIndicationStatus snmp_InformIndication( managername, variable_bindings )

char *managername;


This functions is used to retrieve the information that was sent by another manager. Thisinformation is contained in the list ofvariable_bindings. The name of the manager that sent therequest is indicated by themanagername parameter.


• snmp_InformConfirmStatus snmp_InformConfirm( request_id, errorstatus, errorindex, variable_bindings )





• snmp_TrapIndicationStatus snmp_TrapIndication( agentname, variable_bindings )

char *agentname;


Thesnmp_TrapIndication function denotes that the agent, identified by theagentnameparameter,noticed something extraordinary and informed the concerned managers. The list ofvariable_bindings provides additional information of this situation.

5.2.4 Agent related send functions

To build an agent application the following send functions are available. One function concernsthe sending of a trap and several functions concern the generation of a response.

• snmp_GetResponseStatus snmp_GetResponse( reply_id, error_status, error_index, variable_bindings )

INTEGER32 reply_id;

ERRORSTAT errorstatus;

INTEGER errorindex;


After retrieving the variables delivered by the indication function, a response can be sent backinvoking thesnmp_GetResponse function. Thereply_id must be the same as thereply_id that wasreturned with thesnmp_GetIndication(). Theerror_status, error_index and the list ofvariable_bindings

provide the information that will be sent back to the requesting manager.

The following response functions can be invoked similarly:

• snmp_GetNextResponseStatus snmp_GetNextResponse( reply_id, error_status, error_index, variable_bindings )

INTEGER32 reply_id;


INTEGER errorindex;


• snmp_SetResponseStatus snmp_SetResponse( reply_id, error_status, error_index, variable_bindings )

INTEGER32 reply_id;


INTEGER errorindex;


Besides these response functions asnmp_TrapRequest function exists:

• snmp_TrapRequestStatus snmp_TrapRequest( variable_bindings )

43


In case of an exceptional condition an agent generates a trap by invoking this function. TheSNMPv2 Engine determines to which manager(s) a trap must be sent. Thevariable_bindings listcan be used to provide information about the event that caused the trap.

5.2.5 Agent specific receive functions

The agent specific receive functions deal with the processing of indications.

• snmp_GetIndicationStatus snmp_GetIndication( reply_id, view, timedomain, entity, variable_names )

INTEGER32 *reply_id;

INTEGER *viewindex;

OID *timedomain;

char *entity;


If the snmp_Look() function indicates that a GetIndication arrived, this function can be used bythe agent to retrieve the corresponding data. Thereply_id that is returned, must be used whenthe agent generates a response. Thevariable_names parameter provides the list of objectnamesa manager wants to get. Theviewindex, timedomain andentity provide additional information(see section 3.2) to retrieve these individual objects.

Like thesnmp_GetIndication the other Indication primitives can be described:

• snmp_GetNextIndicationStatus snmp_GetNextIndication( reply_id, view, timedomain, entity, variable_names )


INTEGER *viewindex;

OID *timedomain;

char *entity;


This function is used to denote that the successors of the objects, as denoted by the listvariable names, which must be retrieved.

• snmp_SetIndicationint snmp_SetIndication( reply_id, view, timedomain, entity, variable_bindings )


INTEGER *viewindex;

OID *timedomain;

char *entity;


This function is used to denote that the values of the objects which are provided by means ofthe variable binding list, must be modified.

5.3 Parameters

This section describes the second part of the API, viz. the definition of the data structures usedin section 5.2. The representations which were used by the parameters used in section 5.2, havebeen presented (as much as possible) using the names of the ASN.1 specifications, specified in


theStructure of Management Information document [RFC 1442] and theProtocol Operationsdocument [RFC 1448]. The ASN.1 structures, used in the service specification of chapter 3, aremapped upon abstract representations. Applying these names and mappings makesinterpretation of the API definition and implementation easier. Another advantage of usingabstract representations consequently is, that it makes specification portable.

The local representations are specified below. First, the representations of the universal ASN.1types are presented:

/* Integer representations */

typedef int INTEGER;

typedef int INTEGER32;

/* Bitstring representation */

#define MAXBITSTR 255

typedef struct{

int bstr_len; /* length of bitstring */

OCTET bstr[ MAXBITSTR ]; /* contents of bitstring */

int bstr_bitsunused; /* unused bits of final octet */

}BITSTR;

/* Octet string representation */

typedef unsigned char OCTET;

#define MAXOCTETSTR 255

typedef struct{

int octstr_len; /* length of data */

OCTET octstr[ MAXOCTETSTR ]; /* current pointer into data */

}OCTETSTR;

/* Object Identifier representation */

typedef unsigned int OIDELEM;

#define MAXSUBOID 128

typedef struct{

int count; /* number of sub-identifiers */

OIDELEM sub_oid[ MAXSUBOID ]; /* the list of sub-identifiers */

}OID;

The above used values forMAXBITSTR, MAXOCTETSTR and MAXSUBOID are based on thevalues specified in [RFC 1442]. In practice smaller values may be sufficient and will savememory to store these values.

The below specified application-wide ASN1-types are mapped onto the following localrepresentations:

typedef unsigned int COUNTER32;

typedef unsigned int GAUGE32;

typedef unsigned int TIMETICKS;

typedef unsigned int UINTEGER32;

#define IPADDR OCTETSTR; /* implicit octetstring */

#define OPAQUE OCTETSTR; /* implicit octetstring */

#define NSAPADDR OCTETSTR; /* implicit octetstring */

45

typedef struct{

unsigned upper32;

unsigned lower32;

}COUNTER64;

Besides the universal and application-wide ASN.1 types defined in [RFC 1442], some othertypes were defined which are specifically related to SNMPv2. These SNMPv2 specific types,as specified in chapter 3, theProtocol Operations document [RFC 1448] and which were usedin the above function descriptions have the following C equivalents:

#define MAXBIND 50

/* representation of the list which contains the variable names */

typedef struct {

int count;

OID varname_base[ MAXBIND ]; /* base address of array */

} VARNAMELIST;

/* representation of a variable binding */

typedef struct {

OID objectname;

OBJECTSYNTAX objectvalue;

} VARBIND;

/* representation of the list containing the variable bindings */

typedef struct {

int count;

VARBIND varbbase[ MAXBIND ]; /* base address of array */

} VARBINDLIST;

Notice in the current definition and implementation static arrays are used to represent the listsof variable bindings and variable names. Experience showed, it was not the most suitable kindof representation. It provides no flexibility and results in a less efficient use of memory for thestorage of these structures. In future versions these lists should be converted to dynamicstructures. The same remark can be made to the representation of object identifiers, octetstringsand bitstrings.

/* structure that contains the value and type of an variable: */

typedef struct {

TAGTYPE vartype; /* type of the variable */

OBJECTVALSYNTAX varval;

}OBJECTSYNTAX;

/* representation of value of object */

typedef union {

INTEGER int_val;

BITSTR bit_val;

OCTETSTR oct_val; /* OCTETSTR, OPAQUE, IPADDR, NSAPADDR */

OCTET null_val;

OID oid_val;

COUNTER32 c32_val;


INTEGER32 i32_val;

GAUGE32 g32_val;

TIMETICKS time_val;

COUNTER64 c64_val;

UINTEGER32 u32_val;

}OBJECTVALSYNTAX;

/* values to denote type of value */

typedef enum {

ASN1_INTEGER = 2,

ASN1_BITSTRING = 3,

ASN1_OCTETSTRING = 4,

ASN1_NULL = 5,

ASN1_OBJECTID = 6,

SMI_IPADDR = 64,

SMI_COUNTER32 = 65,

SMI_GAUGE32 = 66,

SMI_TIMETICKS = 67,

SMI_OPAQUE = 68,

SMI_NSAPADDR = 69,

SMI_COUNTER64 = 70,

SMI_UINTEGER32 = 71,

SNMP_NOSUCHOBJECT = 128,

SNMP_NOSUCHINSTANCE = 129,

SNMP_ENDOFMIBVIEW = 130,

}TAGTYPE;

#define SNMP_UNSPECIFIED ASN1_NULL

/* quality of service requirements */

typedef enum{

NONE = 0,

AUTH = 1, /* authentication only */

ENCRYPT = 2 /* encryption and authentication */

}QOS;

/* errorstatus values */

typedef enum{

NOERROR = 0,

TOOBIG = 1,

NOSUCHNAME = 2,

BADVALUE = 3,

READONLY = 4,

GENERR = 5,

NOACCESS = 6,

WRONGTYPE = 7,

WRONGLENGTH = 8,

47

WRONGENCODING = 9,

WRONGVALUE = 10,

NOCREATION = 11,

INCONSISTENTVALUE = 12,

RESOURCEUNAVAILABLE = 13,

COMMITFAILED = 14,

UNDOFAILED = 15,

AUTHORIZATIONERROR = 16,

NOTWRITABLE = 17,

INCONSISTENTNAME = 18

} ERRORSTAT;

5.4 Application Programming Guidelines

Having presented all available functions and data structures, leaves the question how thesefunctions can be combined to form a complete program. Two network management applicationprograms are provided to illustrate how to write an application.

In general a program consists of the following sequence of function calls which may beexecuted repeatedly:

1. Thesnmp_Open() function is used to attach to an SNMPv2 Engine.2. Depending on the kind of application the following functions are included:

In case of an agent application:a. Thesnmp_Look() function is called to determine if there are events received and need to be

processed. Further, it determines the type of request.b. Depending on the received event, indicated by thetype parameter of the previous function,

the specific retrieve function is activated, e.g.snmp_GetIndication().c. The information from the previous step, is used to perform the specific management

operation. The routines that perform these management operations need to be supplied bythe application developer himself.

d. If the operation has been performed, step 2c may yield a response. The response functionthat corresponds to step 2b (e.g.snmp_GetResponse()) will be invoked.

In case of a manager application:a. A request is prepared and it is sent by issuing a request e.g.snmp_GetRequest().b. The manager may invoke other requests (repeating step a and b) or usesnmp_Look() to

receive an event.c. If an event is received it will be handled by the specific function (e.g.snmp_GetConfirm()) as

indicated by thesnmp_Look() function of step 2b.d. Finally, the application processes the received results.

3. The snmp_Close() function terminates the session. It detaches the application from theSNMPv2 Engine.

The above described operational model is illustrated by means of the following applicationprograms. In figure 22 an example of an agent application is outlined and figure 23 shows anoutline of a manager application.


/* Outline of an agent application */

...

/* variable declarations */

snmp_Open( AGENT ); /* role of agent */

...

FD_ZERO( &set );

/* ... include other descriptors */

for(;;){ /* do forever */

readset = set;

snmp_Look( &readset, timeout, &type ); /* determine the kind of operation */

switch( type ){ /* handle events */

case GET_IND: /* retrieval operation */

snmp_GetIndication( &reply_id, &view, &timedomain, &entity,

&variable_names );

/* ... variable processing: Non-SNMP code ....*/

snmp_GetResponse( reply_id, error_status, error_index,

variable_bindings);

break;

case GETNEXT_IND: /* traversal operation */

/* similar to get */

break;

case SET_IND: /* modification operation */

/* similar to get */

break;

default:

printf( "Unknown type" );

}

...

}

...

figure 22: Outline of agent application.

49

/* outline of a manager application */

...

/* variable declarations */

...

snmp_Open( MANAGER );

FD_SET( STDIN, readset ); /* make user input available */

...

for(;;){

PrintMenu();

readset = set;

snmp_Look( &readset, timeout, &type );

switch( type ){ /* wait for events */

case TIMEOUT:

/* retransmit ...... or notice user */

break;

case NONSNMP:

/* check if user input (or other descriptors) are ready */

if ( FD_ISSET( STDIN, &readset ) ){

/* user wants to issue a request */

/* ... construction of a request ...*/

/* send a request, e.g. GetRequest: */

snmp_GetRequest( agentname, request_id, qos, contextname,

variable_names );

}

break; /* proceed */

case GET_CNF:

snmp_GetConfirm( &request_id, &errorstatus, &errorindex,

&varbindings );

/* print results or do something else with the results */

break;

/* GETNEXT_CNF, GETBULK_CNF, SET_CNF : */

/* ...... similar to GET_CNF ....*/

case ERROR_IND:

snmp_ErrorIndication( requestid, errortype );

/* print reason of failure */

break;

default:

printf("not implemented yet\n");

break;

}

}

snmp_Close( GRACEFULL ); /* handle pendning requests */

figure 23: Outline of a possible manager application

6 Choosing an ImplementationStructure

The intent of this chapter is to describe the way SNMPv2 can be implemented in software in aUNIX environment. Basically there are two ways. The first method implements a completeSNMPv2 stack on a local site, i.e. the SNMPv2 PE and possibly the layers below, as a program(see Figure 24a). The second method integrates this stack with the code that implements themanager or agent entity, into one program (Figure 24b). The first option results in separateprograms which will execute as different processes1.

Figure 24: The Server and Activity-thread model

The first way of implementing is known as theServer model [Eijk91] [Svo89]. In this model theinter-layer communication is by means of inter process communication (IPC). The other modelis called theActivity-thread model. Using this model implies that all functionality needed forthe processing of requests through the stack (i.e. the activity) is included into one executableprogram. In this case, the inter-layer communication is implemented by means of procedurecalls.

In section 6.1 both alternatives will be compared. It discusses and motivates why the server wayof implementing has been chosen. Section 6.2 elaborates on this implementation structure. Itdescribes the parts that be distinguished. Section 6.3 and 6.4 consider these different parts andtheir communication.

6.1 Server Model vs. Activity-thread Model

In this section the models which were described above, will be compared. Based on the criteriamentioned in the chapters 1 and 2, a choice was made to implement SNMPv2 using the Servermodel. Compared to the Activity-thread model, the Server model has the following advantages:

1. A UNIX user level process is meant.

a). b).

= executable

SNMPv2 PE

SNMPv2 PE

programM/AEntity

M/AEntity

52 6. Choosing an Implementation Structure

• Multiple managers and agents on a host

The Server model enables the use of multiple applications on a host without having problemsbinding the UDP ports which are specially reserved to SNMP. Two UDP ports, viz. 161 and162, are assigned for the use of SNMP. Because just one SNMPv2 Protocol Machine (SPM)will serve all application processes (see also Figure 25), the applications processes are ableto share the reserved ports.

• A clear structural model

The server model reflects the conceptual layered structure, described in chapter 2, moreclosely. The management application functionality is clearly separated from the managementcommunication functionality. This structure separates the concerns at best and contributes tocomprehensibility of the implementation.

Implementing using the Server model, however has the following disadvantages:

• Performance drawback

The inter-layer communication of the Server model is typically less efficient (i.e. more timeconsuming) compared to the communication in the Activity-thread model. IPC usuallyrepresents higher overhead compared to communication by means of procedure calls. Due toscheduling, switching between processes and the copying of data between processes thismodel may be less suitable to implement.

• Flow of control

Implementation of IPC usually requires more effort than implementing procedure calls.Especially the communication of one SPM with multiple application processes requiresadministration of these processes and their related activities. For example, an SPM needs toadminister which requests were sent by a specific application process to be able to return thecorresponding responses. Application processes must be identified to distinguish among themultiple application processes executing on a single machine (host).

• Security

One needs to implement security mechanisms to guarantee a secure IPC between applicationprocess and SPM. If no secure IPC is realized, the security mechanisms (e.g authentication)provided by the administrative model [RFC 1445] can be misused. Though, internal securityrisks were considered to be less compared to the risks if one uses the network.

Taking the above enumerated points into consideration, it was decided to implement SNMPv2according to the Server model. For a first implementation, the ability to use multipleapplications on a host and a clear structural model were considered to be more important thanperformance aspects (see chapter 1). Practice must show if a reasonable performance can beobtained using this model.

More information about the advantages and disadvantages can be found in [Svo89], [Eijk91]and [Ser93].

6.2 Applied Implementation Structure

The complete implementation structure is shown in Figure 25. The application entitiesmentioned in the previous chapters are mapped onto application processes which aresymbolized by the ovals. The SNMPv2 Protocol Entities described in the chapter 4, areimplemented by means of one SPM. The SPM handles the different application processes

53

running on a host. The code which implements the SPM, comprises most of the SNMPv2functionality. Because the SNMPv2 functionality is made available by means of an API(chapter 5), a part of the SNMPv2 protocol functions will be implemented as part of theapplication program. The conceptual SNMPv2 service boundary is therefore merged in theapplication program. The SPM communicates with the multiple application processes by meansof Inter Process Communication (IPC). IPC is described in detail in the following section. Thestructure of the SPM is described in section 6.3.

6.3 Inter Process Communication

This section considers the IPC that is used to communicate between an SPM and one or moreapplication processes. Several facilities are provided by the SunOS operating system (release4.1) to implement the IPC [SUN 90]. Part of the provided facilities belong to BSD UNIX andpart of it belong to UNIX System V. The following IPC facilities were considered:

• Pipes

Pipes employ a one-way byte stream between related processes. Communicating processesneed to be descendants of a common process. Pipes are implemented using files. This pipemechanism is only suitable in this particular work if local storage is available. Using thenetwork for file access should be avoided (Network management must continue to functionas long as possible). Implying that one should not use the functionality of the network asmuch as possible.

• Named pipes (FIFO queues)

A named pipe (from System V) provides an intermediate for multiple communicatingprocesses which are not related. Also a named pipe is implemented by means of a file. Anamed pipe is identified by an entry in the file system. The same remark can be made withrespect to the use of the network. Another problem relates to the identification of the namedpipe. A unique name for the pipe must be obtained with care.

• Message queues

Messages (from System V) may be exchanged between different communicating processesby means of message queues. To put or fetch messages from a queue only blocking andnon-blocking r/w system calls are defined. This requires the polling of queues to determine

SNMPv2 API

IPC

SNMPv2 PM

applicationprocess

library includedin applicationprocess

Figure 25: General implementation structure.


if data is available. These messages have an explicit length. This length was too small (2Kbyte) and could only be changed with root permission. In order to use the message facilityit must be configured into the kernel.

• Shared memory,

Shared memory (from System V) provides another means of IPC. If one uses sharedmemory, semaphores are needed to regulate the memory access of the different processes.To put or get packets from shared memory one needs to get a semaphore. Only blockingand non-blocking operations are defined to get a semaphore. Polling is demanded todetermine if data is available. In order to use the message facility it must be configured intothe kernel.

• Socket-based IPC

1. Sockets (from BSD) in the UNIX domain:Sockets in the UNIX domain support a bi-directional flow of data between processes on alocal host. A socket in the UNIX domain is identified by a pathname within the file systemname space. The names are only used forrendez-vous and not for message delivery once aconnection is established. Getting unique pathnames that need to be known by the differentprocesses is difficult.2. Sockets in the internet domain:Sockets in the internet domain, using the TCP/IP protocol, provide a full duplex reliablecharacter stream. Identification of the socket is obtained by means of a portnumber and ainternet address. Normally these connections are used between processes on differentmachines, but it works as well for the communication on the same machine. Using the so-called loopback address prevents that the network is used.

• Remote Procedure Call (RPC)

Though RPC is usually used to communicate between processes on different machines itworks as well for the communication between processes on the same machine. RPC hideslow level networking mechanisms such as TCP/IP and UDP/IP. RPC makes programmingprobably easier, but adds overhead. Underneath still TCP/IP is used.

Coming to a conclusion:

In the above given enumeration the available IPC facilities of the implementationenvironment have been described and its advantages and disadvantages were discussed.Socket-based IPC (internet domain) has been considered to be most suitable. Access to TCPis similar to access to UDP. This allows the SPM to communicate with the applicationprocesses and the network, using the same interface.

6.4 Implementation Structure of SNMPv2 Protocol Machine

This section will elaborate on the structure of the SPM. It considers two approaches that can beused to implement an SPM. The tasks of an SPM can be performed, on the one hand by a singlethread or on the other hand by multiple threads. In this report a thread resembles a single line ofcontrol in a program. A thread in UNIX can be implemented as a process1 or as an Light WeightProcess (LWP).

1. A process can consist of a number of LWPs. Note that in UNIX an LWP is usually called a thread.

55

It took a lot of time and discussions whether to implement a multi-threaded or a single-threadedversion of a SPM. The single-threaded version has been chosen at first instance. A single-threaded version is usually easier to implement. There is just one flow of control that can befollowed easily. Debugging of a multi-threaded program is evidently more difficult. As all theSNMPv2 functionality is developed from scratch, it is better to start with a simple version atfirst instance, and (may be) grow towards a more sophisticated multi-threaded implementationin future. Being familiar with the single-threaded way of implementing is another point thatcontributed to this choice.

Though the single-threaded approach has been chosen, the multi-threaded approach is probablybetter suited in this implementation environment. If one uses multiple threads, packets can beprocessed independently. Small, uncomplicated packets can pass quickly through the SNMPv2layer while the construction of packets requiring authentication and encryption is more timeconsuming. Especially encryption can be very time consuming. The encryption of a maximumsized SNMPv2 packet (i.e. 64Kbyte) comprised approximately 15 seconds.

Another issue that has been discussed relates to performance. Is the performance of a single-threaded implementation reasonable? How performs a multi-threaded version compared to asingle-threaded version on a single or a multi-processor system? Beside these questions a lot ofothers arised. But it is hard to answer these questions without having measurements. Futureexperience must show if a single-threaded version will do or that a multi-threaded version isneeded. Of course, it may be possible that the performance of both versions is insufficient. Inthat case one should conclude that a separation of SNMPv2 functionality into applicationprocess and SPM has not been suitable. At the moment further research on this topic ofimplementation structures is done and will be presented in [Kna94].

In the remaining part of this section, both the single-threaded and the multi-threaded structureare considered.

6.4.1 Single-threaded SPM

In a single-threaded SPM implementation, one thread SR interacts with as well the applicationprocesses as the network (see Figure 26). Thread SR continuously checks all the queues1, i.e.the connect request queue (CQ), the data queues (AQi) to the application processes (APi) andthe data queues to the network (i.e. ports 161, 162, etc.). SR handles the incoming and outgoingrequests successively.

Application processes are able to attach to the SPM by means of connect request queue CQ. IfSR sustains the connect request, a new data queue will be allocated and the application processwill be administered. An application process is able to send a request by putting the request inits data queue. Thread SR fetches this request from the data queue, constructs an SNMPv2message and puts it in the queue for outgoing messages (e.g. identified by port 161). Theconstruction of a packet is considered in chapter 7. If an SNMPv2 message is received from thenetwork, SR processes the message and puts the results in the queue of the correspondingapplication process.

To be able to relate a request to a confirm and an indication to a response a local database (DB)is used to administrate incoming and outgoing requests. Further this database includes anadministration is to enable to relate requests to an application entity. For a more detaileddescription concerning these administration activities, consult chapter 7.

1. The IPC is modelled by paired Input/Output queues. These queues uncouple a lower layer from an upper layer,which enables both sides to function independently from each other.


6.4.2 Multi-threaded SPM

In a multi-threaded SPM implementation, multiple threads are used to take care of the severalactivities an SPM has to perform. Basically each received or transmitted request is handled bya different thread. The structure, shown in Figure 27, presents the ideas with respect to apossible multi-threaded implementation. One can distinguish three parts. The first part takescare of the administration of application processes. The second part is responsible for theconstruction and transmission of SNMPv2 messages. Finally, the last part processes themessages that are received over the network (from UDP layer).

The connect requests are handled by thread C. At the sending side one master thread, denotedby S, awaits requests (e.g. GetRequest or GetResponse) from the application processes. Thisthread fetches the request from one of the queues (AQ1,..,AQn), puts it into an internal queueSQ and creates a slave (e.g. S1) that processes the request. Then thread S starts listening againfor new requests. Thread S starts for every request a new slave. In this way uncomplicatedpackets can pass the more time consuming ones, which require e.g. encryption. Because packetscan arrive continuously, multiple threads can be active at a moment.

The newly created thread (e.g. S1) fetches the request from queue SQ, constructs a SNMPv2packet, puts it in the queue (e.g. identified by port number 161) for outgoing packets and

SR

AP1 AP2 APn

CQ AQ1 AQ2 AQn

.....

161 162 local UDP Layer

DB

SNMPv2 Layer

Figure 26: Single-threaded Protocol Machine

SNMPv2 API

Socket Interface

data flow

thread of execution

I/O queue

local data base

continuous loop

57

terminates. If the request is handled and the results put in the queue to the lower layer the slavewill terminate.

The receiver part of the entity can be described similarly. Thread R continuously listens on theused UDP ports for incoming messages. If one or more messages are available these messageswill be read and put in the internal queue RQ. Then, a new thread (denoted e.g. R1) will becreated that handles the incoming message. If it is processed completely the thread terminates.

S2

C

R

AP1 AP2 APn

CQ

161 162 localUDP queues

S

S1 Sn...

R2R1 Rn...

DBRQSQ

AQ1 AQ2 AQn

.....

Figure 27: Multi-threaded Protocol Machine

SNMPv2 API

application data queues

socketinterface

7 Implementation of SNMPv2 Layer

The previous chapter described the implementation structure that was used to implement theSNMPv2 entities of chapter 4. This chapter describes how this structure was implemented. Itconsiders the implementation of the single-threaded SPM, the IPC and the part that is includedin the application process. It describes the implementation strategy, the problems that wereencountered, the implementation decisions that were taken and the inter-operability tests withthe SNMPv2 package from CMU. This chapter also describes the experience that we obtainedimplementing the RFCs.

Section 7.1 considers the implementation strategy. To handle complexity the software has beendeveloped on an evolutionary base, starting simple and extending it little by little (i.e. a bottom-up approach). In this chapter this approach will also be used to describe the implementation ofthe SNMPv2 functionality which has been implemented in this assignment. In the remainingsections the implementation of the distinct parts, that are considered in section 7.1, is described.

To make the implementation easier to understand, the naming conventions and the structure ofthe RFCs is reflected as much as possible in the implementation and in this report.Implementation of the SPM is mainly based on the methods described in the proposed SNMPv2standards and partly based on the mechanisms described in chapter 4.

7.1 Implementation Strategy

This section considers the bottom-up approach which was used to implement the SNMPv2functionality. The functionality was extended little by little. It was considered that in this waythe complexity could be handled at best.

First, a number of functions had been written in order to be able to send and receive messagesover UDP. The implementation of these functions is considered in section 7.2.

Next, the Basic Encoding Rules were implemented. At first instance, only the BER routineswere implemented that were necessary to encode and decode insecure SNMPv2 messages fromtransport format (i.e. the byte stream received from UDP) to a local format. Being able toreceive and decode simple SNMPv2 messages (i.e. without security), the next step comprised

UDP

Figure 28: exchange of UDP messages

60 7. Implementation of SNMPv2 Layer

inter-operability testing with the SNMPv2-package of Carnegie Mellon University (CMU).The CMU manager was used to send SNMPv2 messages to our UT SNMPv2 ‘agent’ (see alsoFigure 29). In this way, there was no need to write an own user interface at first instance. Thedecoded results were compared to the information sent. Comparing the information generatedby the CMU package to the information decoded by the UT package, one immediately seeswhere the processing of a message fails. It provided a suitable debugging tool.

When the decode routines worked properly, the decoded information was used to construct andsend a similar request to a CMU agent. In this way the coding routines of the BER were tested.In section 7.3 the implementation of these routines is described.

Having the means to exchange non-secure packets, the administrative model and related MIBs(i.e. PartyMIB and SNMPv2 MIB) were implemented. The message exchange is driven bymeans of parties and contexts. The parties and contexts are stored by means of a PartyMIB.Implementation of the PartyMIB comprised the definition of suitable data structures and theimplementation of functions to access these data structures. These structures are initialized withPartyMIB information which is stored in files. A program was written to create and maintainthese files off-line. The implementation of the administrative model is described in 7.4.

When the administrative model and related MIBs were implemented properly, the securitymechanisms were added. Implementation of the authentication protocol comprised theimplementation of two additional BER routines for the construction and processing of theauthentication information field. MD5 itself has not been implemented because an MD5implementation was available. The other security protocol, viz. the privacy protocol has notbeen implemented. Implementation of these protocols is considered in section 7.5. Again, theCMU package was used to test inter-operability. Testing became more difficult because thePartyMIB of both CMU and our package needed to be configured. This configuration was notneeded for the non-secure message exchange because CMU automatically generates two initialparties at initialization time.

After being able to send and receive all kind of messages, the API was implemented. In thisstep functionality is distributed over more processes, viz. the SPM and the application process,requiring the implementation of Inter-Process Communication. Further, routines have beenimplemented which map the several API functions upon a single data structure which istransferred between SPM and application process. The implementation of this functionality isconsidered in the sections 7.6 and 7.7.

To demonstrate the usability of the API two simple application programs were written. Theseprograms were also used to test the implemented functionality of the SPM program.

IP

UDP

130.89.16.44130.89.16.43

local ‘161’

CMU UTSNMPv2 AgentManager

SNMPv2

Figure 29: Inter-operability testing.

61

Testing the manager specific functionality of the SPM

The first program provides a manager application program with a simple user interface. Thisprogram was written to be able to test the manager specific functionality of the SPM. At firstinstance, this manager application program was invoked only once because the administrationfacilities were not implemented yet. Then these facilities were added to be able to use moreinvocations of this manager program (see Figure 30).

Note that the CMU implementation consists of just one process using the UDP port to provideidentification.

Testing the agent specific functionality of the SPM

A second program was written to test the agent specific functionality of the SPM. Testing of thisfunctionality provides more problems because the implementation of an agent applicationprogram is a job on its own. Having tested the manager specific functionality of the SPMextensively, this functionality can be used to test the agent specific functionality of the SPM.That is, an application program was written that uses both roles of the SPM. If a request isreceived it administrates this request and on its turn it constructs a new request. This request willbe sent to a ‘real’ agent. If the corresponding response is received the application determines thecorresponding request and sends back a response. This is illustrated in Figure 31.

IP

UDP

130.89.16.44130.89.16.43

161 162 local 161

UT-SPM

CMUSNMPv2Agent

Manager Appl.

Figure 30: Testing of Manager functionality of SPM

Manager Appl.

CMU agentCMU manager UT dual appl.

Get-Cnf.

Get-Req.

Ind.

Rsp.

Req.Ind.Rsp.

Cnf.

Figure 31: Application operating in a dual role.


In fact this can be compared with the ‘proxy agent’ behaviour. Only the application provides theimplicit mapping of context, source and destination party onto proxycontext, proxysource partyand proxy destination party. Besides using the agent functionality of the CMU package one canuse the CMU manager application to test the agent. It provides a more sophisticated userinterface.

In the following sections of this chapter a more detailed description is given of the differentparts considered in this section. The same sequence will be applied to elaborate on theimplementation of these parts.

7.2 Access to UDP

An implementation of UDP is available as a common part of the UNIX environment. UDP isaccessed by means of the 4.3 BSD UNIX socket interface which is part of the operating system(SunOS 4.1.1) [SUN 90]. By means of this socket interface, the access to the network (UDP) issimilar to as the access to a file. Similar to writing to a file, identified by a file descriptor, onetransmits a message over a (transient) ‘connection’ which is locally identified by a socketdescriptor. A socket corresponds to one end of a connection. A socket is identified within thenetwork by means of an internet address (IP address) that identifies the host and a portnumberthat identifies the process using the socket. These addresses are used to identify the source anddestination of a transmitted packet.

7.2.1 Mapping of data transfer SPs upon function calls

The data transfer service based on UDP as described in 4.6, is implemented by the function callsshown in Figure 33. The service primitives have been implemented by the system callssendto()

andrecvfrom(). Beside these routines, other routines are necessary to implement the interactionsbetween UDP and SPM.

7.2.2 Interaction model

One of the decisions one needs to make is whether one wants to interact with UDP in anasynchronous or a synchronous fashion. In principle, the initiative to an interaction may comefrom both sides (e.g. SPM issues a data request SP and the Transport Protocol Machine may

IP

UDP

130.89.16.44

UDP

130.89.16.43

161 162 local 161

UT-SPM

CMUSNMPv2Agent

Manager/Agent Appl.

local

CMUSNMPv2Manager

any

Figure 32: Testing of Agent functionality of SPM.

63

execute a data indication SP). In a UNIX environment using socket-based IPC an interactioncan be implemented by means of a:

• polling model

• interrupt driven model

The models differ with respect to the control and initiative to an interaction. In the pollingmodel, a PM keeps the control and initiative, i.e. it determines whether and when events will behandled. It checks the various sockets to determine if an operation must be or can be carried out.If one uses the interrupt model one can lose control or initiative. One is signalled if data isavailable on one of the sockets. In general, interrupts are handled immediately. Using interruptsusually makes programming more difficult, for example with respect to debugging. Thereforeit is easier to implement an interaction based on the polling model. Because of simplicity wedecided to choose the polling kind of implementation. Another reason for choosing this modelwas the available experience with this way of implementation.

Polling model (in more detail)

Polling can be implemented using non-blocking read/write calls or using a ‘select’ call incombination with the blocking read/write call. Using only blocking read/write system calls toget or pass data between (single-threaded) SPM and UDP is not suitable in this work, due to themultiple sockets and the unreliability of UDP. One never knows when and where data isavailable. So, it is not suitable to block on a specific socket. Take for example, the case that amanager keeps waiting for a response while a trap was sent (to another socket) to denotesomething serious occurred. Or simply the response message was lost. Therefore one cannotblock on a specific socket waiting for data.

In the UNIX environment the following system calls are available that can be used in a single-threaded program to poll multiple sockets [SUN 90]:

SI_DataReq( socket, buffer, size, to, tolen )int socket, tolen, size;char *buffer; /* user data */struct sockaddr_in *to; /* destination address */

{/* ... */

ret = sendto( socket, buffer, size, 0, ( struct sockaddr * ) to, tolen );/* ... */

}

SI_DataInd( socket, buffer, size, from, fromlen )int socket, *size, *fromlen;char *buffer; /* received data */struct sockaddr_in *from; /* address from sender */

{/* ... */

ret = recvfrom( socket, buffer, *size, 0, ( struct sockaddr * ) from, fromlen );/* ... */

}

Figure 33: Implementation of Data-Request SP and Data-Indication SP


• Non-blocking read/write system callsNon-blocking system calls return control to the invoker, if no data is available to beprocessed or if no buffers in which the output must be written, are free. One needs to pollthe sockets to determine if an operation must be or can be carried out. This is usually calledbusy waiting and as the name suggests it is not very efficient.

• Select system callIn the UNIX environment a special system call is available that can be used to checksockets, if data can be read or written. This call, the ‘select’ system call, denotes on whichof the sockets one can read or write data without blocking. The select call effectivelyrelinquishes the processor to other processes if there is nothing to do (except waiting forevents). This is especially desirable in case a managed system has to do a lot of other jobsin addition to handling SNMPv2 requests. Another advantage of the select call is that itprovides a time-out option. If a time-out occurs control is given back to the SPM. Besidesthese points, it makes the implementation of interactions occurring on multiple socketsrelatively clear and simple, it implies a natural flow of control.

Based on the above consideration, it was decided to implement an interaction by means of the‘select’ system call in combination with the blocking read and write system calls.

7.2.3 Byte order conversion

In the above mentioned functions, byte order conversion routines (e.g.htons(), ntohs()) need to beapplied to guarantee a commonly agreed transfer syntax. The use of this routines is necessarybecause machines (generally) differ in the way they store integers. If machines want tocommunicate, a unique representation is required. In the Internet suite of protocols, allimplementations should apply the network byte order scheme (i.e. most significant byte is sentfirst, then the next significant byte, and so on) when they transmit data. As socket-based IPCdoes not ensure a machine architecture independent code a strict use of these conversionroutines (host-to-network byte order and vice versa) is necessary to obtain inter-operability.

7.3 Implementation of Basic Encoding Rules

This section concentrates on the implementation of the Basic Encoding Rules (BER)[ISO8825]. It considers the mapping of ASN.1 structures on C representations, the encoding anddecoding of these representations, the problems encountered and finally the experience whichhas been obtained.

7.3.1 Local C representations

The first step comprised the mapping of ASN.1 structures, as specified in [RFC 1442], uponlocal C representations. These C representations were shown in chapter 5. In this way the BERis separated from the other SNMPv2 functionality. It allows the BER to be substituted for otherencoding rules.

It is possible to generate the mentioned C representations automatically. ASN.1 tools (e.g.structure generators) are available that derive these C representations from an ASN.1specification. One such tool was used to derive the C representations corresponding to theASN.1 part of [RFC 1442]. The resulting representations where not very clear, e.g. with respectto naming. So, it was decided to define our own representations manually.

65

Also the BER-routines can be generated automatically. Although these tools allow the rapidprototyping of applications, it was decided not to use these tools. To encounter all possibleproblems related to the implementation of SNMPv2, the BER is also implemented from scratch.More information about these tools can be found in e.g. chapter 8 of [Rose 89].

7.3.2 Encoding of TLV

As described in chapter 4 a Tag, Length and Value (TLV) encoding is used by the BER toencode an ASN.1 value. In accordance to these fields, seven general routines were defined toencode and decode these tag, length and value (TLV) fields:

These routines are used as the building blocks for the construction or extraction of morecomplicated structures. By means of this interface the BER was split into ASN.1 related BERfunctions and SNMPv2 related BER functions. The implementation of the ASN.1 related part,including these seven routines, is considered in [ScT 93]. In this assignment only the SNMPv2related part has been implemented. This part includes the functions which are used for theencoding, respectively decoding of message headers and PDUs, which were described inchapter 4. The seven routines, described above, are used to implement these functions.

7.3.3 Encoding of Length field

The major problem encountered during the implementation of the SNMPv2 related BERfunctions concerned the avoidance of copying. Copying of data must be avoided as much aspossible, as it has great impact on the performance. Especially, this problem arises when alength-field must be encoded. The value that needs to be encoded in the length-field, dependson the remainder of the message. Usually this value is not known in advance. Copying of datawill be introduced if one encodes the remainder of the message in a temporary buffer. Anothersolution, that has been implemented in this implementation, encodes the packet in two phases.In the first phase the length field is skipped. Space is reserved to be able to fill it in afterwards.Besides reserving space, one needs to keep track of the start of the lenght field. Then the value-field is encoded. In the second phase, the length field is encoded and written at the recordedposition. This approach uses the long form of encoding. It guarantees that the length value fits.Three octets are sufficient to contain the length of a maximum-sized UDP packet (i.e. 64Kbyte). This approach is illustrated in Figure 35. Another approach, the backward generationof a message, is considered in [CoS 91].

7.3.4 Implementation experience

In general, one can conclude that the implementation of the Basic Encoding Rules was straightforward. The RFC 1449 in which some additional constraints are specified forms a sufficientbasis to guarantee inter-operability. No real problems were encountered. It took a lot of time andeffort, to implement the BER from scratch. As the implementation of the BER did not pose thatmuch interesting problems, it would have been better to use an available BER implementation.

BER_append_tag( STRING *message , TAGTYPE tag);BER_append_length( STRING *message , unsigned int length);BER_append_longform_length ( STRING *message , unsigned int length);BER_append_object( STRING *message , OBJECTSYNTAX *value );BER_get_tag ( STRING *message , int *tag );BER_get_length( STRING *message , int *length );BER_get_value( STRING *message , TAGTYPE tag, int length, OBJECTSYNTAX *value );

Figure 34: Basic BER-routines


7.4 Implementation of the Administrative Model

The implementation of the functions related to the Administrative Model comprise on the onehand functions to construct and process SNMPv2 messages and on the other hand functions toaccess the PartyMIB and SNMPv2 MIB. The implementation of the SNMPv2 MIB will not beconsidered. Only a small part, viz. snmpStatistics group of this SNMPv2 MIB, has beenimplemented in the current version.

7.4.1 Generation and processing of SNMPv2 messages

In section 3 of [RFC 1445] the procedures for the processing of incoming and outgoingmessages are described. These procedures are implemented by means of two functions. Becauseall operations are mapped upon one message structure only two functions are needed toconstruct and process a SNMPv2 message. In Figure 37 the outline of routine which handles anincoming message is given.

The administrative model has been implemented in such a manner that it can easily be

maintained or changed. For example, adding another security protocol will cause no problems.

0xA1phase 1:

start oflength-field

append other fields

0xA1 06 01 33 24 68 78 97 .......00phase 2:

30 octets

Figure 35: Encoding of length-field

/* Purpose: Decrypts privData if necessary according to specified protocol, [RFC 1446] 4.2 */ Decrypt( PrivProtocol, PrivPrivate, PrivPublic, privData, privDatalen )

OID *PrivProtocol; /* Privacy protocol (IN) */OCTETSTR *PrivPrivate, *PrivPublic; /* private and public key */OCTET *privData; /* Data that will be decrypted (IN/OUT) */int privDatalen;

{if( CmpOID( PrivProtocol, &noPriv ) == 0 ) /* i.e. Is it 1.3.6.1.6.3.3.1.1.2 ? */

return( 0 ); /* no privacy protocol has been used */if( CmpOID( PrivProtocol, &desPrivProtocol ) == 0 ) /* i.e. Is it 1.3.6.1.6.3.3.1.1.3 ? */{ /* Data Encryption Standard (DES) has been used */

DecryptDES( PrivPrivate, privData, privDatalen, SnmpAuthMsg, SnmpAuthMsglen );return( 0 );

}printf( "this privacy protocol is not supported\n" ) ;

}

Figure 36: Decrypt() function

67

This is illustrated by means of the routineDecrypt() (Figure 36) which is responsible for theselection of the privacy protocol.

7.4.2 Implementation of PartyMIB

The tables of the PartyMIB have been implemented by means of dynamic arrays which arecreated in memory, when a SNMPv2 PM is initialized. The party table is implemented by thestructure shown in Figure 38. After creation these tables are filled with party, context and accesscontrol information. This information is read from distinct files which are maintained off-line.

SNMP_ProcessIncMessage( message, messagelen, SrcPartyId, DstPartyId, ContextId, pdu )OCTET *message;int messagelen;OID *SrcPartyId, *DstPartyId, *ContextId;PDU *pdu;

{/* ... */Increment_snmpStats( snmpStatsPackets ); /* total number of packets received */

/* extract DstPartyId */BER_SnmpPrivMsg_decode( (OCTET *) message, messagelen, &PrivDstId, &offset,

&privDatalen ) );/* ... get destination party ...*//* privacy protocol */Decrypt( &(partytable[ DstPartyIndex ].partyPrivProtocol),

&(partytable[ DstPartyIndex ].partyPrivPrivate),&(partytable[ DstPartyIndex ].partyPrivPublic), privData, privDatalen );

/* ... *//* extract authData and authInfo */BER_SnmpAuthMsg_decode( privData, privDatalen, &authInfooffset,

&authInfolen, &authDataoffset, &authDatalen ) < 0 )

/* ... *//* extract management comm. value to get srcPartyId */BER_SnmpMgmntCom_decode( privData + authDataoffset, authDatalen,

DstPartyId, SrcPartyId, ContextId, &pduoffset, &pdulen ) < 0)

{/* get source and context from PartyMIB *//* ... *//* authentication protocol */

CheckAuthenticate( &(partytable[ DstPartyIndex ].partyAuthProtocol),&(partytable[ SrcPartyIndex ].partyAuthPrivate),&(partytable[ DstPartyIndex ].partyAuthPublic),&(partytable[ SrcPartyIndex ].partyAuthClock),&(partytable[ DstPartyIndex ].partyAuthClock),&(partytable[ SrcPartyIndex ].partyAuthLifeTime),AclPrivileges, privData, privDatalen, authInfooffset, authInfolen )

/* ... *//* extract PDU */BER_PDU_decode( privData+authDataoffset+pduoffset, pdu, &status )

if( !InSet( pdu -> type, AclPrivileges ) ) /* access control *//* ... */

}

Figure 37: Snmp_ProcessIncMessage()


A separate program was written to initialize or change these files. As no meta-management isimplemented one cannot change these tables by using SNMPv2. Only by means of an off-lineconfiguration combined with a (re-)initialization of the SPM one can change the contents of thethree tables. Mind that not all fields of these tables are used, because meta-management is notused (e.g. partyCloneFrom)

7.4.3 Implementation Experience w.r.t [RFC 1445]

Implementation was based as much as possible on the steps described in [RFC 1445]. Also thesame naming convention is applied in the implemented code. A few remarks can be made aboutthis RFC. The steps concerning the generation of messages were clear, unlike the steps that dealwith the processing of incoming messages. Many things are implicitly mentioned. For example,the term "originating party" implies that it must be a remote party (i.e. partyLocal == false).Further, the described sequence does not always seems suitable. In step 7 of 3.2 the originatingparty of the AuthData field is needed, while these values are extracted in step 11. Other remarksand some minor faults were reported and corrected in the current RFC. In my opinion, this RFCis the most problematic one to understand. But probably this RFC will be rewritten.

7.5 Implementation of Security Protocols

This section considers the implementation of the security protocols along the lines of [RFC1446]. First, the implementation of the authentication protocol is considered. In the secondsection the privacy protocol is considered. In the current version, the management of keys and

typedef struct{

Party partyIdentity; /* name of the party */INTEGER partyIndex; /* logical position in the partyTable */OBJECTID partyTDomain; /* transport domain */TAddress partyTAddress; /* address on which messages are received */INTEGER partyMaxMessageSize; /* a bigger message cannot be processed */TruthValue partyLocal; /* own or remote party */OBJECTID partyAuthProtocol; /* authentication protocol that must be used*/Clock partyAuthClock; /* local notion of time */OCTETSTR partyAuthPrivate; /* private authentication key */OCTETSTR partyAuthPublic; /* public authentication key */INTEGER partyAuthLifeTime; /* lifetime of message */OBJECTID partyPrivProtocol; /* privacy protocol that must be used */OCTETSTR partyPrivPrivate; /* private privacy key */OCTETSTR partyPrivPublic; /* public privacy key */Party partyCloneFrom; /* used for meta-management: generation of parties */StorageType partyStorageType; /* denotes kind of medium: now, only primary memory

is used */RowStatus partyStatus; /* used for meta-management: already used to check if

party is active */} PartyEntry;

typedef struct{

int NumofParties; /* number of parties */PartyEntry *base; /* dynamic array */

} partyTable;

Figure 38: partyTable structure

69

clock-synchronization have not been considered. That is, no functions for clock synchronizationor secrets distribution are implemented. These tasks can be characterized as meta-managementtasks, i.e. management of SNMPv2 using SNMPv2 itself. As this assignment only considers theimplementation of functions related to the exchange of management information, these issueswill be left aside. These functions will be implemented in future versions.

7.5.1 Authentication Protocol

The currently defined authentication protocol is based on MD5. This section describes how anauthentication message (SnmpAuthMsg) is constructed and processed. At the sending side anauthentication information field (authInfo) is constructed, i.e. serialized. The authInfo field isconstructed with a private authentication key, a source timestamp and a destination timestamp,prior to computing a digest. This field together with the authData component which includes themanagement information, forms an authentication message (snmpAuthMsg). Over the resultingauthentication message a digest is computed. This digest is computed using the MD5implementation of RSA Data Security, Inc. This implementation was extracted from [RFC1321], without problems. The computed digest value is copied in the message and overwritesthe equally sized, private authentication key. To be able to write the digest value at the rightplace, one needs to store the position at the moment the private authentication key is written.

Figure 39: Serialized Authenticated Message

At the receiver’s side a similar approach is applied. After receiving the message one extracts thedigest-value which is temporarily recorded. To verify the digest the receiver overwrites thedigest with its own private key. A new digest is computed and verified with the received(recorded) digest. Copying the authentication key at the position of the digest guarantees thatall other parts of the message stay the same. If one would reconstruct an authenticated message,i.e. serialization with new values, a different octet sequence might result. Although the BERprovide an unambiguous representation, it is not necessarily unique. The correctness of the BERand MD5 implementation were tested against the CMU package. These routines have beenimplemented and installed without causing problems.

The implementation of clock related authentication mechanisms [RFC 1446] was less clear. Asource timestamp is included to denote the time of message generation, according to the sourceparty’s authentication clock. The destination timestamp represents the time of generationaccording to the clock of the receiving party. The timestamps are used in combination withlifetime values to verify that messages were generated recently. That is if the time of generationincremented with the lifetime value is less than the current time, then the message is evaluatedto be unauthentic. It was assumed that the local notion of the authentication clock (i.e. clock oflocal party) is the conceptual representation of the systemtime. Therefore when this clock needs

0xA1 LEN authInfo authData

0xA2 LEN Digest DstTs. SrcTs.

0x04 LEN octetstring 0x47 LEN Uint32-val 0x47 LEN Uint32-val.

or private authentication key (16 octets)

SnmpAuthMsg :


to be retrieved the systemtime is read. As the implementation of the clock algorithm was testedonly on a local network and the clocks of the several machines are synchronized, inter-operability problems w.r.t clocks are unlikely to happen. Therefore, additional tests are neededto verify the implementation of this mechanism.

7.5.2 Privacy protocol

Messages are protected from disclosure by means of the use of a privacy protocol. This privacyprotocol is based on the Data Encryption Standard (DES). In this assignment the DES algorithmhas not been implemented. Although a DES implementation was available, its correctness couldnot be verified against a another SNMPv2 package. Due to export restrictions from the U.S.A.,DES was probably not included into the CMU package. This resulted to the decision not toinclude DES, at first instance. The DES implementation can be included easily. In theimplementation of the administrative model, the external behaviour of an encryption functionand a decryption function is yet defined by:

7.6 Implementation of the API functions

When most of the SNMPv2 communication functionality was implemented, the processstructure described in chapter 6, was considered. Chapter 6 described that most of the SNMPv2functionality will be included in the SPM and just a small part of it in the application process.This section considers the implementation of the part which will be included in the applicationprocess. It describes the implementation of the API functions defined in chapter 5. Thefollowing section describes the implementation of the SPM.

7.6.1 Implementation of snmp_Open()

Thesnmp_Open() function is responsible for the creation of the process structure as described inchapter 6 and the set up of a connection between an application process and the SPM (see also5.2). If thesnmp_Open() function is invoked, the first thing it will do is create a child process bymeans of thefork() system call (see Figure 40). The parent process continues to execute theapplication code and the child process executes the SPM code. The SPM binds the default port(e.g. 8887) on which applications may attach, to check if another SPM is already running. If thebind succeeds, which means that no SPM was running, it admits a passive open on this defaultport to denote that it is willing to accept connections with the first mentioned application processand all other application processes. If the bind fails, it concludes that another SPM is alreadyrunning and it subsequently terminates.

In the mean time, the process which executes the application code is delayed for some time toallow the SPM to initialize properly. Then, the application process issues an active open(SI_ConnReq()) to connect to the SPM. In principle it is up to the SPM to decide if an applicationis allowed to use the services. If not, the connection will be closed. In the current version a

Decrypt_DES( Privatekey, privData, privDatalen, SnmpAuthMsg, SnmpAuthMsglen );Encrypt_DES( Privatekey, SnmpAuthMsg, SnmpAuthMsglen, privData, privDatalen ); with:

Privatekey, the private privacy key used for encryption or decryption (symmetric algotithm);SnmpAuthMsg, the authenticated message that needs to be encrypted or that has been

decrypted.privData, the encrypted data or the data that needs to be decrypted.

71

connection is never refused. Depending on the requested security requirements of amanagement application, future versions will add authentication for the internal IPC.

7.6.2 Implementation of snmp_Close

Thesnmp_Close() function terminates the connection with the SPM. It is implemented by meansof aclose() system call.

7.6.3 Implementation of snmp_Look

Thesnmp_Look() function is used to receive SPs and to determine the type of SP (see also section5.2). The way on which SPs are processed depends, on the interaction model that will be usedto implement the interactions between the SPM and the application process. In section 7.2 thesimilar problem was described. Again theselect() call will be used because of its simplicity. Inthis case it is used to determine if the SPM has data for the application process. The body of thesnmp_Look() function is depicted in Figure 41. Notice that this function includes the socketdescriptor ‘connEndpoint’ in its readset before theselect() system call is invoked. This socketdescriptor was returned in thesnmp_Open() function and identifies the connection with the SPM.The descriptor has been made global, so that it can be hidden for the application programmers.If the select()call denotes that the SPM has data for the application process, this function willretrieve this data and store it in a local list. Then, the function returns the type by means of the‘type’ parameter. Based on the returned type the corresponding API function can be invoked.Now, the implementation of these API functions is considered.

7.6.4 Implementation of other functions

The API described in chapter 5 consists, besides the functions described above, of a largenumber of functions that implement the service primitives of chapter 3. These functions aremapped within the API upon a single interface data structure (IDU), which is exchangedbetween the SPM and application process using IPC, every time a new service primitive (SP)takes place. This IDU was received by thesnmp_Look() function and was subsequently put in alocal list (see also Figure 41). This IDU is represented by the structure which is shown in Figure42. This structure comprises all parameters that might be used by the different SPs. Because aSP might not use all parameters, not all fields of the IDU need to be filled. This IDU istransferred between the SPM and the application process by means of a stream. Because a

{/* ... */pid = fork();if ( pid == 0 ) {

/* start up SPM program, if it is not running */execve( "programname of SPM code", (char *) NULL, (char *) NULL);exit(0); /* if SPM is not started or if it is finished */

}else {

sleep( 5 ); /* allow SPM to initialize *//* Attach to SPM (SPM running on own system) */ret = SI_ConnReq( "LOOPBACK", 8887, SOCK_STREAM, &connEndpoint );/* if request succeeds connEndpoint is used to identify connection *//* ... */

}/* ... */}

Figure 40: snmp_Open() function


stream is used one needs to take care of fragmentation of the IDU. It is possible that the IDU istransmitted in parts.

The receive functions which are issued based on the type that is returned by thesnmp_Look(),check the local list for corresponding data, extract the relevant parameters from the IDU andpresent this to the caller as the function returns. The send functions map their parameters upon

snmp_Look( readset, timeout, type )fd_set *readset;struct timeval *timeout;SPTYPE *type;{

/* include connEndpoint desc. in readset */FD_SET( connEndpoint, readset ); /* connEndpoint global */

/* wait for events */ret = select( getdtablesize(), readset, (fd_set *) NULL, (fd_set *) NULL, timeout );if ( ret = 0 ){

*type = TIMEOUT; /* timeout occurred*/}else {

if ( FD_ISSET( connEndpoint, readset ) ){ /* snmp message available *//* read from SPM queue identified by connEndpoint */len = SI_DataInd( connEndpoint, buf, &buflen, &fromaddr, &fromaddrlen );if (len == 0 ){

printf("SPM disconnected....Exit\n");exit( -1 );

}if (len != sizeof( IDU ) ){

/* .... read from stream until IDU is received completely ... */}*type = request.type;/* ... put data in in local list ... */

}else { *type = NONSNMP; } /* activity on one of the sockets of the userset */

}FD_CLR( connEndpoint, readset ); /* remove, because readset is returned */

}

Figure 41: snmp_Look() function

typedef struct {SPTYPE type; /* kind of service primitive */

char systemname[ 255 ]; /* name of remote system */QOS qos; /* quality of service */char contextname[ 255 ]; /* symbolic name to identify context */INTEGER32 request_id; /* provides identification for appl. entity */VARBINDLIST variablebindings; /* list of managed objects */INTEGER errorstatus; /* or non-repeaters */INTEGER errorindex; /* or max-repetitions */

}IDU;

Figure 42: IDU structure

73

the IDU structure which is subsequently send to the SPM. The implementation of thesefunctions is illustrated in Figure 43 by means of thesnmp_GetRequest() function.

7.7 Implementation of the SNMPv2 Protocol Machine

The previous sections (7.2 up to and including 7.5) described most of the functions that areneeded to offer the specified SNMPv2 service. These functions were integrated into oneprogram. This program comprises the SPM code. Further, this section describes this program.Further, it describes the implementation of some additional functions that are needed to copewith the multiple application processes which are serviced by the SPM. In Figure 44 the mainprogram of the SPM is shown. After initialization of the MIBs and opening the required UDPports and TCP port, the SPM is ready to service the application processes and network (UDP).The different parts of this program will be described in the remaining part of this section.

Figure 43: snmp_GetRequest()

/* MAPPING upon IDU */snmp_GetRequest( agentname, requestid, qos, contextname, variablenames ){

Send_Request( GET_REQ, agentname, requestid, qos, 0, 0, contextname, variablenames, (VARBINDLIST *) NULL );

}/* with Send_Request: */Send_Request( type, agentname, requestid, qos, maxrep, nonrep, contextname, variablenames,

variablebindings )/* ... */{

IDU msg;

/* construct IDU for SPM */msg.type = type;msg.request_id = requestid;strcpy( msg.systemname, agentname );strcpy( msg.contextname, contextname );msg.qos = qos;if ( type == GETBULK_REQ ) {

msg.errorstatus = nonrep;msg.errorindex = maxrep;

} else {msg.errorstatus = 0;msg.errorindex = 0;

}if ( (type == GET_REQ) || (type == GETNEXT_REQ) || (type == GETBULK_REQ) ) {

Varnamestovblist( variablenames, &(msg.variablebindings) ); /* construct var. bindings list */} else {

msg.variablebindings = *variablebindings;}/* send IDU to SPM */ret = SI_DataReq( connEndpoint, (char *)&msg, sizeof(msg), (struct sockaddr_in *) NULL, 0 );

}


7.7.1 Initialization

In the current implementation SPM initialization involves the following steps:

• The SNMPv2 related MIBs are created in memory and initialized from file.• The UDP ports on which requests and notifications are received are opened based on the

information of the party table.• An arbitrary UDP port is opened to send requests. This port is dynamically assigned by the

network software. This port, in stead of the port which is configured in the party table, is usedto send requests and receive their related responses, in order to provide more flexibility. Onedoes not need to define parties for each system used as NMS. Only parties need to be definedfor the managed systems. That is possible because agents return their responses to the systemwhich send the request using the same address. This approach is the most practical one andis probably practised by most implementations. If it is conform the RFCs is not clear. TheRFCs do not provide a sufficient description. But why would the agents otherwise sent backthe response to the received address?

• A ‘well-known’ port is opened to support IPC between SPM and application processes. Onthis port application processes may attach. Although the port needs to be ‘well-known’among the local applications processes it is not necessarily a reserved port (i.e. not in therange 1..1024).

7.7.2 Event handling

The SPM interacts with both UDP and the application processes (see Figure 45). The interactionwith UDP has already been described in 7.2. Interaction with the application processes ishandled similarly, i.e. using theselect() call. The SPM continuously checks the several sockets(ports) for the occurrence of events by means of theselect() call (see also Figure 44). Events arethe service primitives received from the application processes or UDP. The events are handledone at a time.

One can distinguish three kinds of events:

• Events related to the connection of applications processes,

Application processes can dynamically connect to and disconnect from the SPM. If anapplication process is connected its connection endpoint identifier (socket descriptor) isadministered. The particular socket descriptor is included in the set of socket descriptors1

Figure 44: Main program of SPM

/* MAIN of SNMPv2 PM*//* ... */

Init_SPM( &set ); /* initialize SNMP MIB, PartyMIB, open UDP sockets and Listen socket *//* ... include sockets in set ... */for( ; ; ) { /* loop forever i.e. as long as application processes are connected */

readset = set;ret = SI_Select( (fd_set *) &readset, (struct timeval *) &timeoutval );if( ret == 0 ){ /* no activity on sockets in this period */

CheckOutstRequestList( ); /* determine if outstanding requests are timed-out */}if( ret > 0 ){ /* handle network (UDP sockets) and application processes */

CheckConnEndpoints( &readset, &set );}

}}

75

which need to be checked by the SPM for available data. If an application disconnects itsconnection endpoint identifier is removed from the set. It should be noted that the SPM willautomatically be terminated, if the last application process disconnects.

• Events concerning service primitives issued by application process,

If the SPM detects activity on one of the connections with the application processes (APi),it fetches the data and subsequently constructs an outgoing message. The construction ofan outgoing messages involves the mapping of the IDU fields upon a SNMPv2 message.Then, the constructed message is transmitted over UDP.

• Events related to SNMPv2 messages arriving from the network.

If the SPM detects that a SNMPv2 message arrived it will process the message and mapthe information contained in the message upon an IDU structure. This IDU is sent to anapplication process. To determine which application process is intended to receive aparticular message the SPM needs to keep an administration of among others outstandingrequests. This administration will be considered in section 7.7.3.

7.7.3 Processing of IDUs and SNMPv2 messages by SPM

The processing of an IDU (or a SNMPv2 message) mainly comprises the mapping of IDUinformation upon the corresponding fields of a SNMPv2 PDU (and vice versa for the oppositedirection). Furthermore, the SPM needs to select parties and contexts based upon the parametersof the IDU. These mappings have been described in chapter 4. As the implementation of themapping functions is straight forward the implementation of these functions will not bedescribed.

In the current implementation all service elements described in chapter 4 are completelyimplemented, except the get bulk, inform and trap service elements. These three serviceelements are just implemented rudimentary. The getbulk is just partially implemented. Therequest and confirm SPs of the getbulk service element are implemented but the SPM is unableto handle incoming getbulk request messages. The mechanism which issues several getnextindication SPs to construct a response message as described in 4.2, needs still to beimplemented. To implement the inform service element completely, one only needs toimplement the procedure which maps an incoming InformRequest-PDU back upon a Response-PDU in order to make this element provider confirmed. The trap service element is implementedjust rudimentary as the SPM is able to construct corresponding SNMPv2 messages but the SPMis unable to send these messages. In the current implementation the SPM can not sent these

1. This set includes, beside the application sockets, also the connect request socket and UPD sockets.

Figure 45: event handling

SPM

.....

UDP ports......

C AP1 AP2 APn

connections with Applicationconnect requestsocket Processes


messages because the procedure that selects the destination addresses of the traps, based on theaccess control table [RFC 1448] needs still to be implemented.

Besides the mapping and construction of SNMPv2 messages or IDUs, one needs to implementan administration of outgoing and incoming requests in order to e.g. relate requests to one of theseveral application processes. In section 7.7.4 the administration of outgoing requests isdescribed. Next, in section 7.7.5 the administration of incoming requests is considered.

7.7.4 Administration of outgoing requests

To regulate the message traffic between the SPM and the possibly multiple applicationprocesses the SPM needs to administer which requests are sent by which application processes.The SPM assigns to each request a unique sequence number that is administered together withthe application process identifier (i.e. socket descriptor) and the request-id generated by theapplication process. In this implementation the request-ids are generated by the applicationprocesses themselves. Otherwise, if the SPM would assign a request-id, then the SPM alsoneeds to send back this request-id to the application process involving an additional IDUexchange. This unique sequence number is put in the request-id field of the SNMPv2 messagewhich is exchanged with a peer SPM.

As described in chapter 4 one also needs to administer the type of request to relate a Response-PDU returned by the peer to the corresponding Request-PDU. So, for each outstanding requestthe SPM administers a quadruplet of sequence number, application process identifier, request-id of application process and the type of request (see also Table 11).

As one can see in the table an additional time-out field is included in this table in order to dealwith the unreliability of UDP. Due to loss of messages it is not guaranteed that a requestmessage will be answered with a response message. If the administration of outstandingrequests is not reset regularly the SPM might run out of memory. To prevent this to happen atime-out mechanism is implemented. If a time-out elapses the SPM determines which requestsare not answered and generates error indication SPs to inform the application processes of thetime-outs. The requests are then removed from the administration. In the currentimplementation the time-out mechanism is implemented using the time-out parameter of theselect() function that was mentioned in section 7.2. If no events happen during a user-definableperiod the SPM will check the outstanding request list, i.e. the implementation of table 11.Unfortunately, the current implementation might show a bug. If the SPM continuously handlesevents a time-out will probably not occur, although requests may keep unanswered, eventuallycausing the SPM to run out of memory. This will be repaired in a next implementation.

sequenceno.

Applicationrequest-id

Applicationid.

type ofoperation

time ofgeneration

1 1 1 GET 12:06:01

2 1 2 GET 12:06:10

3 2 1 SET 12:07:00

.. .. .. .. ..

Table 11: Administration of outstanding requests

77

7.7.5 Administration of incoming requests

Similar to the administration of outstanding requests, the SPM needs to administer incomingrequests, i.e. the requests intended for agent application processes. Only a reply-id is passed tothe application process and the other information necessary for the message exchange isadministered by the SPM together with the reply-id. In this way an agent application process isnot confused with the management information exchange. This information, viz. the receivedaddress of the manager, the destination party-id, source party-id and the context-id, is neededby the SPM in order to construct a response message.

In the current implementation it is assumed that the application process always generates aresponse SP and that it uses the same reply-id as denoted by the corresponding indication SP.Therefore, the SPM is not prevented from running out of memory due to unanswered requests.Because agents might crash, protection need to be included to prevent this to happen.

7.7.6 Distribution of incoming requests among agents

A problem that has not been solved in the current implementation involves the distribution ofrequests among agents. Although the SPM allows to attach multiple agent applicationprocesses, it is unable to dispatch requests to specific agents. In the current version all requestsare dispatched to the first attached agent. The SPM consults its administration to determine ifan agent process is running and where it is running. This information is administered by theSPM at the moment that an application process attaches to the SPM. An application processintroduces itself to the SPM as a manager, an agent or a combined manager/agent by means ofthe ‘role’ parameter of thesnmp_Open() function. The SPM administers this role together withthe address (i.e. socket descriptor) of the application process. In future versions the agentapplication processes should also indicate at connection set-up which contexts (i.e. set ofobjects) these application processes handle. The SPM may subsequently use these contexts todetermine which agent process handles the specific request. In this way a great flexibility canbe provided. Multiple application processes can be used each programmed to access a specificpart of the MIB (see also table 13).

reply-idApplication

id.dstPartyId srcPartyId ContextId Taddress

1 3 InitialPartyId.130.89.16.43.1

InitialPartyId.130.89.16.43.2

InitialCtxtId.130.89.16.43.1

130.89.16.448000

2 3 InitialPartyId.130.89.16.43.3

InitialPartyId.130.89.16.43.4

InitialCtxtId.130.89.16.43.2

130.89.16.448000

.. .. .. .. .. ..

Table 12: Administration of incoming request

agent appl.id

context (set ofobjects)

4 MIB-II objects

5 RMON objects

... ...

Table 13: Administration of agents


7.7.7 Testing of SPM that services multiple application processes

The SPM has been tested using the approach described in section 7.1. Initial tests showed thatan implementation structure of multiple application processes served by one SPM, workedpretty well. Additional tests must show if a sufficient performance can be obtained.Unfortunately, in the tests a bug has been found that still needs to be solved in the currentimplementation. This bug may appear when the SPM wants to send an IDU to the applicationprocess and the application process waits until it can complete its IDU transmission to the SPM.Because both SPM and application process use blocking read/write calls this situation mightoccur. Additional algorithms need to be implemented or non-blocking read/write calls shouldbe used to solve this problem.

8 UT-SNMPv2 package

This chapter describes the structure of the initial version of the UT-SNMPv2 package. ThisSNMPv2 software has been developed on SUN workstations running SunOS 4.1.1, which is anextension of Berkeley UNIX release 4.3. Programming was done in standard ANSI C using GnuGcc 2.4.5 and Gnu Make 3.67. The current SNMPv2 package consists of four executables: aprogram that executes the SNMPv2 Protocol Machine implementation, a program to configurethe partyMIB files, and two application programs to demonstrate the usability of the developedAPI. Now the module structure of these programs will be described.

Manager and agents applications

As well an simple agent application (see also section 7.1) as a simple manager application entitywere build using the API functions described in chapter 5. In Figure 46 the module structure ofan agent and manager application program is shown.

Figure 46: Module structure of application entity implementations

The ‘snmpManager’ and ‘snmpAgent’ programs both use the function calls of the ‘snmpAPI’module which provides the local interface to the SNMPv2 service. The ‘snmpAPI’ module onits turn uses the functions of the socket interface ‘si.c’ to communicate with the SPM. Asexplained in the previous chapter the SPM program is automatically started by the firstapplication process. Though for testing purposes it is possible to start the SPM process (i.e.invoking the SPM program) before an application process starts.

snmpManager.c

snmpAPI.c

si.c si.c

snmpAPI.c

snmpAgent.c

80 8. UT-SNMPv2 package

SNMPv2 Protocol Machine implementation

The SPM program consists of the modules depicted in Figure 47. The modules implement thefunctions which have been described in the previous chapter. For each module a shortdescription is given of the functionality that is implemented by the module.

Figure 47: Module structure of SNMPv2 PE implementation

The SPM program is divided in the following parts:

• snmpProvider.c implements the main program of the SPM. It uses the functions ofsnmpUPF.c and si.c.

• snmpUPF.c contains the functions which perform the mapping of SPs upon SNMPv2messages. Further, it provides the functions that take care of the administration of applicationprocesses and related requests.

• snmp_message.c implements the functions which are related to the administrative model.

• si.c provides a common interface to UDP and TCP.

• MD5.c contains the RSA MD5 implementation which was extracted from [RFC 1321].

• ber_SNMP.c contains the functions which implement the Basic Encoding Rules for theconstruction of SNMPv2 message headers, PDUs and its related variable bindings list.

• ber_ASN1.c provides the BER functions which are used to encode general ASN1 types.

• snmpPartyMIB.c contains functions to create and intitialize partyMIB tables in memory.Further it contains functions to operate on these tables, e.g. searching. To initialize thesestructures, the configuration files ‘party.conf’, ‘context.conf’ and ‘acl.conf’ are used.

• snmpMIB.c contains functions to implement the snmpStatistics group of the SNMPv2 MIB.

snmpProvider.c

snmpUPF.c

si.c

ber_SNMP.c

ber_ASN1.c

snmp_message.c

snmppartyMIB.c snmpMIB.cMD5.c

tm.c

party.confcontext.confacl.conf

81

• tm.c is used to create and maintain the configuration files which contain the information usedfor the initialization of the partyMIB.

Besides these modules, a number of other modules have been written. These modules containgeneral routines for I/O (e.g. read and print functions) and routines to manipulate objectidentifiers. Furthermore, a file has been written that includes the definitions of allrepresentations of the ASN.1 notations:

• io.c provides a number of print functions and a number of read functions (e.g. to read an octetstring).

• oid.c contains the routines that are used to manipulate object identifiers.• ber_types.h contains the definitions of the local representations.

Current release available

A release of the current UT-SNMPv2 package is made available via anonymous FTP from

ftp.cs.utwente.nl in the directory "/pub/src/snmp":

-r--r--r-- 1 root 581632 Nov 2 08:45 ut-snmpV2-v1,0.tar

-r--r--r-- 1 root 212405 Nov 2 08:46 ut-snmpV2-v1,0.tar.Z

-r--r--r-- 1 root 121584 Nov 2 08:46 ut-snmpV2-v1,0.tar.gz

82 8. UT-SNMPv2 package

9 Conclusions

This chapter concludes this thesis. It provides the main conclusions concerning the traject ofspecification and implementation of a network management service based on SNMPv2. Section9.1 gives an evaluation of the design and implementation of this network management service.Section 9.2 of this chapter comprises a number of recommendations to improve and extend thecurrent implementation. Furthermore, this section considers the parts of the framework that stillneed to be implemented.

9.1 Evaluation of Assignment and developed Implementation

Becoming familiar with SNMPv2

If one starts to implement SNMPv2 from scratch, it is important to obtain first a clear imageabout the different parts of SNMPv2 and how these parts fit together. It took quite some time tobecome that familiar with SNMPv2 and its principles that it could be implemented withoutproblems. This was partially due to being completely new to SNMP and the lack of SNMPv2documentation at that moment. The RFCs were the only sources about SNMPv2 and theseRFCs changed regularly before they became a proposed standard. Much of the RFCs becameclear by discussion, on the one hand by following the mailing lists and on the other hand bydiscussion with the other members of the project.

Approach of specification and implementation of a SNMPv2 based service

The time which was spent on the different parts of this assignment, viz. service deduction,interface definition and implementation, has not been well divided. To much time has beenspent on the deduction of the service from the proposed standards [RFC 1440-1452]. It wasalmost impossible to derive the service from the protocol definition in one step. Many details ofthe protocol became clear when the protocol was implemented. The service was adapted manytimes.

The bottom-up approach that was used to implement the SNMPv2 protocol proved to work wellfor this assignment. To handle the complexity its important not to bite off more than one canchew. Therefore the implementation has been extended little by little.

Experience with respect to implementing the RFCs

My general experience implementing the RFCs [RFC 1440-1452] is that the RFCs provide asufficient base to obtain inter-operability. In general, the RFCs are hard to read, requiring manyre-reads. Especially, because of the structure that has been chosen to implement SNMPv2, viz.a separation of information exchange and information access, it was difficult to extract the

84 9. Conclusions

relevant information needed to implement the communication functionality. The RFCs do notshow such a separation.

Implemented SNMPv2 package

Easy to write applications

The implemented API allows an easy development of network management applications. TheAPI hides all the SNMPv2 protocol related things like encoding, parties and encryption. Theagent application developers only need to program the routines for the manipulation ofvariables. Furthermore, this kind of API definition makes the move towards a common API thathides the management protocol which is used to transfer management information, e.g.SNMPv2, SNMPv1 or CMIP, easier. Various management protocols could be plugged in.

Multiple application processes

The structure which has been chosen allows multiple application processes to run in parallel onone host serviced by one SNMPv2 Protocol Machine. This implementation structure posesgreat flexibility. Application processes can dynamically attach to and detach from the SNMPv2Protocol Machine. Though, this constraint had a great impact on the implementation. Manyproblems were related to this constraint. As these problems are a local implementation matterthe RFCs provided no base.

9.2 Future work

As not all parts of the complete framework and especially the network management servicecould be implemented during this assignment, still a lot of work needs to be done. In this sectionsome remarks and recommendations are made with respect to continuing the implementationof the complete framework.

Improving the current implementation

At first instance it is suggested to improve the current implementation with respect to theproblems mentioned in chapter 7. For example, one of the things that need to be improved inthe current implementation is the way variable bindings, object identifiers, octetstrings andbitstrings are represented and stored. These local C-representations do not provide sufficientflexibility and do waste memory.

Performance measurements

Having solved the most serious problems it is preferable to do performance measurements. Oneneeds to determine the bottlenecks of the current implementation to get a better view aboutwhat needs to be improved (w.r.t. speed and storage). Further, one should compare thesemeasurements to the measurements of other SNMPv2 packages to determine if a reasonableperformance is obtained.

Complete the implementation of the whole framework

Parallel to improving the communication functionality the remaining parts of the frameworkneed to be implemented. Above all much effort must be spent to the implementation of theSNMPv2 related MIBs (SNMPv2 MIB, PartyMIB and Manager to Manager MIB) and themanagement of these MIBs by means of SNMPv2 (i.e.meta-management). Implementation of

85

these parts is probably easier if one extends the current implementation before (possibly)switching to a multi-threaded version.

Extension of current implementation

In the current application the SNMPv2 Protocol Machine handles all application processesequally. In practice, different applications will have different rights to perform specificoperations on particular objects. Therefore, one needs to consider if mechanisms must beimplemented to distinguish between application processes with probably different rights. And,as mentioned in chapter 7, mechanisms must be implemented to dispatch requests amongdifferent agent application processes. Furthermore, attention must be paid to theimplementation of the context-resolver.

86 9. Conclusions

References

[Clo 93] McCloghrie, K., Security and Protocols,The Simple Times, Vol.2, no. 5, Sept./Oct. 1993, p. 7-8.

[Com 91] Comer, D.E.,Internetworking with TCP/IP Vol.I - Principles, Protocols &Architecture, Englewood Cliffs NJ, Prentice Hall, 1991.

[CoS 91] Comer, D.E., Stevens, D.L.,Internetworking with TCP/IP Vol.II - Design,Implementation & Internals, Englewood Cliffs NJ, Prentice Hall, 1991.

[Eijk 91] Eijk, P. van,Protocol Implementation - Lecture Notes (Course Notes 214004),Enschede, University of Twente, 1991.

[FIPS 46-1] Data Encryption Standard, National Institute of Standards and Technology,Federal Information Processing Standard (FIPS) Publication 46-1, January1988.

[ISO 7498-4] Information Processing Systems - Open Systems Interconnection -BasicReference Model Part 4: Management Framework, International Organizationfor Standardization, 1989, International Standard 7498-4.

[ISO 8824] Information Processing Systems - Open Systems Interconnection -Specificationof Abstract Syntax Notation One (ASN.1), International Organization forStandardization, 1987. International Standard 8824.

[ISO 8825] Information Processing Systems - Open Systems Interconnection -Specificationof Basic Encoding Rules for Abstract Syntax Notation One (ASN.1),International Organization for Standardization, 1987. International Standard8825.

[ISO 9595] Information Technology - Open Systems Interconnection - Common ManagementInformation Service Definition, International Organization for Standardization,1991, International Standard 9595.

[ISO 9596] Information Technology - Open Systems Interconnection -Common ManagementInformation Protocol Specification, International Organization forStandardization, 1991, International Standard 9596.

[Jan 92] Jander, M., Coming soon to a Network near you,Data Communications,November 1993, p. 67 - 76.

[Kna94] Knaap, J.H. van der, (in preparation)Implementation Options for IPC andconcurrency in UT-SNMPv2- M.Sc.thesis, Twente University of Technology,Enschede, Netherlands, 1994.

[M.3010] International Telephone and Telegraph Consultative Committee, Principles for aTelecommunications Management Network, 1992, Recommendation M.3010.

88

[Ram 93] Raman, L., CMISE Functions and Services,IEEE Communications Magazine,May 1993, p. 46 - 51.

[RFC 768] Postel, J.B.,User Datagram Protocol, Request for Comments 768, DDN NetworkInformation Centre, SRI International, 1980.

[RFC 1155] Rose, M., and McCloghrie, K.,Structure and Identification of ManagementInformation for TCP/IP-based internets, STD 16, RFC 1155, May 1990.

[RFC 1157] Case, J., Fedor, M., Schoffstall, M., Davin, J.,Simple Network ManagementProtocol, STD 15, RFC 1157, SNMP Research, Performance SystemsInternational, MIT Laboratory for Computer Science, May 1990.

[RFC 1212] Rose, M., and McCloghrie, K.,Concise MIB definitions, STD 16, RFC 1212,March 1991.

[RFC 1321 Rivest, R.,The MD5 Message-Digest Algorithm, RFC 1321, RSA Data Security,Inc., April 1992.

[RFC 1441] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Introduction to version 2 ofthe Internet-standard Network Management Framework, RFC 1441, SNMPResearch, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., CarnegieMellon University, April 1993.

[RFC 1442] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Structure of ManagementInformation for version 2 of the Simple Network Management Protocol(SNMPv2), RFC 1442, SNMP Research, Inc., Hughes LAN Systems, DoverBeach Consulting, Inc., Carnegie Mellon University, April 1993.

[RFC 1443] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Textual Conventions forversion 2 of the Simple Network Management Protocol (SNMPv2), RFC 1443,SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,Carnegie Mellon University, April 1993.

[RFC 1444] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Conformance Statements forversion 2 of the Simple Network Management Protocol, RFC 1444, SNMPResearch, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., CarnegieMellon University, April 1993.

[RFC 1445] Galvin, J., McCloghrie, K.,Administrative Model for version 2 of the SimpleNetwork Management Protocol (SNMPv2), RFC 1445, Trusted InformationSystems, Hughes LAN Systems, April 1993.

[RFC 1446] Galvin, J., McCloghrie, K.,Security Protocols for version 2 of the Simple NetworkManagement Protocol (SNMPv2), RFC 1446, Trusted Information Systems,Hughes LAN Systems, April 1993.

[RFC 1447] Galvin, J., McCloghrie, K.,Party MIB for version 2 of the Simple NetworkManagement Protocol (SNMPv2), RFC 1447, Trusted Information Systems,Hughes LAN Systems, April 1993.

[RFC 1448] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Protocol Operations forversion 2 of the Simple Network Management Protocol (SNMPv2), RFC 1448,SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,Carnegie Mellon University, April 1993.

[RFC 1449] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Transport Mappings forversion 2 of the Simple Network Management Protocol (SNMPv2), RFC 1449,

89

SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,Carnegie Mellon University, April 1993.

[RFC 1450] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Management InformationBase for version 2 of the Simple Network Management Protocol (SNMPv2),RFC 1450, SNMP Research, Inc., Hughes LAN Systems, Dover BeachConsulting, Inc., Carnegie Mellon University, April 1993.

[RFC 1451] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Manager-to-ManagerManagement Information Base, RFC 1451, SNMP Research, Inc., HughesLAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University,April 1993.

[RFC 1452] Case, J., McCloghrie, K., Rose, M., Waldbusser, S.,Coexistence between version1 and version 2 of the Internet-standard Network Management Framework,RFC 1452, SNMP Research, Inc., Hughes LAN Systems, Dover BeachConsulting, Inc., Carnegie Mellon University, April 1993.

[RFC 1503] McCloghrie, K., Rose, M.,Algorithms for Automating Administration in SNMPv2Managers, RFC 1503, Hughes LAN Systems, Dover Beach Consulting Inc.,August 1993.

[Rose 89] Rose, M.T.,The Open Book - A Practical Perspective on Open SystemsInterconnection, Englewood Cliffs NJ, Prentice Hall, 1989.

[Rose 91] Rose, M.T.,The Simple Book - An Introduction to Management of TCP/IP-basedinternets, 3rd edition, Englewood Cliffs NJ, Prentice-Hall, 1991.

[Rose 93] Rose, M.T.,The Simple Book - An Introduction to Internet Management, secondedition, Englewood Cliffs NJ, Prentice-Hall, 1993.

[Sch 93] Schekkerman, E.J.,An Analysis of the Simple Network Management Protocolversion 2(M.Sc. Thesis), Enschede, University of Twente, 1993.

[ScT 93] Scholtes, H.C., Toet, M., (in preparation) Implementation of a SNMPv2 API(B.Sc. Thesis), Enschede, Polytechnic of Enschede.

[Ser93] Serre, J., Lewis, P., Rosenfeld, K., Implementing OSI-Based Interfaces forNetwork Management,IEEE Communications Magazine, May 1993, p.76-81.

[Sco 91] Scollo, G., Ferreira Pires, L., Kremer, H., &Vissers, C.A.,Protocol Design -Lecture Notes (Course Notes 214007), Enschede, University of Twente, 1991.

[Sta 93] Stallings, W., SNMP-Based Network Management: Where is it headed?,Telecommunications Magazine, Vol.27, No. 6, June 1993, p. 87-91.

[Sta2 93] Stallings, W.,SNMP, SNMPv2 and CMIP, Addison Weshley PublishingCompany, Inc., Massachusetts, April 1993.

[SUN 90] Network Programming(Revision A), Sun Microsystems Inc., March 1990.

[Svo 89] Svobodova, L., Implementing OSI systems,IEEE Journal on selected areas incommunications, Vol.7 no. 7. September 1989, p 1115-1130.

[Yem 93] Yemini, Y., The OSI Network Management Model,IEEE CommunicationsMagazine, May 1993, p. 20 - 29.

Appendix A: List of Abbreviations

AE Application EntityANSI American National Standards InstituteAPI Application Programming InterfaceASN.1 Abstract Syntax Notation One

BER Basic Encoding RulesBSD Unix Berkeley Software Distribution

CCITT International Telephone and Telegraph Consultative CommitteeCLNS Connection Less Network ServiceCLTS Connection Less Transport ServiceCMIP Common Management Information ProtocolCMIS Common Management Information ServiceCMU Carnegie Mellon UniversityCnf Confirm

DES Data Encryption Standard

FIFO First In First OutFTP File Transfer Protocol

IAB Internet Activities BoardIDU Interface Data UnitIEEE Institute of Electrical and Electronics EngineersIETF Internet Engineering Task ForceInd IndicationIPC Inter-Process CommunicationISO International Organization for StandardizationISO/IEC International Organization for Standardization/ International Electrotechnical

CommitteeITU International Telecommunication Union

LAN Local Area NetworkLWP Light Weight Process

MD5 Message Digest algorithm, version 5MIB Management Information BaseMN Managed Node

92 .

NMS Network Management System

OSI RM Open Systems Interconnection Reference Model

PE Protocol EntityPM Protocol MachinePDU Protocol Data Unit

QoS Quality of Service

Req RequestRFC Request For CommentsRsp Responser/w read/write

SGMP Simple Gateway Monitoring ProtocolSNMP Simple Network Management ProtocolSNMPv1 Simple Network Management Protocol, version 1SNMPv2 Simple Network Management Protocol, version 2SMI Structure of Management InformationSP Service PrimitiveSPM SNMPv2 Protocol Machine

TCP Transmission Control ProtocolTCP/IP Transmission Control Protocol/ Internet ProtocolTIOS Tele-Informatics and Open Systems groupTLV Tag, Length, ValueTMN Telecommunications Management Network

UDP User Datagram Protocol

WAN Wide Area Network

Speciﬁcation and Implementation of a Network Management ...€¦ · te bieden aan applicatie...

Documents

Transcript of Speciﬁcation and Implementation of a Network Management ...€¦ · te bieden aan applicatie...