This proposal is somewhat different from what was implemented. See “External Reference Specifications: Series/1 Front-End Processor for KeyKOS”, KL115-02 for what is implemented for the Series 1. See (s1x25) for some comments about the implemented interface.

Desiderata

I identify the following considerations for deciding where to put function:
Cost of implementation:
If the function has been implemented already on one side of the interface and that implementation is available, lets use it.

Cost of Execution
If the S1 has the capacity or it is economical to buy more S1s, then put the function there.

Minimal Interface Specs
CWA & Key Logic must agree on a interface specification to which we both implement. We should minimize the size of this specification. I consider a reference to the X.25 recommendation to be a small part of a specification.

We must consider requirements for diagnostic tools whereby a program with “access to the truth” can talk to a person about a particular circuit on a particular DTE/DCE interface in the terminology of the X.25 recommendation.

We should take into consideration whatever ideas we can concerning SNA functions that might conveniently fall to the S1.

The interface has one channel address used for transmitting packets and interface control in both directions.
I suggest different addresses for input and output.

We postulate here a real device that implements the DTE link level protocol and links to several DCEs. Our plan is for this device to be an IBM Series 1 computer (called ‘S1’ henceforth).

Between the S1 and the 370 channel is an interface with a single 370 I/O address.

It would have been more modular to establish an I/O address per X.25 interface, but with a certain early application we might have exceeded the Series one’s limit on how many I/O addresses it can answer to on a 370 channel interface.

The purpose of the interface is to move X.25 packets between the 370 and the S1 and to associate them with a particular X.25 interface. A packet is that data referred to in the X.25 recommendation as the “information” field of a frame. A packet follows the control field and is followed by the FSC field of the frame.

Experience indicates that some form of error control is frequently useful. It is useful in detecting not only real hardware errors, but also program bugs and misunderstandings of hardware and protocol specifications. This feature should be negotiated at reset time and be in effect only with the consent of both sides of the interface.

Each transmission consists of a two byte discriminant, followed by the body of the transmission, in a format determined by the discriminant, followed by a 16 bit mod 2**16 checksum formed by dividing the format code and body into 16 bit portions and zero padded to an even byte count.
What if the body is an odd number of bytes?

The checksum is omitted unless both sides agree in the reset sequence.

An XOR may be nearly as good here. But I still remember an error 26 years ago on an IBM 727 tape drive where two adjacent tape characters consisting of a single bit were dropped. It cost me several days to track down the error. A sum with carries would have caught that error.

Discriminants X'00FF' and X'FF00' (a diagnostic tool) require no checksum.

A Packet Transmission:
Discriminant X'0000' for inbound and X'0001' for outbound.

The body consists of:

A two byte counter, SC, of packet transmissions in the particular direction and a two byte value, RC, which is the SC value from the most recent transmission in the opposite direction, followed by

A sequence of self delimiting super packets, one for each X.25 DTE/DCE interface with traffic. It is polite but not necessary that one interface have no more than one super packet within a transmission. A super packet consists of:

A two byte X.25 interface index and a sequence of packets each preceded by a two byte packet length indication. A super packet is terminated by a zero length packet.

The offset of each packet length indication within the transmission is the next multiple of M, a parameter selected by the S1 during the reset sequence. M is a power of two.

Thus if M=2 then each packet's size field will be at an even address within a transmission. This restriction may allow a more efficient implementation on some machines.

The transmission counter and check sum fields are for error detection and for possible (undefined) error recovery.

Resetting and Parameter Negotiation
Discriminant X'3355' indicates a reset command and X'5533' indicates a reset response. The transmission counter for a particular direction is set to 0 when a reset command or response is sent in that direction. A reset response should be issued immediately upon receipt of a reset command.

Following the discriminant is a four byte transmission buffer size. The recipient must not send a longer transmission (until another reset).

Following the buffer size of an inbound reset command or response is the two byte offset modulus M.

Following the modulus is a two byte field of bits. Bit 0 of this field is an indication of desire and ability to generate and check checksums. Checksums are in effect just if this bit is 1 in both a reset and the reset response.

I do not think that this reset sequence from the 370 should cause the S1 to issue a “Restart request” to the DCE; the 370 will presumably do that.

Testing
{Please echo} X'00FF' followed by a string of characters to be echoed without modification.

{Echoed string} X'FF00' followed by the echoed string.

Is this useful?

Loose End: We must decide which fields of a transmission are subject to the modulus.

When the interface finishes:
The 370 requires that the checksum of the inbound transmission be correct and then that the SC field be one greater than that of the preceding inbound packet transmission.

When the 370 has ready outbound packets and the interface is idle, the 370 transmits those packets with a write chained to a read.

When the 370 gets an attention interrupt it reads the interface.

When the interface finishes:
The S1 requires that the checksum of the outbound transmission be correct and then that the SC field be one greater than that of the preceding outbound packet transmission.

The S1 transmits any ready inbound packets to the 370.

This action normally matches the 370 channel program’s chained read. There is no such read if that channel program is in response to a collision. In this case the S1 must issue another attention.

When the S1 has ready inbound packets and the interface is idle, the S1 causes a 370 attention interrupt.

The 370 channel program may be blocked by an attention interrupt. In this case the 370 keeps its block B of data to be transmitted and reads the interface instead and then sends B with a read chained to a write.

I still think two addresses would be better.

We anticipate that the 370 may prefer to have the S1 delay and batch transmissions to the 370 into larger batches in order to decrease 370 work. Likewise the 370 may choose to batch its transmissions to the S1 for similar reasons.

In support of this we should devise a transmission from the 370 to the S1 selecting a delay or similar parameter to encourage the batching of input. Presumably this parameter could be changed at any time, perhaps to reflect observed system load.

Perhaps the S1 would like to employ similar control over batching of outbound packets.

Note that the RC field is not read in this scheme. It might be useful in yet unspecified error recovery and it might be of use in debugging.