This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern/ for current CERN information.
J.M.Gerard CN/CS
As described above, we are in the process of replacing the coaxial cables of the CERN Ethernet network by a structured wiring scheme (structured cabling project). This should ensure that no problem with an individual hardware connection will affect all users in the same region. However, this will only partly solve the problems of the end users, to whom the network has to provide a complete solution available all of the time. The other part of the problem comes from the way in which the network is used, and in particular the different protocols spoken over the network. Like the languages used by people in CERN, the number of different protocols is too high for every computer to be able to understand all of them.
To solve this other problem requires breaking up CERN into many small regions by means of inserting network routers. These routers essentially ensure that as much network traffic as possible stays within the region. In addition, communication with a different region is done by relaying this traffic directly between the routers of the two regions. This avoids any interference with regions unconcerned with the traffic.
The main advantage from routing is the reduction in unnecessary network traffic which is broadcast to all systems on the network, whether or not they understand the protocol being broadcast. At CERN there is a steady stream of packets broadcast to all end systems (around 100 every second) and also frequent storms of several hundred broadcasts per second. Routers provide everyone with a protection barrier against this ``network pollution'', thus enabling the network systems to concentrate on what they are meant to do.
A second advantage is that we can be much more permissive in the way in which the end systems use the network. For example, the current need to limit the number of Macintosh computers using AppleTalk protocols directly on Ethernet will disappear. Also, in the longer term, new applications which are now too disruptive, such as network multi-media, will become possible.
There is, unfortunately, one main difficulty involved in switching to a routed network, which is related to the use of IP protocols. Currently, virtually every system on the CERN Ethernet has an IP address identification of the form 128.141.x.y (where x and y are between 1 and 254). However, when different regions are routed then the systems in the region will need to have a different IP address and to redefine different IP addresses for the IP name service, time service and routing. In addition, systems which are moved between different regions, or even possibly inside a region, will require a change of IP address.
We will do as much as possible to minimise the work involved in changing these IP parameters, in particular for the PC systems supported by NICE. However, the end users may still have to do some manual reconfigurations. We are also looking into the possibility of dynamic address allocation, such that such systems as portable PCs or Macs can acquire their IP address information automatically when connected in a new region.
The rest of this article is a more detailed explanation of what are the reasons why we absolutely have to move to network routing and what are the specific points relating to the different network protocols now in use on the site.
The reason for the current problems is partly the number of different protocols in use and partly the way in which these protocols can occasionally be used in a disruptive manner. The unfortunate fact is that, very often, the things that are disruptive for the network are useful, even vital, for the user. For instance, any time that a user of a Macintosh connected directly to the Ethernet opens the Chooser to search for a printer or a file server there are a whole host of packets sent repeatedly all over CERN to find what could meet the search requirements. However, clearly this process is absolutely vital for the Macintosh user.
Routers have an additional advantage of understanding the many different protocols in use and being able to restrict any particular protocols to the particular region. This is particularly important because many of the protocols in use on the CERN networks, including some specifically written at CERN, are designed only for serving very localised regions. When used in our current large bridged network they can cause significant network traffic broadcast all over CERN.
The routers that we will use for CERN will normally be configured to handle the three main protocols in use at CERN, namely AppleTalk, IP and IPX. AppleTalk is the way that Macintosh computers, printers and file servers normally communicate between themselves. IP is the protocol used for general services like World Wide Web, EDH, X-terminals, remote login and file transfer between different systems. IPX is the protocol used by PCs to access the NICE servers and their associated printers. Since most systems in CERN require no other protocols than these, it is clear that restricting all network traffic within a particular region just to these protocols will eliminate the network pollution coming from all the other unnecessary protocols.
There will remain cases where other protocols are required : DECnet, mainly for VMS users, is the most obvious case but there are many other necessary cases. We will handle these for the users for whom they are necessary by continuing to route the three main protocols and by permitting the router to pass all other protocols straight through.
When the routers are installed there will be three possibilities for the creation of regions and connection of end systems. The most simple will be systems which only ever use the IP protocols, such as Unix workstations and X-terminals. These will be connected to a service offering just IP, thus eliminating any network traffic other than IP. Other systems, in particular PCs and Macintoshes, may require IPX and/or AppleTalk protocols (in addition to IP protocols, of course), and so will be connected to a service of type AN (Appletalk Novell) offering the three protocols. All remaining systems, requiring any additional protocols, will be connected to a general purpose (GP) service.
As already mentioned, the main work involved in changing to a routed network is that of changing the IP address parameters of all the systems concerned. This is complicated further by the fact that to each IP address there normally corresponds a registered IP name known to our data base and to the IP Domain Name Servers. For many systems it is essential that the name remain unchanged.
The other two main protocols, AppleTalk and Novell IPX, are self configuring, so that the worst than may happen is that the user sees a message saying that the network has changed. One particular potential advantage is that for AppleTalk we can redefine the acceptable zone names for the region, eliminating any of the current ones which are unnecessary and adding any new names that could be required.
Several documents describe the implementation of the new routed network in technical detail. They are still evolving drafts and are currently only accessible within CERN via the World-Wide Web, from the on-line version of this article, accessed via http://wwwcs.cern.ch/, item Routing and Backbone.