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: A New View on Bulk Retrieval with SNMP
There has been much discussion over the benefits and drawbacks to the Simple Network Management Protocol (SNMP) since its inception in 1987. Unfortunately too much of the criticism results only in discussion, and too little is acted upon. This article will describe some experimental work to address some of the perceived and real deficiencies of SNMP when retrieving bulk data.
Returning to simplicity, SNMP was built simply for a number of reasons other than time to market: robustness in the face of network failure; low overhead on the devices running the protocol; and ease of debugging the protocol itself (the last thing you want to debug is the management protocol that is supposed to be helping you debug your network). Thus, the SNMP limited itself to the User Datagram Protocol (UDP). This gave the implementor the ability and responsibility to manage lost packets and perform any necessary retransmissions. As network debugging in the face of changing routes will certainly mean losing packets, retaining this control from the transport service (layer 4) was considered essential. Since a network management protocol will be run continuously it is mandatory that it consume as minimal network resource as possible. UDP allows the necessary control over packet transmissions, packet size and content (packetization). It was a natural choice.
SNMP has three control primitives that initiate data flow from the requester (get, get-next and set). There are two control primitives the responder uses to reply. One is used in response to the requester's direct query (get-response) and the other is an asynchronous response to obtain the requester's attention (trap). All five of these primitives are carried by UDP and are thus limited in size by the amount of data that can fit into a single UDP packet (65507 octets). All implementations of SNMP must be able to receive messages of at least 484 octets in size. Larger maximum values are permitted, via bi-lateral agreement. The relatively small message size was a goal of the design but for some reasonable set of network management functions, it imposes a limitation.
Often in network management, it is necessary to obtain bulk information without knowing at first what it is. In one case, there is a set of problems having to do with packets not going where they are supposed to, due to device misconfiguration that prevents proper protocol operation where one needs to view the entire set of data. For example, in determining some kinds of network failure modes, one has to know the entire contents of the tables containing routing or address mapping information -- and these tables can be quite large! Cases such as these are more the exception than the rule, but having the complete information available is necessary if the problem is to be solved. Many a time, a problem is uncovered simply by reviewing a routing table.
However, unless employed with care, the get-next primitive can be extremely resource-intensive in real time, network bandwidth, and the agent's CPU time. The simplest use of the get-next primitive is to start at the beginning of a table, await the response and then issue another get-next with the name returned. As an example, say you wanted the next-hop address, next-hop interface and route-type from a routing table containing 1000 entries. Using the simplest form of get-next, this would require 2x3x1000 or 6000 packets (get-next and get-response packets, columns, and rows). A straight-forward optimization would be to request the three columns in a single packet. This puts the number of packets at 2x1000 or 2000 packets. In real time, it is the product of the round trip by the number of requests. In agent CPU time, this is still 6000 lookups in the routing table for both cases.
A second algorithm, the parallel algorithm, reduces the packet count by combining the multiple concurrent get-nexts into a single packet. Although this minimizes the total number of requests sent over the network, no savings are realized for the agent CPU in lookups.
In SNMP, data structures are defined using a subset of Abstract Syntax Notation One (ASN.1), and then encoded using the Basic Encoding Rules (BER). The BER has two ways for encoding the length of data: the definite and indefinite length encoding schemes. The definite length encoding scheme includes all the length fields for each datum. The indefinite length encoding scheme uses markers to denote the end of the encoding. The benefit of the definite scheme is that decoding is easy but encoding is hard. With the indefinite scheme, the burden is actually reversed -- if the entire ASN.1 object can be processed in a single packet. Otherwise, the indefinite scheme requires some extra state be maintained to suspend and resume the decoding operation when new information arrives via TCP. (This assumes a multi-threaded decoder which can decode more then one ASN.1 object simultaneously). For this reason, the definite scheme is used so the decoder can determine when all the data is received to begin decoding.
All of the agent complexity lies in accumulating the SNMP request and spooling the encoded response from and to the requester. On input, the complete request must be gathered prior to ASN.1 decoding (unless the decoder is able to handle and postpone incomplete encodings on the fly.) Once completely received the operation can be processed and the results encoded. If the encoder can be suspended and resumed, then encoding can be given to TCP on the fly; otherwise, the entire result must be encoded to a memory store and then given to the TCP in chunks. For a get-column primitive with many requests, the memory requirements can be substantial.
For the management station, the implementational complexity is roughly half compared to that of the agent. The output requests tend to be small, so output to the TCP connection is simplified. However the input response can be large and thus require enough memory to hold it and some state to fill it up. Again, a smart decoder would make this easier.
For support of the get-column primitive, extra code is required to validate that the argument given is part of a valid table. Since each argument will produce many results, to save on CPU time in the agent, the results are not returned in any particular order. This permits each implementation to return the complete column in its native order. However, each get-column request is expected to be atomic. This allows multiple columns to be consistent across the rows within a single request. Further, each column within the same table must be returned in the same order as the other columns, so the rows are aligned. Errors are returned for the same reasons as the get primitive.
There are two drawbacks to this scheme: the get-column primitive modifies the protocol and requires a TCP transport. The later TCP requirement is easily dealt with by falling back to UDP if TCP is not available. Of course, the get-column primitive adds some extra complexity to the table retrieval logic. We need a broader understanding to determine if this is a serious limitation or not.
Software development moves forward by evolving the unknown into the known. At the time of SNMP's inception, it was not possible to conceive of a reliable transport based network management protocol. Today's problems require more sophistication in the amount of data required to analyze a problem. This puts the burden back on the protocol to gather it quickly and efficiently. The two proposals in RFC 1187 do this without protocol changes but are not scalable. The approach described in this article achieves the same end by using a well-known transport present in a great many internetworking platforms. It also reduces the agent processing overhead at the same time.
The experimental implementation described in this article is presently available in the cisco software 8.3(1) and later releases; the TCP listener will respond to port 1993 and the get-column primitive is number 5.
Welcome to The Simple Times.
Normally the Industry Comment section contains an editorial on the state of network management. Instead, for the premiere issue, we'll look at what this newsletter is all about. In the next issue, we'll have something more thought-provoking.
After securing commitments from my colleagues to help with the project, the next major problem was to determine the business model for the newsletter. There are basically two ways of doing it: professional or volunteer. The professional approach requires that the newsletter be run as a business -- with cost-recovery through subscription fees and perhaps even advertising. The volunteer approach is tricky in that, outside of volunteer time, it requires that all other expenses be sunk-costs.
A professional newsletter about SNMP and network management could probably break even or perhaps show a modest profit. However, it takes a lot of resources to make this happen. If a publication has a subscription fee, then someone has to collect it. If a publication has advertising space, then someone has to sell it. Given that
``there's no such thing as a free lunch, but sometimes it costs less to give away food than to collect money''we decided that the volunteer approach was a better business model. This way, my colleagues and I can concentrate on putting things in the newsletter, rather than spending time putting out the newsletter.
The final step was to set up minimal-cost distribution channels. The Simple Times is available both in hard-copy and electronically. To make the hard-copy distribution a no-cost item, we settled on a rather unique distribution mechanism: hard-copy is distributed by SNMP vendors. When an issue comes out, each participating vendor gets a clean-copy (at no charge). They then make copies for their customer lists or special friends, usually after they put their company name in the upper-right corner. (The Simple Times is not-affiliated with any vendor, although several contributors are employees of vendors of SNMP products and services.)
The electronic distribution is via Internet-mail. The Simple Times is sent out in two formats: MIME and PostScript. MIME, in case you haven't heard of it, is the Multi-media format for Internet-mail. In order to minimize personnel time, a subscriber is added or removed automatically -- via e-mail.
So, the only thing remaining is to let you know who the volunteers are. We'll start with the people who write the featured columns:
Applications and Directions is written by Steve Waldbusser. Steve is the author of the most widely-used public-domain implementation of SNMP. He's also the driving force behind the Remote Network Monitoring MIB, which is receiving wide adoption for LAN monitoring. In his column, Steve talks about the changing face of management, focusing on the applications we need to get the job done, and the problems we have in achieving those goals.
Ask Dr. SNMP is written by Jeff Case. Jeff is one of the four original authors and implementors of SNMP. Since that time, Jeff has been tireless in promoting and productizing SNMP (hence, he's often referred to as Dr. SNMP). In his column, Jeff answers the latest questions people are asking about SNMP.
Security and Protocols is written by Keith McCloghrie. Keith is the co-author of the Internet-standard SMI and MIB. He is also one of the three co-authors of the ``Secure'' SNMP. In his column, Keith talks about ``Secure'' SNMP and other developments from the protocol perspective.
Standards is written by Dave Perkins. Dave, a member of the Network Management Area Directorate of the Internet Engineering Task Force, is working on improving the way MIBs are written. In his column, Dave talks about network management standardization activities within the IETF.
Working Group Synopses is written by Bob Stewart. Bob is the force behind the ``character'' MIBs being developed by the IETF. In his column, Bob has the unenviable task of surveying the various IETF working groups struggling with network management, and then distilling the key issues under discussion.
The Technical Review Board for The Simple Times consists of Jeff, Keith, Steve, and myself.
Finally, as coordinating editor, my job is simply to ``make the trains run on time''. So, when you like the contents of The Simple Times, thank the other volunteers. If an issue comes out late, you know who to blame.
In this issue: Exposing the Myths about Autotopology
Autotopology is often cited as the most requested network management feature in user surveys and by enthusiastic sales and marketing personnel. The dream of autotopology is that a management station can be installed and will automatically learn the configuration of the entire network and display it in a graphical form suitable for network management. This dream is often held by users of large networks daunted by the prospect of configuring hundreds or thousands of network devices by hand. While many aspects of this dream are possible, many others are impossible or are ill-advised.
Network management users need a graphical network map to display the network in a logical and useful manner. This requires a fair bit of information from the network. Autotopology can ease the burden of entering this volume of information into the Network Management System (NMS) by hand. Some network management architects wish to make their products simpler by using autotopology to make up for the lack of a database -- they simply re-discover the network configuration on every startup. Of course, the costs of this strategy are prohibitive for all but the smallest of internets.
There are three aspects to autotopology that should be explored in turn: topology discovery, node discovery, and drawing the map. There are difficulties in each of these areas, as well as ideas that may help make them more solvable.
A second method of device discovery is to send an ICMP ECHO packet to every possible address on the internet, in sequence. This is referred to as the Monte Carlo method of network management (a term coined by Chuck Davin). This method consumes a lot of time and network resources. On a Class A IP network with 4 million possible addresses this would be impossible, but even on a Class B IP network it will generate at least 65,000 packets and take a lot of time (though it's probably the 65,000 ARP broadcast packets that will kill your network). This mechanism should be used with care as well.
A third method of device discovery is to use the passive monitoring capabilities of a Remote Network Monitoring device to discover devices from the source addresses of the packets they send. The Remote Network Monitoring (RMON) MIB defines objects that allow SNMP retrieval of a list of link-level addresses discovered by an RMON probe. The cost of dedicated remote monitoring systems could be a barrier to some users, but as routers, hubs, and other devices implement the RMON MIB, the cost can drop dramatically. The Internet Engineering Task Force (IETF) has chosen RMON as the preferred mechanism for device discovery, and will shortly embark on an effort within the RMON Working Group to add the objects for discovery of the addresses of network protocols such as IP.
To be effective, it is almost always necessary to store the discovered devices and topology in a database. It is also helpful for the NMS to automatically use SNMP to discover configuration information from devices and to store it in the database. This information can be invaluable in tracking down the source of a network failure, at which time it is probably impossible to query the devices directly. A good system will also have facilities for updating its database when it detects additions, replacements, or changes of network devices.
Similar heuristics can be applied to other MIBs. In fact the presence or absence of the particular management objects that make up a MIB might signal that a device is interesting.
Clearly there are several reasons why autotopology cannot be truly automated. Automated systems usually can't get enough topology detail; they can't lay out the map in a logical fashion; and, they can't automatically decide which devices are important enough to deserve an icon on a crowded display. There are some ideas and algorithms which, if used, can make the system more usable and efficient. However, it is important to note that these systems will always require help from the network management user and will never completely satisfy the autotopology dream.
Dear Dr. SNMP,
Are community strings case-sensitive? Some agents don't care, others do. And, now I am
-- CoNfUsEd in Costa Mesa
Dear CoNfUsEd in Costa Mesa,
There is a saying back on the farm:
``You can put a pig in a suit, but it still acts and smells every bit like a pig.''What this means is that, according to RFC 1157, the community name is a string of octets. Octets are 8-bit units of binary information. As such, they don't even need to be ASCII, let alone case-sensitive ASCII. A strict interpretation of RFC 1157 indicates that a community string containing only ASCII characters is indeed case-sensitive. However, an implementor may decide to use case-insensitive matching in an agent. This should be discouraged, as it may confuse users and even management consultants. Of course, some of our parents brought us up tending to be Case sensitive at all times.
Dear Dr. SNMP,
If an agent doesn't support SNMP's set operation, can the vendor claim conformance to the SNMP RFC (or any MIB they claim to implement which has read-write objects)?
-- Jaded in Jersey
Dear Jaded in Jersey,
Your question inspires additional questions in the mind of Dr. SNMP. Suppose a vendor sold you a TCP implementation that could send but could not receive. Would it conform to the TCP specification? Suppose you bought a television which claimed to have a remote control but when you went to use it, you found that it would display the channel on the screen but wouldn't allow you to change it. Would that be satisfactory? Returning to your question, there is a saying back on the farm:
``That dog won't hunt.''What this means is that agents and manager stations which don't support the set operation don't implement SNMP because the set operation is an integral part of SNMP. Similarly, if a MIB has one or more objects which have an ACCESS of ``read-write'', then for an agent to implement that MIB, the agent must allow an authorized management station to issue a set request for that object.
Your question points out an issue that is deeply disturbing to Dr. SNMP. Some vendors found it difficult to implement SNMP sets and read-write variables in the MIB. Rather than commit the engineering resources to fully implement SNMP management framework, they simply claim that that did not implement control operations because of weaknesses in the authentication mechanisms. Such a posture has become fashionable as customers of these vendors have let them get away with it. Of course, while the security of SNMP could be (and is being) strengthened, the correct thing to do would be to fully implement the specifications, including sets and read-write MIB variables. Vendors who are concerned about the weaknesses of SNMP security could ship the systems with the default state of these features disabled, with appropriate cautions in the manual text describing how to enable them.
Dear Dr. SNMP,
Should a management station be able to reset the counters in an agent to zero?
-- Frustrated in Fremont
Dear Frustrated in Fremont,
There is a saying back on the farm:
``Sometimes, sometimes not.''What this means is that it depends on whether the MIB object is defined to have an ACCESS of ``read-write''. If so, then an authorized manager should be allowed to set the variable to any value that makes sense. However, just because you can doesn't mean you should. Counters should be monotonically increasing. This is especially important when multiple managers are in use. The normal SNMP manager application would retrieve the current value of the variable of interest, ``remember'' it, and then compute delta values using the base value and values obtained from subsequent queries. By the way, Dr. SNMP has carefully examined the 1152 objects currently standardized or being developed in the IETF. Of these, he couldn't find a single counter with an ACCESS of ``read-write''. Gentle reader, perhaps there is a very good reason for this.
SNMP Security is the major recent protocol development in the SNMP area. In this article, we'll look at why we need SNMP Security, that is, what are the ``threats'' against which it provides protection, and discuss some of the mechanisms it uses. In future articles, we'll see how the mechanisms are integrated into the protocol and discuss some issues involved in product implementation and deployment.
The original designers of SNMP knew that security would become important, but they also knew that getting agreement on it in 1987 wouldn't be possible. So, they purposefully provided a general community field to provide a handle for both authentication and authorization. Hence, the community field in today's SNMP is used, among other things, to identify the authentication algorithm for a message. The only authentication algorithm defined was the trivial algorithm, for which a message having a known string in its community field was automatically authentic.
Since SNMP is designed to be datagram-based, a community string is included in every message. So, while today's SNMP is not wide-open (you do have to know the right community string), neither is it secure. Any unauthorized person able to capture a SNMP packet off the network immediately learns a community string for the target device, and can then perform his own management operations on the device. A minor improvement is to add restrictions based on the source address (e.g., the IP address) of a message, but authorized addresses are as easy to learn as community strings and the source IP address of a datagram is easily faked.
The level of concern this raises for network administrators depends on their network environment. The most common variation has been in their willingness to use SNMP for control. Some administrators find the community mechanism completely unacceptable for control; in contrast, others have very little concern. Thus, while SNMP has seen tremendous growth in popularity for monitoring networks, it has not been so widely used for controlling networks. Indeed, some vendors have used this as an excuse not to support SNMP's set operation in their agents.
However, over the last three years other threats have been identified. These are:
Countering these four threats led to the major goals of SNMP Security: origin authentication, message integrity, replay protection, and privacy (i.e., encryption). In addition, SNMP Security recognizes the importance of allowing network administrators to choose how much security they want and when. At one extreme, an especially security-conscious administrator might want every message to be authenticated and private. A different administrator might not want any security except in rare circumstances.
MD5 is a cryptographic checksum algorithm which specifies how to generate a 16-octet checksum (called the digest) for a block of data. The strength of MD5 relies on the fact that it is not feasible to compute a different block of data which generates the same digest value. For SNMP Security, the block of data is the concatenation of the message to be transmitted and a secret value (which is not transmitted). By having the secret value known only to the sender and receiver, two of SNMP Security's goals are obtained. First, the digest value can be computed only by the sender or receiver, providing origin authentication; and, second, no other entity can compute the correct digest value for an altered message, providing message integrity.
DES has been the U.S. Federal Data Encryption Standard for several years. SNMP Security uses its Cipher Block Chaining (CBC) mode for privacy. In this mode the value of one part of the message affects the encrypted value of all later parts of the message. This is important considering that two SNMP messages often have the same values in some of their fields.
The use of loosely synchronized clocks enables the sender to include a timestamp in a message, and the receiver to use that timestamp to verify that the message has arrived within a defined lifetime. This lifetime value must be large enough to accommodate variation in message transmission times across the network. In addition, clocks tend to drift and so they must be synchronized periodically. Fortunately, the frequency of such drift is small compared to potential variations in transmission time, so the clocks need only be loosely synchronized. This provides replay protection, in that the message can be replayed only during the lifetime interval, during which time the duplication of messages can occur for non-malicious reasons in a typical IP-datagram network.
A major function of the IETF is to produce standards for the TCP/IP suite of protocols. Documents generated by the IETF which are completed and meant for distribution are published in the Request for Comments (RFC) document series. Not all RFCs are standards. To become a standard, a document enters the standards track as a proposed standard, moves to draft standard, and finally emerges as a full standard. Other documents in the RFC series are labeled as experimental, informational, or historical.
This column is about the standards that define the Internet-standard Network Management Framework. Each issue of this column will summarize the status of relevant documents. The current issue looks at documents on the standards track, while the next issue will present the Internet standardization process.
The format and interpretation of SNMP messages are described in this document, along with the definitions of generic traps. Some parts of this document are modified by standard practice, and by the new work on SNMP Security.
RFC 1155 - Structure of Management Information (SMI)
The method to name and describe managed objects is defined in this standard. Much of the document has been updated by the Concise MIB (RFC 1212) and Trap Definitions (RFC 1215) documents. Further, some parts of this document are modified by standard practice. This document needs to be updated to reflect the state of the art.
RFC 1213 - Management Information Base (MIB-II)
This MIB defines objects for basic management of TCP/IP-based devices, and obsoletes RFC 1156, the original Internet-standard MIB. Areas covered in the MIB include: objects describing the system, objects for device interfaces, address translation objects, IP protocol objects, ICMP protocol objects, TCP protocol objects, UDP protocol objects, EGP protocol objects, SNMP protocol objects, and, a placeholder for interface objects based on transmission medium type.
This document defines a format for producing concise, yet descriptive, MIB modules. It accomplishes this task by redefining through augmentation of the OBJECT-TYPE macro defined in the SMI document (RFC 1155) and describing how to specify and interpret the instance encodings for SNMP variables.
Objects for generic interfaces are defined in MIB-II (MIB-I). When MIBs for media-specific objects were developed, it was discovered that there was an additional set of objects common across the media types. This MIB defines that collection. These include: interface counter and configuration objects, objects used to perform tests, and, a list of receive addresses for an interface. Note: this document is updated by RFC 1239.
RFC 1230 - IEEE 802.4 Token Bus Interface Type MIB
This MIB defines objects for interfaces that conform to the IEEE 802.4 Token Bus specification. These objects include: those that report operational state and parameter values, initialization values for operational parameters, interface statistics, and, object identifier assignments for well-known tests and chip sets. Note: this document is updated by RFC 1239.
RFC 1231 - IEEE 802.5 Token Ring Interface Type MIB
This MIB defines objects for interfaces that conform to the IEEE 802.5 Token Ring specification. These objects include: those that report operational state and parameter values, interface statistics, timer values, and, object identifier assignments for well-known tests and chip sets. Note: this document is updated by RFC 1239.
RFCs 1232/1233 - DS1/DS3 Interface Type MIB
These two MIBs define objects for DS1 and DS3 physical interfaces based on the AT&T T-1 specifications and Extended Superframe formats for DS1 or ANSI T1.102-1987, ANSI T1.107-1988, and ANSI T1.404-1989 for DS3. These include: configuration objects, error counters over the last 24 hours in 15 minute intervals, interface statistics, and, mappings for fractional DS1 channels (for DS1 interfaces). Note: these documents are updated by RFC 1239.
RFC 1239 - Reassignment of experimental MIBs to standard MIBs
When RFCs 1229, 1230, 1231, 1232, and 1233 were published, they were not updated to specify the correct MIB subtree root. This document corrects that oversight.
RFC 1243 - AppleTalk MIB
This MIB defines objects for the AppleTalk suite of protocols. Included are objects for: LocalTalk Link Access Protocol (LLAP), AppleTalk Address Resolution Protocol (AARP), Datagram Delivery Protocol (DDP), Routing Table Maintenance Protocol (RTMP), Kinetics Internet Protocol (KIP), Zone Information Protocol (ZIP), Name Binding Protocol (NBP), and, AppleTalk Echo Protocol. Also included are objects describing the configuration and status of AppleTalk Ports.
RFC 1253 - OSPF version 2 MIB
This MIB allows routers that have implemented OSPF to be fully managed via SNMP. The groups in the MIB include: global status and configuration objects, area table and area stub metric table, the link state database, address range table and host route table, interface and interface metric tables, the virtual interface table, and, the neighbor and virtual neighbor tables.
RFC 1269 - BGP version 3 MIB
The BGP MIB allows routers implementing the BGP routing protocol to be monitored. This MIB consists of a few objects that specify the global information, a table of information about BGP peers, and, a table of path attributes.
RFC 1271 - Remote Network Monitoring MIB
This MIB defines the objects needed to completely manage via SNMP a device that monitors ethernet (802.3) LANs. It is structured so that other LAN types such as token ring may be added. It is probably the most extensive MIB developed within the IETF, and defines a new model for row creation which can be used in the development of other MIBs. The objects include the following groups: statistics based on the LAN type being monitored, historical samples of statistics, alarm generation objects, tables of statistics based on source and destination addresses in LAN frames, frame capturing after filtering, and, event generation.
RFC 1284 - Ether-Like Interface Type MIB
This MIB defines objects for interfaces that conform to the ether-like (i.e., IEEE 802.3 CSMA/CD, Ethernet, and StarLan) specifications. These objects include: those that monitor and control operational state and parameter values, interface statistics, a table of collision types, and, object identifier assignments for well-known tests and chip sets.
RFC 1285 - FDDI Interface Type MIB
This MIB defines objects for interfaces that conform to the FDDI specifications. The ANSI committee that wrote the FDDI specifications also included management objects in those specifications. This MIB is a translation of the SMT revision 6.2 mandatory objects. The goal of the translation was to keep the object semantics the same even though the names or structure of the objects were changed. The objects in the MIB include: those for SMT monitoring and control, MAC status and control, port status and control, attachment status and control, and, object identifier assignments for well-known chip sets.
RFC 1286 - Bridge MIB
Devices which provide transparent bridging that is consistent with the IEEE 802.1d specification, and source routing bridges consistent with the IBM Token Ring Architecture may be monitored and can have a few objects configured via this MIB. The objects defined by IEEE for transparent bridging were mapped trying to keep the semantics unchanged even though the names or structure may be changed. The groups for both types of bridging include: global bridge parameters, statistics and configuration per bridge port, spanning tree objects, per port spanning tree configuration and statistics, source routing information per port, forwarding database for transparent or SRT bridges, per port statistics for transparent bridging, and, a destination address filtering database. The MIB also includes traps for new root and topology change.
RFC 1289 - DECnet phase IV MIB
This MIB defines objects so that a device using DECnet phase IV can be managed via SNMP. The objects come from the July 1983 DECnet Architecture Network Management Functional Specification version 4.0.0. This MIB contains quite a few objects. They are combined in the following groups: system, network management, session layer, end communication layer, routing layer, circuit parameters and counters, DDCMP circuits, DDCMP multipoint control, ethernet, counters, adjacency, line, nonbroadcast line, and area.
RFC 1304 - SMDS Interface Protocol (SIP) MIB
For use with IP over SMDS, this MIB provides statistics at SIP level 3, SIP level 2, and for the Physical Layer Convergence Protocol (PLCP) layer. MIB objects for the physical layers DS1 and DS3 are provided in other MIBs. There are MIB object for the mapping information as defined in RFC 1209 for running IP over SMDS. Finally, a table is provided to log SIP level 3 errors.
Many IETF working groups address SNMP-relevant issues. In some cases, the group is under the Network Management Area, and the work is entirely directed toward SNMP, such as developing a MIB for a particular transmission medium. In other cases, the SNMP work is a small component of a primary task, such as developing a protocol for the Internet community.
The following synopses summarize the charter and current status of both types of groups and provide the address to use if you wish to join the group's Internet mailing list. Future columns will report SNMP-relevant occurrences in these groups, and also introduce any new groups that may appear.
Request Address: snmp-request@psi.com
Request Address: iwg-request@rice.edu
Request Address: bridge-mib-request@nsl.dec.com
Request Address: char-mib-request@decwrl.dec.com
Request Address: phiv-mib-request@jove.pa.dec.com
Request Address: enet_mib-request@europa.clearpoint.com
Request Address: fddi-mib-request@cs.utk.edu
Request Address: hubmib-request@synoptics.com
Request Address: idpr-wg-request@bbn.com
Request Address: apple-ip-request@apple.com
Request Address: iplpdn-request@nri.reston.va.us
Request Address: isis-request@merit.edu
Request Address: noctools-request@merit.edu
Request Address: ospfigp-request@trantor.umd.edu
Request Address: ietf-ppp-request@ucdavis.edu
Request Address: rmonmib-request@mti.com
Request Address: ietf-rip-request@ftp.com
Request Address: ietf-rreq-request@jessica.stanford.edu
Request Address: snmp-sec-dev-request@tis.com
Request Address: trunk-mib-request@saffron.acc.com
Request Address: x25mib-request@dg-rtp.dg.com
Abstract Syntax Notation One: Tutorial and Reference
Douglas Steedman, Technology Appraisals Ltd., 1991. ISBN 1-871802-06-7
This is the authoritative, readable reference on ASN.1 language, written by one of its designers. Because the Internet-standard SMI is based on ASN.1, this is a good text for readers of management documents.
Integrated Network Management, II
Iyengar Krishnan, Wolfgang Zimmer, ed., North-Holland, 1991. ISBN 0-444-89028-9
This is the proceedings of the IFIP TC 6/WG 6.6 Second International Symposium on Integrated Network Management. It contains many papers regarding the Internet-standard Network Management Framework including:
IEEE Network. ISSN 0890-8044
ConneXions. ISSN 0894-5926
March 16-20, San Diego, CA
For information: +1 703-620-8990
May 18-22, Washington, DC
For information: +1 415-941-3399
July 13-17, Boston, MA
For information: +1 703-620-8990
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.