Section 2.3.2 looked at some of the problems associated with multi-vendor networks. Specifically, it looked at SNMP, and how the standard MIBs do not adequately cater for network technology.
One of the biggest hindrances to MIB-II is the standards process itself. All revisions to the MIB-II RFC require that it follow the full standards, from Internet Draft through to acceptance as an RFC [BCP 9]. This can take a significant amount of time. Further to this, there are usually considerable delays between the publishing of a new standard and vendors implementing it. The result is that it is almost impossible for MIB-II to keep up with the advances in technology. In fact, RFC 1213 has not been updated since November 1996.
For example, MIB-II assumes that all internet traffic is symmetric — that is that the media has the same amount of bandwidth in both directions. As such, it only has one entry per interface in the MIB to record the speed at which the line is running, namely interfaces.ifTable.ifEntry.ifSpeed. This assumption was valid in 1991 when RFC 1213 was written, and in 1996 when it was updated by RFC 2011. Recent developments, such as ADSL and the ITU's v.90 standard for 56K analogue modems, have changed this. Any modern technology that uses asymmetric transfer rates is not catered for by MIB-II. This forces manufacturers to include the extra information in the enterprises section of the MIB, usually in a proprietary way.
These inconsistencies make writing vendor-independent network monitoring software that caters for these new technologies an onerous task. Such software needs to be aware of what OID each vendor uses for particular bits of information. There are two ways of dealing with this: either one hardwires the values into the program (resulting in the support of a limited subset of vendors), or one provides some way for the software to work out what OIDs it should be referring to. Since the first of these approaches is clearly not ideal, these focus will be on the second.
What is needed is a way to consolidate the various vendors' enterprises entries into a single format that is understood by the network monitoring tools.
In its simplest form, such an amalgamation method could be a text-based configuration file that is read by the monitoring software. It would be more useful, however, if this information could be shared between applications. The ability to do this requires a layer of abstraction between the devices being monitored and the network monitoring applications.
There are two ways of achieving this abstraction: by creating a middleware application that translates requests for information from the monitoring software into SNMP requests to the network hardware being monitored, or by creating a method for configuring the monitoring program that is both abstract and flexible enough to be shared between different programs. These two approaches are shown in Figure 3-1, with the middleware approach on the left. Both these approaches use essentially the same idea, the first simply formalises the idea of a middleware layer by making it a separate entity.
The problem with having a separate middleware layer is identical to the one faced by MIB-II. The middleware application would have to keep abreast of advances in technology changes, and vendors would be relying on a third party to do this. In all likelihood, the middleware application would quickly become out of date, leaving users no better off than they currently are.
For this reason, having the abstraction layer embedded within the monitoring application itself seems to be the most feasible approach. The problem then lies in making the abstraction information easily portable between applications. This requires that the format that the abstraction information is stored in be standardised, or at least formalised to some extent.
The eXtensible Markup Language (XML) is a meta language that allows one to define new markup languages [W3C, 2003]. A markup language can be developed using XML that would allow us to pass the consolidation information around in a standardised way. If done correctly, this markup language would enable vendors to rapidly share information about new products.
Work was done on developing a simple proof-of-concept version of such a language. Several Document Type Definitions (DTDs) were developed in an attempt to accurately model both the structure of the network and the various network devices that make up the network. An early example of such a DTD is given in Figure 3-2.
Figure 3-2. Example XML DTD for network monitoring
<?xml version="1.0" standalone="no" ?> <!DOCTYPE monitor [ <!ELEMENT monitor (host+) > <!ELEMENT host (ports?, oids?) > <!ELEMENT ports (port+) > <!ELEMENT port (#PCDATA) > <!ELEMENT oids (oid+) > <!ELEMENT oid (#PCDATA) > <!ATTLIST host name CDATA #REQUIRED > <!ATTLIST host port CDATA 161 > <!ATTLIST host community CDATA public > <!ATTLIST oid name CDATA #REQUIRED > <!ATTLIST oid type (text|gauge|counter) text> <!ATTLIST oid precision (16|32|64) 32 > ]>
This DTD attempts to describe both the layout of a local area network as well as the methods for communicating with each device on the network. In many ways, this DTD is both overly complex and overly simple. It is overly complex because it tries to describe two things at once: a communications protocol and a network layout. As such, it does not differentiate between information specific to the network layout and information specific to a particular class of network devices. For example, all Cisco 2900 switches store their system description in the OID .184.108.40.206.220.127.116.11.0, but not all Cisco 2900 switches have the same hostname. These two different classes of information should be separated, perhaps into two distinct DTDs. This separation was attempted in later revisions of the DTD.
The DTD is overly simple because it does not yet allow for the complete description of all network devices. It is not abstract enough to be able to handle the rapid changes in network technology, nor is it refined enough to be applicable to all existing technologies. As a proof-of-concept, however, it was sufficient to allow some testing to be done. Two network monitoring applications were built upon this DTD in order to determine whether the idea of an abstraction layer at this level was feasible.
The first of these was a monitoring application for the Computer Science Department's remote access subnet, and is described in Section 3.3. The second was an application to do automatic network topology discovery on Rhodes' LAN, and is described in Chapter 4. Both these applications showed that, while using XML to create an abstraction layer was feasible, a lot more work would need to be done on this approach to make it universally applicable.
For an XML-based approach such as this to work, it would need active community support. This means that the DTD would have to be publicly available and open to public discussion. Without such peer review, it would be impossible to develop a model that was generic enough to have wide scale use, since it is impossible for one person to anticipate every possible network layout and configuration.
There may be some merit in reworking this DTD to be an XML schema, since there is a trend towards the use of schemas [W3C, 2000]. This would make the system more universally applicable, since it would be in keeping with an accepted way of doing things. For the purposes of this project, however, the representation as a DTD is sufficient to allow other applications to be built using this concept. This is especially true since the applications developed using this approach use the Expat XML parser, which is a non-validating parser.