The nice thing about standards, so the old joke goes, is that there are so many to choose from. Nowhere is this so true as in the network management field, where a potent mix of de jure and de facto standards combines with a variety of devices that have to be managed. As the great and the good of the network industry surveyed the landscape, it became clear that this was not a mess that would untangle of its own accord. There were no signs, for instance, that the Simple Network Management Protocol, beloved of the Unix world, would wither in the face of Open Systems Interconnection’s Common Management Information Protocol. On the contrary, if anything its popularity increased. For the writers of network management applications, the problem was compounded by a lack of standard hardware on which to write their software. So the networking world made a stab at solving some of these problems as an unprecedented number of standards bodies and industry grouping lent their muscle to Omnipoint 1 (CI No 2,001). Omnipoint 1? Thankfully it is not another standard, but an ambitious project designed to take all of these disparate standards and pull them together into a single framework where they can work together harmoniously.

Dissent

A kind of networking equivalent of IBM’s Systems Application Architecture if you like. The Omnipoint team is at pains to say that its primary aim is not to tell people which protocols they should use to communicate with the network devices. That way lies the kind of dissent that occurred previously when the standards bodies said build CMIP into your bridges and the industry replied no. Instead, Omnipoint has two main aims first, to link network management systems and second, to specify a network management application environment that should allow some degree of portability for developers. Omnipoint 1 is the first fruit of the collaboration and it is a snapshot of existing completed and emerging standards. It is expected that Omnipoint 2, due in about two years, will extend and solidify the work. On linking management system to management system, Omnipoint is based very much on the upper layers of the OSI model, building profiles on top of the CMIP. A profile describes one of the basic building blocks of network management and defines a standard message for functions such as event and alarm management, state management and trouble ticketing. On top of this, there are object management definitions, templates that describe particular managed objects, outline their behaviour and the kind of messages they can send and recieve. If it sounds cumbersome then that’s because it is. However, since it’s a protocol that will be used to link management systems only, this does not matter too much and the benefits should be substantial. One management system will be able to ask another to carry out a test and return the results, or share trouble tickets, event and alarm information. It sounds good, but its not easy and the authors of Omnipoint 1 admit that there are serious problems. The SNMP CMIP work is far from finished. warns an introductory document, continuing, each protocol is based on a different management model and each has a different way of describing managed resources.

By Chris Rose

Seamless transfer of information between the two protocols may never be achievable, but it may be possible to bridge the gap more effectively for suppliers. Not exactly bursting with optimism. One of the differences between CMIP and SNMP is the former’s reliance on intelligent agents which actively send reports to the management station, which then filters the input. SNMP, in contrast, requires the station actively to poll the the two. Bruce Murrill, the Network Management Forum’s technical director, explains that the Omnipointers are exploring a number of approaches. Among these are attempts to build parsers that automatically convert SNMP and CMIP messages. An alternative tack involves building proxy agents that can work in each other’s environment. Already, Omnipoint includes descriptions of various SNMP mana

gement information bases in the object description format required by CMIP, and these will be extended with time. The really tough technical challenge to the Omnipoint partners has been to recognise that OSI management is only one part of the equation, the introductory document admits. On a slightly brighter note, Murrill points out that SNMP itself is currently being revamped and the Omnipoint members will be liaising with SNMP standards-makers to try and ensure that future incompatibilities are minimised. If rationalising the protocols sounds tough, then the attempt to produce a standard environment for application developers is even harder. Not every product that is Omnipoint-compliant will be for end users, Murrill says; what developers need is a standard set of programming interfaces and services to write to. Again this is a ‘when-worlds-collide situation’. The group has decided that the Object Management Forum’s Common Object Request Broker Architecture, provides a suitable basis for building management systems. There is a certain elegance in using object-oriented programming techniques when you are trying to manage network objects, and the modularity makes it pleasingly simple for developers to slot in their own. One problem is that OSI defines its objects in one way, using its Abstract Syntax Notation, and CORBA defines objects in quite another.

Weddings

Despite progress over the last year, Omnipoint warns that there is still work to do before solid advice can be given to suppliers on how to make use of CORBA as a general purpose interface that will fit well with the OSI management model. The result is that CORBA-compliance is not a requirement yet, and instead, Omnipoint incorporates X/Open’s Communications Management Application Programming Interface – but again, compliance is only high recommended – and in the end it is up to the users to decide whether they want a particular feature. Which only leaves the question of implementation. Will anyone use it? With the weight of UK and US Gosip behind it the answer is probably yes – those lucrative government contracts will depend on conformance. Not only that, but the news of Omnipoint was accompanied by a sheaf of well-wishing letters of the kind more normally associated with weddings. First offerings are set for release in 1994 from a number of vendors. The most important absentee is Sun Microsystems Inc, and while SunNet Manager is due to get CMIP/CMIS next year, the company says that it will consider backing Omnipoint at that time. Forum partners include, from the user community, the US government’s National Institute of Standards & Technology, the UK Central Computer & Telecommunications Agency and Network Management Forum User Advisory Council. Industry consortia include Corp for Open Systems; INTAP; Network Management Forum; Object Management Group; Open Software Foundation; SPAG; Unix International Inc; and X/Open Co Ltd. Letters of support came from Telecom Canada; Ascom Timeplex; Unitel Communications Inc; Cable & Wireless Plc; Stet SpA; Siemens Nixdorf Informationssysteme AG; Hewlett-Packard Co; GPT Telecommunications Systems Group; IBM Corp; British Telecommunications Plc; Network Equipment Technologies Inc; and Telefonica de Espana SpA.