Contact us Heritage collections Image license terms
HOME ACL ACD C&A INF CCD Mainframes Super-computers Graphics Networking Bryant Archive Data Literature
Further reading □ OverviewJANETEARNRAL LANNetwork News 25Network News 26Network News 27Network News 28Network News 29Network News 30Network News 32
CISD Archives Contact us Heritage archives Image license terms

Search

   
CCDNetworking
CCDNetworking
ACL ACD C&A INF CCD CISD Archives
Further reading

Overview
JANET
EARN
RAL LAN
Network News 25
Network News 26
Network News 27
Network News 28
Network News 29
Network News 30
Network News 32

Network News 29

July 1989

Produced by the Computer Board And Research Councils' Joint Network Team and Network Executive.

Networkshop 18

Due to clashes with other meetings next year's Networkshop in Newcastle has been moved by a week. The new dates are:

Tuesday 27th March until Thursday 29th March 1990

The format will be similar to Networkshop 17, however the programme has yet to be decided. If there is a networking issue that you would like to see discussed which would be of general interest to those working in the Academic Community, please submit it to the organisers for consideration.

The organisers are:

Alan Hunter at Newcastle, Sue Weston for the JNT

Law Commission Report on Computer Abuse

In August 1988 the Law Commission produced a working paper which examined a range of activities which it considered might represent computer misuse, and considered the extent to which the existing criminal law applied to such activities.

The working paper reached a provisional conclusion that there is no compelling case for the introduction of wholesale revisions to the law in order to deal with the misuse of computer systems, and that most types of criminal activity involving the misuse of computer systems were already covered by existing legislation. The working paper invited comments from the public.

In response to this invitation, it was suggested by the Network Advisory Committee that comments should be invited from the academic community, and I undertook to consolidate these comments into a reasoned submission. An e-mail discussion group was established and a number of those interested contributed between October 1988 and February 1989. Most of those participating were members of University, Polytechnic or Research Council computer centres, but there were queries or contributions from administrators and even the occasional real user.

The discussion was wide spread, but by the end it seemed that four major points had emerged, and these formed the main thrust of the feedback to the Law Commission. Very briefly, the points made were:

  1. The original report referred to access without being specific about the meaning of the word. The submission attempted to clarify the distinction between access as make contact with and as make use of. It then went on to propose that access as make contact with should not, of itself, be an offence, but that unauthorised access as make use of should give rise to a presumption that an offence might have been committed.
  2. The original report placed emphasis on the damage that misuse might cause to a computer. The submission emphasised that in general such damage would be minimal, and that the real risks lay in consequential damage if the data or program within the system were to be corrupted either inadvertently or deliberately. The loss caused to the person running the computer system if it became necessary to reinstate data was also pointed out.
  3. The original report proposed a clarification of the existing law, by making an explicit statement that deception can include deception by a machine. In general deception is not, of itself, an offence, but for example stealing by deception is. The submission suggested that an equivalent clarification of deception of a machine in order to gain an advantage, should be made.
  4. A point not actually dealt with by the original report was the notion that a fraud can be committed by the offering of a user identity and password by someone other than the owner of the user identity. The submission urged that this was not an acceptable situation and that the law should be made unambiguous on this point.

As a final point, the Law Commission had invited opinion on the question as to whether there should be a new offence, of misusing a computer. The report offered four provisional versions of such legislation, and asked for advice as to the most suitable. No clear consensus emerged, although there was marginal support for the notion that the mere act of obtaining unauthorised access (used in the sense of make use of) should be seen as an offence.

The full text of the submission to the Law Commission can be obtained from the JNT Administrative Officer.

I am grateful to my colleagues who helped in the discussions.

Mike Wells University of Leeds

New Performance Upgrade Initiative

Introduction

A major new initiative to upgrade the performance of the network infrastructure at both the WAN and LAN levels has been launched following the Computer Board Policy Review in March. The initiative is divided into three complementary parts which have been named JANET MK II, High Performance Backbone LAN Initiative and Super JANET. Funding for the first two has been approved by the Computer Board, funding for Super JANET is the subject of a 1989 PES bid for additional funding. This article is intended to give a brief summary; detailed plans have still to be developed and more information will be available as these plans mature.

JANET MK II

The strategy for upgrading the wide-area network has two components. JANET MK II provides an immediate upgrade path but the performance achieved is not expected to meet the requirements of the community for more than a few years at most- The strategic objective is Super JANET which is intended to provide much higher performance and support a wider range of applications.

JANET currently offers a 64Kbps X.25 service to a large number of user sites and a 9.6Kbps service to the remainder. There is growing demand from several quarters for improved performance, both to support specific requirements and to provide a general level of performance which is commensurate with the growth in the use of IT within the community. The principal bottlenecks are caused by the limitations in access line bandwidth, particularly for the larger sites, and in the bandwidth of the links used to connect the national centres. However, any widespread programme to remove these bottlenecks would result in the trunk network becoming the principal performance constraint and the upgrade programme must therefore address all parts of the network. JANET MK II is aimed at creating a network with 2Mbps access and commensurate performance in the trunk network. The upgrade will commence in FY89-90.

The aim is to provide a 2Mbps network to a major part of the community over a five year period. An installation rate of about seven to ten 2Mbps access and trunk line circuits per year is planned. The new circuits will replace existing kilostream circuits and this will provide some cost savings. The provision of upgraded access lines will be targeted on the sites where upgraded performance is most needed. Interim arrangements will be made where possible for sites requiring upgraded performance earlier than the availability of the full 2Mbps X.25 service.

A major upgrade of the JANET X.25 packet switching exchanges is proposed over a three year period. Improved performance exchanges will be required to handle the increased traffic from the upgraded lines, but the opportunity will also be taken to change to more modern technology which will provide improved reliability. The programme also covers the provision of management tools to handle fault monitoring and diagnosis on 2Mbps lines,

Some enhancement of the campus X.25 facilities will be required and this will be funded from the ongoing site network installation programme.

High Performance Backbone LAN Initiative

The Computer Board has approved funding to support a pump priming initiative aimed at providing an initial lOOMbps-t- backbone LAN on each university campus over the next five years. This is similar in concept to two previous LAN initiatives funded by the Board where the Board provided the stimulus for the development of site X.25 and lOMbps LANs in the universities.

The new initiative will be focused on interconnecting existing 10Mps LANs to the backbone, interconnecting the backbone to an upgraded JANET and providing management tools to support the new LAN. A development programme will support studies, pilot projects, some product development and, above all, will ensure that the backbone can be fully exploited with suitable applications. Although most of the access to the backbone is expected to be via 10Mbps feeder LANs, the programme will also cover the interfacing of some services directly to the backbone where appropriate. As with past initiatives, it is assumed that the fibre optic cabling will be covered by university/UFC funds.

It should be noted that the standards for high performance LANs are still in a state of flux. FDDI I currently offers the most stable and mature choice but significantly improved technologies such as FDDI II and DQDB are in the standards pipeline. It is likely that FDDI I will play a significant part in the initiative but it will be necessary to monitor closely the evolution of the other options and be prepared to include them in the programme if they achieve wide support from product suppliers within the required time frame.

Super JANET

Over the next few years a high performance wide-area backbone wilt be required to complement the availability of high performance site LANs and the increasing use of supercomputers and sophisticated workstations. Several other countries, notably Germany and the US, have already launched ambitious projects to develop wide-area backbones based on optical fibres offering bandwidths in the 140Mbs region or greater. It is proposed to launch a similar initiative for the UK academic community with the objective of providing 140Mbs access to all universities and the major Research Council laboratories within a five year time frame.

The funding requirement cannot be estimated with any accuracy until an analysis of the technical options has been undertaken and the scope of the project could be adapted to fit the level of funding available although this could result, for example, in a reduction in the number of sites directly served by the backbone. An early provision of very high bandwidth links to the major sites in the community could obviate the need to install additional 2Mbps circuits in the short term as part of the JANET MK II upgrade programme. Furthermore, the availability of the additional

bandwidth at an early stage in parts of the community would provide considerable flexibility in meeting new and demanding requirements and would complement other initiatives such as the proposed initiative on visualisation and the supercomputer initiative. A wide-area fibre backbone will provide a major asset for the community for the next decade and would represent a good capital investment.

The objective would be to create a single I40Mbps-f-network interconnecting the backbone LANs on each site. The technology to achieve this objective is not yet available in mature product form, indeed it is not yet clear which technology would be the most appropriate. An interim alternative would be to extend the JANET MK II concept to higher speeds by multiplexing the 140Mbps bandwidth to provide discrete subchannels which could be configured to support a range of requirements.

A bid for funding to support this project has been submitted to the DES as part of a much larger initiative to support widespread use of IT in the universities.

Bob Cooper Director of Networking

NRS Campus Servers

In the community's planned transition to OSI, a key component is the ability to use the NRS to alleviate the necessity of users having to be aware of every system's transition, by using unchanging names to hide the inevitable addressing changes. This does require that all systems update their NRS information daily, to avoid longer service interruptions when transitions occur.

To enable up-to-date NRS information to propagate quickly it is planned to provide each University Computing Service with the necessary hardware and software for an NRS Campus Server. In July 1988 the Computer Board agreed to fund the first phase of the development of the NRS Campus Server software. This software is now ready for beta test, and was successfully demonstrated to the community at Networkshop in April. The NRS Campus Server will act both as a distribution point receiving incremental updates daily from the central NRS service and propagating these to local end-systems, and as a responder for the NRS Lookup Protocol which can be used by diskless systems (e.g. PADs, gateways) and by small systems to save the necessity of them storing NRS information. It will also store and disseminate addressing information of purely local significance.

The next phase is to provide a suitable hardware base at each University to enable the NRS Campus Server software to be brought into service. As well as providing an enabling mechanism for tie OSI Transition, this will bring immediate benefit to users as it will enable full use to be made of equipment currently capable of using the NLP to resolve name to address translations. In particular, users of Netcomm PADs, Spider Ether/X.25 gates and the Rainbow package for PCs will see an immediate enhancement to their service.

The Computer Board has approved funding to provide a NRS Campus Server for each University Computing Service. It is planned to make a bulk purchase of hardware for this provision and the JNT recently issued an Invitation to Tender for the supply of a suitable computer system. The IBM 6151 has been selected and delivery of these systems is expected to commence in October.

Any other site in the academic community wishing to purchase hardware for an NRS Campus Server as part of the JNT order should contact J.Dyer@UK.AC.RUTHERFORD.

Jim Craigie Joint Network Team

Co-ordinating Committee for Intercontinental Research Networking

The Co-ordinating Committee for Intercontinental Research Networking (CCIRN) had its first meeting in Washington D.C. in November of 1987. For the lack of any other name and until May of 1988 the committee was known as the Necessary Ad Hoc Coordinating Committee. The purpose of the CCIRN is to help coordinate intercontinental networking for the research community.

The committee's aims are to:

Membership in the CCIRN is currently by organisations with an active interest in developing a continental network with the aims described above. Currently the CCIRN has representation from Europe, Canada, and the United States with plans to expand at a slow controlled pace. The next most likely countries to join the CCIRN will be Japan and Australia in the autumn of 1989.

At the last meeting of the CCIRN it was agreed to endorse the Ethics statement on the facing page. All networks supporting research workers are encouraged to adopt this statement.

Shirley Wood, Network Execute

Networking Ethics CCIRN - April 1989

Status of this Memo

This memo is a recommendation of policy by the Co-ordination Committee for Intercontinental Research Networking (CCIRN) concerning the proper use of resources in research networks (referred to as the networks'}.

At great human and economic cost, resources drawn from government, industry and the academic community have been assembled into a global collection of interconnected networks. The networks have become an important international infrastructure supporting an increasingly widespread, multi-disciplinary community of researchers ranging, inter alia, from computer scientists and electrical engineers to mathematicians, physicists, medical researchers, chemists, astronomers and space scientists.

As is true of other common infrastructures (eg roads, water reservoirs and delivery systems, and the power generation and distribution network), there is widespread dependence on the networks by users for the support of day-to-day research activities.

The reliable operation of the networks and the responsible use of their resources is of common interest and concern for their users, operators and sponsors. Recent events involving the hosts on the networks underscore the need to reiterate the professional responsibility every user bears to colleagues and to the sponsors of the system. Many of the resources are provided by government; abuse of the system thus becomes a legal matter above and beyond simple professional ethics.

Statement of Policy

The networks form an international facility whose utility is largely a consequence of its wide availability and accessibility. Irresponsible use of this critical resource poses an enormous threat to its continued availability to the technical community.

The governments sponsoring these systems have a responsibility to the public to allocate government resources wisely and effectively. Justification for the support of these systems suffers when highly disruptive abuses occur. Access lo and use of the networks is a privilege and should be treated as such by all users of these systems.

The CCIRN strongly endorses the following as unethical and unacceptable.

Any activity which purposely:

  1. seeks to gain unauthorized access to the resources of the networks
  2. disrupts the intended use of the networks,
  3. wastes resources (people, capacity, computer) through such actions,
  4. destroys the integrity of computer-based information, and/or
  5. compromises the privacy of users.

The networks exist in the general research milieu. Portions of them continue to be used to support research and experimentation on networking. Because experimentation on the networks has the potential to affect all of their components and users, researchers have the responsibility to exercise great caution in the conduct of their work. Negligence in the conduct of such experiments is both irresponsible and unacceptable.

The CCIRN plans to initiate whatever actions it can, through the appropriate agencies and other interested parties, to identify and to have set up technical and procedural mechanisms to make the networks more resistant to disruption. Such security, however, may be extremely expensive and may be counterproductive if it inhibits the free flow of information which makes the networks so valuable. In the final analysis, the health and well-being of the networks is the responsibility of its users who must, uniformly, guard against abuses which disrupt the system and threaten its long-term viability.

Acknowledgement

This statement was developed from one prepared by the Internet Activities Board which in turn followed from work undertaken by the Division Advisory Panel of the National Science Foundation Division of Networking and Communications Research and Infrastructure.

Directory Service Pilot Project

Brief Overview of the International Directory Standards

The joint ISO/IEC 9594 and CCITT X.500 Directory Standards (which were ratified late last year) model the user interacting with the Directory through a Directory User Agent (DUA). The DUA communicates with the Directory by means of an OSI protocol, the Directory Access Protocol (DAP). In this conceptual model the Directory is a single entity containing all the information its users might ever require. Clearly it is not feasible to implement the entire global Directory in one single centralised system. Therefore the conceptual Directory model is refined, giving a Directory Service which is provided by the co-operative efforts of many Directory Service Agents (DSAs). DSAs communicate through another OSI protocol called the Directory System Protocol (DSP).

There are two methods of communication between the Directory components which can be used when a DSA receives a query which is outside the scope of its local information: chaining and referral. Chaining is when the queried DSA takes a proactive role by itself establishing a connection to another DSA to which it passes the query. Referral is when the queried DSA simply returns an immediate response indicating another DSA which the originator of the query might try.

The information held in the Directory consists of Entries. Each entry consists of a set of Attributes. Attributes comprise an Attribute type and one or more Attribute Values. Attributes may consist of one value which is guaranteed unique among its peers, called the Distinguished Value, and other values which have no uniqueness requirements.

The information in the Directory is structured into a hierarchical tree. The Directory Standards do not constrain the types of attributes which can be used to define the structure of the tree. They do however give examples of a structure which may be appropriate.

An Attribute which is used to name the nodes under some other node in the tree must have a Distinguished Value, called the Relative Distinguished Name (RDN), which uniquely identifies that node relative to its parent node. The Distinguished Name of a node is the concatenation of the RDNs of each node in the ancestral hierarchy from the root of the tree to the node in question.

Objectives of the Pilot Project

Uses of the Directory

The principal aim of the Academic Community Directory Service Pilot Project is to provide information about humans, and in particular information for other humans on how to establish communication. The initial user requirement came from the difficulty in determining electronic mail addresses. However, the advent of sophisticated telephone systems with direct dial in to the office phone has introduced a new requirement. While most organisations have an internal paper telephone directory, finding a direct dial phone number in another organisation is very difficult. This information is currently seldom published.

In addition to electronic mail address and telephone number, the pilot directory will include Room Number, Postal Address, and Fax and Telex numbers.

Use of the Directory to provide a system directory service - the mapping from Application-Entity-Title to Presentation Address - will only be of secondary importance initially in the UK Academic Community as this functionality is already provided by the Name Registration Scheme (NRS). This was initially developed to provide both name to address mappings and incoming call source validation services. It has since been enhanced to provide sub-network addressing information and validation - mapping Network Service Access Point (NSAP) address to Sub-Network Point of Attachment (SNPA), The NRS also provides an essential tool in managing the transition from Coloured Books to OSI protocols by providing unchanging naming of systems thus hiding protocol transitions from users and by manipulating addressing information so that protocol converters can be used to make all Coloured Book services appear to be equivalent OSI services and vice versa.

Potential uses of the Directory to contain Message Handling Service (ISO/IEC I0021/X.400(88) routing information and Distribution List membership are likely to be realised in the foreseeable future.

Heterogeneity

The second major objective of the pilot project is to demonstrate interworking of heterogeneous implementations of OSI protocols. An OSI pilot which involved only multiple incarnations of one single implementation would fail to demonstrate the most insignificant benefit - interworking of heterogeneous systems.

The directory pilot intends to use two implementations - QUIPU and THORN - which were originally developed as parts of two separate ESPRIT projects. QUIPU was developed by University College London as part of the INCA project and has been incorporated into the publicly available ISODE package. The first full X.500 QUIPU release happened in April 1989. THORN was developed by a European consortium consisting of a mixture of commercial and academic organisations. THORN originally implemented the ECMA TR32 Directory Protocol and has a planned X.500 migration which is not yet available. Another X.500 implementation is being developed by the University of British Columbia, Canada, which might provide a third option although little detail is currently known about this.

Directory Standards Demonstration and Testbed.

Two further objectives are to demonstrate the viability of the current (88) Directory Standards and to discover shortcomings in time to have these rectified in the 1992 revision.

There are some facilities which were known to be required but were omitted from the 88 version because of insufficient time (eg Access Control, Replication, Knowledge management and distribution). Both QUIPU and THORN have (different) temporary implementation specific solutions to provide Access Control and Knowledge Management facilities as no implementation is viable without these, but these ad hoc solutions will be replaced when these aspects are defined in the standards. However, it is felt that user experience with implementations of the current standards may reveal other deficiencies and desirable extensions, and that pilot use now is necessary to ensure that these expected requirements are discovered in time for solutions to be included in the 1992 version of the Directory Standards.

Replication is seen as a vital long-term requirement to allow DSAs to hold shadow copies of frequently used information where the master copy is held elsewhere, but not absolutely essential in the short-term pilot phase. A replication facility already exists in the NRS and would be needed in the Directory standards before they could replace that part of the NRS functionality.

Principal Problem

The principal problem envisaged is the acquisition and maintenance of the data. While initial enthusiasm may be sufficient to get data loaded into a new DSA, unless adequate maintenance mechanisms are defined and incorporated into routine procedures continued accuracy of the data is highly unlikely. Therefore it is imperative that Directory maintenance tasks are assigned, probably to those whose job is to maintain that part of the data, and that individuals responsible are aware of the benefits achieved from the maintenance of Directory data.

One difficulty is that the data is usually currently held by several disparate sources: there is one administrative department holding basic staff records; another maintaining student records; telephone number records are often the responsibility of the telephone operators; room allocation responsibility and records are frequently devolved to departmental level; and electronic mail addresses are often administered by the relevant computer system administrator (some users will use University Computer Service electronic mail facilities while others will use departmentally administered systems). Maintenance of the Directory thus requires the co-operation of several parts of the University Administration, each of which needs sufficient motivation to ensure that Directory maintenance is

regarded as an integral part of the relevant data maintenance task for which it is responsible.

Another impediment to Directory maintenance is that universities usually have Administrative Computing Departments which are totally separate from the Academic Computing Service. Frequently the Administrative computers are not even networked.

An unexpected problem is that there are a few Universities which have not yet computerised their staff records. The discovery of continued use of manual card records in 1989 was most surprising!

User Interfaces

QUIPU and THORN each have several DUA implementations giving a variety of differing user interfaces. However, all these interfaces are aimed at the computer literate familiar with the Directory standards. User requirements have been identified for better fuzzy matching techniques, and for a user interface suitable for non-specialist users. A project is just starting which aims to design and implement a user interface targeted at users who are not familiar with the structure and terminology of the Directory. The design goal is to produce an interface capable of implementation on a variety of WIMP environments (eg X Windows, Microsoft windows, Macintosh) which will as far as possible follow the look and feel appropriate to each environment whilst remaining recognisably the same interface in all cases.

Knowledge Management

Knowledge is the glue which keeps the disparate DSAs glued together into a coherent directory. It is the information which indicates to DSAs where information on other parts of the Directory Tree is likely to be found. This is an area where there will be some early experimentation. It is anticipated that the knowledge will be arranged so that a query within the academic community can be answered by accessing not more than two DSAs.

Naming of Organisations

The principal aim of naming should be user friendliness. However, there are two incompatible views of user friendly names: self descriptive names; and short, easy to type names. Fortunately, the Directory offers the potential to satisfy both requirements.

Directory entries consist of attributes which can be multi-valued. Only one of the set of names can be used as (possibly part of) an entry's distinguished name. However, when searching for an entry, the name being queried is compared with the whole set of names.

It is therefore proposed that the Academic Community institutions should use several values of their organisation name attribute. The Distinguished Name should follow the Directory principles of being Intelligible and Easy to Guess, and should be chosen with national uniqueness in mind despite the current lack of a UK Registration Authority.

The following examples illustrate potential values of the Distinguished Name and other values:

Distinguished: University of Aberdeen, Aberdeen University, Aberdeen, Abdn

Distinguished Rutherford Appleton Laboratory, Rutherford, RAL, RL

Distinguished University of Manchester, Manchester University, The Victoria University of Manchester, Manchester, Man, Owens, Mcr

Pilot Directory Services

The establishment of initial services using QUIPU has been inhibited by the lack of suitable hardware platforms in University Computing Services. Some experimental use has been made by Computer Science Departments, notably at UCL, Nottingham, Brunei and Surrey; however these are experiments with very limited data.

To establish a viable pilot directory service some provision of suitable hardware is required. The aim of the pilot project is much more than simply beta testing the two Directory Service implementations, although this is a component. Much more significant will be the exploration of the necessary co-operative arrangements for data gathering and maintenance. Given these two aspects, a pilot project involving between 6 and 12 sites seemed appropriate.

Last September the JNT invited all Computer Centre Directors and Registrars to nominate participants to a discussion group, which would be discussing the problems of establishing Directory Services in the Academic Community. The pilot project was discussed in the group and Computing Service members were invited to submit proposals for participation in the Directory Pilot. Twelve proposals were received, all of a high standard, from Bath, Birmingham, Bloomsbury, Brunel, Cambridge, Edinburgh, Heriot-Watt, Nottingham, Reading, Rutherford, Strathclyde and Surrey. Funding has been approved to provide a computer system at each of these sites to mount a pilot Directory Service. The SUN SPARCstation 330 has been selected as a suitable hardware base and it is expected that the delivery of these system will commence in August. Complementary work is in hand to encourage the development of user friendly Directory User Agents and to link the Pilot to pilot projects, particularly a European Directory Pilot being promoted by RARE.

Jim Craigie, Joint Network Team.

Networkshop 17

Earlier this year, Warwick University was host to Networkshop 17. The major themes of the formal presentations were; High Speed Networking, Electronic Mail, Workstations, Network Management, Full Screen Services and International Networking. Of these topics three were chosen for discussion in greater depth by three parallel groups. The major points of discussion were summarised by a rapporteur for each group and presented to the full Networkshop on the last day. So as to bring the conclusions of the groups to as wide an audience as possible, the rapporteurs were asked to provide written summaries for publication in the Networkshop proceedings. As in previous years, they are also being published in Network News.

My thanks to all those that contributed.

John Dyer, Joint Network Team

Discussion Group Report - Workstations

Chairman - Willie Black (Joint Network Team) Rapporteur - Annette Hawarth (University of Reading)

This was a very well attended session.

What is a Workstation?

The Chairman opened by asking whether Macintoshes should be included in the scope of discussion. Many assented to this, but warned that if Macintoshes were considered Appletalk should be avoided - a lot of Macintoshes were moving to Ethernet now and Appletalk was slow as well as being deeply embedded in the system. Implementations, such as a directory user agent, could be ported to Macintoshes - there are tools for porting from OS/2 - but it remained difficult to port at the low level.

There was some feeling that VAXstations should also be encompassed. However, there was a worry that we were trying to overstretch ourselves by having too many machine types to port to. Macintoshes and VAXstations were dropped from the rest of the discussion.

Project for mail and priorities

The Chairman spoke of a project to design a mail user agent which could encapsulate X.400 (MOTIS) and then put the design out to sites to produce high quality products. The meeting felt that mail for DOS users was important. The Chairman pointed out that Grey Book mail for DOS users had been rejected at Networkshop two years previously and the JNT believed that it was too late to revive this idea.

The Chairman attempted several times to get the meeting to vote on priorities for projects on:

The meeting consistently refused to vote since the weight to be given to an item very much depended on the context- For example, many of the facilities were already available, albeit through non-OSI protocols, and the important thing was to plug the gaps. The gap which most needed filling was mail for wide area access.

There was discussion on how you tell which is the most important item and in particular the meeting agreed that no project should be started until there was a thorough knowledge of what was happening, and what was likely to happen, commercially. For example, there were already commercial equivalents of mail agents. There was a basic feeling that inside a cluster the use of non-proprietary solutions should be desirable rather than mandatory. Some of the mail aspects and lower level interfaces for PCs would be discussed at the PC-Comms meeting the following week.

There was similar discussion on UNIX systems, and the possibility of using ISODE, and whether suppliers were already implementing. An action was put on the Chairman to ascertain from Jim Craigie exactly what was being made available commercially.

Two rather opposing points were made. One, that a standard user interface was required across all systems. Two, that an interface compliant with that on the USER workstation was required. For example, a wordprocessing package interface to mail.

There was then a circular discussion on whether it was preferable to have an X-windows interface on your workstation to a main machine dealing with mail or to have all mail based on your workstation. Eventually there were two main conclusions: one, that the user wants the interface to be seamless, and does not care where the work is actually done; two, that costs will often dictate the chosen solution in a given situation.

Getting back to mail, the worry was raised that P7 would not be finalised until 1992 - and let's face it, how long are DOS PCs going to be around? It was reiterated that proprietary solutions were already available and any action by the community might in any case be overtaken by commercial products.

RPC

The Chairman raised the subject of RPC. There was some confusion over whether the RPC being discussed as a standard (not yet ratified) was the same as SUN's. The point was made that RPC was in a different category from the other functions under discussion, being an implementor/s tool, and lots of other things were needed on top to make it useful.

FTAM

The Chairman pointed out that there would not be room for FTAM under DOS. How much would an additional board for a PC to provide FTAM cost? There was a general feeling it would have more powerful processor on it than the PC itself.

Conclusion

The Chairman concluded that X.400 mail should be pursued, portability being the important thing so that when DOS machines drop out we still have something.

Discussion Group Report - Network Management

Chairman - Les Clyne (Joint Network Team) Rapporteur - Phil Harrison (University of Nottingham)

Two papers were given out at Networkshop 17 which were relevant to this discussion, namely:

Network Management Tools by Les Clyne, a partial survey of management tools currently in use at various sites,

A Review of OSI Management Standards by Tony Jeffree, DTI.

The discussion covered the emerging OSI standards and the existing management products in use.

The question of timescales was raised to determine for how long interim management solutions would be required.

The OSI standards bodies participants present thought that implementation of the OSI management protocols was imminent. The Common Management Information Protocol (CMIP) was being used as a basis for management protocols by several large suppliers including IBM and DEC.

A straw poll of those manufacturers present whose equipment is in widespread use within the community suggested that the appearance of OSI protocols might take some considerable time. Most of the available management systems currently in use appear to rely on X29 as the universal communications protocol and carry proprietary information formats.

More user input was required to the standards bodies to define the management objects to be manipulated by the protocols. It was stated that the DTI are sponsoring the promotion of OSI network management. There was concern that as users we are not tracking the standards adequately and as network managers with considerable experience we are not involved enough in the standardisation process. It was felt strongly that a user forum should be set up for dissemination of standards information and discussion of the OSI management protocols.

There was some concern that the OSI standards would require the full ISO stack for operation, whereas the equipment being managed would be unlikely to be able to support this. It was pointed out that the CMIP information could be carried in any suitable way using whatever partial protocol stacks were available for communication purposes. The important point is the standard information format, not how it is communicated. It was thought that all major manufacturers were working on implementations of CMIP based on a set of standard management objects plus extra objects to give each manufacturer its particular competitive edge.

It was suggested that CMIP might be used between different manufacturers' management domains and that proprietary protocols could be used within the domains. Thus a central OSI based management system would be able to extract management information from the proprietary systems using CMIP This raised the spectre of having one management system per vendor on site and it was felt that the aim should be rather to have one, or at most two, management systems on a site for all the different vendors' equipment. Currently X.25 and CSMA/CD seem to have different management products available, hence the need for two management systems on a site.

Concern was expressed that using the same network to carry the management information as the one being managed might lead to difficulties when the network failed since the management information would be unable to be communicated.

The discussion moved on to existing product for management. A quickly drawn up summary table of perceived requirements and availability of functions supporting these requirements in existing tools was displayed. The requirements suggested included Faults, Configuration, Security, Performance Monitoring, Accounting, Link-level Statistics, use of OSI CMIP, and Information Provision. The question of what other requirements were thought necessary was answered by a suggestion that since the table included what had already been provided by a number of manufacturers and site managers that the headings represented a good picture of the total requirement.

The comment was made that good management is expensive, requiring systems costing around £50k. This comment was echoed by the opposite viewpoint that £50k is cheap if the network being managed costs around £500k. It was suggested that it is the presentation facilities provided in a management system that will push up the price, rather than whether it uses OSI protocols or not.

An investment of 10% of the capital cost in management equipment was thought by some to be quite low. It was pointed out that some U.S. network installers regard an investment of around 40% of the capital cost as essential for network management equipment. The comment was made that most commercial networks must have good network management since the company may not survive financially if the network is unreliable. It was felt that such levels of management were not necessarily justified within the academic community.

A complaint was made that money was not earmarked for network management in network installation guidelines. It was felt that the OR proforma for communications requirements should be updated now that it is possible to specify some management standards.

It was thought essential to define the network management strategy before procurement of network equipment, and the availability of support for the strategy should be used in evaluating tenders received. The academic community has significant purchasing clout and it was felt this was not being properly harnessed to ensure the supply of better management facilities.

Conclusions

Money should be made available for procurement of network management systems and earmarked for that specific use.

The DTI should be approached with a view to setting up a user forum to help in tracking the standards and to provide a means of inputting comment based on a wide experience of networking in the academic community.

A group should be set up within the academic community to discuss and advise on network management. A mailing list,

NETMAN@UK.AC.RUTHERFORD

has been set up as the first step in this direction. To join the list send a message to

NETMAN-REQUEST@UK.AC.RUTHERFORD.

Procurement pressure should be applied more effectively to promote better network management in suppliers equipment.

It is worth earmarking a significant percentage of the capital cost of a network for network management functions.

The discussion should continue. All interested parties should join the mailing list that has been set up.

More information is still required about interim network management tools in use at sites. Send any details to Les Clyne, (JNT-B@UK.AC.RUTHERFORD).

Discussion Group Report - Practical Mail

Chairman - Jim Craigie (Joint Network Team) Rapporteur ~ Piete Brooks (University of Cambridge)

Authorisation + Cost

We were told that in principle, all volume tariffs will be passed on to the user, but for economic reasons, small bills may be waived. As such, sites should not imply from the lack of a bill for mail to a site that a route is free- Information on the Maximum volume tariff for a route will be made available, but it is hoped that it will normally be possible to find a cheaper route. As an example, with X.400 the quoted charge will be for routing via ADMDs, whereas it is likely that for high volume routes we will install private links. Within this framework, the cost of various routes may he averaged out.

There are no long term plans for the gateways to perform user authorisation, even though they are the machines with the most relevant information available. All sites will have to restrict access to the gateways by users for whom they are unwilling to pay charges, by whatever route they may attempt to use. There was no guarantee to provide a list of all the tariff routes.

Some concern was raised about who will pick up the bills for public DLs.

Part-time User Agents

There are no plans to provide part-time user agents for PCs etc until the P7 code is available. Some amusing alternatives were proposed.

Connections to Proprietary systems

One site is experiencing problems with LAN connections to VMS machines, but a number of sites found no such problems. More discussing was left until the bar.

Telecom Gold needs every X.400 user to be registered in the MailBridge, but this is soon to be replaced by Mail 400, so things should improve. There were further amusing suggestions on how to bypass the current problems, one of which involved various X.400 telex converters ...

A single unified international gateway

At one of the talks, the suggestion had been made that as the NRS partial domain tables only contained gateways which would guarantee to relay mail to EVERY site in the relevant domain, even if it contains non-communicating networks, it would be preferable for a single site to know the correct route for each host in these problem domains, rather than every JANET mail system needing to know. It was observed that all the gateways were in the process of migrating, and it might be that in the not too distant future that they would all be connected to the same X.25 switch and that many of them may be running identical code. However, it was thought a bad idea to announce a single gateway, as all sites would send all international mail through it. There was discussion of a list for day-to-day mail administrators who have had their knuckles wrapped when they use mailgroup for this purpose.

With the move of the US side of the trans-Atlantic link, there was a hope that we may be able to obtain a better link to the InterBit cluster, thus making mail to BITNET via UK.AC.NSFNET-RELAY more reliable.

The quality of some of the error messages returned by the gateways was criticized, as mere mortals were often unable to interpret them.

Continuing from the discussion on NRS partial domains, it was stated that the NRS is the registration body for the union of those domains which use the coloured book protocols and the UK.AC for ISO.

X.400 Mail User Interface (MUI)

Continuing from the JNT's support for a single MUI (EMAS), for ISO 10021 they will be concentrating all their effort on a single WIMP interface. The user comments were that even in a few years time they were expecting some users to be stuck with dumb VDUs and that they were keen to have an interface which integrated with their local system.

Access to US Internet via ULCC Gateway

The new 56Kbps transatlantic satellite link between JANET and the US Internet came into service at the end of April. Users should now be using the service name UK.AC.NSFNET-RELAY to access the gateway.

The satellite link is due to be replaced by a TATS link in September and the MicroVAX used to run the gateway at ULCC is being replaced by a SUN system in July thus improving the performance for users.

We would encourage those users who currently send mail to Internet sites via EARN to switch to using this route, wherever possible. We believe that the link between ULCC and the USA will provide a quicker and more reliable link to the Internet sites.

Shirley Wood Network Executive

EARN Gateway

The EARN service has improved considerably as a result of the problem which limited the bandwidth on the CERN/Montpellier line being overcome. The new 64kbps HEP link to CERN is now available and the EARN service uses a 9.6 kbps channel on this link in place of the dedicated analogue link. A new version of RSCS has been introduced and this has made it possible to run multiple streams on the same physical link, which should enable more efficient use of the link.

The name UK.AC.RL.EARN was removed from the NRS tables at the end of 1988. It is apparent that users are still using this old name, therefore would sites please check their tables and ensure that their users are aware that they should be using UK.AC.EARN-RELA Y to access the EARN Gateway.

Shirley Wood Network Executive

Addendum to Networking over Asynchronous Lines

An addendum to the Yellow Book Networking over Asynchronous Lines has been produced. The document describes two amendments. The first amendment has been introduced to overcome deficiencies of an existing implementation. The second removes an unnecessary difference between ATS and X.25(80). Copies of the addendum are available from the JNT Administrative Officer

JNT Admin Officer@UK.AC.RUTHERFORD

Sue Weston Joint Network Team

JANET Networked Information Services Project

Status Report

NISP is the JANET Networked Information Services Project, which is funded by the JNT; it aims to develop tools to enable good group communication and information dissemination over JANET amongst academics of all disciplines.

Ron Chennells, formerly of the Computing Service of the University of Dundee, was appointed as the Research Associate to work on the project as from January 1st this year. A small advisory group for the project, NISP-AG, consists of local members of NISP, IUNC, IUSC and the Directory Services Project. It has recently been expanded to include a representative of NISS (National Information on Software and Services), of JUGL (the JANET User Group for Libraries) and of the JNT.

Initial Study - Part 1: Survey of existing facilities

A questionnaire on Network User Support was sent out in January to all the major national and international networks, including JANET. Many of the mature networks have a great deal of experience in the provision of on-line information services to a large user community, therefore a survey of the major types of service currently available should provide a very useful starting point when discussing the functionality needed for the JANET Networked Information Services.

The majority of the networks completed and returned the questionnaire. A full report on the survey will be published shortly.

Initial Study - Part 2: Assessment of Users' Needs

An initial assessment of the requirements of JANET users as regards information services is being undertaken by means of interviews with a small number of individual users from different disciplines, plus direct consultation with the representatives of some of the groups using JANET. The purpose of this study is two-fold: to give NISP an insight into the requirements of JANET users and user-groups for information sharing and to raise the awareness of NISP. A short report on this assessment will be published shortly.

Stage 2: Functional Specification of Service and Pilot System

Stage 2 will be specified in detail once the Initial Study is complete. The intention is to produce a functional specification of the service and to develop a pilot system. It is envisaged that such a system would enable a Special Interest Group to mount their own Information Server and make it available across JANET to other members of their group. There will be early access to a prototype system to allow feedback from the academic community; as a result of this the functional specification will be refined and the prototype improved.

Consultation with the academic community forms an important part of both stages of this project. There will be ample opportunity for all groups and all users to input ideas and to provide feedback on the project. With this in mind, a national mailing list has been set up to discuss the project. To join the list simply send a mail message to:

LISTRAL@UK.ACRUTHERFORD.IBM-B

with the following command in the text of the message:

SUB NISP *lt;my full name>

Example:

SUB NISP Jill Foster

An archive of past messages will be kept, and there is the ability to make relevant files (for example reports) available too. To query what files (if any are stored send the command:

INDEX NISP

as the text of a message to:

LISTRAL@UK.AC.RUTHERFORD.IBM-B

The report on the Survey of Network User Support on National and International Networks will be available from LISTRAL in the near future. Although this survey was not intended to be an exhaustive survey of the services available, it is nonetheless a useful source document. A limited number of printed copies will be available shortly from the JNT Administrative Officer.

JNT Admin Officer@UK.AC.RUTHERFORD

Future progress reports on NISP will be made in Network News and via the electronic mailing list,

NISP@UK.AC.RUTHERFORD.IBM-B

Jill Foster, University of Newcastle upon Tyne

NISS Update

We have made some significant changes to the Main Menu recently. The changes were made to highlight the importance of academic discipline-specific information on NISSBB.

Sections N, O, P and R are subdivided (roughly alphabetically) into individual subject areas. Each subject area is edited/administered by a coordinator (whose interest is in that area) and is no longer controlled by NISS.

Each subject section is under the direct control of one of the CTI Subject Centres which were established around the UK on 1 April. (The CTI Subject Centres are listed in section D4B on NISSBB.) To prepare for this we have been developing tools to allow such specialist groups to control their own areas of NISSBB; the NISS team is severely overstretched and so we hope to extend the opportunity for more groups to edit their own specialist areas on NISSBB in the future.

The Bulletin Board continues to attract considerable interest, consistently recording around 200 accesses per working day. We expect usage to increase still further when the CTI Subject Centres are fully operational, as almost all of them will be using NISSBB as their principal online information service.

For security reasons we have had to withdraw the file transfer service on NISSBB; this was originally the only way you could download information from NISSBB to your own system. As the POST facility now does the same job (much more simply) we hope that the withdrawal of this little-known service will not cause you too much inconvenience.

The NISS Bulletin Board can be accessed on JANET. The service is registered in the NRS as NISS, so CALL NISS should work in most cases. If it does not work ask your network manager to configure NISS'-in the NRS table you use and in the meantime you will have to use the JANET X.25 address, 000062200000, to access the service.

Rob Armstrong

Information Services Manager

NISS

Project Jupiter Update

Project Jupiter - the Project which aims to promote JANET to academic libraries - has now been running for over 4 months, in which time a great deal of useful information has been gathered, and several contacts made.

The most recent activity has been in the Scottish sector of the community, in preparation for the first of the Project's 1-day regional seminars, which was

held for librarians from all Scottish universities in the Computer Centre of Glasgow University on 14th June. Each Scottish university library was visited prior to the seminar, in order to gain a picture of current use of the network by the libraries concerned. This data will be used in the Final Report of the Project, which should be produced late next year.

The seminar on the 14th looked at the general situation, and then went on to focus on network services of interest to libraries (bulletin boards, distribution lists, PD-Soft, file transfer applications, etc). Two invited speakers also gave papers: one on JANET in the context of a medical library, and the other on a library-produced front-end package offering access to any JANET library's automated catalogue across the network. The seminar concluded by focussing on the training needs of libraries in the use of the network.

Later in the summer the first part of a serial publication entitled Guide for libraries on JANET will be published. Invitations to subscribe to this publication have already been distributed, and a free Project Jupiter newsletter will also be sent to subscribers.

Project Jupiter will also soon launch a bulletin board service, which will make available a variety of information sources and services to the UK academic library community. Exhibition display material has been commissioned, and the Project will be exhibiting at the Library Technology Fair at Sheffield Polytechnic in July, and again at conferences in Edinburgh, Cranfield and Bath over the next few months.

Already, then, the Project is having an impact on the library community, even though its training and promotional efforts have not properly begun. A number of issues have been identified as being of special concern to librarians, two in particular:

1. The lack of promotion of the network. There has been a scarcity of intelligible documentation, and - so far - little in the way of training on accessing the network, and on the various services available.

2. Standards for library operations. Although some work is being done here, the pace of change is not fast enough. Librarians want standards on interlending, textual database searching, and file transfer of bibliographic records. Once these are in place, the library community will be in a position to use its wide area network in a big way.

Project Jupiter is certainly ready to address the first of these problems, but the second will obviously take time. The production of standards in the multivendor environment of automated library operations is a requirement which is becoming ever more urgent.

John MacColl, Project Jupiter

Interspan

Some of you may have seen mail arriving at your system from addresses of the form:

<strange name> (a;.gb.%old-40().inter span and wondered where it had come from.

It could, in fact, have come from a variety of sites throughout the UK. Interspan itself is a commercially-run message handling service, which was set up in 1987 to provide an E-mail service suitable for use in schools. Most of the sites connected to the system are therefore schools, although there are also a few LEA teachers' centres, private individuals, and commercial organisations. The users range from those with standalone micros up to schools with campus-wide networks; most have networks of either BBC micros or RML Nimbus (a PC clone).

The initial impetus for the project came from the reaction to the DTI Modems in Schools scheme. Under this scheme, the Department of Trade and Industry supplied a modem to every secondary school in the country. Unfortunately, many schools found that they could not afford the costs of using these modems to full effect, especially as school working hours are mostly in the peak rate period for telephone costs. Our plan was to provide software that would allow people to prepare messages on their local systems, and to have a central system that would call in to all the subscribers' systems during the night to make the actual transfers. This also meant that the system could be used by a whole class of pupils at once, as the modem (and telephone line) are not required to prepare or read mail.

Around this time it became apparent that the X.400 standard was going to be the way forward for mail systems, and we decided to base our system around this. X.400 systems are expected to communicate by means of an OSI communications stack, and are typically implemented over X.25 packet switched networks. Clearly some compromise was required to build a system from such unpromising components as V.23 half-duplex modems and BBC Micros with only 32K of memory. In fact, we have been able to provide all the standard features of X.400 as seen by the user, and have only compromised on the communications link (which uses a non-standard protocol, specially designed to cope with the peculiarities of the hardware in use).

A typical site will have a local area network providing fileserver facilities to a number of micros. Users can use the mail send/read programs to interact with in-tray and out-tray files on the fileserver. One micro on the network provides a mail server function; it will be set up each night before people go home and will collect up all the mail ready to forward it when the central system dials in. If sufficient equipment is available, the server can be run continuously and will provide a rapid-delivery local mail system as well as the overnight dispatch to other sites.

Different people are using the system for a variety of purposes. For some, it provides a way to introduce pupils to communications, by exchanging messages direct with pupils in other schools; for language teaching the prospect of overseas mail connections is quite exciting. Others use the system for more administrative purposes, such as distribution of software and teaching materials from an LEA centre to the local schools; the X.400 facility to send binary files as well as plain text is particularly important here.

Whilst the system internally uses non-standard protocols, the messages themselves are fully conformant with X.400, and the central switching system at our offices in Cambridge has standard X.25 facilities available, with a connection to PSS. Hence we can connect to any standard X.400 system and relay messages that have come in from out subscribers. In particular, we have a connection tc BT's GOLD 400 system, which in turn is connected to JANET through a gateway at UCL.

Andrew Gordon, Interspan Electronic Mail Ltd

Open Meeting on User Agent Interface for 'ISO 100211 X.400 (88)'

The JNT is sponsoring a project at Nottingham University to produce a design for a user agent interface for ISO 10021/X.400(88). The aim of the project is to produce a design suitable for implementation in window-based environments (e.g. X, PM, MS/DOS).

Deliverables from the project will include a functional specification for the UA, a WIMP user agent interface design, and a prototype demonstrator. The demonstrator will take the form of a co-located UA/MTA which uses the UCL/Nottingham PP MTA and runs in X windows on a Sun.

As part of the design process we would like to solicit advice and opinions from the community and with that in mind are planning to hold an open meeting/workshop at Nottingham on 17th July.

If you are interested in attending or receiving further, details please mail to:

Dr. Hugh Smith

Communications Research Group

Computer Science Department

Nottingham University

Nottingham NG7 2RD

Network Level Converters

The article in Network News Number 28 entitled Lower Layer Transition to OS1 described various elements of the transition to OSI services and protocols at or below the Network layer. In particular the need for conversion between hosts and networks that use the X.25(84) protocol to support the OSI Network service, and hosts and networks that use X.25(80) to support the Yellow Book service, was identified.

A number of possibilities were explored for the provision of such converters within the X.25 packet switching environment i.e. within the current JANET X. 121 like DTE addressing domain. Following a procurement exercise and extended discussions with potential suppliers of general purpose and specialist gateways, a contract has been placed with Netcomm Limited for the supply of an initial batch of Network level converters. A phased acceptance of the product is planned with initial site testing at the University of Edinburgh, through which the contract has been placed, scheduled for December. Subsequent testing will be carried out at other sites which have X.25(84) implementations not available at Edinburgh. Any site interested in helping with the additional testing should contact JNT Section B.

JNT-B@ UK.AC.RUTHERFORD

Les Clyne, Joint Network Team

SUN Products

A new version of Sunlink X.25 is available for the latest version of SunOS.

Sun are introducing Sun Pink Book in the near future and will also be releasing a new version of Sun Coloured Book software. These may well be available before you receive this issue of Network News.

The products will be available on Sun's latest Sun-3 and Sun-4 products as well as existing machines.

Please contact your local Sun office for further details.

Collette Truman, Joint Network Team

IBM Network AIX/RT

IBM Network AIX/RT program allows the IBM 6150 RT/PC to partake in the Coloured Book environment as specified for the UK Academic Community by the Joint Network Team (JNT).

The work was funded by IBM and performed by Edinburgh University.

Terminal support and Hie transfer, job transfer and mail support are provided over both Wide Area (WAN) and Local Area (LAN) Networks.

Highlights

The Network AIX/RT program provides the 6150 RT/PC user with the following facilities:

If you would like a copy of the specification please contact

Bruce Guthrie, Academic Systems Marketing, IBM UK Ltd

CSMA/CD to CSMA/CD Bridges

As reported in last November's issue, Rutherford Laboratory Informatics Department has been contracted to act as a Bridge Evaluation Centre, with a mandate to survey, on a continuing basis, bridges suitable for use by the Academic Community. A table of initial results, recommending local, kilostream and megastream bridges was circulated in April at Networkshop. This table has DOW been placed on the JANET.NEWS machine. It is hoped to revise this table shortly, and to include a section on performance and management. The table will continue to be revised as other bridges come to our notice and are tested.

Both the Bridge tables and a recent survey by Edinburgh University of repeaters, are filed under ETHER, and may be read by logging in, or by transferring the appropriate file to your own machine. NEWS.ETHER.INDEX gives a list of available files. Use username NEWS, no password.

Dick Gillman, Joint Network Team

ISDN OSI Capability Study

As reported in a previous edition of Network News, the JNT commissioned a study on the potential impact of ISDN on JANET for the provision of open systems data communications services. The study was carried out by Professor Kurstein and his colleagues at University College, London and their final report is now available. Copies of the report can be obtained from the JNT Administrative Officer.

JNT Admin Officer@UK.AC.RUTHERFORD

The recommendations of the report will be considered by the Network Advisory Committee in the near future in the context of discussions on developments of the open systems infrastructure for the academic community. The key points of the report were outlined in a presentation by Professor Kirstein to Networkshop 17 at Warwick.

Les Clyne, Joint Network Team

The ULCC Network Monitor

Introduction

ULCC hosts very extensive networking facilities that include the London X.25 network, the JANET PSE, front-end access to the CRAY computer via AMDAHL/MVS and VAX/VMS systems, JTMP and FTP servers and an ETHERNET. Information on the operation of ULCC's networking is required by three different types of user; network operators, network managers and network users. At present there are no commercially available products for monitoring a multi-vendor network in a coherent way and presenting information in different forms. Consequently ULCC have developed their own network monitoring system.

The ULCC Monitor separates interaction with network components and presentation of data to users from the monitoring function itself. In this way it provides a very flexible and powerful tool enabling support for new types of equipment and new user functions to be added to the monitoring system at will.

The primary aim of the monitor is to provide fault detection and performance analysis. The monitor stores information in a standard format to satisfy these requirements including current network status, a historical record of status changes and statistical information about traffic flows. In addition any other monitoring data can be collected and stored as received for other management uses. The status of a component can be one of UP, DOWN, OUT of SERVICE, UNKNOWN, PARTIAL or FLAKEY

User Facilities

End user management facilities are provided by separate commands or processes that use the data stored by the monitor and that use an abstract management interface for interaction with network components themselves.

Network user facilities already provided are a local TELETEXT display of CRAY and front-end availability for centre users and a remote news facility showing the current status of certain hosts on the London network and the CRAY and front-end availability. Also provided for remote users is a message gathering facility that enables a user to send a message to network operators. The message is flashed on a colour display and recorded in a file.

Network managers are provided with summaries of network performance as required. At ULCC this is achieved by archiving monitoring data to a VAX/VMS system nightly and using programs developed on the VAX to provide the summaries.

Network operators are provided with a variety of network control and diagnostic tools. An interface to a component database is provided so that the network configuration can be recorded. Detailed current network status is available for each component. This includes the status of communication lines and host processes as well as hosts and switches themselves. The current number of virtual circuits or other useful parameters can be recorded including clearing codes.

Network operators can connect to any component by using a single command which multiplexes the user's connection onto the one used by the monitor. This is particularly useful in cases where the monitor has to use the only available remote operator port. Control commands for components can be batched together and scheduled to be issued at given times. The operation of the monitor can be controlled dynamically by changing the operating flags of any component for instance for disabling or enabling monitoring. In addition the status of any component can be reset dynamically. These facilities are all available through a dumb terminal interface in order to be usable in any local or remote situation.

A paged colour TELETEXT status display is also available. This is a textual display which can contain up to ninety pages of information and where the status of each object is indicated by the colour in which its name is displayed. A failing object causes the appropriate page to be displayed and the colour of the name of the object to change to flashing red as an alarm. The Network Operation Center at ULCC find this an invaluable tool that is quicker and easier to interpret than a graphics display.

System Design

The system is required to monitor switches, hosts, host services and communication lines even though these are somewhat different types of object. Information about some components is only available by interrogating another component. For instance the status of some communication lines may only be available from their controlling switch. Thus for each component a list of attributes is defined which includes a list of the components for which it can provide information. Therefore a component representing a switch may include a list of the lines on the switch and a component representing a host may include services available on the host. This scheme provides a very flexible way of representing the network configuration. Other component attributes are such things as address, logon id, password, component type and to which other components it is connected.

Monitoring information is obtained in a variety of ways. Initially a connection must be made to a component and in some cases the result of this connection attempt itself is the only information available. In others either further commands must be issued to solicit data or else the component may itself spontaneously generate relevant messages. Data received from components must be filtered to select relevant messages and to deal with bursts of error reports. Some messages may require a response to obtain further information.

The details of how information is obtained is hidden from the monitor itself by an abstract management interface which defines a consistent set of information and control functions for every component. Therefore for each type of component a set of routines must be written to convert the abstract interface into the commands necessary to obtain information from that component and to convert the received information into the standard format. Producing a new set of interface routines is straightforward for a competent C programmer and will normally take less than a week.

Types of Component

Currently we have developed routines for eight different types of component.

  1. CAMTEC JNT PAD version 2.5F
  2. GPT type 3 CPSE.
  3. SEEL TELEPAC.
  4. ULCC CAMAC switch.
  5. The ULCC Amdahl/MVS system running JTMP and FTP servers.
  6. The individual communication lines to the Amdahl/MVS system.
  7. A general host. The availability of a host computer is determined by attempting to connect to it and obtain some type of response such as a login prompt.
  8. A gateway. Where no information is available from a machine its status is determined from the status of lines connecting it to other machines.

Other interfaces for machines such as CAMTEC PAD V4.0. Netcomm PAD and Spider PAD are not required by ULCC at the present but will be provided when required.

Hardware

The initial design specification required a cheap product with a clear upgrade path. This meant it should be usable on existing kit and be available both locally and remotely on a variety of simple terminals. It was therefore decided to base the monitor on UNIX and initially to use an IBM-PC/AT with a SYMICRON X.25 interface card and to use a BBC Micro as a display terminal,

A UNIX BSD SOCKET-based network interface has subsequently been written, thus enabling the system to be run under different versions of UNIX and to use different network devices. It has already been ported to a DEC MicroVax running ULTRIX with DEXPAND X.25 card.

The Network Monitor has been in full and continuous operation at ULCC since January I9S8 where it monitors the equivalent of 40 switches and 300 lines. The size of the network at ULCC has required us to move from using an IBM-PC/AT to a COMPAQ-386/PC. However for smaller networks an IBM-PC/AT (or equivalent) is adequate; the whole system costing approximately £5000. Other sites have been given copies of the network monitor and are installing it for use in their OWP environments,

Futures

A number of new developments are planned. An event server is being produced which enables individual user processes to dynamically specify events for which they require notification thereby enabling more sophisticated automatic management facilities to be provided. It is planned to develop a Meta- Language to enable non programmers to specify new component types. A STREAMS-based network interface will be developed extending the range of systems on which the network monitor can be run. Other display formats are being planned including a graphical one. The facilities of more sophisticated terminals such as VT100 will soon be supported and eventually an X/WINDOWS interface will be provided.

Further information about the monitor can be obtained from:

Tom Daniel University of London Computer Centre

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site