W8SDZ@SIMTEL20.ARPA (Keith Petersen) (09/03/85)
The following is supplied by TYMNET, Inc. and forwarded for your
information. Tymnet now supports this protocol. It offers error-free
terminal sessions, something all us modem users wish we had with our
net hosts!
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
uucp: ...!seismo!SIMTEL20.ARPA!W8SDZ
uucp: ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz
uucp: ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz
---cut here---X-PC.DOC part one of two---cut here---
X.PC Protocol Specification
Version 1.0
September 8, 1983
Tymshare, Inc.
Network Technology Division
N O T I C E
This specification is published by Tymshare as a proposal to
the designers and implementors of personal computer communica-
tions software and packet network systems. Tymshare Inc.
reserves the right to revise this specification for any reason,
including conformity with standards promulgated by ANSI, CCITT,
ECMA, ISO, NBS, or similar agencies; utilization of new tech-
nology; or accommodation of changes in communications systems.
Liability for difficulties arising from technical limitations
is disclaimed.
The provision of a network service based on a protocol as
described in this document requires further technical assess-
ment as well as certain business decisions. As of the date of
publication of this document, this technical assessment has not
been completed nor have the business decisions been made. Any
expenditures that may be made predicated on the possible avail-
ability of this service are the sole responsibility of the
party authorizing such expenditures.
PREFACE
This specification is the product of Tymnet research into the
market need and potential models for a reliable communication
protocol that provides value-added packet switched network
services to personal computers.
Personal computers, once used only as dedicated and isolated
systems, are increasingly being used in applications requiring
reliable communication with other personal and host computers.
The X.PC protocol provides reliable communication over dial-up,
asynchronous communications links between personal computers
and packet switched networks.
Being a derivative of X.25, X.PC provides the class of service
defined by the Open Systems Interconnect model for the network
layer.
Tymnet solicits comments on this specification from all inter-
ested parties. Comments should be addressed to:
X.PC Development Group
Network Technology Division
Tymshare, Inc.
10261 Bubb Road
Cupertino, CA 95014
X.PC Protocol Specification September 8, 1983
CONTENTS
1.0 SCOPE AND FIELD OF APPLICATION .......................... 1
2.0 REFERENCES .............................................. 2
3.0 DESIGN GOALS ............................................ 3
3.1 Reliability .......................................... 3
3.1.1 Low Undetected Bit Error Rate ................... 3
3.1.2 Delivery of Data in Correct Sequence ............ 3
3.1.3 Recovery from Loss of Physical Connection ....... 4
3.2 Throughput ........................................... 4
3.2.1 Low Protocol Overhead ........................... 4
3.2.2 Window Algorithm ................................ 4
3.2.3 Timely Recovery from Transmission Line Errors ... 5
3.3 Functionality ........................................ 5
3.3.1 Multiple Logical Paths .......................... 5
3.3.2 Operation Without a Packet Switched Network ..... 5
3.3.3 Optimization for Batch or Interactive Traffic ... 5
3.3.4 Different Levels of Service ..................... 6
3.4 Standards ............................................ 6
3.5 Compatibility with Personal Computer Capabilities .... 6
4.0 PACKET LAYER LOGICAL INTERFACE .......................... 7
4.1 Introduction and General Considerations .............. 7
4.1.1 Logical Channels ................................ 8
4.1.2 Packet Layer Entity ............................ 11
4.1.3 Basic Packet Structure ......................... 11
Page i
X.PC Protocol Specification September 8, 1983
4.1.4 Maximum Packet Size ............................ 13
4.1.5 Determining DTE/DXE Characteristics ............ 13
4.2 Flow Control Procedures ............................. 13
4.2.1 Numbering of Packets ........................... 13
4.2.2 Window Description ............................. 14
4.2.3 Data Packet Limit .............................. 14
4.2.4 Flow Control Principles ........................ 14
4.2.5 Receive Ready Packet ........................... 15
4.2.6 Receive Not Ready Packet ....................... 16
4.3 Error Recovery Procedures ........................... 16
4.3.1 T15/T25 Timer and R15/R25 Counter .............. 16
4.3.2 T17/T27 Timer and R17/R27 Counter .............. 18
4.3.3 Other Timers and Counters ...................... 19
4.3.4 Out-of-Sequence Packet ......................... 19
4.3.5 Duplicate Packets .............................. 22
4.4 Packet Format Introduction .......................... 22
4.4.1 General Format Identifier Field ................ 23
4.4.2 Logical Channel Identifier Field ............... 24
4.4.3 Packet Receive Sequence Number Field ........... 24
4.4.4 Packet Send Sequence Number Field .............. 24
4.4.5 Packet Type Identifier Field ................... 24
4.5 Call Setup and Call Clearing Packet Formats ......... 26
4.5.1 Call Request and Incoming Call Packets ......... 26
4.5.2 Call Accepted and Call Connected Packets ....... 30
Page ii
X.PC Protocol Specification September 8, 1983
4.5.3 Clear Request and Clear Indication Packets ..... 33
4.5.4 Clear Confirmation Packet ...................... 35
4.6 Data and Interrupt Packet Formats ................... 36
4.6.1 Data Packet .................................... 36
4.6.2 Interrupt Packet ............................... 37
4.6.3 Interrupt Confirmation Packet .................. 38
4.7 Flow Control Packet Formats ......................... 39
4.7.1 Receive Ready Packet ........................... 39
4.7.2 Receive Not Ready Packet ....................... 40
4.8 Reset Packet Formats ................................ 41
4.8.1 Reset Request and Reset Indication Packets ..... 41
4.8.2 Reset Confirmation Packet ...................... 43
4.9 Restart Packet Formats .............................. 44
4.9.1 Restart Request and Restart Indication Packets . 44
4.9.2 Restart Confirmation Packet .................... 47
4.10 Diagnostic Packet Format ........................... 47
4.11 Reject Packet Format ............................... 49
4.12 Optional User Facilities Other Than X.25 ........... 50
4.13 Optional User Facility Format ...................... 50
4.13.1 Flow Control Parameter Packet Size ............ 51
4.13.2 Flow Control Parameter Window Size ............ 51
4.13.3 Reconnect Facility ............................ 52
5.0 DATA LINK LAYER SPECIFICATION .......................... 53
5.1 Framing Format ...................................... 53
Page iii
X.PC Protocol Specification September 8, 1983
5.2 Maximum Data Link Frame Size ........................ 55
Appendix A, PACKET FORMATS ................................. 56
INDEX ...................................................... 66
Page iv
X.PC Protocol Specification September 8, 1983
Tables
______
1 Packet Groupings/Functions ............................. 12
2 DCE and DTE Timers and Counters ........................ 19
3 General Format Identifier .............................. 23
4 Packet Type Identifier ................................. 25
5 Coding of the Restarting Cause Field in Restart
Indication Packets ..................................... 46
Figures
_______
1 Logical Channel Identifier Assignment .................. 9
2 General Packet Format .............................. 11, 56
3 Timer Recovery from Lost Acknowledgment ................ 17
4 Timer Recovery from Loss of Last Packet Sent in a
Window with No More Packets to Send .................... 18
5 Recovery from Out-of-Sequence Packet ................... 20
6 Recovery from More Than One Lost Packet ................ 21
7 Timer Recovery from Loss of Last Packet Sent in a
Window with More Packets to Send ....................... 22
8 Call Request and Incoming Call Packet Format ....... 27, 57
9 Call Accepted and Call Connected Packet Format ..... 31, 58
10 Clear Request and Clear Indication Packet Format ... 34, 59
11 Clear Confirmation Packet Format ................... 36, 59
12 Data Packet Format ................................. 37, 60
13 Interrupt Packet Format ............................ 38, 60
14 Interrupt Confirmation Packet Format ............... 39, 61
15 Receive Ready Packet Format ........................ 40, 61
Page v
X.PC Protocol Specification September 8, 1983
16 Receive Not Ready Packet Format .................... 41, 62
17 Reset Request and Reset Indication Packet Format ... 42, 62
18 Reset Confirmation Packet Format ................... 44, 63
19 Restart Request and Restart Indication Packet
Format.............................................. 45, 63
20 Restart Confirmation Packet Format ................. 47, 64
21 Diagnostic Packet Format ........................... 48, 64
22 Reject Packet Format ............................... 49, 65
23 X.PC Data Link Transmission Frame Format ............... 54
Page vi
X.PC Protocol Specification September 8, 1983
X.PC PROTOCOL SPECIFICATION
SECTION 1.0 SCOPE AND FIELD OF APPLICATION
___________
This specification defines the formats and procedures at X.PC's
packet and data link layers for Data Terminal Equipment (DTE)
and Data Communication Equipment (DCE). Both switched virtual
call and permanent virtual call modes of operation are defined.
This specification covers DTE and DCE operation when a packet
switched network is accessed through a circuit switched or ded-
icated connection. It also includes the additional packet
layer procedures necessary for two DTEs to communicate directly
(i.e., without an intervening packet switched network) over a
dedicated or circuit switched connection.
SCOPE AND FIELD OF APPLICATION Page 1
X.PC Protocol Specification September 8, 1983
SECTION 2.0 REFERENCES
______________________
CCITT Recommendation X.25, Interface between data terminal
equipment (DTE) and data circuit-terminating equipment (DCE)
for terminals operating in the packet mode on public data net-
works, X25 DR80002.
ISO Standard X.25, Packet Layer Specification for Data Terminal
Equipment, ISO/TC 97/SC 6.
CCITT Recommendation X.96, Call progress signals in public data
networks, Vol VIII, Fascicle VIII.3.
ISO Reference Model of Open Systems Interconnection for CCITT
Applications.
REFERENCES Page 2
X.PC Protocol Specification September 8, 1983
SECTION 3.0 DESIGN GOALS
________________________
This section addresses reliability, throughput, functionality,
compatibility with standards, and compatibility with personal
computer processing capability.
SECTION 3.1 Reliability
_______________________
The X.PC protocol must provide for the error-free exchange of
data between DTE and DXE, where error-free is defined as a low
undetected bit error rate, the delivery of data in correct
sequence, and the ability to recover from loss of the physical
connection. The term DXE is used in those contexts where
either a DTE or a DCE is applicable.
3.1.1 Low Undetected Bit Error Rate
____________
User data is grouped into X.PC packets that are protected by
the X.PC data link frame. Cyclic redundancy check bits provide
the following level of detection:
Single bit errors: 100%
Double bit errors: 100%
Odd number of error bits: 100%
Error burst less than 17 bits: 100%
Error burst greater than 17 bits: 10(-5) probability that the
burst is undetected
Assuming a fixed-length block of 1000 bits transmitted over a
1200 bit per second dial-up telephone line with an error rate
of 10(-3), the theoretical undetected error rate is 10(-3) x
10(-5) or 10(-8). The probability is that as many as 100,000
blocks can be transmitted (in 1388 hours) before an undetected
error occurs. The figure used for the telephone line error
rate, 10(-3), is pessimistic.
3.1.2 Delivery of Data in Correct Sequence
_____
User data is grouped into packets that are sequentially num-
bered using modulo 16 arithmetic. Packets lost due to trans-
mission line errors are retransmitted using this sequence num-
ber, recovering the lost packet in the correct sequence.
DESIGN GOALS Page 3
X.PC Protocol Specification September 8, 1983
Duplicate packets, which may be transmitted to recover from
transmission line errors, are detected by the same sequence
numbering scheme and are discarded, thus preserving the origi-
nal data sequence.
3.1.3 Recovery from Loss of Physical Connection
X.PC reconnects logical paths without loss or duplication of
data using its reconnect facility. Keys are exchanged at the
time logical paths are established which, in the event the
physical connection is lost, can be exchanged to reestablish
logical connections once the physical connection is reestabl-
ished.
SECTION 3.2 Throughput
______________________
Given the 20% overhead of asynchronous character framing, X.PC
must utilize the remaining bandwidth as efficiently as possible
to provide good throughput and to minimize delay. Bandwidth is
utilized efficiently through low protocol overhead, a window
algorithm, and timely recovery from transmission line errors.
3.2.1 Low Protocol Overhead
____________________
Assuming a packet containing 128 octets of user data, X.PC's
protocol overhead is 8 octets, resulting in 94% utilization of
the asynchronous bandwidth.
Length encoding for data transparency minimizes protocol over-
head. Unlike byte stuffing, which incurs an increasing amount
of overhead dependent on data values, length encoding incurs a
low constant fixed overhead independent of data values.
Eliminating duplication of function between protocol layers
also contributes to the reduction of protocol overhead. X.PC
provides flow control and error recovery at one protocol layer
and error detection at another.
3.2.2 Window Algorithm
________________
Through the use of sequence numbers combined with a window
algorithm X.PC allows multiple packets to be transmitted before
acknowledgment is required. X.PC also allows acknowledgments
to be added to data flowing in the opposite direction.
DESIGN GOALS Page 4
X.PC Protocol Specification September 8, 1983
3.2.3 Timely Recovery from Transmission Line Errors
X.PC's data frame protects the packet header, which contains
the packet sequence numbers, separately from the rest of the
packet, which contains user data. Because the packet sequence
numbers are known, errors that occur in the second part of the
frame result in the immediate request for retransmission of the
frame rather than waiting for another packet or a timeout.
SECTION 3.3 Functionality
_________________________
X.PC combines the capabilities and characteristics of a packet
switched network and personal computers. This is accomplished
by providing multiple logical paths over a single physical con-
nection, operating without an intervening packet switched net-
work, allowing optimization for batch or interactive traffic,
and providing different levels of service.
3.3.1 Multiple Logical Paths
___________________
The combination of X.PC's multiple logical paths with a multi-
ple window server on a personal computer opens the door to a
new generation of networking applications nearly unlimited in
scope. X.PC is also ideally suited to service the coming gen-
eration of multiple task applications.
3.3.2 Operation Without a Packet Switched Network
Although X.PC is intended for use between a personal computer
and a packet switched network, the protocol does allow for
direct connection between personal computers or between a per-
sonal computer and a host.
3.3.3 Optimization for Batch or Interactive Traffic
During call setup, both packet size and window size can be
negotiated to optimize for the traffic type.
DESIGN GOALS Page 5
X.PC Protocol Specification September 8, 1983
3.3.4 Different Levels of Service
______________
X.PC specifies both a simple permanent virtual call procedure
and a more powerful switched virtual call procedure. Both pro-
cedures can be used simultaneously over the same physical con-
nection.
SECTION 3.4 Standards
_____________________
X.PC is based on CCITT recommendation X.25 and thus benefits
from the wide understanding of X.25's principles. Further,
because X.PC provides nearly all X.25 functions to asynchro-
nous, low-speed personal computers, it is possible for an
intelligent packet switched network to convert X.PC into a
CCITT X.25 network.
X.PC's being based upon CCITT recommendation X.25 also provides
a growth path for the implementation of X.28/X.29 PAD functions
in a personal computer. In general, X.PC provides an excellent
base upon which higher level protocols may be implemented.
SECTION 3.5 Compatibility with Personal Computer Capabilities
X.PC was designed to be implemented easily on the current gen-
eration of high performance 8-bit and 16-bit microprocessors.
Most of the protocol fields occupy either the high order 4 bits
or low order 4 bits of an octet, which are easily accommodated
by both high-level and low-level languages. The remaining
fields occupy full octets.
The use of length encoding for data transparency minimizes CPU
overhead compared to byte stuffing, in which every data charac-
ter must be processed.
DESIGN GOALS Page 6
X.PC Protocol Specification September 8, 1983
SECTION 4.0 PACKET LAYER LOGICAL INTERFACE
___________
This section contains an introduction to the packet layer logi-
cal interface, flow control and error recovery procedures, and
discussions of the various packet formats and optional user
facilities other than X.25.
SECTION 4.1 Introduction and General Considerations
__
This section defines X.PC's packet layer, which governs the
transfer of packets at a DTE/DCE or DTE/DTE interface, from the
viewpoint of both the DTE and DCE.
The packet layer in a sending DXE packetizes messages delivered
by a higher level entity in the same DXE before giving the
information to a link layer protocol for transmission.
The packet layer in a receiving DXE receives packets from the
link layer, checks the packets for correctness, strips off
packet layer headers, generates messages from the packetized
user data, and passes them to a higher level entity in the same
DXE.
X.PC's packet layer logical interface provides the following
capabilities that facilitate reliable and efficient data commu-
nication:
o Multiplexing: The ability to support multiple data streams
o Flow control: The ability to control, for each data
stream, the flow of data between transmitting and receiv-
ing DTEs and DXEs
o Error control: The ability to detect errors at the packet
layer and to correct errors indicated by the link layer
o Reset and restart: The ability to reinitialize communica-
tion paths at the packet layer if serious errors occur
These functions are made possible through the use of:
o Logical channel numbers
o Send and receive sequence numbers
o Data packets
PACKET LAYER LOGICAL INTERFACE Page 7
X.PC Protocol Specification September 8, 1983
o Control packets that regulate information flow
o Control packets that request retransmission of data packets
o Control packets that reinitialize communication
4.1.1 Logical Channels
________________
To permit simultaneous switched virtual calls, logical channels
are used. Each call is assigned a logical channel identifier,
which is a number in the range 1 - 15. The logical channel
identifier is assigned during the call setup phase from a range
of previously agreed upon logical channel identifiers. Logical
channel identifier 0 is reserved and may not be assigned.
A DTE's use of particular logical channels is agreed upon for a
period with the DXE. Figure 1 shows the structure for assign-
ing logical channels. No more than 15 simultaneous virtual
calls may be established at any one time.
Logical channel 1 is used for a single logical channel DTE/DXE
interface. The logical channels shown in Figure 1 are used for
a multiple logical channel DTE/DXE interface.
PACKET LAYER LOGICAL INTERFACE Page 8
X.PC Protocol Specification September 8, 1983
LCI
-----------------
0 |
1 |
//
LIC | --.
| | One-way incoming
| |
HIC | --:
//
LTC | --.
| |
| | Two-way
| |
HTC | --:
//
LOC | --.
| |
| | One-way outgoing
| |
| |
HOC | --:
//
15 |
-----------------
LCI: Logical channel identifier
LIC: Lowest incoming channel HIC: Highest incoming channel
LTC: Lowest two-way channel HTC: Highest two-way channel
LOC: Lowest outgoing channel HOC: Highest outgoing channel
Figure 1 Logical Channel Identifier Assignment
The following comments apply to Figure 1.
Logical channels are assigned for a period with the DXE as fol-
lows:
Logical channels LIC to HIC: The range of logical channels that
are assigned to one-way incoming logical channels for virtual
calls (see Note 4).
Logical channels LTC to HTC: The range of logical channels that
are assigned to two-way logical channels for virtual calls.
PACKET LAYER LOGICAL INTERFACE Page 9
X.PC Protocol Specification September 8, 1983
Logical channels LOC to HOC: The range of logical channels that
are assigned to one-way outgoing logical channels for virtual
calls (see Note 4).
Logical channels outside the ranges LIC to HIC, LTC to HTC, and
LOC to HOC are unassigned logical channels.
Note 1: The references to logical channel identifiers are made
according to a set of contiguous numbers from 0 (low-
est) to 15 (highest) using bits 4 through 1 of octet 1.
The numbering is binary coded, where bit 1 is the low
order bit.
Note 2: logical channel identifier 0 may not be assigned.
Note 3: All logical channel boundaries are agreed upon with the
DXE for a specified time.
Note 4: In a DTE/DTE environment, one DTE views the range of
logical channel identifiers as presented here, whereas
the other DTE views it as a DCE (e.g., the latter DTE
views the range from LIC to HIC as one-way outgoing)
(see Section 4.2.5).
Note 5: In the absence of one-way incoming logical channels,
logical channel 1 is available for LTC. In the absence
of one-way incoming logical channels and two-way logi-
cal channels, logical channel 1 is available for LOC.
Note 6: The search algorithm of a DCE, or a DTE performing as a
DCE in a DTE/DTE environment, for a logical channel for
a new incoming call will be to use the lowest numbered
logical channel in the ready state (p1) in the range of
LIC to HIC and LTC to HTC. (See CCITT recommendation
X.25.)
Note 7: To minimize the risk of call collision, the DTE search
algorithm starts with the highest numbered logical
channel in the ready state (p1) in the two-way logical
channel (HTC) or one-way outgoing logical channel (HOC)
ranges.
PACKET LAYER LOGICAL INTERFACE Page 10
X.PC Protocol Specification September 8, 1983
4.1.2 Packet Layer Entity
___________________
The concept of communication via logical channels is native to
packet layer terminology. It is conceivable, however, that a
DTE may have one or more connections to one or more packet net-
works and/or to one or more DTEs without an intervening packet
network. Therefore, it is necessary to introduce the concept
of a 'packet layer' entity. One such entity exists in a DTE
for each DTE/DTE (without an intervening packet network) inter-
face or for each DTE/DCE (packet network) interface.
Which entity to use to reach a particular destination is
decided external to the protocol described here. The items
discussed in this section pertain to each packet layer entity
in a DTE or DCE.
4.1.3 Basic Packet Structure
___________________
Each packet transferred across the DTE/DXE interface consists
of three or more octets. The first two octets contain the gen-
eral format identifier, logical channel identifier, packet
receive sequence number, and packet send sequence number
fields. The third octet contains either the packet type iden-
tifier or one octet of packet user data. Other packet fields
are appended as required (see Section 4.4). Figure 2 shows the
generalized packet format.
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | L C I |
1 | | |
|---:---:---:---:---:---:---:---|
| P(R) | P(S) |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | |
|---:---:---:---:---:---:---:---|
| Additional fields dependent |
// on packet type //
| |
|---:---:---:---:---:---:---:---|
Figure 2 General Packet Format
PACKET LAYER LOGICAL INTERFACE Page 11
X.PC Protocol Specification September 8, 1983
For interoperability across all DTE/DXE interfaces, any addi-
tional field appended after the first three octets must contain
an integral number of octets.
Packet types are given in Table 1.
Table 1
Packet Groupings/Functions
|--------------.--------------------------.------------------------|
| Packet Group | Function | Packet Type |
|--------------|--------------------------|------------------------|
| Call setup | Establish and terminate | Call request |
| and call | a virtual call for | Incoming call |
| clearing | DTE/DXE communication; | Call accepted |
| (see note) | may convey data for | Call connected |
| | higher-level entity | Clear request |
| | processing | Clear indication |
| | | Clear confirmation |
|--------------|--------------------------|------------------------|
| Data and | Convey data or | Data |
| interrupt | interrupt information | Interrupt |
| | for higher-level | Interrupt confirmation |
| | entity processing | |
|--------------|--------------------------|------------------------|
| Flow control | Control the flow | Receive ready |
| and reset | of data packets | Receive not ready |
| | across a DTE/DXE | Reject |
| | interface | Reset request |
| | | Reset indication |
| | | Reset confirmation |
|--------------|--------------------------|------------------------|
| Restart | (Re)Initialize all | Restart request |
| | communication between | Restart indication |
| | a DTE and a DXE | Restart confirmation |
|--------------|--------------------------|------------------------|
| Diagnostic | Pass error diagnostics | Diagnostic |
| | to a DXE | |
|------------------------------------------------------------------|
Note: Call setup and call clearing packets and procedures are not
required for permanent virtual circuit Services.
PACKET LAYER LOGICAL INTERFACE Page 12
X.PC Protocol Specification September 8, 1983
4.1.4 Maximum Packet Size
___________________
The data packet user data field may contain no more than
256 octets. The maximum packet size, including packet over-
head, is 258 octets. The maximum number of data packet user
data field octets can be negotiated (see Section 4.13).
4.1.5 Determining DTE/DXE Characteristics
______
In a DTE/DTE environment (i.e., no intervening packet switched
network), the restart procedure determines which DTE acts as a
DCE with respect to logical channel selection during virtual
call establishment and the resolution of virtual call colli-
sion.
This procedure is defined in the ISO X.25 DTE packet layer
specification. In essence, the restart-cause code determines
the appropriate mode of operation. A restart-cause code of
zero in a restart indication packet identifies the originator
as a DTE.
A restart-cause code other than zero in a restart indication
packet identifies the originator as a DCE. Refer to the ISO
X.25 DTE packet layer specification for full details on the
restart procedure.
SECTION 4.2 Flow Control Procedures
__________________
At the DTE/DXE interface of a logical channel, the transmission
of data packets is controlled separately for each direction and
is based on authorization from the receiver.
4.2.1 Numbering of Packets
____________________
With the exception of the reset request/indication, restart
request/indication, receive ready (RR), receive not ready (RNR)
and reject packets, all packets transmitted across the DTE/DXE
interface in each direction are sequentially numbered. This
number is called the packet send sequence number P(S). The
sequence numbers are modulo 16. The packet sequence numbers
cycle through the range 0 - 15.
The restart request, restart indication, reset request, and
reset indication packets reset both the DTE and DXE P(S) and
P(R) to zero. Subsequent packets are numbered consecutively.
PACKET LAYER LOGICAL INTERFACE Page 13
X.PC Protocol Specification September 8, 1983
4.2.2 Window Description
__________________
At the DTE/DXE interface of a logical channel, a window is
defined as the modulo 16 ordered set of P(W) consecutive packet
send sequence numbers P(S) of all packets authorized to cross
the interface.
The P(S) of the first of the P(W) packets in the window is
referred to as the lower window edge. The upper window edge is
the P(S) of the last of the P(W) packets authorized to cross
the interface.
The P(S) of the first packet not authorized to cross the inter-
face is the value of the lower window edge plus P(W) (modulo
16). The standard window size P(W) is 8 for each direction of
packet transmission at the DTE/DXE interface. The minimum win-
dow size P(W) is 4.
4.2.3 Data Packet Limit
_________________
The data packet limit is the number of data packets that may be
transmitted in a window. The data packet limit is one half of
P(W) for each direction of data transmission at the DTE/DXE
interface. The standard default data packet limit is 4.
The DXE uses D(S) to count transmitted data packets and D(R) to
count received data packets.
4.2.4 Flow Control Principles
__________________
When the send sequence number P(S) of the next packet to be
transmitted by a DXE other than a data packet is within the
window, the DXE is authorized to transmit the packet.
When P(S) of the next data packet to be transmitted by a DXE is
within the window and D(S) is greater than zero, the DXE is
authorized to transmit the data packet. On transmitting the
data packet the DXE decrements its D(S).
When P(S) of the packet received by a DXE other than a data
packet is next in sequence and is within P(W), the DXE will
accept the packet.
When P(S) of the data packet received by a DXE is next in
sequence and the DXE's D(R) is greater than zero, the DXE will
accept the packet and decrement its D(R).
PACKET LAYER LOGICAL INTERFACE Page 14
X.PC Protocol Specification September 8, 1983
The modulo 16 packet receive sequence number P(R) conveys
across the DTE/DXE interface information from the receiver for
the transmission of packets. When transmitted across the
DTE/DXE interface, a valid P(R) (as defined below) becomes the
lower P(W) window edge. In this way, additional packets may be
authorized by the receiver to cross the DTE/DXE interface.
The packet receive sequence number P(R) is conveyed in data,
RR, RNR, and reject packets.
The value of a received P(R) must be greater than or equal to
the last P(R) received and less than or equal to the P(S) of
the next packet to be transmitted by that DXE. Otherwise, the
DXE will consider the receipt of this P(R) a procedure error
and will reset the logical channel. A DCE will indicate the
cause as 'Local Procedure Error.' A DTE will indicate the
cause as 'DTE Originated.' In either case, the diagnostic will
be 'Invalid P(R).'
The P(R) returned in any of the above mentioned packets is less
than or equal to the P(S) of the next packet expected. It
implies that the DXE transmitting P(R) has accepted all packets
up to and including the packet number P(R)-1. If any data
packets were acknowledged by the transmitted P(R), the number
of data packets acknowledged is added to D(R).
If the received P(R) acknowledges any data packets, the number
of data packets acknowledged is added to D(S). As acknowledg-
ments for data packets are sent, the number of data packets
acknowledged is added to the DXE's D(R).
4.2.5 Receive Ready Packet
____________________
A DXE uses receive ready (RR) packets to indicate that it is
ready to receive P(W) packets within the window starting with
P(R), where P(R) is indicated in the RR packet.
The transmission of an RR packet with a particular P(R) value
is not to be taken as a demand for retransmission of packets
that have already been transmitted and are still in the window.
For further information see Receive Ready Packet (Sec-
tion 4.7.1).
PACKET LAYER LOGICAL INTERFACE Page 15
X.PC Protocol Specification September 8, 1983
4.2.6 Receive Not Ready Packet
_________________
A DXE uses receive not ready (RNR) packets to indicate a tempo-
rary inability to accept additional data packets for a given
virtual call. A DXE receiving an RNR packet stops transmitting
data packets on the indicated logical channel but updates P(W)
by the P(R) value of the RNR packet if the P(R) is valid. The
receive not ready situation indicated by the transmission of an
RNR packet is cleared by the transmission in the same direction
of a receive ready packet or by the initiation of a clear (vir-
tual calls only), reset, or restart procedure.
The transmission of an RR packet after the transmission of an
RNR packet is not to be taken as a demand for retransmission of
data packets that have already been transmitted.
The RNR packet may be used to convey across the DTE/DXE inter-
face the P(R) value corresponding to a data packet that had the
D bit set to 1 if additional data packets cannot be accepted.
For further information see Receive Not Ready Packet (Sec-
tion 4.7.2) and Receive Ready Packet (Section 4.7.1).
SECTION 4.3 Error Recovery Procedures
________________
Lost or corrupted packets are recovered by the retransmission
of packets based on packet sequence numbers. Packets are
retransmitted whenever an out-of-sequence packet is detected or
a timer expires.
4.3.1 T15/T25 Timer and R15/R25 Counter
________
Timer T15 is used by a DCE and timer T25 by a DTE in recovering
from errors involving sequenced packets. The default value is
4 seconds.
Timer T25 is started when the first packet is transmitted
across the DTE/DXE interface. If T25 is still running at the
time of the transmission of succeeding packets, it implies that
previously transmitted packets are awaiting acknowledgment, and
no further action is taken.
When a P(R) is received acknowledging some of the outstanding
packets, T25 is restarted. If all the outstanding packets are
acknowledged, T25 is stopped.
PACKET LAYER LOGICAL INTERFACE Page 16
X.PC Protocol Specification September 8, 1983
When T25 expires, the DXE retransmits the last unacknowledged
packet, as many as R15 times for a DCE and R25 times for a DTE.
The default value of R15/R25 is 4. See Figures 3 and 4.
If the DCE R15 count is exceeded, the DCE will transmit a reset
indication. If the DTE R25 count is exceeded, the DTE will
transmit a reset request.
DCE timer T15 is stopped when a restart request or a reset
request is received. DTE timer T25 is stopped when a restart
indication or a reset indication is received.
DXE DXE
--- ---
| |
T25 started | Data 1,2 |
|---------------------->|
| Data 1,3 |
|---------------------->|
| Data 1,4 |
|---------------------->|
| Data 1,5 |
|---------------------->|
| |
RR packet | RR 6 | Acknowledges packets
is lost |<----- X --------------| 2 through 5
| |
| |
T25 expires, | Data 1,5 |
last packet |---------------------->|
is resent and | |
T25 restarted | | Duplicate packet is
| | discarded and reject
| REJ 6 | is issued
T25 stopped |<----------------------|
| |
T25 started, | Data 1,6 |
transmission |---------------------->|
continues | |
| |
| |
Figure 3 Timer Recovery from Lost Acknowledgment
PACKET LAYER LOGICAL INTERFACE Page 17
X.PC Protocol Specification September 8, 1983
DXE DXE
--- ---
| |
T25 started | Data 1,2 |
|---------------------->|
| Data 1,3 |
|---------------------->|
| Data 1,4 |
|---------------------->|
| Data 1,5 |
|------------- X ------>|
| |
| RR 5 | Acknowledges packets
T25 restarted |<----------------------| 2 through 4
| |
| |
T25 expires, | Data 1,5 |
last packet |---------------------->|
is resent and | |
T25 restarted | |
| RR 6 | Acknowledges packet 5
T25 stopped |<----------------------|
| |
| |
Figure 4 Timer Recovery from Loss of Last Packet Sent
__________in a Window with No More Packets to Send____
4.3.2 T17/T27 Timer and R17/R27 Counter
________
DCE timer T17 and DTE timer T27 are started whenever a reject
packet is transmitted. The T17/T27 timer is stopped when the
first retransmitted packet is received.
The DXE retransmits a reject packet no more than R17/R27 times
if no response is received.
DCE timer T17 is stopped when a restart request or a reset
request is received. DTE timer T27 is stopped when a restart
indication or a reset indication packet is received.
PACKET LAYER LOGICAL INTERFACE Page 18
X.PC Protocol Specification September 8, 1983
4.3.3 Other Timers and Counters
________________
In addition to the T15/T25 and T17/T27 timers and the R15/R25
and R17/R27 counters, other X.25 timers and counters are used
as specified. These are shown in Table 2.
Table 2
DCE and DTE Timers and Counters
DCE Timers and Counters
_____________
Timer Default Value Counter Default Value
T10 60 seconds
T11 180 seconds
T12 60 seconds
T13 60 seconds
T15 4 seconds R15 4
T17 4 seconds R17 4
DTE Timers and Counters
_____________
Timer Default Value Counter Default Value
T20 180 seconds R20 1
T21 200 seconds
T22 180 seconds R22 1
T23 180 seconds R23 1
T24 60 seconds
T25 4 seconds R25 4
T26 180 seconds
T27 4 seconds R27 4
4.3.4 Out-of-Sequence Packet
___________________
A lost packet is indicated when a P(S) is received that is not
consecutive (modulo 16) with the previous P(S). See Figures 5,
6, and 7. Where this happens the DXE sends a reject packet to
request retransmission of the missing packet.
Restart request, restart indication, reset request, and reset
indication packets have a P(S) of zero. Reception of these
packets out of sequence is not considered an error; these pack-
ets have the effect of resetting P(S) and P(R) to zero.
PACKET LAYER LOGICAL INTERFACE Page 19
X.PC Protocol Specification September 8, 1983
DXE DXE
--- ---
| |
T25 started | Data 1,2 |
|---------------------->|
| Data 1,3 |
|---------------------->|
| Data 1,4 |
|------------ X ------->| Packet lost
| Data 1,5 |
|---------------------->| Packet is out of
| | sequence, reject
| REJ 4 | is issued for
T25 stopped |<----------------------| missing packet 4
| |
| |
T25 started, | Data 1,4 |
retransmission |---------------------->|
starts with | Data 1,5 |
packet 4 |---------------------->|
| |
| |
Figure 5 Recovery from Out-of-Sequence Packet
PACKET LAYER LOGICAL INTERFACE Page 20
X.PC Protocol Specification September 8, 1983
DXE DXE
--- ---
| |
T25 started | Data 1,2 |
|---------------------->|
| Data 1,3 |
|---------------------->|
| Data 1,4 |
|------------ X ------->|
| Data 1,5 |
|------------ X ------->|
| |
| RR 4 | Acknowledges packets
T25 restarted |<----------------------| 2 through 3
| |
| |
T25 expires, | Data 1,5 |
last packet |---------------------->|
is resent and | | Packet is out of
T25 restarted | | sequence, reject
| | is issued for
| REJ 4 | packet 4
|<----------------------|
| |
T25 started, | Data 1,4 |
retransmission |---------------------->|
starts with | Data 1,5 |
packet 4 |---------------------->|
| |
Figure 6 Recovery from More Than One Lost Packet
PACKET LAYER LOGICAL INTERFACE Page 21
X.PC Protocol Specification September 8, 1983
DXE DXE
--- ---
| |
T25 started | Data 1,2 |
|---------------------->|
| Data 1,3 |
|---------------------->|
| Data 1,4 |
|---------------------->|
| Data 1,5 |
|------------- X ------>|
| |
T25 restarted | RR 5 | Acknowledges packets
|<----------------------| 2 through 4
| |
| |
Window rotates,| Data 1,6 |
packet 6 sent |---------------------->| Packet received
T25 restarted | | out of sequence,
| REJ 5 | and reject issued
T25 stopped |<----------------------|
| |
T25 started, | Data 1,5 |
retransmission |---------------------->|
starts with | Data 1,6 |
packet 5 |---------------------->|
| |
| |
Figure 7 Timer Recovery from Loss of Last Packet Sent
__________in a Window with More Packets to Send_______
4.3.5 Duplicate Packets
_________________
Duplicate packets are discarded and the DXE sends a reject
packet to indicate the next P(S) expected. See Figure 3.
SECTION 4.4 Packet Format Introduction
_______________
A packet always includes the general format identifier field,
the logical channel identifier field, the packet sequence num-
ber(s), and the packet type identifier field. Depending on the
particular packet type, other fields may also be defined. (See
Section 4.1.3.)
PACKET LAYER LOGICAL INTERFACE Page 22
X.PC Protocol Specification September 8, 1983
The possible extension of packet formats by the addition of new
fields requires further study. Any such field would be
included only as an addition that follows all previously
defined fields and not as an insertion between any of the pre-
viously defined fields. It would be transmitted to a DTE only
when the interfacing DXE has been informed that the receiving
DTE is able to interpret this field and act upon it or when
the receiving DTE can ignore the field without adversely
affecting the operation of the interfacing DXE. It would not
contain any information pertaining to a user facility to which
the DTE has not subscribed.
The bits of an octet are numbered 8 to 1, where bit 1 is the
low order bit and is transmitted first. Octets of a packet are
consecutively numbered from 1 and are transmitted in order.
4.4.1 General Format Identifier Field
__________
The general format identifier field is a 4-bit, binary coded
field that indicates the general format of the rest of the
header. The general format identifier field comprises bits 8,
7, 6, and 5 of octet 1, where bit 5 is the low order bit (see
Table 3).
Bit 8 of the general format identifier is set to 0 to indicate
a data packet; it is set to 1 for all other packets. Bits 7,
6, and 5 of the data packet are used for the D bit, Q bit, and
M bit respectively (see Section 4.6.1).
Bits 7, 6, and 5 of all other packets are set to 1.
Table 3
General Format Identifier
|-------------------------------------|
| | Octet 1 |
| | Bits |
| | 8 7 6 5 |
|---------------------|---------------|
| Data packets | 0 D Q M |
|---------------------|---------------|
| All other packets | 1 0 0 0 |
|-------------------------------------|
PACKET LAYER LOGICAL INTERFACE Page 23
X.PC Protocol Specification September 8, 1983
4.4.2 Logical Channel Identifier Field
_________
The logical channel identifier field appears in every packet in
bit positions 4, 3, 2, and 1 of octet 1. The field is binary
coded, and bit 1 is the low order bit.
For each logical channel, this number has local significance at
the DTE/DCE interface.
In restart and diagnostic packets all bits in this field are
set to 0's.
4.4.3 Packet Receive Sequence Number Field
_____
The packet receive sequence number field appears in every
packet in bit positions 8, 7, 6, and 5 of octet 2. The field
is binary coded, and bit 5 is the low order bit.
In the restart request and restart indication packets all bits
in this field are set to 0.
4.4.4 Packet Send Sequence Number Field
________
The packet send sequence number field appears in every packet
in bit positions 4, 3, 2, and 1 of octet 2. The field is
binary coded, and bit 1 is the low order bit.
In the restart request, restart indication, RR, RNR, and REJ
packets all bits in this field are set to 0.
4.4.5 Packet Type Identifier Field
_____________
Packets with bit 8 of the general format identifier set to 1,
i.e., all packets other than data packets, are identified in
octet 3 as specified in Table 4.
PACKET LAYER LOGICAL INTERFACE Page 24
X.PC Protocol Specification September 8, 1983
Table 4
Packet Type Identifier
|------------------------------------------------------------------|
| Packet Type | Octet 3 |
| | Bits |
| From DXE to DTE From DTE to DXE | 8 7 6 5 4 3 2 1 |
|------------------------------------------------|-----------------|
| Call Setup and Call Clearing | |
| | |
| Incoming call Call request | 0 0 0 0 1 0 1 1 |
| Call connected Call accepted | 0 0 0 0 1 1 1 1 |
| Clear indication Clear request | 0 0 0 1 0 0 1 1 |
| Clear confirmation Clear confirmation | 0 0 0 1 0 1 1 1 |
| | |
| DATA and Interrupt | |
| | (Note 2) |
| Data (Note 1) Data | X X X X X X X X |
| Interrupt Interrupt | 0 0 1 0 0 0 1 1 |
| Interrupt confirmation Interrupt confirmation | 0 0 1 0 0 1 1 1 |
| | |
| Flow Control and Reset | |
| | |
| Receive ready Receive ready | 0 0 0 0 0 0 0 1 |
| Receive not ready Receive not ready | 0 0 0 0 0 1 0 1 |
| Reject Reject | 0 0 0 0 1 0 0 1 |
| Reset indication Reset request | 0 0 0 1 1 0 1 1 |
| Reset confirmation Reset confirmation | 0 0 0 1 1 1 1 1 |
| | |
| Restart | |
| | |
| Restart indication Restart request | 1 1 1 1 1 0 1 1 |
| Restart confirmation Restart confirmation | 1 1 1 1 1 1 1 1 |
| | |
| Diagnostic | |
| | |
| Diagnostic Diagnostic | 1 1 1 1 0 0 0 1 |
| (Notes 3,4) (Note 4) | |
|------------------------------------------------------------------|
Note 1: Octet 3 of the data packet contains one octet of user data.
Note 2: An X bit may be set either to 0 or to 1, as discussed in
subsequent sections.
Note 3: DCE to DTE, if implemented by the network.
Note 4: A DTE may originate a diagnostic packet only in a DTE/DTE
environment and only if it can be suppressed when connected
to a network.
PACKET LAYER LOGICAL INTERFACE Page 25
X.PC Protocol Specification September 8, 1983
SECTION 4.5 Call Setup and Call Clearing Packet Formats
The packets described in this section set up and clear a vir-
tual call.
4.5.1 Call Request and Incoming Call Packets
___
Figure 8 illustrates the format of call request and incoming
call packets.
In a DTE/DCE environment, call request and incoming call pack-
ets are separate packets because of the intervening network.
However, in a DTE/DTE environment, the call request packet sent
by one DTE is the same as the incoming call packet received by
the other DTE.
The first three octets consist of the general format identi-
fier, the logical channel identifier, the packet receive
sequence number, the packet send sequence number, and the
packet type identifier fields (see Sections 4.4.1 through
4.4.5).
PACKET LAYER LOGICAL INTERFACE Page 26
X.PC Protocol Specification September 8, 1983
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | L C I |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| P(R) | P(S) |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 0 1 0 1 1 |
|---:---:---:---:---:---:---:---|
| Calling DTE : Called DTE |
4 | address length: address length|
|---:---:---:---:---:---:---:---|
| DTE address(es) |
// (Note 2) //
| :---:---:---:---|
| | 0 0 0 0 |
|---:---:---:---:---:---:---:---|
| 0 0 | Facility length |
| | |
|---:---:---:---:---:---:---:---|
| Facilities |
// (Note 3) //
| |
:---:---:---:---:---:---:---:---:
| Call user data |
// (Notes 4 and 5) //
| |
:---:---:---:---:---:---:---:---:
Note 1: Coded 1000
Note 2: The figure is drawn assuming the total number of
address digits present is odd.
Note 3: The maximum length of the facilities field is 63
octets.
Note 4: Bits 8 and 7 of the first octet of call user data may
have particular significance (see Section 4.5.1).
Note 5: The maximum length of the call user data field is 16
octets.
Figure 8 Call Request and Incoming Call Packet Format
PACKET LAYER LOGICAL INTERFACE Page 27
X.PC Protocol Specification September 8, 1983
Address Lengths Field
_____________________
Octet 4 consists of field length indicators for the called and
calling DTE addresses. Bits 4, 3, 2, and 1 indicate the length
of the called DTE address in quartets. Bits 8, 7, 6, and 5
indicate the length of the calling DTE address in quartets.
Each address length indicator is binary coded, and bit 1 or 5
is the low order bit of the indicator.
Address Field
_____________
Octet 5 and subsequent octets consist of the called DTE address
when present, then the calling DTE address when present.
Each digit of an address is coded in a quartet in binary coded
decimal, when bit 5 or 1 is the low order bit of the digit.
Starting from the high order digit, the address is coded in
octet 5 and consecutive octets, with two digits per octet. In
each octet, the higher order digit is coded in bits 8, 7, 6,
and 5.
The field will be rounded up to an integral number of octets by
inserting 0's in bits 4, 3, 2, and 1 of the last octet of the
field.
This field may be used for optional addressing facilities such
as abbreviated addressing. The optional addressing facilities
employed and the coding of those facilities require further
study.
Facility Length Field
_____________________
Bits 6, 5, 4, 3, 2, and 1 of the octet following the calling
DTE address field (or calling DTE address field length if the
calling DTE address field length is zero) indicate the length
of the facility fields, in octets. The facility-length indica-
tor is binary coded, where bit 1 is the low order bit of the
indicator.
Bits 8 and 7 of this octet are unassigned and are set to 0.
PACKET LAYER LOGICAL INTERFACE Page 28
X.PC Protocol Specification September 8, 1983
Facility Field
______________
The facility field is present only if the DTE or DXE is using
an optional user facility requiring some indication in the call
request packet or the incoming call packet.
The facility field contains an integral number of octets. The
maximum length of this field depends on the facilities that are
supported at the DTE/DXE interface. However, this maximum can-
not exceed 63 octets.
For further information see Sections 4.12 and 4.13.
Call User Data Field
____________________
Following the facility field, the call user data field may be
present. It has a maximum length of 16 octets. This field
must contain an integral number of octets (see Section 4.1.3).
If the call user data field is present, the use and format of
the field are determined by bits 8 and 7 of the first octet of
this field. When a virtual call is being established between
two packet mode DTEs, the network does not act on any part of
the call user data field unless required to do so by an appro-
priate request for an optional user facility on a per-call
basis. Such a facility requires further study.
If bits 8 and 7 of the first octet of the call user data field
are 00, a portion of the call user data field is used for pro-
tocol identification in accordance with other CCITT recommenda-
tions such as X.29.
If bits 8 and 7 of the first octet of the call user data field
are 01, a portion of the call user data field may be used for
protocol identification in accordance with specifications of
public network administrations.
If bits 8 and 7 of the first octet of the call user data field
are 10, a portion of the call user data field may be used for
protocol identification in accordance with the specifications
of international user bodies.
If bits 8 and 7 of the first octet of the call user data field
are 11, no constraints are placed on the DTE regarding the use
of the remainder of the call user data field.
PACKET LAYER LOGICAL INTERFACE Page 29
X.PC Protocol Specification September 8, 1983
If bits 8 and 7 of the first octet of the call user data field
have any value other than 11, a protocol may be identified that
is implemented in public data networks.
4.5.2 Call Accepted and Call Connected Packets
_
Figure 9 illustrates the format of call accepted and call con-
nected packets.
In a DTE/DCE environment, call accepted and call connected
packets are separate packets because of the intervening net-
work. However, in a DTE/DTE environment, the call accepted
packet sent by one DTE is the same as the call connected packet
received by the other DTE.
The first three octets consist of the general format identi-
fier, the logical channel identifier, the packet receive
sequence number, the packet send sequence number, and the
packet type identifier fields (see Sections 4.4.1 through
4.4.5).
---cut here--end of part one---cut here