The management group at Twente University in the Netherlands is currently developing SNMPv2 software. The purpose of this article is to provide an overview of this development and give future plans. It is not the intention to go into to much detail — the last section of this article tells how to obtain more detailed information

Pras, Aiko

Togtema, Jacques

English

University of Twente Research Information

The Simple TimesTMTHE QUARTERLY NEWSLETTER OF SNMP TECHNOLOGY, COMMENT, AND EVENTSSMVOLUME 3, NUMBER 1 FEBRUARY, 1994The Simple Times is an openly-available publicationdevoted to the promotion of the Simple Network Man-agement Protocol (SNMP). In each issue, The SimpleTimes presents: a refereed technical article, an industrycomment, and several featured columns. In addition,some issues include brief announcements, summariesof recent publications, and an activities calendar. Forinformation on submissions, see page 12.In this Issue:Technology and CommentaryTechnical Article : : : : : : : : : : : : : : : : : : : 1Industry Comment : : : : : : : : : : : : : : : : : 4Featured ColumnsApplications and Directions : : : : : : : : : : : : 4Ask Dr. SNMP : : : : : : : : : : : : : : : : : : : : 5Security and Protocols : : : : : : : : : : : : : : : 7Standards : : : : : : : : : : : : : : : : : : : : : : 8MiscellanyActivities Calendar : : : : : : : : : : : : : : : : : 11Publication Information 12The Simple Times is openly-available. You are freeto copy, distribute, or cite its contents. However, anyuse must credit both the contributor and The SimpleTimes. (Note that any trademarks appearing herein arethe property of their respective owners.) Further, thispublication is distributed on an “as is” basis, withoutwarranty. Neither the publisher nor any contributorshall have any liability to any person or entity withrespect to any liability, loss, or damage caused or allegedto be caused, directly or indirectly, by the informationcontained in The Simple Times.The Simple Times is available via both electronicmail and hard copy. For information on subscriptions,see page 12.Technical ArticleAiko Pras and Jacques TogtemaTwente University of TechnologyIn this issue: SNMPv2 at Twente UniversityThe management group at Twente University in theNetherlands is currently developing SNMPv2 software.The purpose of this article is to provide an overview ofthis development and give future plans. It is not theintention to go into to much detail — the last section ofthis article tells how to obtain more detailed information.BackgroundThe last couple of years the network managementgroup of our university has participated in a numberof European RACE and Esprit projects. We workedon management architectures and, as most Europeans,concentrated on OSI and TMN.After some time however it became clear to us that weneeded more experience to judge the merits of the variousarchitectural concepts. This resulted in a decision tostart our own implementation project. Given the growingimportance of Internet management and the different“atmosphere” of the Internet world, we decided to startimplementing the complete SNMPv2 Framework (RFCs1441–1452). Since we weren’t involved in the definitionof SNMPv2, our work would reveal whether SNMPv2is sufficiently defined to allow implementation by non-adepts.GoalsOur first goal was to learn through experience. Toachieve this goal, we decided to discuss and implementall aspects of SNMPv2 ourselves. For example, weimplemented the Basic Encoding Rules from scratch,although we could have started from one of the existingSNMPv1 packages.Our second goal is to share our ideas with thecommunity. We therefore make our software freelyavailable and invite others to comment.It should be noted that we’re not working on acommercial product. If, for example, we have to choosebetween clarity and performance, we choose clarity.The Simple Times 2FeaturesThe two main differences between our implementationand those of others (e.g., CMU and 4BSD/ISODE), is ourmulti-process structure and our high-level programminginterface (API). We will discuss each of them in aseparate section.Multi-process StructureOur software development takes place on SUN Sparc-stations running UNIX (SunOS 4.1 and Solaris 2) usingthe GNU C compiler. Although we can’t really test oursoftware on other UNIX systems, we try to keep oursoftware portable.As UNIX allows multiple processes to cooperate, wedecided to use this facility and develop a structure inwhich a single process, called the SNMPv2 Protocol Ma-chine (SPM), serves multiple management applications.The SPM is responsible for the transfer of SNMPv2management information between systems and has noknowledge of management application issues. The SPMis therefore not bothered with MIB issues and thingslike Textual Conventions. The attractive property ofour structure is that the SPM can be the same forthe manager and agent side: it is the managementapplication that determines whether a system acts ina manager or agent role.Modification of this role is easy, since other applica-tions (playing different roles) can be connected to thesame SPM. Development of dual-role intermediate-levelmanagers (e.g., to support the Manager-to-ManagerMIB), is therefore straightforward.transport (e.g., UDP)SPMmanagementapplicationXCommunication between SPM and management ap-plications uses interprocess communication, such asTLI and sockets. As such, it is even possible to runmanagement applications on different machines. Ofcourse there is a performance penalty in having thismulti-process structure with IPC. We believe howeverthat this performance penalty is sufficiently compensat-ed by the improved flexibility and the lower complexity.As the first management application becomes active,the SPM is automatically started. The SPM initializes byreading a configuration file and is then ready to serve theapplication. If other management applications becomeactive, they will be connected to the same SPM. The SPMremains active until all management applications haveterminated. Upon termination, the SPM saves a copy ofthe recent configuration information to disk.The SPM is implemented in a single-threaded fash-ion, although we originally considered a multi-threadedapproach. The advantage of a multi-threaded approachis that messages can be processed in different threadsindependent from each other. It guarantees that largemessages that require authentication and encryptionwill not delay the processing of small messages thatdo not have security requirements. However, after aninvestigation of DES and MD5 processing times and afterwe understood the complexity associated with multi-threaded design, we decided to use a single-threadedapproach.ImplicationsThe decision to have a multi-process structure and toseparate management transfer functions from manage-ment application functions, has important implications.Let’s discuss two of them.The first implication is that management of SNMPv2itself (meta-management) should not be performed bythe SPM, but by special (meta-management) applica-tions. As a consequence, the SPM is not bothered withissues such as maintaining the Party, SNMPv2 andManager-to-Manager MIBs. This is equivalent to theapproach followed with other protocols, such as IP andTCP. Implementors of IP and TCP are not bothered withMIB issues either; it is sufficient if they provide a localinterface that allows reading and writing of IP and TCPvariables by a special management process. It is the taskof this special process to transform local information intothe form required by the MIB-II and check the validityof the management operations.transport (e.g., UDP)SPMmanagementapplicationXmeta-managementapplicationYVOLUME 3, NUMBER 1 FEBRUARY, 1994The Simple Times 3To illustrate the functioning of our meta-managementapplication (MMA), consider the example of changing aparty’s authentication clock. To change this clock, a setPDU must be received by the MMA via the same IPCport (e.g., X) as used for other application exchanges.The MMA (and not the SPM!) implements the rules (asspecified by the Party-MIB) for changing clocks: theMMA therefore checks whether the received PDU alsochanges the authentication key. If this is the case, theMMA uses the local interface port (e.g., Y) to perform theactual clock change.A second implication is that proxy relationships willnot be performed by the SPM, but by special proxyapplications. This makes the design of proxy agentsstraightforward: it is sufficient to understand themanagement API, it is not necessary to know the detailsof SNMPv2.Application Programming InterfaceThe main difference between our implementation andother implementations (e.g., CMU and 4BSD/ISODE)is the programming interface. As opposed to otherimplementations, our API hides most of the complexityof SNMPv2 from the management applications. Writersof management applications need little knowledge ofSNMPv2, which makes development of applicationseasier.Our API is actually a library of C-functions, whichmust be included in every management application.Details of the IPC mechanism are handled within theAPI and are therefore not visible to the writer ofmanagement applications.The API functions can be divided into two categories:functions necessary for initialization and terminationpurposes and functions necessary for sending and re-ceiving SNMPv2 PDUs. To initialize, the applicationcalls the snmpOpen function. This function starts, ifnecessary, the SPM and connects the application to it. Toterminate, the application calls the snmpClose function.This function removes the connection with the SPM —if no other applications are connected to the SPM, theSPM will terminate too.Most of the API functions are used for sending andreceiving SNMPv2 PDUs. Most “service elements” (e.g.,get) require four function calls: two for sending (Requestand Response), and two for receiving (Indication andConfirm). The Response and Confirm function calls arenecessary for sending and receiving Response PDUs.Although it is possible to use the same Response andConfirm functions for all ‘service elements’, we decided(primarily for clarity reasons) to introduce separatefunction calls for each individual “service element”.Since the application can not know in advance towhich “service element” a received PDU will belong, theapplication precedes each Indication and Confirm callwith a snmpLook call. This call tells the application thetype of service element that has been put into the IPCqueue by the SPM and must therefore be handled first.The table below shows all API calls that can be usedto send and receive SNMPv2 PDUs. Note that becausethe SPM translates, at the agent’s side, a get-bulk intoa number of get-next calls, there are no Indication andResponse calls for get-bulk. The table also shows thatthe SPM, upon receipt of an inform PDU from anotherSPM, automatically generates the response PDU.Req Ind Res Con+=======+=======+=======+=======get | x | x | x | xget-next | x | x | x | xget-bulk | x | | | xset | x | x | x | xinform | x | x | | xtrap | x | x | |Of course, associated with each function call are anumber of parameters, including: the IP address of remote system; the list of variable bindings; the request ID; the requested security, i.e., “none”, “auth” (MD5 isused), or “priv” (MD5 and DES is used); and, a string that helps to determine the context, whichmay be empty.StatusThe first version of our software was released in Novem-ber 1993. The major part of this software was writtenby a single student as part of his M.Sc. thesis. Thisfirst release should be considered as a “statement ofdirection” — although it can be used to manage SNMPv2systems, it is not yet complete, e.g., there are nometa-management applications, so it is not yet possibleto modify the Party, SNMPv2 and Manager-to-ManagerMIBs.ExperienceAt the beginning of our project we assumed SNMPv2would be simple and easy to implement. This assumptionproved to be wrong. SNMPv2 is complex for the followingreasons:VOLUME 3, NUMBER 1 FEBRUARY, 1994The Simple Times 4The demands put on SNMPv2 are much stronger thanthose put on SNMPv1. This inherent complexity appearsfor instance from the fact that 12 RFCs were needed tospecify SNMPv2.SNMPv2 has been specified as a monolithic whole —little attempt has been made to decompose SNMPv2into a number of building blocks with clearly definedinterfaces. We believe that a decomposition of SNMPv2into transfer, application, meta-management and proxy-oriented parts (along the lines of our approach) wouldhave made SNMPv2 easier to understand.The RFCs describe various mechanisms into greatdepth, but they hardly explain their purpose and theway they should be used (this is particularly true forSNMPv2’s administrative model). It would for instancebe helpful to see a description of how to search throughthe party, context, access control, and view table todetermine the party and context identities that must beincluded with the PDU.Still no real problems were encountered. Interoper-ability testing against the CMU package went smoothly.We may therefore conclude that it is possible for non-adepts to implement SNMPv2.FutureAfter our first release demonstrated that it was possibleto develop SNMPv2 software, we formed a project teamto continue this development for at least another year.Our new team is much bigger than the one we had lastyear, so we expect to complete all aspects of the SNMPv2framework, including meta-management, this year. Ourplan is to make new versions available on a regularbasis (e.g., every three months) Our sources can beobtained via anonymous FTP from ftp.cs.utwente.nlin the directory pub/src/snmp. Our email address is:snmp@cs.utwente.nl. Further information, including allproject documentation, is made available via our WWWserver:http://snmp.cs.utwente.nl:8001/snmp/html/homepage.htmlIndustry CommentMarshall T. RoseWelcome to the third year of The Simple Times.With this issue, we’re moving to a quarterly distri-bution cycle. The reason is simple: the coordinatingeditor simply doesn’t have enough time to put togethersix issues each year. So, we’re going to try four issues ayear.As a consequence of this, the Working Group Synopsiscolumn is discontinued. Although Fred Baker, DeidreKostick, and Kaj Tesink have done a wonderful job witheach issue, the column will lose too much of its value witha longer distribution cycle. Fortunately, each of thesecontributors has promised to write a technical articlelater on for The Simple Times!Applications and DirectionsSteven L. WaldbusserIn this issue: Deploying SNMPv2As people have been tracking the progress of SNMPv2deployment they have wondered about where the bot-tlenecks in the deployment process are, what is drivingthe process, and where products will materialize mostquickly. Of course, this is a chicken and egg problem, sothe answer to the question “Will the deployment be ledby managers or agents?” is largely “Yes!”. In an attemptto be a bit more accurate than this, we will compare thecurrent scenario with the deployment of SNMPv1, andthen make some observations about the current situationand predictions of the future.SNMP (version 1) DeploymentIn 1988, as the first SNMP specifications were finished,there were two interesting things about the industry:there were very few network management applicationsor protocols available, and much of the networkinginfrastructure (gateways and servers) was built on UNIXplatforms. The first point created an incredible vacuumthat was filled by SNMP. The second meant that a fewfree and commercial UNIX products easily built a criticalmass of deployed products. This was followed fairlyquickly by many embedded (i.e., non-UNIX) agents asvendors realized it was quite inexpensive to add anagent to a product and provide another check-off itemfor customers who had been loudly demanding networkmanagement capabilities.Applications and platforms of varying sophisticationcame later, and when vendors realized the complexity ofbuilding a platform, many scaled back to only providingVOLUME 3, NUMBER 1 FEBRUARY, 1994

SNMPv2 at Twente University

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information

NARCIS