Jump Over Left Menu
PROTOCOLS IN THE SERC/NERC NETWORK
8 March 1982
- PART A : LINK LEVEL (Level 2)
- Binary Synchronous Protocol (BSC)
- BSC Data Record Format
- X25 Level 2 Protocol (HDLC)
- PART B : PACKET LEVEL (Level 3)
- Special Features in SERCnet
- PART C : TRANSPORT LEVEL (Level 4)
- Transport Service Primitives
- CONNECT Primitive
- DISCONNECT Primitive
- RESET Primitive
- Application Interface to Transport Service
- PART D : APPLICATION LEVEL
- X29 and TS29
- PART E : REFERENCES
- APPENDIX 1: CLEARING CAUSE AND DIAGNOSTIC CODE FIELDS
- APPENDIX 2: DEVICE TYPES (for ITP)
- APPENDIX 3: BATCH CLASSES (for ITP)
- APPENDIX 4: LOCAL PARAMETERS SPECIFIABLE (for ITP)
An attempt has been made to bring all parts of this paper up to date at the time of writing. The paper describes the various protocols used in the SERC/NERC Network, in sufficient detail to be useful as a guide for implementors. It also aims to give a descriptive overview, especially in the Introduction. Where a protocol is defined in detail in other publications, as for instance PSS X25 Level 3, full details are not repeated here; it is sufficient in such cases to refer to the base publication and indicate how the SERC/NERC version is related to it. In the case of ITP the full specification is given, as there is no published document giving the relevant information.
An effort has been made to use consistent terminology throughout, though this is not always possible where severals levels are involved. The full name SERC/NERC Network is abbreviated hereafter to SERCnet. The term connection is normally used in the sense of a Transport Level connection between two Application processes. In general this can span multiple networks. The word call belongs to Level 3, as for instance when discussing an X25 call across a single network. Where it is not necessary to distinguish between calls and connections, the tendency will be to use the term call, as it has less extraneous meanings. The term host is used to denote a machine or system connected to the network, containing Application level software. When discussing Level 3 concepts, the British Telecom term DTE is preferred instead of host. An exchange is part of the network itself: it enables calls to be set up between any pair of hosts. When discussing Level 3, an exchange is commonly called a DCE. A gateway is a special type of host, whose function is to link two or more networks together; it contains software at least up to Transport Level, and may also have software for mapping high level protocols between the networks, and probably some access control and monitoring software.
The function of SERCnet is to interconnect in a flexible manner a number of geographically separated computer installations. In particular, no assumptions are made about the type of computing equipment at each host site, and the design is open-ended so that further sites may be connected to the network when required. The network as a whole may be connected to other networks via gateways. For instance, there is a gateway between SERCnet and the British Telecom PSS network.
Interconnectivity and flexibility are achieved by the adoption, wherever possible, of protocols which are becoming accepted as standards, and by using them in a properly layered manner, each layer forming a self- contained (and thus independently replaceable) component.
Although the paper describes the levels in detail in a bottom-up direction because this is technically more convenient, it is useful to present a general picture first by starting at the highest level.
The high level, or Application, protocols are the tools directly available to the user. Protocols currently in use on the network include HASP, ITP, FTP, X29 and TS29. JTMP is likely to be added shortly. HASP provides the sort of service available through remote workstations with readers, printers and punches, communicating with a distant mainframe; however, in a network context the same physical workstation may be used to access more than one host simultaneously, and the hosts may be of different types. ITP provides a means of connecting teletype- compatible terminals to a host and thence accessing the interactive services provided by any other host. FTP provides a method of shipping data or job files from one host to another. X29 is the CCITT-specified standard protocol for interactive terminals over X25, and TS29 is a variant of this usable over any type of network. JTMP is the new Job Transfer and Manipulation Protocol, which will in due course supplant HASP.
To carry such protocols across a network, a general mechanism of some kind is normally required, and this has come to be referred to as the Transport Service. The software which provides this service in a particular host may be called a Transport Station. The functions of the Transport Service are firstly to provide all the end-to- end facilities likely to be needed for driving any Application protocol, and secondly to insulate Applications from the characteristics of particular networks. The former function may require a certain amount of extra control information to flow between the two ends, thus giving rise to what may be called a transport protocol; the latter function, network independence, requires the provision of a flexible and general interface between the Application software and the Transport Level. The most basic facility provided by the Transport Service is to allow a "connection" to be set up between any two Transport Stations. This connection then provides the full-duplex logical path along which the Application level data can flow. A subset of the PSS Study Group 3 Transport Service is used by SERCnet.
A connection may pass through a series of networks joined by gateways, and within each network through a series of exchanges. A lower-level mechanism is therefore needed to handle the various separate interfaces, and to provide the means for multiplexing many connections on the same physical transmission media. The multiplexing of connections also involves a switching function in exchanges and gateways, because different connections will in general be between different host machines. The requisite lower-level mechanism is provided by the Packet Level protocol, which in SERCnet is a subset of the PSS X25 Level 3 protocol.
The Packet Level protocol provides the mechanism for setting up a call between any two hosts on a single network. If only one network is involved, there is a one- to-one correspondence between the call and the connection, and it is then convenient to talk simply in terms of calls. If there are multiple interconnected networks, however, the end-to-end connection is made up of a series of calls, one across each intervening network. Use of the Packet Level protocol involves dividing up the higher level data into convenient amounts to go into packets, and adding to the front of each packet a header containing routing, sequencing and flow-control information. There are also special control packets for such functions as setting up, clearing and resetting calls. Each packet is thus individually identified as belonging to a particular call, and the packets can be multiplexed and switched as necessary within the network. Packets may contain any length of data up to the maximum imposed by the network.
Finally, there is the task of controlling transmission on each individual link. The standard here is X25 Level 2, often referred to as HDLC. SERCnet supports IBM Binary Synchronous protocol in addition to HDLC, but it is envisaged that eventually Binary Synchronous will be phased out.
PART A: LINK LEVEL (Level 2)
Two alternative Level 2 protocols are in use, namely IBM Binary Synchronous and X25 Level 2 (HDLC).
2. IBM Binary Synchronous Protocol (BSC)
This was the original SERCnet Level 2 protocol, and details are given here as there is no other document defining the SERCnet subset. The subset corresponds basically to that used by HASP MULTILEAVING for transparent working. A few salient features, including the deviations from HASP usage, are mentioned below.
The only control sequences recognised are:
SOH ENQ (line initialisation) DLE ACK0 (positive acknowledgement) NAK (negative acknowledgement)
Data blocks are introduced by DLE STX, followed by a Block Control Byte (BCB) containing the modulo-16 sequence number, and a 2-byte Function Control Sequence (FCS). Only the second bit of the FCS is used: this is the WAIT- A-BIT signal (WABT), whose meaning is the same as in HASP. The FCS is followed by data in the form of one or more records. The format of a record is defined in the next section, but it may be noted at this point that no RCBs or SRCBs, as defined by HASP, are present. The last record in the block is followed by DLE ETB and a 16-bit cyclic redundancy check.
|BSC CONTROL BYTES||RECORDS|
REC1 | REC2 | -----
At the present time the maximum block size is 270 bytes, and only one record is allowed in each block. It is undesirable, however, to entrench these limitations too rigidly in the software. Larger blocks containing multiple records may be desirable on some links.
A null buffer is defined as a data block containing a single record which begins with a zero byte.
The protocol is unsymmetrical in certain respects. The main unsymmetrical feature is that only one end is allowed to send SOH ENQ; the other end must be prepared to recognise SOH ENQ as input at any time. The normal response to SOH ENQ is DLE ACK0. SOH ENQ is sent by the initiating end when it first wishes to make contact, and typically is repeated at one-second intervals until the responding end replies. The initiating end may subsequently send SOH ENQ, if at any time it wants to restart the line from scratch, or if lack of responses from the other end suggests that contact has been lost. The responding end may effectively force a line restart, by refusing to respond to anything except SOH ENQ. (It may also force the other end to send SOH ENQ, by sending a one-byte ENQ signal, if use of this protocol extension has been agreed for the link concerned). The initiating end should use a smaller timeout constant than the responding end, for instance two seconds compared with three. Either end should transmit NAK if a timeout occurs.
A line restart (at either end) should automatically cause a signal to be passed to the Packet Level software, telling it to clear all calls using the line and issue Clear Request Packets accordingly.
Each end is responsible for protecting itself from line thrashing to the extent it considers necessary, by introducing suitable delays when the line is in an idling state. Large delays should be avoided, because full duplex protocols are likely to be carried: this differs from the situation where HASP only is involved. For example, in the MVT system at RL, delays of 200 mS are introduced when the line begins to idle, and this is increased to over 1 second when the line has been continuously idling for half a minute or so. Each end may also take what measures it thinks fit, to deal with continuous line errors, or protracted lack of response. It is advisable in these circumstances to discard any queued outgoing packets which cannot be transmitted, and then to insist upon a line restart. Until the line restart takes place, either no further packets should be queued for the line, or they should be searched for and discarded periodically.
To maintain synchronisation during transmission of data blocks, DLE SYN must be inserted once per second as a synchronisation signal. This is unlikely to occur in practice unless longer blocks are used in the future, but in principle the receiving end must be able to detect and discard DLE SYNs within the data.
If DLE occurs as a data character, it is doubled up for transmission purposes in the normal manner, to distinguish it from DLE as an escape character.
The recovery procedures provided at link level should ideally eliminate all need for manual intervention in the software. Even in the event of hardware failures requiring a line to be taken out of service, other lines, if any, should not be affected, and the software should recover the failed line automatically as soon as the hardware has been reconnected.
3. BSC Data Record Format
A BSC data block contains a series of records as previously stated, the maximum number of records being one at present. The records lie adjacent to one another in the block, with no intervening control bytes.
A record (other than in a null buffer - see previous section) consists of an X25 packet preceded by a special two-byte prefix:
Bits 0 - 5 : 001001 Bits 6 - 15 : L, the length of the packet, excluding prefix and next 3 bytes
The definition of L is such that it indicates the actual data length in data packets.
Data packets have a maximum data length of 256 bytes.
4. X25 Level 2 Protocol (HDLC)
PSS-compatible LAPB is the preferred version of HDLC. At the present time, LAP is also supported, but this will probably be a temporary feature and no new implementations should use it.
Implementors should refer to Ref. M2, which is the appropriate British Telecom Technical Guide.
Part B: PACKET LEVEL (Level 3)
The network supports a subset of PSS X25 Level 3, for details of which the implementor should refer to Ref. M2.
The most common packet-size maximum negotiated on SERCnet is 256 bytes, but many hosts also support 128 bytes. For driving the HASP protocol, the 256 byte maximum is mandatory.
Most DTEs have not implemented RESET packets and will clear the call is a RESET packet is received. A DTE must handle incoming RESTART packets properly, by clearing all calls on the affected link and returning a RESTART CONFIRMATION packet.
2. Special Features in SERCnet
This Section identifies the most important ways in which the protocol used by SERCnet differs from that used by PSS.
The SERCnet Level 3 protocol is a subset of PSS X25, which does not support DTE REJECT packets, Call Re-direction, Call Statistics, PVCs, CUGs, or packet sizes greater than 256 bytes.
The use of LCNs differs from PSS practice in that a DCE always assigns LCNs from group 2. A DTE may use LCNs in any group allowed by PSS and the maximum LCN to be used (by both DTE and DCE) may be fixed at subscription time.
At the time of writing, some transitional features are still present: A DTE must specify FAST SELECT, and must give explicit packet and window size values in the Facilities field of the Call Request packet. The receiving end may negotiate downwards if it wishes, but it should in any case return explicit values in the Call Accepted packet. Failure to observe these requirements will lead to difficulties when the final stage in the PSS compatibility exercise takes place: this involves changing the defaulting rules that apply to non FAST SELECT calls, to bring them into line with PSS.
PART C: TRANSPORT LEVEL (Level 4)
A Transport Service which is a subset of the PSS Study Group 3 Transport Service is implemented in SERCnet.
The main function of the Transport Service is to provide a standardised set of primitives that can be used by any Application process. This insulates Applications from whatever lies below, making it possible in principle to drive the Application across any set of networks. The Transport Service implementation in a particular host is tailored to the type of network to which it directly interfaces, and it ensures that the quality of service offered to the Application is brought up to a certain minimum standard. In this sense the Transport Service may be thought of as providing a Global Network Layer.
A particular encoding of the Study Group 3 Transport Service is defined for interfacing it to PSS-compatible X25 networks. It is this encoding that SERCnet uses.
The CCITT-defined X29 protocol for terminals cannot be driven over the Transport Service because it makes direct use of certain special features of X25, such as the Q-bit. In effect, X29 uses a private Transport Service of its own which is not separable from the terminal protocol proper. What this means in practice is that implementations must have special Transport Level code to deal with X29, alongside the Study Group 3 Transport Service code used by all other Application protocols. X29 is not discussed further in this part of the paper, but is included amongst the Application protocols.
2. Transport Service Primitives
Eight primitives are defined, namely CONNECT, ACCEPT, DISCONNECT, ADDRESS, PUSH, EXPEDITED, RESET, and DATA. Of these, most SERCnet hosts have implemented at least CONNECT, ACCEPT, DISCONNECT, PUSH and DATA. All implementations should be capable of interworking with full implementations, but arrival of a RESET is likely to cause closure of the connection.
It will be noted that primitives are defined only for those functions capable of causing a transfer of information to the other end. Purely local functions, such as listening for an incoming connection request, being willing to receive data, or managing buffers are not defined.
Primitives requiring special comment are discussed in the following sections.
3. CONNECT Primitive
The CONNECT primitive establishes a connection with a remote Transport Station, and carries Transport level destination and source addressing. SERCnet, though compatible with the Study Group 3 CONNECT, imposes the following restrictions, conforming to Ref. M1. The CONNECT message must fit entirely into the Call User Data Field (CUDF) of an X25 Call Request Packet and there must be no Application level data in the CUDF. The restrictions were imposed on the assumption that PSS 'FAST SELECT' formats will normally be used; these allow a CUDF of up to 128 bytes. At the present time, the 'quality of service', and 'explanatory text' parameters are not defined, and if present are liable to be discarded by the receiver.
The Transport Level addressing information in the destination and source address fields conforms to the Study Group 3 proposals, which were designed to facilitate interworking between multiple networks joined by gateways.
The SERCnet addressing scheme is described in Refs. A4 and A5.
If the first byte of the CUDF in a Call Request packet is set to X'CC' rather than to X'7F', this is interpreted as a request not to send a Transport Service ACCEPT message or other types of Transport Service control message. The use of X'CC' is a transitional feature, and at the time of writing it is still used or required by some SERCnet hosts. It is expected to disappear within about 3 months.
4. DISCONNECT Primitive
In a minimal implementation, a connection may be cleared by sending a DISCONNECT in the form of an X25 Clear Request. If a DISCONNECT control message is received, an X25 Clear Request may likewise be sent.
5. RESET Primitive
In a minimal implementation, a host which receives a RESET must at least close the connection, if it is not able to process RESETs more fully.
6. Application Interface to Transport Service
It should be noted that the Transport Service defines a set of primitives for Applications, rather than an explicit procedural interface. It is no doubt desirable to work towards standard procedural interfaces for particular high level languages, but this remains a task for the future and is not essential to achieve a working implementation.
The details of the interface are thus at present at the discretion of the implementor, the aim being to support as fully as necessary the Transport Service primitives. The following general considerations are likely to apply in most cases.
The implementor needs to provide a mechanism for sending CONNECT and receiving ACCEPT messages, and vice versa. No data, and no RESETs, should be sent after a CONNECT until an ACCEPT has arrived, but a DISCONNECT may be sent immediately after a CONNECT if necessary. An ACCEPT may be followed immediately by data. DISCONNECT in the form of an X25 Clear Request must be able to get through under all circumstances, and anything still in transit may be discarded. EXPEDITED, if implemented, needs to by-pass the normal flow control provisions, so it is desirable to provide in some way a full-duplex control channel in parallel with the normal full-duplex data channel. The Application process should have some way of specifying PUSH (or otherwise) when it sends data, and some way of indicating whether it is sending an ADDRESS message or not, if the ADDRESS primitive is likely to be implemented. Although the DATA primitive is defined in terms of single bytes, it is unlikely to be sensible for the Application to pass single bytes to the Transport Station or vice versa. An interface is required that can handle groups of bytes, probably in the form of Application level records or blocks of records.
The Transport Service PUSH primitive may be safely used to delimit Application Level records, as well as to force delivery without delay of all previous data. If data is sent without a following PUSH, the Transport Service will normally postpone its transmission until a full network packet has been built up.
PART D: APPLICATION LEVEL
The network currently carries a number of high level protocols including HASP, ITP, FTP, X29 and TS29. Fairly soon, JTMP will be added to the list.
To simplify the description, a single-network environment is assumed and the term call is used rather than connection. It should be remembered, however, that these protocols (except X29) can also be carried across multiple networks in series, as they run on top of a network independent Transport Service.
HASP as an Application must not of course be confused with the use of BSC protocol at link level. They have nothing whatever to do with one another.
HASP MULTILEAVING was designed by IBM as a half-duplex protocol, in which the mainframe and the workstation transmit alternately. For reasons of efficiency, it has been converted into a full-duplex protocol for use across the network, and this makes it possible to eliminate all the unnecessary handshaking that would otherwise take place.
- Making a HASP Call: A call must be made to the appropriate network address and sub-address. The first data packet should contain the usual HASP SIGNON request, but the remote number is not taken from here: it is communicated as part of the network sub-address at call set-up time. It should be noted that SOH ENQ is not used at this level.
- Breaking a HASP Call: A Transport Level DISCONNECT from the workstation end (or a SIGNOFF request, if all the streams are drained) will suffice to release all resources at the server end. If the server wishes to break the HASP call, it may send out its own DISCONNECT.
- HASP Protocol: The protocol carried inside the packets conforms to the protocol used on an ordinary line by a standard HASP workstation. The following special features should be noted however.
Each MULTILEAVING data block must be transmitted in a separate packet and must not be more than 252 bytes in length, including the DLE STX BCB FCS FCS control bytes on the front. The DLE ETB CRC CRC sequence which normally ends a block is not transmitted across the network, and is not included in the 252-byte maximum.
NAK signals and timeouts are inappropriate when the protocol is being driven across a network, and must not be used. Inclusion of a NAK signal in a packet constitutes a breach of protocol.
As the protocol is to be driven full-duplex, handshaking packets containing DLE ACK0 are redundant and may be eliminated. HASP null blocks should be sent only if they contain significant FCS information. Significant FCS information means an FCS field which turns on at least one bit which was formerly off, or vice versa. The format of the field is exactly as in ordinary HASP.
The HASP WAIT-A-BIT (WABT) mechanism must be handled locally at each end if necessary, so that the WABT bit is always zero in any packets actually sent out. Flow control across the network is handled by the call level, and WABT signals in packets are therefore not appropriate.
Because the call is full-duplex, an FCS field may be out of date by the time it arrives. The remote end must therefore be able to tolerate (even if unwillingly) the arrival of a complete window-full of packets for any given output stream. If the call traverses a lot of intervening links, and if link-by-link flow control is used, the possibility of mutual interference between streams is increased, because each link may accumulate a window-full of packets for the same stream, at the expense of other streams. This problem has now been greatly reduced as a result of the adoption of end-to-end flow control on the network.
3. ITP (Version 3, dated 18th December 1981)
The Interactive Terminal Protocol is designed to support communications between a user-driven interactive terminal and a service accessible via a network.
The SERC/NERC version was based on a small subset of the original EPSS ITP, but it has now diverged quite considerably from the latter, and would no longer be fully compatible with it. However, there is no likelihood of the original protocol being implemented anywhere.
This specification does not describe a user interface for ITP. It confines itself to describing the protocol as it appears in packets sent across the network. The symbol @ (not to be confused with the character @) is used to denote the network escape character (X'FF'). The symbol CR denotes the IA5 carriage return character, with parity-bit zero (X'0D').
The basic material handled by the protocol is an intermittent stream of bytes in each direction. The byte stream contains commands and data. All commands are introduced by @ and terminated by CR. The data consists of messages, which are terminated by message terminators. A message is the unit of communication at Application level - typically a line of input or output. There are two standard message terminators, namely the commands @ CR and @SCR as described below, but additional terminators may be defined by means of the @T command.
Commands must not be embedded within messages. Care is therefore needed to ensure that each message is terminated before any command (other than @ CR or @SCR) appears.
When the stream of bytes is transported across a network in packets, there is no relation whatever between the structure of the byte stream and the incidence of packet boundaries. Thus there may be many messages and/or commands in each packet, and packet boundaries may occur inside messages or commands.
The order of messages and commands in the byte stream is significant, and no re-ordering of either is permissible. In particular, commands must not overtake messages, unless the messages are actually discarded in the process, as with @Y. This means that commands, except @Y, may be held up behind queued data, if the latter cannot be immediately dealt with. Commands are not themselves subject to ITP- level flow control however (@G, @W, etc).
Commands are defined to be valid in both directions unless the contrary is stated. Any command which is not meaningful to the receiver, for instance because it is not implemented, should be tolerated but discarded.
The byte stream in each direction is assumed to begin with data, unless the first character is @. In practice the latter will always be the case, as each end is obliged to send at least an initial @G command. The character @ introduces a command unless it is immediately followed by another @, in which case the @ @ sequence is to be interpreted as a single X'FF' byte, treated as ordinary data. The character @ is invalid inside commands, whether or not it is followed by another @. As previously pointed out, the only commands which may validly begin within a message are the standard message terminators @ CR and @SCR.
All characters within a command are in IA5 code with parity-bit zero. Where alphabetic characters appear in commands, they must be in upper case. Every command except @ CR starts with an alphabetic character identifying the command, and some commands also have one or more parameters separated by commas. A parameter, though encoded in IA5 characters, normally represents a hexadecimal or decimal value. For instance, if the parameter of an @G command consists of the two IA5 characters '3C', this is to be interpreted as a hexadecimal value of X'3C'. The commands which have been defined are as follows:-
- @ CR means end of message, with an implied newline on the end. If there is no preceding data, a message of zero length (apart from the implied newline) is to be assumed. This command is one of the two standard message terminators. In binary mode, however, it is undefined and should be discarded if received.
- @SCR means end of message, without an implied newline on the end. If there is no preceding data, the command may be simply discarded by the receiver. This command is one of the two standard message terminators. In "binary" mode, it is the only standard message terminator.
- @ACR indicates that character mode is to be assumed from now on. The byte stream begins in this mode at the start of a call. Character mode implies that the data is in IA5 code, with parity-bit settings arbitrary, and is liable to be fed through a translate table at the receiving end.
- @BCR indicates that binary mode is to be assumed from now on. Binary mode means that the data is coded in a way unknown to the ITP level. Such data is therefore shipped transparently, and must not be subjected to translation at the receiving end. Message boundaries must, however, be marked by an @SCR or by some other defined terminator.
- @YCR provides a mechanism for resetting the call at ITP and Application levels. The sending end should discard any complete messages waiting for transmission, before queueing the @YCR. It should also arrange to discard all messages arriving from the network, until the @ZCR response arrives. The receiver of an @YCR must queue an @ZCR response. Where appropriate, the receiving end may pass on an interrupt signal to the Application level, causing the latter to cease outputting and listen for input. Not all systems may be able to provide an automatic Application level interrupt in this form; they may instead implement the basic @Y,@Z mechanism together with a separate Application level interrupt facility. However, an automatic mechanism is preferable where possible. If any of the @P facilities are in use, the issue of @YCR causes all knowledge of previous @P commands to be destroyed at both ends.
- @ZCR is the compulsory response to a received @YCR. If an automatic Application level interrupt mechanism is provided, the @ZCR response should be queued after the latter has taken effect.
- @GnnCR gives permission to the other end to send nn messages in addition to any messages it already has permission to send. The two IA5 characters, nn, denote a hexadecimal value (for instance @GD8CR denotes the value X'D8'), and a leading zero must be present if needed. @G00CR has a special meaning: it gives permission to send an unlimited number of messages. At the start of a call, neither end has permission to send any messages, so each end is obliged to send an initial @GnnCR.
- @WCR resets to zero the permission counter incremented by the last @G command. Thus, on receipt of @WCR, the receiver has no permission to send any messages (though there may be some in transit).
@Ts,t,xxyyzzCR defines how the end sending the
command will interpret what it receives, in terms of
The parameters are all composed of IA5 characters denoting numeric values.
s is the maximum acceptable message size (including the terminator) expressed in decimal form. The number may be from 1 to 5 digits in length. This parameter should be treated as a warning that if messages longer than this are received, they are liable to be truncated. If zero is specified, (or if no @T command is received at all), this implies that messages of any length are acceptable.
t should have the single-digit decimal value 3, meaning that @ CR and @SCR are the standard message terminators. Other options defined by the original EPSS protocol are not supported, so in practice each end should assume a value of 3 for this parameter regardless of what may be specified, and likewise if no @T command is received at all.
xxyyzz indicates what additional characters will be regarded as message terminators, in addition to the standard ones. All characters in the hexadecimal range xx to yy (except zz if it is within this range) will be treated as terminators. If zz is outside the range, it will be treated as an additional terminator. It can be seen that the value 000000 may be used to indicate that no special terminators are specified.
The xxyyzz parameter may be useful in the case where a server needs to communicate with a terminal on a character by character rather than a line by line basis. The terminal handler should wherever possible communicate with the terminal itself on the same basis: i.e: transmit the data whenever one of the special terminators is recognised in the input. Some terminal handlers will not be able to do this, however, in which case they should ignore this parameter. The parameter should also be ignored when received by the server end.
- @MCR is a command from the server end to the user end to turn off local echoing on the user's terminal. (M stands for Mute).
- @ECR is a command from the server end to the user end to turn on local echoing on the user's terminal. Local echoing is the default assumption at the start of a call.
- @DnnCR is a command from the user end to the server end, passing a two-digit hexadecimal number representing the user's device type. For instance, @D0CCR specifies the type number X'0C'. Actual device type values are given in an Appendix.
- @CnnCR is a command from the user end to the server end, passing a two-digit hexadecimal number representing the default RJE output destination for jobs launched from the user's terminal. This is most likely to be useful where the terminal is actually connected via a particular RJE station. For instance, @C2ACR specifies RJE station number X'2A' (or decimal 42). The default value is 00, denoting the server's local pool of printers.
- @OCR is defined only for the direction server to user. It requests the user end to obtain binary information from the terminal and transmit it. This is likely to be a cursor reading in practice. The user end should switch to "binary" mode to ensure transparency. The server end, however, should not attempt to wait for an @BCR, as the user end may not have implemented it. The user must abstain from typing ahead when the server is liable to request binary input, as the typed ahead material may be mistaken for this by the server.
- @NCR is defined only for the direction server to user. It cancels the effect of a preceding @OCR command. The user end should switch to character mode if appropriate, but the server should not wait for an @ACR, as the user end may not have implemented it.
@P------CR is a family of commands that has been included in the protocol, but whose implementation is optional. It allows messages to be batched together, when the application level wishes to work with units of data larger than single messages. Only one batch may be transmitted at a time in each direction. The parameter str is an IA5 upper case string describing the class of messages to be transferred. The classes defined are listed in an Appendix.
@PTstr CR informs the other end that a batch of messages of class str is waiting to be taken.
@PDstr CR is a request for a batch of messages of class str to be sent by the other end. If the other end has previously sent an @PTstr CR, it must respond to an @PDstr CR, though it may send only an @PECR if it no longer wishes to send a batch. If the other end has not sent an @PTstr CR, it is not obliged to respond, but it may optionally send the batch requested, or decline to do so using @PECR.
@PSCR introduces a batch of messages requested by an @PDstr CR.
@PECR terminates a batch of messages or indicates that no batch is available.
@PI---CR is a request for status information from the other end. The other end is not obliged to respond. Details of this command are for further study.
@PJ---CR is a response to a request for status information. Details of this command are for further study.
Messages within a batch are not counted for @G flow control. Only network flow control applies.
There is no logical relationship between the incidence of @PI/@PJ commands and the rest of the @P command set.
If an @YCR command is issued by either end, all knowledge of previous @P commands is destroyed at both ends.
- @I<x><nn>CR provides a means of setting certain parameters used at the other end. <x> is an IA5 character identifying the parameter concerned, and <nn> consists of two IA5 characters representing the hexadecimal value to be assigned to the parameter. Defined parameters and values are listed in an Appendix.
The protocol is defined in such a way that a limited service can be offered without implementing all the commands, provided that unrecognised or unimplemented commands from the other end are tolerated but discarded. It is clear that all implementations must be able to transmit at least the following:
@ CR to terminate messages @ZCR in response to @YCR
@GnnCR to give permission for messages
All implementations must be able to receive and act upon at least the following:
@ CR as a message terminator @SCR as a message terminator @YCR as a request for @ZCR in response @GnnCR to receive permission for messages @WCR to reset the permission counter
Apart from this minimal subset, the fullness of the implementation is for the local implementor to decide, depending on the quality of service he wishes to offer.
At the start of a call, each end must send a suitable @Gnn<R>, and no messages should be transmitted until an @GnnCR has been received from the other end. Each end should also send an @T command (which should be positioned before the @G), if it proposes to truncate received messages greater than a certain length, or wishes to declare any special terminators.
The local software may clear the network call if it detects a breach of protocol by the other end. However, some implementations are likely to be more tolerant than others. All implementors should of course ensure that their own software is not vulnerable in any way.
The Network Independent File Transfer Protocol ("Blue Book") has been implemented on most types of SERCnet host".
Two versions of the protocol are now defined. At the time of writing, SERCnet implementations mostly conform to FTP77, but a transition exercise to FTP80 is under way. During the transitional period, new implementations should conform basically to FTP80 but tolerate certain features of FTP77. Implementors should refer to Refs. A8 and A9 for the protocol definitions, and to Refs. M6 and M7 for details of the transitional arrangements.
5. X29 and TS29
TS29 is a Transport Service compatible variant of the CCITT standard protocol X29. Both are used on SERCnet. Implementors should refer to Refs. M2 and A7.
SERCnet implementations for the most part follow the recommendations of Ref. A7, except that PAD parameter 7 is likely to be set by the host to 21 rather than 5.
No implementations are currently in service. The protocol is defined in Ref. A10.
PART E: REFERENCES
- A4) SERCnet - Addressing Scheme (P.M.Girard)
- A5) SERCnet - Addressing Summary (P.M.Girard)
- A6) A Network Independent Transport Service (PSS User Forum Study Group 3)
- A7) Character Terminal Protocols on PSS (PSS User Forum Study Group 3)
- A8) A Network Independent File Transfer Protocol (High Level Protocol Group)
- A9) A Network Independent File Transfer Protocol Revised Version (File Transfer Protocol Implementors Group)
- A10) A Network Independent Job Transfer and Manipulation Protocol (Sept. 1981) (JTP Working party of the DCPU)
- M1) JNT Transport Service Recommendations (23/12/80) (B.J.Charles)
- M2) PSS Technical User Guide (British Telecom)
- M4) HASP II Manual (IBM)
- M5) HASP Multileaving Workstation Support in GEC 2050 (C.J.Adams and A.G.Waters) - RL-73-138
- M6) Conversion to Revised NIFTP (M.J.T.Guy)
- M7) Conversion of FTP(77) to FTP(80) in SERCnet (C.S.Cooper)
The author of this paper is not of course the author of all the material it describes. This has been the work of the SERCnet Development Committee, and of many individual people from RAL, DL, and NERC over a period of several years.
Clearing Cause and Diagnostic Code Fields in Clear Packets
The Clearing Cause field is for use by DCEs only. If this field is zero, it can be assumed that the call was cleared by the remote DTE rather than by a DCE.
The Diagnostic Code field is currently used as follows (if the Clearing Cause field is zero - otherwise it is undefined).
0: Normal clearance by DTE application level 1 to 127: Clearance by DTE Transport level. 128-255: Abnormal clearance by the DTE Application level (codes defined independently for each application).
Device types defined for use with the @DnnCR command DEV(nn) Terminal Lines/page Chars/line 00 Typewriter 999 100 01 Computek 400 30 80 02 Tektronix 4002 30 80 03 Tektronix 4010 30 72 04 Teletype 999 68 05 Teletype 999 76 06 16 80 07 Case Vista 16 76 08 Newbury/Delta 5000 22 76 09 36 80 0A 18 72 0B 12 100 0C Tektronix 4010 60 100 0D HP2640 24 80 18 HP2641 24 80 19 HP2645 24 80 1A HP2648 24 80 1B Tektronix 4013 60 100 20 AJ830 999 132 21 AJ832 (with plot.) 999 132 22 DECWRITER (no plot.) 999 132 23 VT100 24 132
Batch Classes for use with @P----CR Commands
str = 10 : Terminal memory = 11 : Terminal in "forms mode" (unprotected fields only) = 20 : Cartridge = 90sssss : File in terminal known as 'sssss' to terminal
Parameters specifiable in an @I<x><nn>CR command
<x> = 'A' : Local escape character. By issuing @IA<nn>CR a server can request the terminal handler to accept from the user the character X'nn' as a local escape character, instead of the character normally used for this purpose.
<x> = 'B' : Broadcast flag. By issuing @IB<00>CR, a server can tell the terminal handler to allow broadcast messages to reach the terminal. By issuing @IB<01>CR it can tell the terminal handler to disable delivery of broadcast messages, other than those which belong to the ITP call itself.
<x> = 'C' : Backspace character. By issuing @IC<00>CR, a server can request the terminal handler to forward 'backspace' characters (CTRL H) to the server. By issuing @IC<01>CR, a server can request the terminal handler to process 'backspace' characters locally. It should be noted that no defaults are defined for these options, these being a matter for the local implementor. The commands enable the server to try to override the local default whatever it may be.