The Simple Times is an openly-available publication devoted to the promotion of the Simple Network Management Protocol. In each issue, The Simple Times presents: a refereed technical article, an industry comment, and several featured columns. In addition, some issues include brief announcements, summaries of recent publications, and an activities calendar. For information on submissions, see the end of this issue.
The Simple Times is openly-available. You are free to copy, distribute, or cite its contents; however, any use must credit both the contributor and The Simple Times. (Note that any trademarks appearing herein are the property of their respective owners.) Further, this publication is distributed on an "as is" basis, without warranty. Neither the publisher nor any contributor shall have any liability to any person or entity with respect to any liability, loss, or damage caused or alleged to be caused, directly or indirectly, by the information contained in The Simple Times.
The Simple Times is available via both electronic mail and hard copy. For information on subscriptions, see the end of this issue.
In this issue: SNMPv2 at Twente University
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.
After some time however it became clear to us that we needed more experience to judge the merits of the various architectural concepts. This resulted in a decision to start our own implementation project. Given the growing importance of Internet management and the different ``atmosphere'' of the Internet world, we decided to start implementing the complete SNMPv2 Framework (RFCs 1441-1452). Since we weren't involved in the definition of SNMPv2, our work would reveal whether SNMPv2 is sufficiently defined to allow implementation by non-adepts.
Our second goal is to share our ideas with the community. We therefore make our software freely available and invite others to comment.
It should be noted that we're not working on a commercial product. If, for example, we have to choose between clarity and performance, we choose clarity.
As UNIX allows multiple processes to cooperate, we decided to use this facility and develop a structure in which a single process, called the SNMPv2 Protocol Machine (SPM), serves multiple management applications.
The SPM is responsible for the transfer of SNMPv2 management information between systems and has no knowledge of management application issues. The SPM is therefore not bothered with MIB issues and things like Textual Conventions. The attractive property of our structure is that the SPM can be the same for the manager and agent side: it is the management application that determines whether a system acts in a manager or agent role.
Modification of this role is easy, since other applications (playing different roles) can be connected to the same SPM. Development of dual-role intermediate-level managers (e.g., to support the Manager-to-Manager MIB), is therefore straightforward.
+-------------+
| |
| +-------------+
| | |
+-| +-------------+
| | management |
+-| application |
| |
+---------(.)-+
\
\
\
+-----------------(.)---------------+
| X |
| |
| SPM |
| |
+-----------------------------------+
| |
| transport (e.g., UDP) |
| |
+-----------------------------------+
Communication between SPM and management applications uses interprocess communication, such as TLI and sockets. As such, it is even possible to run management applications on different machines. Of course there is a performance penalty in having this multi-process structure with IPC. We believe however that this performance penalty is sufficiently compensated by the improved flexibility and the lower complexity.
As the first management application becomes active, the SPM is automatically started. The SPM initializes by reading a configuration file and is then ready to serve the application. If other management applications become active, they will be connected to the same SPM. The SPM remains active until all management applications have terminated. Upon termination, the SPM saves a copy of the recent configuration information to disk.
The SPM is implemented in a single-threaded fashion, although we originally considered a multi-threaded approach. The advantage of a multi-threaded approach is that messages can be processed in different threads independent from each other. It guarantees that large messages that require authentication and encryption will not delay the processing of small messages that do not have security requirements. However, after an investigation of DES and MD5 processing times and after we understood the complexity associated with multi-threaded design, we decided to use a single-threaded approach.
The first implication is that management of SNMPv2 itself (meta-management) should not be performed by the SPM, but by special (meta-management) applications. As a consequence, the SPM is not bothered with issues such as maintaining the Party, SNMPv2 and Manager-to-Manager MIBs. This is equivalent to the approach followed with other protocols, such as IP and TCP. Implementors of IP and TCP are not bothered with MIB issues either; it is sufficient if they provide a local interface that allows reading and writing of IP and TCP variables by a special management process. It is the task of this special process to transform local information into the form required by the MIB-II and check the validity of the management operations.
+-------------+
| |
| +-------------+
| | |
+-| +-------------+ +---------------+
| | management | | meta |
+-| application | | management |
| | | application |
+---------(.)-+ +-(.)------(.)--+
\ / |
\ / |
\ / |
+-----------------(.)----------(.)--+
| X Y |
| |
| SPM |
| |
+-----------------------------------+
| |
| transport (e.g., UDP) |
| |
+-----------------------------------+
To illustrate the functioning of our meta-management application (MMA), consider the example of changing a party's authentication clock. To change this clock, a set PDU must be received by the MMA via the same IPC port (e.g., X) as used for other application exchanges. The MMA (and not the SPM!) implements the rules (as specified by the Party-MIB) for changing clocks: the MMA therefore checks whether the received PDU also changes the authentication key. If this is the case, the MMA uses the local interface port (e.g., Y) to perform the actual clock change.
A second implication is that proxy relationships will not be performed by the SPM, but by special proxy applications. This makes the design of proxy agents straightforward: it is sufficient to understand the management API, it is not necessary to know the details of SNMPv2.
Our API is actually a library of C-functions, which must be included in every management application. Details of the IPC mechanism are handled within the API and are therefore not visible to the writer of management applications.
The API functions can be divided into two categories: functions necessary for initialization and termination purposes and functions necessary for sending and receiving SNMPv2 PDUs. To initialize, the application calls the snmpOpen function. This function starts, if necessary, the SPM and connects the application to it. To terminate, the application calls the snmpClose function.
This function removes the connection with the SPM -- if no other applications are connected to the SPM, the SPM will terminate too.
Most of the API functions are used for sending and receiving SNMPv2 PDUs. Most ``service elements'' (e.g., get) require four function calls: two for sending (Request and Response), and two for receiving (Indication and Confirm). The Response and Confirm function calls are necessary for sending and receiving Response PDUs. Although it is possible to use the same Response and Confirm functions for all `service elements', we decided (primarily for clarity reasons) to introduce separate function calls for each individual ``service element''.
Since the application can not know in advance to which ``service element'' a received PDU will belong, the application precedes each Indication and Confirm call with a snmpLook call. This call tells the application the type of service element that has been put into the IPC queue by the SPM and must therefore be handled first.
The table below shows all API calls that can be used to send and receive SNMPv2 PDUs. Note that because the SPM translates, at the agent's side, a get-bulk into a number of get-next calls, there are no Indication and Response calls for get-bulk. The table also shows that the SPM, upon receipt of an inform PDU from another SPM, automatically generates the response PDU.
Req Ind Res Con
+=======+=======+=======+=======
get | x | x | x | x
get-next | x | x | x | x
get-bulk | x | | | x
set | x | x | x | x
inform | x | x | | x
trap | x | x | |
Of course,
associated with each function call are a number of parameters,
including:
The demands put on SNMPv2 are much stronger than those put on SNMPv1. This inherent complexity appears for instance from the fact that 12 RFCs were needed to specify SNMPv2.
SNMPv2 has been specified as a monolithic whole -- little attempt has been made to decompose SNMPv2 into a number of building blocks with clearly defined interfaces. We believe that a decomposition of SNMPv2 into transfer, application, meta-management and proxy-oriented parts (along the lines of our approach) would have made SNMPv2 easier to understand.
The RFCs describe various mechanisms into great depth, but they hardly explain their purpose and the way they should be used (this is particularly true for SNMPv2's administrative model). It would for instance be helpful to see a description of how to search through the party, context, access control, and view table to determine the party and context identities that must be included with the PDU.
Still no real problems were encountered. Interoperability testing against the CMU package went smoothly. We may therefore conclude that it is possible for non-adepts to implement SNMPv2.
Welcome to the third year of The Simple Times.
With this issue, we're moving to a quarterly distribution cycle. The reason is simple: the coordinating editor simply doesn't have enough time to put together six issues each year. So, we're going to try four issues a year.
As a consequence of this, the Working Group Synopsis column is discontinued. Although Fred Baker, Deidre Kostick, and Kaj Tesink have done a wonderful job with each issue, the column will lose too much of its value with a longer distribution cycle. Fortunately, each of these contributors has promised to write a technical article later on for The Simple Times!
In this issue: Deploying SNMPv2
As people have been tracking the progress of SNMPv2 deployment they have wondered about where the bottlenecks in the deployment process are, what is driving the process, and where products will materialize most quickly. Of course, this is a chicken and egg problem, so the answer to the question ``Will the deployment be led by managers or agents?'' is largely ``Yes!''. In an attempt to be a bit more accurate than this, we will compare the current scenario with the deployment of SNMPv1, and then make some observations about the current situation and predictions of the future.
Applications and platforms of varying sophistication came later, and when vendors realized the complexity of building a platform, many scaled back to only providing applications that managed their products. This author hastens to add that the complexity was not due to SNMP, but due to the difficulties of writing X-based GUIs. There was a great sucking sound as the hierarchical map gobbled up development resources (for scant value to the customer, but that a subject for another time).
These issues explain why SNMPv2 has not been deployed as quickly as SNMP1. Despite this environment, some vendors have already shipped SNMPv2, each of the major platform vendors have committed to delivering SNMPv2 support this year, and many of the major equipment vendors have made the same commitment. So what will lead the pack?
Todays networks are built with many closed systems that are managed by open systems. A customer can add SNMPv2 management applications by using one of the shipping commercial products or one of the free implementations, but there is no way for a customer to add SNMPv2 to a router, bridge, or hub. This makes it more important for the vendors of managed systems to act. Of course, the advantage to them is that they are not as dependent on the MS vendors as the MS vendors are dependent on the agents. Customers can make some use of configuration capability, security, and speed in SNMPv2 agents by using the available managers, independently of the availability of SNMPv2 for the popular platforms.
For these reasons, the chicken-and-egg situation will be broken first by agents, followed closely by applications and platforms. This will all be playing out this year as vendors make good on their commitments.
Dear Dr. SNMP,
We are working with some agent software that sends back replies on a port other than 161. For example, a get is sent from port 3000 to port 161, and the agent sends its response from port 4000 back to port 3000. This is disconcerting to us because we can't decode it with a protocol analyzer.
I have looked at the relevant RFCs (SNMP and UDP). The SNMP RFC states only that ``the agent receives requests on port 161'' but doesn't implicitly state that it should reply to them on this port. So, is this behavior legal?
--Bummed out Believer from Beaverton
Dear Bummed out Believer from Beaverton,
Down on the farm, we have a saying:
``You'd be right, but you'd be dead.''When I first learned to drive an automobile, I was taught that in the jurisdiction where I lived, the pedestrian always has the right-of-way. Consequently, if a person is standing beside the road, and a large, tri-axle dump truck is hurtling down the hill toting a 20 ton load of gravel, and the person leaps in front of the truck, then the truck must stop, because the person on foot has the right-of-way. The fact that this violates physics is irrelevant. Of course, when the truck runs over the pedestrian, while it may be good for the pedestrian's estate, this has rather drastic consequences for the pedestrian.
You might ask, ``What does this have to do with my problem?'' There are many things in SNMP which are ``legal'' but which have rather drastic consequences. By my reading of the SNMP protocol specification, as articulated in RFC 1157, it says:
A protocol entity receives messages at UDP port 161 on the host with which it is associated for all messages except for those which report traps (i.e., all messages except those which contain the Trap-PDU).It is noteworthy that it does not say ``agent''! It says ``protocol entity'', and elsewhere in the specification, protocol entity is used when referring to agents and managers. Therefore, the specification appears to require all protocol entities, i.e., both managers and agents, to send and receive request/response messages at port 161.
I can tell from your question that you are well aware (but your supplier may not be aware) that existing practice for the request-response PDUs is as follows:
Given this background, it is easy to see that the law of the land may not match perfectly with existing practice, which is directly analogous to the notion that that the lawyers involved would debate whether, in fact, the truck really is or is not required to stop.
You ask if the unit's operation is ``legal''. Dr. SNMP is an engineer, not a jurist, and is unable to state an opinion on your question at this time. It is regrettable that there are several issues similar to the one you cite in the SNMPv1 protocol specification. Use of OBJECT IDENTIFIER fragments which are too large to fit in an unsigned longword and use of INTEGERs which too large to fit in a signed longword are but two examples, both of which are addressed in the new SNMPv2 specifications, but we must bear with the current undesirable situation until SNMPv2 is more widely deployed. Use of these questionable practices may be ``legal'', just as jumping in front of the truck may be legal. However, few would debate whether thrusting oneself in front of a truck in order to create a roadkill-in-motion situation is a good idea, and most would agree that deploying systems that don't conform to the existing practice is a similarly bad idea. I think the better question is, ``Is it better to be right, or to be alive?'' and to avoid being roadkill.
Since the original publication of MIB-I (RFC 1066), in August 1988, several of its MIB groups have needed to be upgraded. The latest such upgrade is for the interfaces group, with the recent publication of RFC 1573 as a Proposed Internet Standard. In this article, we'll look at the needs for, and results of this evolution of the interfaces group.
Consistent with this new approach is the clarification that there is no requirement that an internet-layer protocol runs at some layer above a network interface. For example, in MAC-layer bridges, for those ifTable counters of packets/octets received on an interface and ``delivered to a higher-layer protocol'', the bridge's forwarding module is considered to be a ``higher-layer'' to the MAC-layer of each port on the bridge.
In order to prevent a surfeit of linkUp and linkDown traps, one for each sub-layer, with this new multiple sub-layer model, an object has been added to enable/disable these trap types. By default, the lowest sub-layer of each interface stack has its traps enables, and each higher sub-layer has its traps disabled.
To address this issue, the evolution makes use of the SNMPv2 capability to define overlapping MIB groups for conformance purposes. It defines an ifGeneralGroup which applies to all network interfaces, an ifPacketGroup group containing those objects applicable to all packet-based interfaces, and an ifFixedLengthGroup containing objects applicable to interfaces which transmit data in fixed-length transmission unit, including character-oriented interfaces. It then specifies conformance statements requiring each interface to implement the ifGeneralGroup and whichever other group is applicable.
To address this issue, the evolution was granted a waiver to use the new SNMPv2 64-bit counter type for use with higher speed interfaces. 64-bit octet counters are specified for interfaces greater than 20Mb/s. 64-bit packet counters are specified for interfaces greater than 650Mb/s. These new counters supplement, not replace, the existing 32-bit counters in order to foster compatibility with existing implementations.
Since the last issue, there have been five new SNMP-related standards published. These include an updated and extended version of the interfaces group from MIB-II, three MIBs for managing applications, and an update of the DECnet Phase IV MIB as it proceeded to Draft Standard status.
This MIB module (in SNMPv1 SMI format) is an updated version of RFC 1289. There were general cleanups to fix typos, and to bring the MIB in conformance with the general editorial style. A new version of the adjacency table was created. A few redundant object types were removed, and the status of seven of the groups was changed from mandatory to optional.
RFC 1565 - Network Services Monitoring MIB (Proposed Standard)
This MIB module (in SNMPv2 SMI format) presents a general framework to monitor network services such as mail transfer agents, or directory service agents. The MIB module is designed to complement the Host Resources MIB (RFC 1514) and also to be application and transport protocol neutral. There are two tables in this MIB module: the first contains basic information about each network service in a system, and the second contains a limited number of attributes about each active association for each network service.
RFC 1566 - Message Transfer Agent (MTA) MIB (Proposed Standard)
This MIB module (in SNMPv2 SMI format) is the first example of a class of network service that may be monitoried. This MIB module applies to generic message relays. The first table measures aggregate incoming and outgoing mail traffic. The second table measures in greater detail the traffic including associations and errors for ``groups''. The final table is used to show which ``associations'' belong to each ``group''.
RFC 1567 - Directory (X.500) System Agent (DSA) MIB (Proposed Standard)
This MIB module (in SNMPv2 SMI format) is for another type of network service, X.500 DSAs. The first table has counters for each incoming operation, each outgoing operation, and errors observed. The next table reports cache performance. The final table tracks interactions with peer DSAs.
RFC 1573 - Interfaces Group MIB (Proposed Standard)
The interfaces group from MIB-II (RFC 1213) was extracted and expanded to create this MIB module (in SNMPv2 SMI format). This 55 page document is the evolution of a key component of the core IETF SNMP model of managed systems. The first 20 pages address general and specific issues with the original interfaces group. The remainder of the document consists of two MIB modules. The first contains the definition of the textual convention used to define each interface type. This organization allows easy update by the Internet Assigned Numbers Authority (IANA). The second MIB module contains five tables. The first is the original IF table from MIB-II. The second table extends the IF table with new object types, replacements, and ones from the ifExtnsTable from RFC 1229. A ``stack'' table is next, which defines relationships among the sub-layers of an interface. The fourth table is used to perform specific tests on interfaces, replacing a similar table in RFC 1229). And the last table specifies the addresses which each interface may receive packets/frames.
SNMPv2 Framework (Proposed Standards):
Full Standards:
Draft Standards:
Proposed Standards:
Experimental:
Informational:
Historical:
AToM MIB Working Group:
BGP Working Group:
Bridge MIB Working Group:
Character MIB Working Group:
DECnet Phase IV MIB Working Group:
FDDI MIB Working Group:
Frame Relay Service MIB Working Group:
Host Resources MIB Working Group:
IEEE 802.3 Hub MIB Working Group:
IDPR Working Group:
IDRP for IP Working Group:
Interfaces MIB Working Group:
IPLPDN Working Group:
IS-IS Working Group:
Mail and Directory Management Working Group:
Modem Management Working Group:
NOCtools Working Group:
OSPF Working Group:
PPP Working Group:
RIP Working Group:
Remote Monitoring (RMON) Working Group:
SNA DLC Services MIB Working Group:
SNA NAU Services MIB Working Group:
SNMPv2 Working Group:
TCP Client Identity Protocol:
Trunk MIB Working Group:
Uninterruptible Power Supply Working Group:
X.25 MIB Working Group:
March 28-April 1, Seattle, WA
For information: +1 703 620 8990
May 2-6, Las Vegas, NV
For information: +1 415 578 6900
The Simple Times also solicits terse announcements of products and services, publications, and events. These contributions are reviewed only to the extent required to ensure commonly-accepted publication norms.
Submissions are accepted only via e-mail, and must be formatted in HTML version 1.0. Each submission must include the author's full name, title, affiliation, postal and electronic mail addresses, telephone, and fax numbers. Note that by initiating this process, the submitting party agrees to place the contribution into the public domain.
In addition, The Simple Times has numerous hard copy distribution outlets. Contact your favorite SNMP vendor and see if they carry it. If not, contact the publisher and ask for a list.