You are here: irt.org | RFCs | RFC187 [ previous next ]
A NETWORK/440 PROTOCOL CONCEPT
Network Working Group Douglas B. McKay
Request for Comments #187 Donald P. Karp
NIC #7131 IBM Thomas J. Watson Research Center
Categories: C3,C4,C5,C6,D7 Yorktown Heights, New York
Update: None
Obsoletes: None
This RFC is being circulated as an
information RFC. Its intent is to
convey some of the thinking and
philosophy that went into IBM's
network protocol and overall
network design.
[Page 1]
INTRODUCTION Network/44O is an experimental project in computer netting that was undertaken by the Computer Science Department of IBM Research. The primary objectives of the project have been to understand netting, identify design problems and implement the solutions to these problems. The above objectives have been met since a network has been built and is presently being operated by the project. Implementation discussions transpired with another department at Research in order to define a realistic user system interface. The protocol defined for the project's network is also the basis for the operation of an IBM OS network. The Network/44O project has also been involved in the philosophical and architectural concepts of network systems. The basic premise in our work is the concept of a logical network machine.(1) The main theme is to treat all systems involved in the network as a part of a single (large) multiprocessor system. Although many of the ideas have been based on hypothetical concepts, an equal number of ideas were derived from our network implementation and operating experience. The scope of this paper is to describe the philosophy and definition of a network protocol that is not restricted to any physical configuration. This is exemploified by the fact that a major portion of the ideas are implemented in IBM's two major operational networks, one of which is a distributed configuration and the other a star configuration. (1) Intenet - Report 2, February 1, 1970, Computer Science Department, IBM Corporation, T. J. Watson Research Center, Yorktown Heights, New York. BASIC ASSUMPTIONS There was a necessity to delineate many network functions in setting up an operating protocol. These functions included switching control, buffer control, message control, and operating control. The operating control function becomes further complicated as the user is able to program the network as if it were a single operating system. The protocol had to be further broken dowm into detailed functions in order to cope with error recovery and handling techniques. The original thoughts on handling these functions were to provide two basic realms of control. The net control is a higher level function that recognizes and controls all aspects of net jobs and the execution of job steps in the network machine. In addition, a communication control facility (referred to as an "Express Interpreter") was incorporated to provide fast service for all messages that were to be moved between user systems without intervention by the net controller. [Page 2]
--------------- | NC | --------------- ^ | / ----> in | out / -------------------------------- | Express Exchange | <---- -------------------------------- out in ^ \ \ The above figure illustrates the two major functions with messages travelling in both directions and directly through the Express Exchange, except in the case of messages that must be acted on by the Net Controller. These messages will be explained in detail later. These two functions can exist on any system and operate in any physical configuration providing the control information reflects the configuration so that proper operation can be maintained. There is no reference to physical configuration in this paper because of the flexible nature of the protocol and its adaptability to any configuration. For example, in the case of a distributed net, the Express Exchange would pass messages directly to the next station without any 'NC' overhead. The 'NC' would only come into play at the final destination and with the same reasoning, the 'NC' would not have to be present at every station. DEFINITIONS Before proceeding with the discussion of protocol and control, the basic message content and concepts must be defined. A transmission block is a physical entity that consists of header and text. A message (logical) consists of many transmission blocks. ------------------------------------ | Header | Text | ------------------------------------ The primary purpose of the network is to deliver messages from one user system to another in an orderly controlled manner. In order to provide all the information necessary to maintain control, the header contains a set of operational functions. These functions are listed below with the rationale for each. [Page 3]
Action Code This code selects the immediate destination of the transmitted blocks; the data may be transmitted directly to the user described in the DSID field, sent to 'NC', or used by 'EE'. Any conflict in information between this field and any other field in the header will cause an error message to be returned to the originating station. The AC will serve a similar function at the receiving system, indicating to the communications interface (CI) whether the data block is destined for a user routine or contains control information for the CI. [The CI is that function which interfaces directly with the local operating system.] Transmission Block Number Each block of transmission within the network will contain a sequential number inserted by the transmitting station. As the block flows through the network, every station will insert its own number into the block, overlaying the previous station's number. The purpose of this sequential number is to guarantee that no messages are lost in the physical communications process. Network Job Identifier The function of this field is to associate a transmission block with the network job to which it belongs. The identifier is assigned to the network job and to each associated transmission block by the user system or by the 'NC'. In order to establish a unique name for each job within the network, the user node identifier (i.e., the name of the user system originating the net job) will be concatenated with a number generated by the originating user system. Job Step (Marker) The purpose here is to uniquely identify a job step within a network job. The NC will assign this name since it maintains control of all network jobs. Originating System Identifier In order to route a block of data from one user system to another, a unique name must be associated with each user system. The name will be assigned by the network control group at the time the user system is accepted as a network participant. The station originating a block of data will place his assigned identification in this field in every block of data originating at his system. [Page 4]
Message Priority This field indicates transmission priority (not to be confused with processing priority) by block within the queue for a particular user system. Destination System Identifier This is similar to the originating node identifier except that the identification inserted is that of the node for which the block is destined. Logical Message Flags The message flags denote the first and last blocks of a message; all intermediate blocks are noted by their absence. The flag field in conjunction with the logical message sequence number will enable the user to determine if any blocks are missing from a message and will also provide an identifier that can be used to recover missing blocks. When the first and last indicators are turned on in a single block, the message is contained within the block. Logical Message Sequence Number This field is used to number sequentially the blocks within a message. The first block (denoted by the LMID) will contain the lowest number assigned (not necessarily 1) within a message while the last block will contain the highest number. Unlike the TBN, this number will remain intact throughout the journey of the block through the network. It is used for error detection and recovery along with the logical message flag. Logical Message Identifier Since all communications lines in the network can be multiplexed (blocks within a message will be interleaved with blocks from other messages), a message identifier becomes necessary in order to reassemble the message at the user destination. Therefore; each block within a message will contain an identifier unique to the message. In the simple case where the message is contained in one block, the identifier performs no function. When multiple blocks comprise a message, LMID will enable the user to reassemble the message. There can be any number of physical message blocks associated with any logical message. It is important that the that this LMID be used in the messages generated by the CI in response to NC commands. [Page 5]
Length of Text This field contains a binary number that equals the number of characters in the text portion of the transmission block, Although there are other means available to obtain this number, it is included in the header for redundancy check purposes. Logical Message Structuring The network controller maintains control for every user job submitted by NJID. The following hierarchical structure is set up for a message configuration, Any message pertaining to any step in a network job can be tracked and retransmitted if necessary. It provides a mapping of the logical structure of any network job into their appropriate message configuration. Net Controller ------------------------------- | | | NJID(1) NJID(2) - - - NJID(N) ---------------------- . . . . . | | Stepname Stepname ------------------------------- | | | LMID(1) LMID(2) LMID(n) ----------------------------------- | | LMSN(1) LMSN(2) LMSN(n) The Express Exchange is a combination of functions. It is basically a communication handler and store and forward switch. The 'EE' has the ability to keep track of all messages in the network by TEN (defined earlier). It is therefore possible to record and reflect the entire status of the network down to any detail desired. PROTOCOL The protocol for operating a network system has different levels of control. The 'EE' must exercise control on the communication link between any pair of stations. The NC maintains control at the net job level. However, the functions that each unit performs are combined to handle special control cases. These complimentary functions will be discussed in detail as they arise in the protocol discussion. [Page 6]
First of all, there must be a series of initialization messages sent from one station to another before any actual message transmission takes place. These messages are sent between each station and positive acknowledgments must be received in order to complete the initial hand shaking. At any point during the transmission of messages an error can occur which will be detected by a negative acknowledgement. The message in error will be retransmitted several times. If the error persists, the line is timed out and will be retried later. The assumption here is the line may be temporarily noisy and we give it time to quiesce. When a station receives an initialization message it is possible to respond in several ways depending on the status of the user system. (1) The station receiving the initialization message can acknowledge that it is ready to receive and transmit. (2) Temporarily cannot receive certain logical messages (actual data transmissions) but can receive special control messages. This option allows a user system to selectively process net jobs as facilities on his system become available. (3) Unable to receive traffic (in other words, the user system is logically or physically disconnected from the network). (4) Unable to receive new network job requests but able to handle traffic for jobs in progress. The user system may have several jobs in progress that are transmitting and receiving messages. This acknowledgement gives the user system the ability to allow these jobs to continue normal processing. The last alternative gives the CI at each user system the mechanism to selectively demultiplex itself to handling one logical message. The temporarily deactivated. Thus, all user systems can selectively halt messages throughout the entire network. The destination system can selectively halt all messages for a given NJID or selective halt logical messages within a net job. The adjacent system would keep accepting messages until its buffers were filled to some operational threshold limit that must be maintained to keep the network from coming to a complete standstill, and would issue selective halts to systems sending to it. It is conceivable that the message blocks of one logical message would be stored in distributed segments throughout the network. The same selective halt mechanism can be applied in reverse through a resume message. The resume message can apply to an entire set of messages for a net job or selective logical messages within a job. The reinitiation of a transmission takes place between any two stations that wish to allow more message blocks to be transmitted. The destination [Page 7]
station must resume on a particular logical message to allow the message to reach its final destination and complete transmission through the network. The LMID of the message header enables the 'EE' and 'NC' to cooperate in controlling and cleaning up network operation. Not only does this cooperation between logical levels reduce a duplication of effort but it enables the control to become realistic and practical. Complete separation of communications and control functions could cause a loss of useful information that may not be obtained by other means. For example, if a file transmission consisted of many blocks and a transmission error occurred that the network was unable to recover. The 'EE' would notify the 'NC' of the error occurrence on this file transmission and then 'NC' would issue purge messages to the 'EE's for those particular 'logic message' blocks. This mechanism-allows a general 'clean-up' and management of all file transmissions. There is also the condition when a receiving system goes down. When this occurs there may be a number of network jobs involved with that user system. If the user system remains down for an extended period of time and the 'EE' buffer resources are filled to threshold limit, it may be necessary to purge pending message blocks. The 'EE' will notify the 'NC' of the user system being down and the 'NC' will issue purge commands to the 'EE' for all pending messages of those netjobs involved with the down user system. However, in our present implementation the 'EE' uses disk storage as a logical extension of core for message buffering. In this operation, the freeing of real core buffers becomes a simple matter of moving the messages on to disk for later retrieval. In some instances of transmission a file may be scored in segments at several locations until the receiving system is able to receive it. Network buffer resources are treated as a logically simple entity that may be physically distributed. When the user system comes back on the air the involved user network job will be restarted by issuing resume transmit commands to the 'EE'. If the user is, an interactive user controlling the network, he would be notifed of the problem and status of his file transmission. He could then reinstate his command at a later time. The batch network jab would be restarted at a point where no unnecessary retransmission would occur. It has not been determined how long files should reside in a store and forward node before being purged from the network. If a backing storage device is available to network operation, the file can remain for a longer time but still not indefinitely. [Page 8]
NC PROTOCOL The File Transmission Protocol of the 'NC' is primarily concerned with the control and transfer of user files for storage, temporary use at a remote system, and execution. The commands and status messages that pertain to the second level logic of the 'NC' are sent and interpreted by the sending and receiving systems. All initiation of file transfers result from direct user commands to the 'NC'. The sending system will first be interrogated to determine if the file is resident at that system. The user must provide the necessary information to locate the file if it is not catalogued at that system. This information consists of the physical attributes, such as volume and serial number. A negative acknowledgement to this message would result in the termination of a net job step with the reason for termination returned to the originator. When a positive acknowledgement is received by the 'NC' it has two options available. It must first determine the amount of unused buffer space in the 'EE' and based on the size of the file to be transferred, decide whether to have the data set sent immediately or wait for an acknowledgement to the receive message. If the 'NC' decides to move the file regardless of the state of the receiving system, the 'NC' will issue a send or receive message to both systems simultaneously. A negative response to the 'receive' message is taken as a definite refusal by the receiving system to accept the data transmission. This may result from insufficient resources to handle the job. If the file was transmitted from the receiving system and is resident in the network storage facilities, the user will be notified of its exact location so that he may move it from that point at a later time. If the 'NC' chose the second option, the file would still be resident at the originating system. A positive acknowledgement will allow the file to continue its normal flow through the network. Queuing in the 'EE' is always done in order that 'receive' messages will be sent before the actual data files. The possibilities include loading the file directly into the job stream (this step assumes the appropriate JCL is included in the text of the files) or cataloguing the file at the remote system or storing it for temporary immediate use. All network files are catalogues with a unique name that includes User ID (unique at his home node), home node ID (unique in the network) and his own data name which is unique in his own work. The 'receive' message may also contain some special instructions to print or punch a file. [Page 9]
When the sending and receiving stations have completed the file transfer, they send status messages back to the 'NC' indicating the completed action. These status messages enable the 'NC' to keep a record of user network job steps and their progress through the network. These status messages play an important part in insuring proper checkpoint restart for the network. Files routed specifically for execution require a third status message from the receiving user system. The system must indicate when and how the job completed execution. This status message will also contain the appropriate accounting information to allow dynamic updating of network user and system accounting information. It is not clear at this time what should be accounted for in the network, but it is an area of prime concern to operational networks. An error in the second logic level can occur during the file transmission. There may be an error moving files from devices into the line buffers or reading from the line buffers. When this occurs, the operating system must pass this information to the 'NC'. The 'NC' will then terminate the task involved in this job step and purge all the network buffers containing blocks of this message transmission. When the 'NC' receives the file error message it will immediately send a 'release' message to all the network tasks supporting this job step. This action will cause the user systems to end all pending tasks associated with this net job step. In addition a purge message for that job step will be sent to the 'EE' to purge the message from its buffers. If there is more than one 'EE' involved, the purge message would be passed to all other 'EE's. This is another example of the 'EE' and 'NC' combining functional capability and providing effective management of network traffic. The mapping of message Into the job step allows the 'NC' to selectively choose all messages it wishes to purge. The protocol the user must use for interactive use of the network is different, There are some standard message types that are provided for interactive use to insure the proper message recognition from one system to another, Terminal type traffic will be sent across the network through the normal netting' interface, The control information that a terminal sends to the operating system must be incorporated in the network protocol by the 'CI'. The interactive user can request a direct connection to the remote system through the 'NC'. The 'NC' will notify the remote system of the user request and establish the user's direct link, The 'NC' becomes a monitor of the conversation but no longer becomes involved with the messages. Other conversational messages are sent back and forth through [Page 10]
the 'EE' with no interaction by the 'NC'. In the event one of the systems goes down breaking the logical link, the 'NC' must notify the other system to terminate the waiting task, In most cases a user system will be isolated from the second user system by other stations and the 'NC' is a convenient way of notifying other user systems about the "disaster." Once the user's connection is established, three types of messages may be generated, These messages are identified by the 'AC' field in the header. The three basic transmission types covered by the protocol are: a response requested - with or without text included in the message, a text message which is simply a response to the first or just data to be printed at the user's terminal, and finally, an interrupt message which indicates the user wishes to stop a task or talk directly to the operating system. It is important to note that regardless of what type of conditions exist, there are always enough buffers left to receive an interrupt message and terminate or flush any existing task and the associated operation it may be supporting. CONCLUSION The protocol concepts discussed in this paper were developed to facilitate the transfer of data between two or more independent systems. The protocol is able to handle the various pathological cases that may arise during network operation, A fundamental design consideration in developing these concepts was to maintain complete recovery from any recoverable error condition. Many of the concepts have been used in an operational star network, with a single 'EE' and 'NC' located in the central system and a 'CI' located at each participating system. The successful operation of the network has proven the feasibility of this protocol. ACKNOWLEDGMENT The authors wish to acknowledge the design and implementation effort of the contributing members of the Computer Science Department of the T. J. Watson Research Center. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Tim Buck 5/97 ] [Page 11]