DTJ Number 3 September 1987 - Digital Technical Journals

New Productsprogramming environment and other networkingimplementations on the ULTRIX system. Suchcompatibility required that it be easy to portapplications that used other protocols, such asthe transmission control protocol (TCP) and theinternet protocol (IP) to use the DECnet system.Also, it should be possible to write applicationsthat would run over the DECnet and other protocolsat the same time. We felt that the DECnet­ULTRIX software should perform at least as wellas the TCP jiP implementation.Significant Design DecisionsFor several weeks at the project's start we examinedalternatives for the basic design. Two majorones were considered for the basis of the networkenvironment. The first was to extend the"socket" interface from the ULTRIX system,which had been developed as pan of Berkeley4. 2BSD for the Defense Advanced Research ProjectAgency (DARPA) TCP jiP project. A socket isan addressable end point of communicationswithin a process, directing data to a similarsocket in another process. This socket interfacehad many of the functions we needed, althoughsome additions would be required. It had a disadvantagein that the socket environment wouldbe difficult to port to another variant of theUNIX software, should we eventually decide todo that.The second alternative was to build a versionof a communications executive on the ULTRIXsoftware that would isolate the protocol modulesfrom depending on the operating system.1 Thisapproach had been used successfully in anotherproduct set and had the primary advantage ofmaking more of the implementation portable.For example, this alternative would make it easierfor us to port the DECnet-ULTRIX software tothe UNIX System V software.Our final decision was to implement theDECnet-ULTRIX software with the first alternative,using the 4.2BSD interprocess communications(IPC) mechanisms. This alternative providedthe most compatible interface with otherprotocols and took advantage of the servicesalready provided by the IPC code in the ULTRIXkernel. We knew that the socket interface wouldhave to evolve to support other protocols, suchas ISO transport, and that we could provide someleadership in managing its evolution. In the shortterm we would provide extensions since theDECnet system requires op(ions having no equivalentin the IPC socket interface.We also had to find ways to present thoseoptions to users without extensively modifyingthe IPC routines in the ULTRIX kernel. Modifyingthe kernel's IPC code would require changesto other protocol implementations and reduceour ability to port the DECnet code to other4.2BSD-based systems. In pmicular, a way had tobe found to allow a server process to reject arequested connection. We also had to supportDECnet's ability to pass user-supplied data withconnect, accept, or reject operations. The IPCinterface in 4.2BSD provides no means for programsto pass data or acces control informationwithin a connection request. Therefore, nomeans existed for a program to decide that arequested connection should be rejected. Thislimitation was not acceptable for a DECnetimplementation because certain applicationlevel protocols in the DNA structure depend onconnection data for versin coordination andaccess control.Another weakness found in the existing4. 2BSO mechanisms was in the area of networkmanagement. One of DECnet's strengths is itsmanagement and control functions provided bynetwork management tools across nodes within anetwork. 2·3 Using a single command interfacecalled the network command program (NCP), auser may examine and ch'ange the state of keyparameters on any system within his network. Inaddition, he may examine counters describingnetwork activity and errors. Many conditionsoccurring on systems within a network cantrigger the generation of events or notificationmessages. These messags can be directed toconsoles, files, and programs anywhere in thenetwork.To implement these network management features,we had to add program-level access tochange parameters and to read counters andother information kept in the ULTRIX kernel.The network device control needed an especiallyIlarge number of changes. :Berkeley 4.2BSD providesa very limited set of controls over networkinterfaces. These controls are insufficient to supportthe functions of DECnet network management.In particular, the DECnet software has tobe able to turn interfaces on and off, gather counterskept in the device, ad enable and disable·multicast addresses,Digital TecbntcaljournalNo. 3 September 1986101