DTJ Number 3 September 1987 - Digital Technical Journals

More documents

Recommendations

Info

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 DECnetULTRIX 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
The DECnet,ULTRIX SoftwareComponents of the DECnet-ULTRIXSoftwareProgramming InterfaceAs mentioned earlier, we decided to base theprogramming interface in the DECnet-ULTRIXcode on the 4.2BSD interprocess communicationsfacilities, which are modeled on the socketinterface. Operations on sockets are similar tooperations performed on "logical units" or "filedescriptors," which direct IjO operations to afile or another device. Programs make systemscalls to create, bind names to, connect to, sendand receive data over, and destroy sockets.The IPC interface in 4. 2BSD is designed sothat sockets exist in specified communicationsdomains. Sockets within a domain share commonproperties, such as their naming scheme, andmay communicate only with other sockets in thesame domain. To implement the DECnet-UtTRIXsoftware, we had to add the "DECnet" communicationsdomain to the existing Internet and UNIXdomains. The basis of this support was the additionof new modules implementing the DECnetprotocols (at OSI levels 2, 3, and 4). These moduleswould be linked into the ULTRIX kernelwhen the DECnet domain was installed. Theyallow programs to create sockets using the DECnetnetwork services (NSP), routing, and Ethernetdata link protocols to communicate.Within the DECnet domain, two types of socketsare provided: stream, .and sequenced packet.Stream sockets provide a bidirectional, reliable,and flow-controlled stream of data between twoprocesses. Sequenced packet sockets providethese same features while preserving the messageboundaries of the data as presented to: thesending socket interface. All existing DECnetapplications protocols use the sequenced packetinterface because the message boundaries areused to indicate the lengths of data within messages.The stream socket interface was providedto facilitate porting applications from the otherUNIX communications domains to the DECnetdomain. In stream sockets,, the data flowingthrough the stream must be self describing. Inthat way the applications programs using thestream know how long each data element is withoutrelying on message boundaries. Data deliveryis based on buffering and flow control considerationsrather than preserving information aboutthe way the sender presented the data to thestream.We had to provide many supporting routinesin addition to the DECnet protocol code linkedinto the ULTRIX kernel. Those routines are modulesarchived in the standard C-language libraryat DECnet installation time. They provide accessto the DECnet node and object databases,address-conversion routines, and several routinesproviding a simplified programming interface tothe kernel socket routines.Kernel ChangesOur goal was to minimize the number of kernelchanges required to support the DECnet system.All the new functions that reject connections andpass data or access control information on connectionrequests were implemented using theexisting "setsockopt" (set socket option) and"getsockopt" (get socket option) system calls.We modified the ULTRIX kernel to allow thosecalls to be dispatched to domain-dependentcode. That was something the 4.2BSD designershad documented but not fully implemented. Wealso increased from 112 to 1024 bytes the maximumamount of data that could be passed acrossthose interfaces. In that way we could accommodatepassing all the access control information ina single request.We found several bugs in the kernel supportfor this type of socket. Therefore, this DECnetimplementation appears to be the first networkingdomain to support sequenced packets. Allthese bugs were fixed in version 1. 2 of theULTRIX-32 software.Most of the kernel changes were made in thenetwork device drivers. The initial release of theDECnet-ULTRIX software was to act as a nonroutingnode on the Ethernet. Therefore, we wereconcerned only with the Digital Ethernet interfacesand the DEUNA and DEQNA networkadapters. As written, the drivers for those devicessupported only the internet protocol (IP) usedby TCP for routing. They had explicit informationabout the IP protocol types coded into thedevice interrupt routines. We also wanted to addsupport for additional protocols (e.g., the LocalArea Transport, IAT, and maintenance operationsprotocol, MOP) at a later date. Therefore, weadded kernel routines that could be. called fromany Ethernet driver. Those routines:dispatch todomain-dependent routines when a message is tobe transmitted or a new message is received. Wealso added a number of I/0 control (ioctl) functions:to those drivers. Those functions allow102Digital TecbnlcalJour.nalNo. 3 September 1986' .
Page 1 and 2:
Netwo;king ProductsDigital Technica
Page 3 and 4:
Editor's IntroductionRichard W. Bea
Page 5 and 6:
BiographiesRaj Jain Raj Jain gradua
Page 7:
BiographiesDavid R. Oran Dave Oran
Page 10 and 11:
increase the sizes of networks, we
Page 12:
New Productsmust be able to coexist
Page 15 and 16:
A Digital Network Architecture Over
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
---A Digital Network Architecture O
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Performance Analysis and Modeling o
Page 29 and 30:
---Performance Analysis and Modelin
Page 31 and 32:
Performance Analysis and Modeling o
Page 33 and 34:
---Performance Analysis and Modelin
Page 35 and 36:
--Performance Analysis and Modeling
Page 37 and 38:
The DECnet/SNA Gateway Product• H
Page 39 and 40:
The DECnetjSNA Gateway ProductFrom
Page 41 and 42:
The DECnetjSNA Gateway Productcommu
Page 43 and 44:
The DECnetjSNA Gateway ProductUSER
Page 45 and 46:
The DECnetjSNA Gateway ProductThe u
Page 47 and 48:
The DECnetjSNA Gateway ProductDECne
Page 49 and 50:
The DECnetjSNA Gateway Productopera
Page 51 and 52: The DECnetjSNA Gateway ProductSegme
Page 53 and 54: The DECnetjSNA Gateway Product• O
Page 55 and 56: WiUiam R. HaweMark F. KempfAlanJ. K
Page 57 and 58: The Extended Local Area Network Arc
Page 75 and 76: Terminal Servers on Ethernet Local
Page 89 and 90: Paul R. Beckjames A. KryckaThe DECn
Page 91 and 92: The DEC net- VA X Product - An Inte
Page 93 and 94: The DECnet- VA X Product - An Integ
Page 95 and 96: The DECnet- VAX Product - An Integr
Page 97 and 98: The DEC net- VA X Product - An Inte
Page 99 and 100: The DECnet- VAX Product - An Integr
Page 101: john Forecastjames L. jacksonjeffre
Page 105 and 106: The DECnet- ULTRIX Softwarehave pro
Page 107 and 108: The DECnet- ULTRIX Softwaresystems.
Page 109 and 110: Peter 0. MierswaIDavid J. MittonMar
Page 111 and 112: The DECnet-DOS Systemthat CCB, whic
Page 113 and 114: The DECnet-DOS Systemdata link laye
Page 115 and 116: Tbe DECnet-DOS SystemNDU and the vi
Page 117 and 118: Th e DECnet-DOS Systemconsole can a
Page 119 and 120: The Evolution of Network Management
Page 131 and 132: The NMCCjDECnet Monitor Design5. Op
Page 133 and 134: Th e NMCCjDECnet Monitor DesignFigu
Page 135 and 136: The NMCCjDECnet Monitor DesignKERNE
Page 137 and 138: The NMCCjDECnet Monitor Designinto
Page 139 and 140: The NMCCj/JECnet Monitor DesignThe
Page 141 and 142: The NMCCjDECnet Monitor Designcan s
Page 143 and 144: Editorial StaffEditor - Richard W.
show all

DTJ Number 3 September 1987 - Digital Technical Journals

Create successful ePaper yourself

Delete template?

Save as template?