New Productslink layer directly, its operation is restricted toadjacent nodes. A system to be down-line loadedmust be directly connected to its load server.That load server might be controlled by an NCPlocated elsewhere in a network (using NICE) .Moreover, the server might be reading the filecontaining the load image from yet anothernode (using the data access protocol, or DAP, inthe application layer) .In examining Figure 2, note the arrows on theleft side that connect the network managementlayer with each lower layer. Each arrow is a controlpath used by network management to coordinatethe activity of each layer in a node. Eachlower layer of the DNA structure specifies a networkmanagement interface that defines the networkmanagement functions provided by thatlayer.A basic principle followed in designing DNAnetwork management was to perform managementfunctions at.the highest level possible. Forexample, management functions use the regularapplications layer service for accessing filescontaining management information. Thesefunctions can also communicate using the normalservices of the session layer. The alternativeto this principle would have been to use somespecial-purpose mechanism to achieve the managementfunctions, thus adding unwarrantedcomplexity to the architecture and to its implementations.Out of practical necessity, however,the direct use of the data link layer by DNA managementrepresents a partial deviation from thisdesign principle. Implementing all the lowerlayers of DNA in ROM microcode was deemed tobe uneconomical. Although the sizes of low-costROM memories have expanded in the last tenyears, fixing all the DECnet layers into ROMremains undesirable. Changes to add new functionsor correct implementation or architecturalbugs would simply require too many costlyhardware updates.Another basic design principle followed indesigning DNA network management was to firstspecify primitive functions, then make themavailable to network managers or to specializedapplications programs. The goal was to have asimple, flexible structure implemented in allDECnet nodes while still providing the opportunityfor dedicating computing resources to themanagement of large networks. 4iiNetwork Applications: LayerThe network application lyer provides genericservices to the user and network managementlayers.5 These services include remote fileaccess and transfer, remote interactive terminalaccess, and gateway access to non-DNA systems.6Modules in this layer operare independently andasynchronously. A single DECnet node may supportmany different network applications modules,which communicate using many differentprotocols. This layer supports modules suppliedby both <strong>Digital</strong> and users. As new network applicationsare developed, they can easily be addedto this layer. One application layer protocol isdescribed below to illustrate a typical operationof the applications layer.1DAP provides remote file access and transfer.Two cooperating application layer modulesexchange DAP messages using the DNA sessioncoiurol service: the user :module at the noderequests the file operation, and the server moduleacts on the user's behaif at the remote node.Figure 3 depicts those services.These applications layer modules operateunder the control of either"a utility program or auser program residing i the user layer. Forexample, a file transfer oeration might be initiatedby a utility program. In some DECnetimplementations, such as the DECnet-VMS system,remote file operations are initiated by normalVMS user programs using VMS file systemcalls. File naming conventions will determinewhether or not a local or remote · file operationis implemented.7In a typical DAP protocol dialogue, the firstmessage exchange involves configuration messagesproviding information about the operatingand file systems. Those essages are followedby attribute messages that supply informationabout the file. An access-tequest message typi-1cally follows to open a picular file. A controlmessage then sets up th'e data stream. Afterfile transfer has completed, access-completemessages will terminate the data stream. Withthese messages, either an entire file can betransferred at one time or· portions of a file canbe transferred, either randomly, sequentially, orindexed.<strong>Digital</strong> <strong>Technical</strong> JournalNo. 3 <strong>September</strong> 198615
A <strong>Digital</strong> Network Architecture OverviewLOCAL NODEREMOTE NODEUSER LAYERTHE ACCESSING PROGRAM:•NF"i' UTILITY•A VAX/VMS COMMAND• A USER-WRITTEN PROGRAMNETWORK APPLICATION LAYER.----t DAP - SPEAKING ROUTINES:• NFARs, OR ROUTINES IN THELOCAL FILE SYSTEM (E.G.,RMS)SESSION CONTROL LAYEREND COMMUNICATION LAYERROUTING LAYERDATA LINK LAYERNETWORK APPLICATION LAYER·- ------ -·DAP - SPEAKING SERVER:• FILE ACCESS LISTENERSESSION CONTROL LAYEREND COMMUNICATION LAYERROUTING LA YEADATA LINK LAYERDAP - DATA ACCESS PROTOCOLFCS - FILE CONTROL SYSTEMRMS - RECORD MANAGEMENT SERVICESNFARs - NETWORK FILE ACCESS ROUTINESNFT - NETWORK FILE TRANSFER UTILITYFigure 3File Transfer across a NetworkDAP's principal design problem was accommodatingthe needs of diverse file systems. It wasnecessary to define a mapping between the featuresand functions of each different system. Thisdefinition was not always easy to make. Some systemshad differing capabilities (for example,some supported index files); others had differingmeans of providing similar capabilities (forexample, stream or record structures for textfiles). Moreover, it was very important for filetransfers between like systems to operate at maximumefficiency and to be completely transparent.For example, it should be possible to copy afile from one VMS system to another and stillretain exactly the same bit patterns in the copy.Two design approaches were studied to achievethese capabilities: using a common, or canonical,file format in protocol messages; and performingneeded translations. The canonical formatwas rejected because it was not transparentor efficient enough in the homogeneous case.The second approach, in which translation isperformed at the client DAP protocol module,was adopted.Session Control LayerThe session control layer resides directly abovethe end communications layer.8 The session controllayer provides system-dependent, process-toprocesscommunication functions for processesresiding in the user, network management, andnetwork application layers. These functionsbridge the gap between the pure communicationfunctions provided by the end communicationslayer and the functions required by processesrunning under an operating system. The communicationservice provided by the session controllayer is connection oriented: an initiating processrequests a connection to a destination process.The session control layer manages theseconnections. Once a connection is established,data flows between the processes without furtherintervention by the session control layer, usingthe facilities provided by the end communicationslayer.When establishing a connection, the higherlayer specifies th e destination process in twoparts: first, by destination node, then, by processwithin destination node. Destination nodes are16<strong>Digital</strong> TecbnicalJournalNo. 3 <strong>September</strong> 1986