rfc187.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 590 行 · 第 1/2 页

           |             |             |
        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]