rfc705.txt

RFC 相关的技术文档

Network Working Group
Request for Comments:  705
NIC# 33644
                                                         




                         FRONT - END PROTOCOL
    
                            B6700 VERSION




                           2 September 1975


This is a working document which has been developed as the specification 
and guideline for design of a Burroughs B6700 attachment to an ARPA-Style
network.

The approach is to utilize a front-end processor with a new protocol for 
network operation.  That protocol, described herein, has been built upon
the concepts expressed by M.A. Padlipsky, et al, in NIC# 31117, RFC# 647.

This proposed, site-specific, FEP implementation is the work of Gerald 
Bailey and Keith McCloghrie of NSA and of David Grothe of ACC.  It has 
already sustained some corrections provided by MAP.  It will be helpful
if interested networkers will review and provide comments to us.

Comments to BRYAN@ISI.

Roland Bryan - ACC							1



Network Working Group
Request for Comments:  705
Front-End Protocol: B6700 Version



                        ***WORKING DOCUMENT***


                          FRONT-END PROTOCOL


                               PREFACE

This document describes the protocol to be used for connecting a general-
purpose computer system (host) to an ARPANET-like network via a "front-end" 
computer.  The main body of the document is aimed at a reader who is not 
conversant with all the details of network protocols.  However, a paragraph
marked with [n], refers a reader familiar with network protocols to the
n-th item of Appendix A which will amplify that particular paragraph.  
Further information on the network protocols referred to in this document 
can be obtained from the Network Information Center.

Appendix B contains diagrams showing the transitions between the different
connection states.  Appendices C and D give the implementation details of 
this protocol in the Front-End and the Hosts.

This protocol is predicated upon the assumption that for each host, a line
protocol, at a lower level, will be established between the device-driver
modules in the Host and the Front-End, and that this line protocol provides
Front-End Protocol with error-free transmissions.


                             INTRODUCTION				2

A host computer may be connected to a network for a variety of reasons.  
Network connection may be an attempt to expand the usefulness of the
Host to the community of users which it serves by making network resources
available to them.  Conversely, the services which the Host provides may 
be made available to a larger community of users, with the network providing 
the method of access to those services.

In order for members of a network community to communicate in an intelligent 
way, there must exist a set of protocols.  The implementation of these 
protocols in a host computer is typically called the Network Control Program
(NCP).  The size and complexity of the NCP is proportional to the number and 
complexity of protocols which it implements.  For an ARPANET like network,
both the number and complexity are substantial.


                       ***WORKING DOCUMENT***


                                 1



RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


A host which directly connects into the network must assume the responsibility
for implementing this set of protocols.  That is the "price of admission"
to become a network host.  It is not necessary to implement every protocol
and every option in every host, but even in the simplest case -- implementation
of an NCP is not a small task.  The intrusion into the normal operating
environment of the host is also not small.

An alternative method for network connection is to connect the host to some
intermediate processor, and in turn, directly connect that processor to the
network.  This approach is called "Front-Ending."  There are many arguments
which may be posed to justify a host connection to a network through a front-
end processor.  The most obvious being that the responsibility for 
implementation of the network protocols (the NCP) can be delegated to the
front-end (FE), thereby reducing the impact on the host.

The purpose of this document is not to justify Front-Ending as a philosophy,
but rather, to introduce a protocol for communications between a host and
a front-end processor which is providing it network access.  The Front End
Protocol (FEP) is intended to permit the host to make use of the network 
through existing protocols, without requiring that it be cognizant of the 
complexities and implementation detail inherent in their execution.

The FEP is sufficiently general to permit its implementation in the host 
to be in terms of the function the host is performing, or the services
which it is providing.  Of primary consideration in specification of FEP
was that it must provide the host with a sufficiently robust command 
repertoire to perform its network tasks, while buffering it from the
details of network protocols.


                               CONCEPTS					3

Introduction								3a

Before a detailed description of the command structures is undertaken it 
seems appropriate to introduce several of the concepts upon which the FEP
is predicated.

The following section serves to briefly describe the FEP commands, and to
elaborate on the concepts of addressing and types of connections provided.



                       ***WORKING DOCUMENT***


                                  2

RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


Commands  (General)							3b

1.  BEGIN Command

This command is sent from the host to the front-end processor.  Its function
is to direct the establishment of one or more network connections.  The type
and number of connections is specified in the BEGIN command string.

2.  LISTEN Command

Through this command the host indicates its willingness to accept requests
for connection arriving from other hosts.  It directs the front-end processor
to LISTEN for any such connection requests.  The number and type of 
connections are specified in the command string.

3.  RESPONSE Command

The front-end processor uses the RESPONSE command to indicate to the host that
a particular path specified in a BEGIN or LISTEN command is now open or that
the open attempt failed.

4.  MESSAGE Command

Message text passing between the host and its front-end processor is sent in
this command string.  The MESSAGE command is bi-directional, and is the same 
for host or front-end.

5.  INTERRUPT Command

The INTERRUPT command is sent by either the host of FE.  Its most common use is
to convey that the user wishes to terminate what he is doing - i.e., he has 
depressed the Control-C, ATTN, or INT key.

6.  END Command

One or more connections may be closed by either the FE or the host issuing
this command.  The connection(s) which are affected by the action of the END  
are specified in the command string.

7.  REPLY Command

This command is required to be sent by both the host and FE to acknowledge
receipt of all command types (except REPLY).  The success or failure of the
command being acknowledged is conveyed in the REPLY command string.



                       ***WORKING DOCUMENT***
                                 

                                 3


RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***



Connections								  3c

In order to engage in a meaningful conversation, the parties involved must
be connected.  A network connection is defined by the ARPA Host-Host Protocol
document (Nic #8246) as follows : "A connection couples two processes so
that output from one process is input to the other.  Connections are defined
to be unidirectional, so two connections are necessary if a pair of processes
are to converse in both directions."  The components of a connection, the
sockets, are defined: "... a socket forms the  reference for one end of a
connection, and a connection is fully specified by a pair of sockets.  A 
socket is identified by a Host number and a 32-bit socket number.  The same
number in different Hosts represents different sockets."

The existing network protocols incorporate prescribed strategies for 
selecting socket assignments, pairing sockets to form connections, and in 
the number of connections required to implement the protocol.

Conversations, in most cases, are bi-directional.  Thus to simplify the
Host's procedures in these cases, FEP permits duplex connections on which
the Host can both send and receive.  Send only and Receive only connections 
are also available for those situations where communication is one-way.

Thus, FEP provides the flexibility to reduce complexity in the Host, in
addition to accommodating existing protocols and allowing for the 
development of new protocols.

Addressing								3d

Conversations in FEP are uniquely identified at initiation by some combination
of Host address, Index number, Path number and Socket assignment.  The Host 
address and Socket assignment are required to form the connection(s); there-
after the Index and Path are sufficient to identify the conversation.

Host Address

If, through the BEGIN command, the local Host explicitly directs the creation
of network connection(s), it must specify the address of the foreign host to
which it desires communication.  If the local host indicates a willingness to
communicate, through the LISTEN command, the Front-End processor will supply 
the address of the connecting foreign host(s) in its RESPONSE command(s).


                     ***WORKING DOCUMENT***


                                 4


RFC 705
Front-End Protocol


                     ***WORKING DOCUMENT***

	
Socket

A socket is either a send socket or a receive socket.  This property is 
called the socket's gender.  The sockets at either end of a network 
connection must be of opposite gender.  As previously defined a socket
forms the reference for one end of a network connection.  To the extent
possible, the FEP shields the Host from the responsibility of assigning
sockets for individual conversations.  However, because the 
socket is a fundamental part of the addressing mechanism of the network,
the Host may need to be aware of socket assignments when establishing
connections.

It is through a "well-advertised" socket that a host provides services
to other members of the network community.  The Initial Connection 
Protocol (ICP) [1] is used to first connect to the well-advertised socket
in order to exchange the number of a presently unused socket which is then
used for the connections required so that the well-advertised socket can
be freed for others attempting to connect.

When establishing a conversation (with a BEGIN or LISTEN command) the 
Host indicates in the value of the CONN-TYPE field whether the socket 
specified is to be employed directly, or to be used as an initial 
connection socket.

Index/Path Addressing							3e

Indexes are values assigned by the local Host to identify network con-
versations.  When conversations are established (with the BEGIN or LISTEN 
commands) the Host must specify an index value.  This value will be
associated with the resultant conversations for their duration.

It is often necessary to affiliate conversations [2].  To accommodate this, 
data paths are defined such that each index has one or more path(s) 
associated with it (a path can not exist except as a subordinate to an
index) and all network communication is transmitted on some path.

The maximum number of indexes which may be in use at any one time, and the
maximum number of paths within one index are installation parameters.

Index 0 is reserved for controlling other indexes, and logically represent the
"pipe" through which all other indexes "flow."



                       ***WORKING DOCUMENT***


                                 5



RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***


Addresses in FEP command strings are conveyed by the pair of fields "INDEX"
and "PATH."  In commands which cause new indexes to be opened, or new data 
paths to be added to an existing index (BEGIN or LISTEN), the PATH field 
indicates the first path to be acted upon by this command.  For those
commands which do not create new paths or indexes, if PATH is 0, then all
paths associated with this INDEX are addressed; if PATH is non-zero, only the 
specific path within the specified INDEX is addressed.

Path Types								3f

A path can be one of three types:

	a.  DUPLEX - both the Host and the FE can issue MESSAGE commands
	    on the path.

	b.  SEND - only the Host can issue MESSAGE commands on the path.

	c.  RECEIVE - only the FE can issue MESSAGE commands on the path.

The paths within an index may be a mixture of path types but one BEGIN/
LISTEN must be used for each contiguous set of the same type.

An FEP path is analogous to a network connection with the following exception.
Network connections are always simplex.  This is true for paths of type SEND
or RECEIVE.  However, a DUPLEX path is formed by the FE connecting two local
sockets to two foreign sockets.  This is a "duplex connection" which is
composed of two network (simplex) connections.

Modes of Establishing a Path						3g

One or more paths are established by the action of a single BEGIN or LISTEN
command, with the mode specified in the CONN-TYPE field of the command.
Each of the path types is established in one of two modes - directly or via 
ICP.  The gender of the path (its ability to receive or send or both) is not
affected by the mode.

When any of the path types is specified with the ICP mode, the socket value
in the SOCKET field is used as the "well-advertised" socket and an actual
working socket will be exchanged according to the Initial Connection Protocol.
When the direct mode is indicated, the specified socket is used as the working
socket.



                        ***WORKING DOCUMENT***


                                 6

RFC 705
Front-End Protocol


                        ***WORKING DOCUMENT***



In either mode, when multiple paths are indicated, the next higher socket
number values of the appropriate gender are selected for each path. [3]

Translation								3h