ABSTRACT
The installation of a public packet switched service for data transmission is prepared in France by the operation of an experimental network known as RCP. Its initial configuration includes three switching computers and three time division multiplexors in six different towns spread over the country. Customer computers have access to the network through 4800 bit/s transmission lines over which they can have several interleaved conversations with other computers and/or terminals. Terminals' access to RCP can be through the telephone and the telex switched networks or also through point to point lines.
Data transmission is based on the establishment of "virtual circuits" between pairs of customers. Over such a virtual circuit sequences of packets containing 8-bit bytes can be transmitted in both directions. The network provides for automatic correction of transmission errors and flow control between transmitter and receiver. Internal operation is based on a few effective and well understood principles like fixed routing and fixed buffer allocation on a call basis. Further optimisation of the switching software can be done in the future without changing customer interfaces or protocols.
1. INTRODUCTION
Most commercial data transmission is made at present over private networks using leased telephone lines and over the switched telephone network. New developments are taking place in three directions: digital leased circuits, digital switched circuits and packet switched services.
Relevant to packet switching there exists a wide range of systems with various purposes and characteristics. Their common ground is essentially the use of high speed store and forward techniques for data transmission. The need for standardization in this field is therefore very clear and international bodies like IFIPS, CEPT and CCITT have set up new working groups on the subject. The French Telecommunication Administration having recognized that packet switched services can potentially satisfy a large fraction of future data transmissions needs, is taking an active part in the related studies.
The development of the RCP experimental network is one element of the set of actions which are to result in the definition and implementation of a public data transmission service based on packet switching.
The purpose of this experiment is to verify the soundness of a few design principles, to face those operational difficulties which might be peculiar to this service, to deal in advance with the problems of customer equipment interfacing. In one word RCP can be viewed as a testing stand for some aspects of the future packet switched service.
2. ARCHITECTURE OF THE RCP NETWORK
2.1. A general overview of the networks implantation, as it is planned for the time of opening in January 1975 is given on figure 1. At the time of writing the three switching computers are interconnected by 4800 bit/s lines. Two of them are in Rennes and one is in Paris (the Lyon's computer will be taken from Rennes. Accesses to RCP via the telephone switched network and the telex network exist in both Paris and Rennes. A multiplexor like the one to be installed in Marseille, Lille and Bordeaux, and the management computer are connected locally to one of the Renne's computers.
The building blocks of RCP which are described below are presented on figure 2.
2.2. Customer equipments.
Their types are only indicative. Large computing centers can exchange data via the network with remote batch terminals, terminal concentrators and/or directly connected low speed terminals.
A time-sharing computer is better connected to RCP via a synchronous leased line over which numerous conversations can be interleaved, but it can also be accessed through a set of its ordinary low speed entries, connexion between RCP and these entries is feasible by asynchronous leased lines; it can also be done via the switched telex network where RCP can automatically call the time-sharing computer when access to a new entry is needed.
2.3. The distribution subnetwork includes the transmission facilities which lie between customer equipments and the multiplexors or switching computers of RCP:
1) - synchronous leased line are normally operated in full duplex at 4800 bit/so However higher speeds like 9600 or 19200 bit/s with baseband modems can be offered.
2) - asynchronous leased lines are normally operated in full duplex, either at 600-1200 bauds with a 1 start/8bits/ 1 stop character format, or at 110, 200 or 300 bauds with a 1 start/8bits/1 or 2 stops character format. Other speeds like 134.5 bauds with a 1 start/7bits/1 stop character format are envisaged.
3) - Access to RCP via the switched telephone network is available for the same speed and format combinations as for asynchronous leased lines up to 300 bauds. For this, any modem in conformity with CCITT recommendation V 21 can be used by customers. Modems installed on RCP entries have automatic answer capabilities.
4) - On the telex network RCP has both automatic answering and calling capabilities. Telex signalling is always handled at 50 bauds with a 1 start/5 bits/1.5 stop format, but once the connexion established and after a SSSS sequence has initiated the data transmission phase, other speeds up to 200 bauds are possible. The same combinations of speeds and formats as indicated for leased lines, up to 200 bauds, are then accepted.
2.4. Internal subnetwork. It comprises switching computers, multiplexors for low speed entries and trunk lines.
Switching computers are PDP-11 's models 20, 21 and 40 from Digital Equipment. Each one includes a memory of 24 K.16 bits words with 950 ns cycle time. Telecommunication adapters provide for synchronous transmission at rates up to 50 000 bit/s depending on modem speed. Adapters for asynchronous transmission have internal clocks for 50, 75, 110, 134.5, 150, 200, 300, 600 and 1200 baud operation. The actual rate of a given entry is under dynamic program control. Likewise the character format of each entry is modifiable by software within the set 1 start/5 to 8 bits/1, 1.5 or 2 stops.
The only peripheral equipments of a switching computer are a 30 char/s typewriter and high speed paper tape reader and punch.
Multiplexors are SAT 3729's from the Société Anonyme des Télécommunications. They provide for fixed time division multiplexing of several asynchronous lines over a single synchronous line. They are capable of automatic speed and character format recognition on low speed lines; for this, when a customer has just called a multiplexor via the telephone switched network, he must indicate his characteristics by sending a specially chosen character.
On the PDP-11 a special adapter has been developed to handle directly the multiplexed synchronous line. The fixed frame structure of the SAT 3729 with 9-bit time slots for low speed lines is processed by the adapter. When necessary, elimination and generation of empty time slots is done without computer intervention.
Trunk lines are made of high quality 4-wire point to point telephone lines with modems at 4.8 and 9.6 K bit/so Between two switching computers the rule is to have at least two lines at 9.6 K bit/s; where this is possible they must follow different physical routes. Between a multiplexor and a switching computer the rule is to have one line at 4.8 K bit/s; if the load of the multiplexor grows above this rate modems at 9.6 K bit/s are substituted.
An adapter to a foreign network is represented on figure 2. It indicates how interconnection is planned on the RCP side However an actual interconnection has yet to be organized. The line from the adapter to a switching computer can be a single or multiple full duplex synchronous line.
2.5. Management center.
Network supervision is centralized in the "management center". It includes a T 1600 mini-computer from the Télémécanique company with a 10 M bytes {This contradicts Bache, Guillou et al. who claim 1E6} disk storage, a 180 char/s printer and high speed paper-tape input-output. Connexion of this computer to the internal subnetwork is achieved, as for a customer computer, through a synchronous point to point line at 4.8 K bit/s, it is only by software that the computing center is granted privileges higher than other connected equipments.
Images of the Télémécanique T1600 computer.3. THE SERVICE OFFERED.
Click here to open technical illustrations (150KB) in a new window. These figures provide detailed data structures and state diagrams for link ctl, flow ctl and call setup/clear. IA2 to IA5 translation is also defined.3.1. Virtual circuits
The basic service offered on RCP is the setting up of full duplex "virtual circuits", or VC's for short, and the control of data transmission on these. A VC is defined by two characteristics:
- data are transmitted with flow control at both ends
- the rate of undetected transmission errors is very low, negligible for many applications.
1) Data are transmitted with flow control at both ends :
- a data source transmits on a VC only when it has useful data to send, and when it does so it is submitted to the varying acceptance rate of the VC.
- a destination receives data from a VC only when useful ones have been transmitted by the source at the other end of the circuit, and when it does so it can impose a varying acceptance rate on the VC.
- there is only limited storage within a VC. Thus a source is necessarily slowed down if it can send faster than the corresponding destination can receive.
2) The rate of undetected transmission errors is very low :
- on RCP it is expected that an average of 1010 bits are correctly transmitted by a customer before it can experience an undetected error.
- all types of errors are understood here, not only bit modifications but losses, permutations, duplications or insertions of extraneous data
- this definition includes no figure on the probability of detected errors. However, thanks to store and forward which incorporates internal error correction by retransmission and thanks to a careful buffer allocation scheme this probability can also be kept very low. On RCP a non recoverable detected error appears to a concerned user as a circuit clear down, with a cause indication, or as an obvious failure of its local switching computer. Besides characteristics 1) and 2) above, a full definition of VC's on RCP includes a few secondary characteristics.
3) Customer data, as transmitted on a VC, are composed of 8-bit bytes with interspersed "end of message" markers :
- there is no restriction on the value of data bytes
- the number of bytes between two ends of messages is arbitrary. In particular it can be zero.
- In general customers at both ends of a VC exchange their data with the network using packets which contain several data bytes. There is no need nor there is any guarantee that packet lengths at the destination are the same as at the source. The network, for internal reasons or because of differences on maximum packet lengths at both ends, may split packets or regroup consecutive ones. What is guaranteed is the sequence order of data bytes in the flow of packets and the exact position of end of message markers between these data bytes.
4) Either end of a (full duplex) circuit can reinitialize it at any time :
- a reinitialization results in a destruction of all the data which are still in the VC at this time, this for both directions
- the customer which has not asked for reinitialization is informed of it by an appropriate signal. His ability to control the flow of incoming data doesn't apply to this signal which therefore is always promptly received.
- if the two ends of a VC ask for reinitialization at the same time, reinitialization takes place but both requests annul each other. No one needs to be informed of the other's request since it already knows that data may have been destroyed.
3.2. Virtual circuit set-up and clear down
A virtual circuit. like a real one, could be permanent, i.e. Without any switching capability. On RCP all virtual circuits however are switched: one is set up after a call request and is cleared down when one of the two parties asks for it (or exceptionally if the network has to do it because of a failure).
3.2.1. A call request includes the following items of information:
- address of the called customer (the "callee")
- address of the calling customer (the "caller")
- a collect-call flag
- a class of service indicator
1) address of the callee :
- this address has two parts. Two bytes give the identification of the callee within RCP and up to thirteen bytes give an address complement to be used by the callee itself if it needs further identification
- the callee can be a customer equipment or an access to a foreign network. It can also be an internal service of RCP like an access to the telex network, with automatic calling capacity, or an echoing system for customer software or network testing, etc...
2) address of the caller
- its content has the same structure as for the address of the callee
- its purpose is to allow each called customer to check the identification of its callers, when it needs to.
- internal services which can appear as callers are not necessarily the same which can appear as callees. Access to RCP via the telephone network is handled as an internal service which can only be a caller within RCP.
3) collect call flag
- if this flag is set, the callee must be charged for the call
- a call initiated by a customer on the switched telephone network is always a collect call, the caller being unknown
- a call via RCP to an ordinary telex terminal cannot be a collect call since the callee, has no means to refuse it. Thus it is not practicable, for charging reasons, to send an ordinary telex message from the switched telephone network. If a market is found for such a service, provisions for caller identification will be added. A system with account numbers and passwords is envisaged.
4) class of service
- different virtual circuits may be used with quite different traffic patterns. The question of whether the network should be informed of these patterns, for optimization, or not, has no simple answer. On one hand customers should not be concerned with network implementation techniques and should not have to indicate their traffic characteristics if this is not really useful. On the other band resource utilization can be improved if the appropriate indications are available to the network.
- In RCP it has been taken into account that most of the traffic is likely to come from a minority of high traffic calls while a majority of the calls will have limited traffic with low peak throughput. Two classes of service are thus defined:
1) peak throughput below 120 customer bytes/s
2) peak throughput above the limit of class 1)
- It is expected that measures on RCP will help to understand better this problem.
3.2.2. A "connection confirmation" is returned by the callee when it accepts the call request.
- there is no built in time out between the request and the confirmation. It the caller's responsibility to decide when to give up if the callee doesn't answer. This allows for placing calls through a private or foreign network without RCP having to know their timing properties.
- data transmission from the caller towards the callee can start before the corresponding connection confirmation. Thus the delay before reception by the caller can be kept to a minimum. If the callee finally rejects the call, the caller who is informed about this, knows that data which were transmitted in anticipation may have been destroyed.
- although the detailed charging method has yet to be decided upon, it seems reasonable that a call which is rejected by callee is not free: the callee, not only has received an address complement of up to 13 bytes, but may have also received an unlimited amount of data if the caller has sent in anticipation. The rule is that any possibility to transfer information from customer to customer must be charged fairly, this to avoid any incentive to use sophisticated and indirect means for information transfer.
3.2.3. A "clear down" signal can be sent at any time by any customer involved in a virtual circuit, or also by the network itself in case of failure. The effect is that any data which were left in the virtual circuit are destroyed and that the network recovers all its resources which were attached to the VC. A customer is always informed of clear down.
The same mechanism applies to call refusal, i.e. clear down by the callee or the network before connection confirmation, to call abortion, i.e. clear down by the caller before he has received either a refusal or a confirmation, and to normal termination, i.e. clear down by either the caller or the callee after the VC has completely been set-up.
The clear down signal includes an explanation as to the origin and the cause of clear down. The origin can be the customer in the direction where the signal comes from, or it can be the network. When a customer is responsible for clear down, he codes himself the cause in an 8-bits byte. This facility extends to private networks which are connected to RCP the ability to clear VC's down and tell the end customers the origin of clear down.
The network itself can clear VC's down in various occasions:
1) call refusals due to the customer
- the callee doesn't exist
- the callee is out of order
- the callee is saturated and cannot accept one more call
- the collect call was of the called type and the callee doesn't accept collect calls
2) call refusals due to the network
- the network is overloaded and could not successfully establish a VC
3) VC clear down due to the customers
- a customer has sent an "end of transmission" signal and the other one, being "passive", relies on the network to clear the VC down as soon as all the data have been transmitted (see 3.2.4.)
4) VC clear down due to the network
- a network failure resulted into an immediate cleardown of the VC. This can happen after VC establishment, in which case both customers receive the appropriate clear down signal. If it happens before the caller has received a connection confirmation it appears to him as a call refusal. If the clear down signal going toward the callee catches up the call request before the callee has received it, then the callee will never know about this call. Finally, if the clear down signal reaches the callee after the call request but before the connection confirmation was returned. then it appears to the callee as a call abortion.
3.2.4. An "end of transmission" signal can be transmitted by one end to tell the other one that no more data will follow. Its purpose is to speed up the clear down process when the last one to transmit data is also the one to decide of clear down: if it would send a clear down signal after the last data, there would be a serious danger that the signal would catch up and pass the data, thus destroying them.
The end of transmission signal is useful in particular when transmission takes place toward a "passive" customer, i.e. a customer which only accepts calls and data but has no intelligence to answer. In this case the network can act as a substitute to the passive customer and request clear down as soon as the last data have been delivered. This is the typical utilization of VC's for delivering messages, as it is done with the telex network, but here with flow control and error correction.
3.3. CUSTOMER PROCEDURES
3.3.1. The basic service of RCP, virtual circuit switching, is offered to a customer, on his local interface, by means of a procedure (or protocol). Two customers may have different local interfaces and procedures and yet be able to communicate through a virtual circuit. For example a terminal which has a BSC compatible procedure and a 1200 bauds asynchronous interface can communicate with a computer which has a packet interleaved multiconversation procedure and a 9600 bit/s synchronous interface. This flexibility is indeed one of the most promising aspects of store and forward techniques applied to public data transmission services.
The number of interfaces and procedures which are offered on a network can grow with time. On RCP there an currently three procedures: two for start-stop character terminals, respectively based on CCITT codes number 2 and 5 and one for synchronous transmission. The first two, because of their own limitations, don't give access to the full capabilities of VC's: they offer only limited flow control and no error correction on customer lines. The third procedure on the contrary covers the full RCP service. With it several simultaneous VC's can be handled on a single customer line. It can therefore be used to make adapters to different customer procedures and to foreign networks.
3.3.2. The "teletype compatible" procedure (figure 3)
This procedure applies to character terminals which operate with full duplex transmission and have local echoing, i.e. which don't rely on RCP for sending back all the characters they transmit. It is based on CCITT code number 5.
1) flow control
When the terminal is involved in a VC, it is normally assumed to accept characters at its nominal speed. However it may stop the flow of incoming characters by sending a DLE character and re-accept input by sending a CR (the combination DLE CR is an ineffective command to RCP); this facility should be used carefully since sending a DLE to RCP can corrupt one or two incoming characters. On the opposite direction. RCP can have a limited control over the outgoing characters from the terminal. If the customer at the other end of the VC is too slow. RCP tries to stop the flow of data by sending an XOFF to the terminal; when transmission can resume RCP sends an XON. This flow contro1 mechanism is appropriate for a large number of teletypes with paper tape readers. It is however clear that, when a slow terminal sends data to a computer. it is in general not useful to have a slowing down mechanism for the terminal: the receiver is much faster than the sender. If for some incidental reason the terminal sends more characters than RCP can accept, a message is returned by RCP to "the terminal:
CR LF % PER CR LF
2) parity of characters
The standard rule is that RCP transmits the parity of characters without modification, that it ignores parity, when it decodes signalling characters, and that it puts an even parity to the signalling or flow control characters, it produces. It is envisaged that different options are offered, in particular that the appropriate parity is (computed by RCP when it sends to a terminal which doesn't accept even parity.
3) Commands and messages
Signalling between terminal and RCP is done by means of "commands" and "messages". The terminal sends commands to RCP enclosed between the characters DLE and CR. If the 'customer at a terminal wants to transmit a DLE to the customer at the other end of the VC, it does so by sending DLE DLE to RCP. A command can be sent to RCP at any time: the network never stops looking for DLE's even if it has no buffer space left for data characters.
When RCP has signalling information to transmit to the terminal, it sends a "message" enclosed between the character sequences CR LF % and CR LF. Messages can be sent by RCP at any time (in case of contention, messages have priority over data and commands coming from the terminal).
1) A "call request" command contains the following elements - letter "A" for command identification
- an optional "+" or"-" to select a collect call or an ordinary call respectively. The default option is ordinary calls for terminals on point to point lines and collect calls for those which have access to RCP via the telephone or telex switched networks.
- the hexadecimal address of the callee. The first four digits are mandatory and leading zeroes must be explicit. The number of other digits depends on the need for an address complement with a maximum of 26 (cf. 3.2.1.). Digits are left justified in the bytes of the address and. if necessary. a hexadecimal F is added by RCP for padding in the last byte. A hexadecimal digit is represented by a character 0 to 9 or A to F.
- an optional address complement of the caller, with a leading comma. RCP includes itself the first two bytes of the caller's address (cf. 3.2.1.). The address complement of the caller is composed of up to 26 hexadecimal digits as for the callee's address.
- examples: DLE A035B CR.
This is a call to the customer of RCP whose number is hexadecimal 035B.
DLE A + 02 19 06, E CR
This is a collect call to customer number 0219 and more precisely a call to the internal subadress number 6 of this customer (6 could designate, for example, an access to a BASIC or FORTRAN subsystem of a computing center, or a specific terminal on a customer owned concentrator). The caller has a one byte address complement with an 0XEF value (EF could, for example, specify a type of peripheral or be an account number).
2) As an answer to a "call request" command. RCP returns immediately a "call request confirmation". This message contains a replica of the command itself and provides for error checking on the call request.
- examples: CR LF APP + 035B CR LF
CR LF % APP + 021906, EF CR LF
3) If a call request from a terminal is successful, the "connection confirmation" will appear to the terminal as a COM message:
CR LF % COM CR LF
4) If a terminal is the addressee of a call request while it is not involved in a VC. RCP accepts the call, i.e. returns a "connection confirmation" to the caller, and informs the terminal with an "incoming call" message having the same parameters as the "callrequest confirmation" but a different symbol
examples: CR LF % COM + 035B , 021C CR LF
Terminal number 035B is informed that a VC has just been established with customer number 021C as a consequence of a collect call.
CR LF % COM + 021904. 0138 EF CR LF
Terminal number 0219 has been called by customer number 0138. Address complements were given both for the callee and the caller: 04 and EF respectively.
5) A "clear down request" has the following format:
DLE L CR
It results in the transmission a clear down signal over the current VC (cf. 3.2.3.)
6) When RCP receives a "clear down request" from a terminal it immediately returns to it a "clear down confirmation" message with the following syntax:
CR LF % LIB CR LF
The terminal is then free to initiate a new call.
7) If, while a terminal is involved in a VC, a clear down signal comes from either the network or the other customer, then the VC is immediately cleared and the terminal is informed by a "clear down" message.
CR LF % LIB x y y CR LF
Where x is "R" if the origin of the clear down is the network and "C" if it is the other customer, and where y y are two hexadecimal digits giving the cause of the clear down (cf. 3.2.3.).
If a collision occurs between a "clear down request" and a "clear down message", then the request is ineffective and is not followed by a "clear down confirmation".
8) An "end of transmission request" can be used to indicate to the other customer that no more data will follow (cf. 3.2.4.). Its syntax is
DLE F CR
9) An "end of transmission confirmation" is immediately returned by RCP after an "end of transmission request". In general it will be followed, after a short time, by a "clear down" message resulting from a "clear down request" made by the other customer. If the other customer is slow, e.g. a 50 bauds telex terminal, it may however take several seconds before the VC is cleared. The syntax of the "end of transmission confirmation" is
CR LF % FIN CR LF
10) A terminal can reinitialize a VC by means of an "initialization request" (cf. 3.1.4.)
DLE I CR
11) RCP informs a terminal of VC reinitialization by an "initialization" message:
CR LF % INI CR LF
This message can come as an immediate answer to an "initialization request" or as a consequence of an initialization signal coming from the other customer.
12) A terminal may have to send "end of message" markers to the other customer (cf. 3.1.3.). It does so with an ETX character. This exception to the general format of commands is justified by the fact that these markers may be used frequently, perhaps at the end of each transaction in a conversational application; furthermore the command should have no effect on page layout, which means that no CR character can be used. The ETX character has a secondary effect it prompts packet transmission.
When a packet is not completely filled yet. Otherwise incomplete packets are transmitted only after a timeout which may be as large as 2 sec.
For transparency the combination DLE ETX can be used to transmit an ETX as a data byte on the VC. There is no local flow control imposed by RCP after it has received an ETX and some time should elapse before new data or a new ETX can be sent: this depends on the acceptance rate at the other end of the VC. But there is no danger to lose data if after an "end of message" sent by the terminal an answer from the other customer is expected; this should be the rule when using the teletype compatible procedure. A teletype compatible terminal cannot receive "end of message" markers. If such a marker arrives on a VC to the terminal RCP simply ignores it.
13) RCP returns an "error" message to a terminal when an illegal command has been received. It can be illegal for syntactic or semantic reasons but the format of the message is always
CR LF % ERR CR LF
3.3.3. The telex procedure.
It is similar to the teletype compatible procedure but is based on CCITT code number 2 and has the following differences:
- the DLE character of the previous procedure is replaced by the ✠ character and the ETX character is replaced by ✠ M for indicating an "end of message";
- there is no XOFF XON flow control for paper tape readers.
- RCP makes an automatic code conversion between codes CCITT numbers 2 and 5 so that the assumed code for transmission on VC's is code number 5. A translation table is indicated on figure 4. Parity is even for the code number 5 characters which are produced and is ineffective for those which are translated into code number 2.
3.3.4. The multichannel synchronous procedure or "RCP procedure".
This procedure has three levels: the frame level, the packet level and the command level.
1) The frame level concerned with error correction and local flow control on the synchronous customer line; it provides for a secure sequential transmission of "blocks", each blocks containing one or several "packets" handled by the second level of the procedure. This level could be replaced by any currently available procedure with the same objectives, BSC for example. However the frame level of the RCP procedure is better adapted to full duplex transmission lines (in this respect it is more like the HDLC procedure which is under study at ISO but it doesn't need specialized hardware and is significantly simpler for the particular case of point to point lines).
Both ends of the line send frames which have the format indicated on figure 5. They comprise, successively:
(i) a synchronization pattern made of the SYN-SYN-SYN-STX sequence in code CCITT number 5,
(ii) a length indicator L of one byte.
(iii) the block which is either empty, if L = 0, or contains one or several packets in L bytes, L is always less than 256 but can be limited to a lower maximum upon bilateral agreement,
(iv) two bytes used for the service fields which relate to error detection, acknowledgments and flow control,
(v) two bytes for redundancy checking; bytes from STX to the second redundancy byte make a cyclic polynomial divisible by x16 + x12 + x5 + 1
(vi) a variable length sequence of SYN bytes for padding between two consecutive frames.
For each direction the receiver controls the transmission from the sender by the SA, TA and TR fields of the frames which go in the other direction. The sender for its part gives indications about the frames it transmits in their SA and TT fields.
SA, TA and TR are the copied values of three variables SAI, TAI and TRI which are constantly updated by the receiver. SAI gives, modulo 2, the number of retransmissions which have been asked for since the last reinitialization. PAI gives modulo 16, the number of nonempty blocks which have been accepted. PRI is, modulo 16, equal to PAl plus the number of nonempty block that can be received (this last number must never exceed 15 to avoid ambiguity).
ST and TT are the copied values of two variables, SEI and PEI, which are constantly updated by the sender. SEI gives modulo 2, the number of retransmissions asked for by the receiver since the last reinitialization. PEI gives, modulo 16, the number of nonempty blocks which have been transmitted since the last reinitialization and which have been acknowledged or are waiting for acknowledgment.
The algorithm for the receiver when a frame is correctly received is the following:
(i) If ST and TT match SAI and PAI and if the frame contains a non-empty block, then the block is accepted and TAI is incremented by one.
(ii) If ST and TT match SAI and PAI but the frame is empty there is nothing to do. (When there are no transmission errors only statements (i) and (ii) are executed).
(iii) If ST matches SAI but TT is different from PAI, then at least one ordinary frame has been lost and a retransmission must be asked for by doing SAI = SAI + 1 (mod 2).
(iv) If ST doesn't match SAI, it means that the receiver has recently asked for a retransmission but the sender was not aware of this fact when it transmitted the frame; the frame is simply ignored.
The sender, besides the two variables SEI and PEI, keeps, in a variable PRC the last value of TR. This variable tells it constantly how many nonempty blocks are acceptable to the other end. There are also two queues to be handled by the sender: the WAIT queue, which holds the blocks waiting for transmission, and the ACK queue, which holds the blocks waiting for acknowledgment. When the WAIT queue is empty, or when no more blocks can be received at the other end, the sender transmits empty frames with three purposes they convey the control information for the other direction, they provide, when applicable, a means for detecting quickly, the loss of the previous non-empty frame, they maintain a minimum activity on the line so that a line break down can be detected.
The sender makes decisions on two occasions, when it receives control information from the other direction and when it transmits a frame. The corresponding algorithms are the following:
Reception of control information :
(i) Handle the positive acknowledgments: for this, eliminate the blocks which are at the head of the ACK queue up to and excluding the one which was sent with a TT equal to TA. (The ACK queue may be totally emptied during this process if all the blocks which have been transmitted have also been received at the other end).
(ii) If there is a new retransmission request handle it: if SA doesn't match SEI, then move the ACK queue at the head of the WAIT queue and reset SEI and PEI to SA and TA respectively.
(iii) Update the flow control indication: PCR = TR .
Transmission of a frame
(i) If the frame is used to convey a non-empty block. which implies that PEI is not equal to PRC, the block is moved from the head of the WAIT queue to the tail of the ACK queue. ST and TT are copied from SEI and PEI respectively and then PEI is incremented by one.
(ii) If the frame is empty. ST and TT are only copied from SEI and PEl respectively.
Initialization can be requested by one end of the line at any time. It should however take place only when power is turned on or as a recovery action after a failure at one end which is operating normally. It applies to both directions and is considered to be effective by one end only when it has both sent and received an initialization frame.
When one end receives an initialization frame while it was not waiting for it, it must make its own initialization and send back an initialization frame.
2) While the frame level transforms a synchronous full duplex transmission line with a non negligible error rate into a secure transmission tool for blocks of information containing up to 255 bytes each, blocks being transmitted with flow control by each end and delivered in their original order, the packet level of the RCP procedure transforms this transmission tool into another capable of handling one or several virtual circuits as they are defined in section 3.1. Each VC is associated with a so called "logical channel" identified by a channel number in the range 0 - 255. Every packet corresponds to one channel, the number of which is given in the "V" field (packet formats are indicated in figure 6). Different types of packets are defined for implementing the functions of VC's: transmission of data bytes, flow control, initialization, end of message markers. These types, coded in the "TP" fields of packets, are PR, D, I, M, P :
PR(k): ready to receive k more bytes on this channel
D (d1, d2,.., dn) : customer data bytes d1 to dn
I : initialization
M : end of message marker
P : the previous M of the other direction has been processed and transmission of D or M packets may be resumed.
Each end of a VC keeps a count of the number of data bytes it may transmit to the other end. This count is decreased by n when a D packet of n bytes is sent, and is increased by k when a PR(k) is received.
When a new VC is established on a channel, by means of the command level to be described in 3), the counts at both ends are initialized to zero.
When a customer wants to reinitialize a VC it transmits an I packet and waits for an I packet on the associated channel. Conversely he may receive an I packet while not waiting for it; he must then reset its channel and send back an I packet. A secondary effect of VC initialization is that the number of bytes which are acceptable to each end is reset to zero. There is thus a resynchronizing mechanism for channel flow control, but it should only be useful in case of hardware or software problem at one of the ends.
A type M packet conveys an end of message marker (cf.3.1.) It is clearly necessary to have a flow control mechanism on a channel for these markers: a source could otherwise send any number of these irrespectively of the receiver's speed. This is done by an obligation following a M packet to retain D and M packets until a P packet is received. Channel initialization also resets this flow control mechanism in that sense that D and M packets are authorized without waiting for any P and that a P will be sent after an I only as an answer to a M which has followed initialization.
3) The part of the command level is the setting-up and clearing down of VC's on channels 1 to 255. Channel zero is reserved for this use and acts as a permanent VC between a customer and its local switching computer. The bi-directional flow of bytes on channel 0 has an internal structure: it conveys individual commands separated by a reserved byte, the "command separator". For transparency of command transmission the bytes of a command itself which are identical to the separator are doubled.
There are four types of commands corresponding to the four functions which were identified in 3.2. plus one for error indications:
A commands for call request
C commands for connection confirmation
L commands for clear down
F commands for ends of transmission
E commands for answering to commands with inconsistent contend.
The set of channels 1 to 255, for a given customer equipment is separated into three subsets: "outgoing" channels which can be used by the customer as a caller, "incoming" channels on which the customer can be a callee, and "unused" channels. The allocation of channels, for a given customer, can only be changed from the management center. Channel numbers of each class are consecutive.
A state diagram giving the rules for using A, C and L commands is given on figure 8 for both the cases of outgoing and incoming channels. Three principles apply:
1) a clear down can be initiated at any time on any channel,
2) clearing down a VC, from a customer's viewpoint, is a local matter, which means that it is effective in a time which is independent of the behaviour at the other end of the VC.
The F command is sent to transmit an "end of transmission" signal on a VC and is received when such a signal comes on a VC (3.2.4.).
An E command will be sent by RCP when it receives an illegal command either because of its syntax or because of the time when it comes; the illegal command is otherwise discarded.
If RCP receives an E command it ignores it.
4. INTERNAL OPERATION
It would take another paper to present the details of internal operation in RCP. There is, in theory, a large independence between the precise RCP procedure for customers and the way virtual circuits are implemented within the network. In practice it is envisaged that some significant improvements will be made on the network software without the users noticing more than a better insulation from internal failures and network ability to handle more traffic.
For the time being advantage is taken from the fact that the RCP procedure is fully symmetrical and as a consequence is well adapted to network interconnection. ("a connected equipment is no more a user of RCP than RCP is a user of this equipment"). The key is that a network node is a particular case of network and that, if customer procedures are appropriate for network interconnections, they are appropriate for node interconnection.
In its initial version RCP works with customer compatible procedures on its internode trunk lines. One obvious improvement, which is under study, is to handle two or more lines linking the same pair of nodes as though they were a single line with higher bandwidth and a lower failure rate.
As far as routing is concerned, it is fixed for the duration of a call but may differ among two calls having the same extreme switching computers. If a node fails, all the VC's going through it are cleared down and the routing tables are updated so that VC's bypass this node. Normal action from customers is then to reset their VC's by placing new calls.
Buffer storage is assigned to a VC when it is created and is not shared with other VC's. Depending on the class of service buffer space is 32 or 256 bytes per VC per node.
The straightforward options which have been taken are seen as a basis for safe operation of the network irrespective of user behaviour. In particular the efficiency of the network is expected to be the highest, in terms of useful throughput, when the load is maximum (there is no "freeway" effect such that the throughput decreases sharply when the load increases too much).
5. CONCLUSION
The RCP experimental network is but one step towards the implementation of public packet switched data transmission services, both nationally and internationally.
The two main criteria according to which the RCP system is scrutinized are, besides economics, network serviceability and ease of connection for customer applications.
Click here to open technical illustrations (150KB) in a new window. These figures provide detailed data structures and state diagrams for link ctl, flow ctl and call setup/clear. IA2 to IA5 translation is also defined.