X.PC protocol description - part two of two
Keith Petersen
W8SDZ at SIMTEL20.ARPA
Tue Sep 3 22:36:09 AEST 1985
---cut here---X-PC.DOC part two of two---cut here---
PACKET LAYER LOGICAL INTERFACE Page 30
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 1 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 9 Call Accepted and Call Connected Packet Format
PACKET LAYER LOGICAL INTERFACE Page 31
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 32
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.
4.5.3 Clear Request and Clear Indication Packets
Figure 10 illustrates the format of clear request and clear
indication packets.
In a DTE/DCE environment, clear request and clear indication
packets are separate packets because of the intervening net-
work. However, in a DTE/DTE environment, the clear request
packet sent by one DTE is the same as the clear indication
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 33
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 1 0 0 1 1 |
|---:---:---:---:---:---:---:---|
| Clearing cause |
4 | |
|---:---:---:---:---:---:---:---|
| Diagnostic code |
5 | (Note 3) |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Note 2: Address format default is CCITT X.121.
Note 3: Diagnostic code is optional
Figure 10 Clear Request and Clear Indication Packet Format
Clearing Cause Field
____________________
Octet 4 is the clearing cause field; it contains the reason for
the clearing of the call.
The bits of the clearing cause field in a clear request packet
must be set to 0 by a DTE. Further study is required to deter-
mine whether other values of these bits are ignored or proc-
essed by the DCE in a DTE/DCE environment.
The coding of the clearing cause field in a clear indication
packet is defined in CCITT recommendation X.96. In a DTE/DCE
environment, a DTE, to allow for possible later extensions of
the defined values of the clearing cause field, must be able to
accept any value in the clearing cause field. In a DTE/DTE
environment, a DTE may either accommodate a nonzero clearing
cause field as it does in a DTE/DCE environment (i.e., process
the packet normally) or treat it as an error. In the latter
case, the packet layer transmits a clear request packet with a
PACKET LAYER LOGICAL INTERFACE Page 34
X.PC Protocol Specification September 8, 1983
cause indicating 'DTE Originated' and the diagnostic 'Nonzero
Cause Field from DTE.'
Diagnostic Code Field
_____________________
Octet 5 is the diagnostic code field; it contains additional
information regarding the reason for the clearing of the call.
The coding of the diagnostic code field follows CCITT X.25 rec-
ommendations.
In a clear request packet, the diagnostic code field is
required, even if it indicates no additional information.
In a clear indication packet, if the clearing cause field indi-
cates 'DTE Originated,' the diagnostic code field has been
passed unchanged from the remote DTE as a result of its having
initiated either a clearing procedure or, in a DTE/DCE environ-
ment, a restarting procedure. In a clear indication packet, if
the clearing cause field does not indicate 'DTE Originated,'
the diagnostic code field is network generated.
The contents of the diagnostic code field do not alter the
meaning of the clearing cause field. A DTE is not required to
undertake any action on the contents of the diagnostic code
field. The clearing cause field must be accepted even if the
diagnostic code field contains an unspecified code combination.
4.5.4 Clear Confirmation Packet
________________
Figure 11 illustrates the format of the clear confirmation
packet transmitted by a DTE and the format of the clear confir-
mation packet received by a 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 35
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 1 0 1 1 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 11 Clear Confirmation Packet Format
SECTION 4.6 Data and Interrupt Packet Formats
________
The data, interrupt, and interrupt confirmation packets trans-
mit data or are used with the interrupt procedure.
4.6.1 Data Packet
___________
Figure 12 illustrates the format of the data packet transmitted
by a DXE and the format of the data packet received by a DXE.
The first three octets consist of the general format identi-
fier, the logical channel identifier, the packet receive
sequence number, and the packet send sequence number fields
(see Sections 4.4.1 through 4.4.5). The 0 in bit 8 of the gen-
eral format identifier distinguishes the data packet from other
packet types; the remainder of the general format identifier
field is used as noted below.
Bit 7 of octet 1 is the delivery confirmation (D) bit.
Although the D bit is specified, D bit procedures are not yet
specified. The procedures require further study.
Bit 6 of octet 1 is the more data mark (M bit). A 0 indicates
no more data; a 1 indicates more data.
Bit 5 of octet 1 is the qualifier (Q) bit.
PACKET LAYER LOGICAL INTERFACE Page 36
X.PC Protocol Specification September 8, 1983
Octets following octet 2 contain user data. This field must
contain an integral number of octets, to the stated maximum
(see Section 4.1.3). The field must contain at least one octet
of user data.
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | L C I |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| P(R) | P(S) |
2 | | |
|---:---:---:---:---:---:---:---|
| User data |
// //
| |
|---:---:---:---:---:---:---:---|
Note 1: Coded 0DQM, where D = D bit, Q = Q bit, and M = M bit
Figure 12 Data Packet Format
4.6.2 Interrupt Packet
________________
Figure 13 illustrates the format of the interrupt packet trans-
mitted by a DXE and the format of the interrupt packet received
by a DXE.
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).
Octet 4 contains the one octet of interrupt user data.
PACKET LAYER LOGICAL INTERFACE Page 37
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 1 0 0 0 1 1 |
|---:---:---:---:---:---:---:---|
| Interrupt user data |
4 | |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 13 Interrupt Packet Format
4.6.3 Interrupt Confirmation Packet
____________
Figure 14 illustrates the format of the interrupt confirmation
packet transmitted by a DXE and the format of the interrupt
confirmation packet received by a DXE.
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 38
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 1 0 0 1 1 1 |
|---:---:---:---:---:---:---:---|
4 | Interrupt user data |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 14 Interrupt Confirmation Packet Format
SECTION 4.7 Flow Control Packet Formats
______________
The receive ready and receive not ready packets control the
flow of data packets (The data and reject packets, described in
Sections 4.6.1 and 4.11 respectively, also control the flow of
data packets.)
4.7.1 Receive Ready Packet
____________________
Figure 15 illustrates the format of the receive ready packet
transmitted by a DXE and the format of the receive ready packet
received by a DXE.
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).
Bits 8, 7, 6, and 5 of octet 2 indicate the packet receive
sequence number P(R). P(R) is binary coded, where bit 5 is the
low order bit.
Bits 4, 3, 2, and 1 of octet 2 are set to 0.
PACKET LAYER LOGICAL INTERFACE Page 39
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) | Reserved |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 0 0 0 0 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 15 Receive Ready Packet Format
4.7.2 Receive Not Ready Packet
_________________
Figure 16 illustrates the format of the receive not ready
packet transmitted by a DXE and the format of the receive not
ready packet received by a DXE.
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).
Bits 8, 7, 6, and 5 of octet 2 indicate the packet receive
sequence number P(R). P(R) is binary coded, where bit 5 is the
low order bit.
Bits 4, 3, 2, and 1 of octet 2 are set to 0.
PACKET LAYER LOGICAL INTERFACE Page 40
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) | Reserved |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 0 0 1 0 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 16 Receive Not Ready Packet Format
SECTION 4.8 Reset Packet Formats
_____________________
The reset request, reset indication, and reset confirmation
packets (re)initialize the flow of both data and interrupt
packets.
4.8.1 Reset Request and Reset Indication Packets
Figure 17 illustrates the format of reset request and reset
indication packets.
In a DTE/DCE environment, reset request and reset indication
packets are separate packets because of the intervening net-
work. However, in a DTE/DTE environment, the reset request
packet sent by one DTE is the same as the reset indication
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). However, the packet receive sequence number and packet
send sequence number fields are set to zero.
PACKET LAYER LOGICAL INTERFACE Page 41
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) | |
|---:---:---:---:---:---:---:---|
| 0 0 0 0 0 0 0 0 |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 1 1 0 1 1 |
|---:---:---:---:---:---:---:---|
| Resetting cause |
4 | |
|---:---:---:---:---:---:---:---|
| Diagnostic code |
5 | (Note 2) |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Note 2: Diagnostic code is optional.
Figure 17 Reset Request and Reset Indication Packet Format
Resetting Cause Field
_____________________
Octet 4 is the resetting cause field; it contains the reason
for the reset.
The bits of the resetting cause field in a reset request packet
must be set to 0 by a DTE. Further study is required to deter-
mine whether other values of these bits are ignored or proc-
essed by the DCE in a DTE/DCE environment.
The coding of the resetting cause field in a reset indication
packet follows CCITT recommendations X.25 and X.96. In a
DTE/DCE environment, a DTE, to allow for possible later exten-
sions of the defined value of the resetting cause field, must
be able to accept any value in the resetting cause field. In a
DTE/DTE environment, a DTE may either accommodate a nonzero
resetting cause field as it does in a DTE/DCE environment
(i.e., process the packet normally) or treat it as an error.
In the latter case, the packet layer transmits a reset request
packet with a cause indicating 'DTE Originated' and the diag-
nostic 'Nonzero Cause Field from DTE.'
PACKET LAYER LOGICAL INTERFACE Page 42
X.PC Protocol Specification September 8, 1983
Diagnostic Code Field
_____________________
Octet 5 is the diagnostic code field; it contains additional
information regarding the reason for the reset. The coding of
the diagnostic code field follows CCITT X.25 recommendations.
In a reset request packet, the diagnostic code field is
required, even if it indicates no additional information.
In a reset indication packet, if the resetting cause field
indicates 'DTE Originated,' the diagnostic code field has been
passed unchanged from the remote DTE as a result of its having
initiated either a resetting procedure or, in a DTE/DCE envi-
ronment, a restarting procedure. In a reset indication packet,
if the clearing cause field does not indicate 'DTE Originated,'
the diagnostic code field is network generated.
The contents of the diagnostic code field do not alter the
meaning of the resetting cause field. A DTE is not required to
undertake any action on the contents of the diagnostic code
field. The resetting cause field must be accepted even if the
diagnostic code field contains an unspecified code combination.
4.8.2 Reset Confirmation Packet
________________
Figure 18 illustrates the format of the reset confirmation
packet transmitted by a DTE and the format of the reset confir-
mation packet received by a 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 43
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 1 1 1 1 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 18 Reset Confirmation Packet Format
SECTION 4.9 Restart Packet Formats
___________________
The restart request, restart indication, and restart confirma-
tion packets (re)initialize the DTE/DXE packet layer interface.
4.9.1 Restart Request and Restart Indication Packets
Figure 19 illustrates the format of restart request and restart
indication packets.
In a DTE/DCE environment, restart request and restart indica-
tion packets are separate packets because of the intervening
network. However, in a DTE/DTE environment, the restart request
packet sent by one DTE is the same as the restart indication
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). However, the logical channel identifier, packet
receive sequence number, and packet send sequence number fields
are set to zero.
PACKET LAYER LOGICAL INTERFACE Page 44
X.PC Protocol Specification September 8, 1983
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | 0 0 0 0 |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| 0 0 0 0 0 0 0 0 |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 1 1 1 1 1 0 1 1 |
|---:---:---:---:---:---:---:---|
| Restarting cause |
4 | |
|---:---:---:---:---:---:---:---|
| Diagnostic code |
5 | (Note 2) |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Note 2: Diagnostic code is optional.
Figure 19 Restart Request and Restart Indication Packet Format
Restarting Cause Field
______________________
Octet 4 is the restarting cause field; it contains the reason
for the restarting of the call.
The bits of the restarting cause field in a restart request
packet must be set to 0 by a DTE. Further study is required to
determine whether other values of these bits are ignored or
processed by the DCE in a DTE/DCE environment.
The coding of the restarting cause field in a restart indica-
tion packet is given in Table 5 (the definition of each clear-
ing cause code is given in CCITT recommendation X.96). In a
DTE/DCE environment, a DTE, to allow for possible later exten-
sions of the defined values of the restarting cause field, must
be able to accept any value in the restarting cause field. In
a DTE/DTE environment, a DTE may either accommodate a nonzero
restarting cause field as it does in a DTE/DCE environment
(i.e., process the packet normally) or treat it as an error.
In the latter case, the packet layer transmits a restart
PACKET LAYER LOGICAL INTERFACE Page 45
X.PC Protocol Specification September 8, 1983
request packet with a cause indicating 'DTE Originated' and the
diagnostic 'Nonzero Cause Field from DTE.'
Table 5
Coding of the Restarting Cause Field
____in Restart Indication Packets___
|------------------------------------------|
| | Octet 3 |
| | Bits |
| | 8 7 6 5 4 3 2 1 |
|------------------------|-----------------|
| DTE originated | 0 0 0 0 0 0 0 0 |
|------------------------|-----------------|
| Local procedure error | 0 0 0 0 0 0 0 1 |
|------------------------|-----------------|
| Network congestion | 0 0 0 0 0 0 1 1 |
| Network operational | 0 0 0 0 0 1 1 1 |
|------------------------|-----------------|
Note: Other than the 'DTE Originated' restarting cause code,
the remaining codes in the table apply only to a DTE/DCE
environment.
Diagnostic Code Field
_____________________
Octet 5 is the diagnostic code field; it contains additional
information regarding the reason for the restart. The coding
of the diagnostic code field follows CCITT X.25 recommenda-
tions.
In a restart request packet, the diagnostic code field is
required, even if it indicates no additional information.
In network applications, the diagnostic code field is passed to
the corresponding DTEs as the diagnostic code field of a reset
indication packet.
The contents of the diagnostic code field do not alter the
meaning of the restarting cause field. A DTE is not required
to undertake any action on the contents of the diagnostic code
field. The restarting cause field must be accepted even if the
diagnostic code field contains an unspecified code combination.
PACKET LAYER LOGICAL INTERFACE Page 46
X.PC Protocol Specification September 8, 1983
4.9.2 Restart Confirmation Packet
______________
Figure 20 illustrates the format of the restart confirmation
packet transmitted by a DTE and the format of the restart con-
firmation packet received by a 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).
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | 0 0 0 0 |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| P(R) | P(S) |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 1 1 1 1 1 1 1 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 20 Restart Confirmation Packet Format
SECTION 4.10 Diagnostic Packet Format
________________
Figure 21 illustrates the format of the diagnostic Packet.
All DTEs must be able to receive a diagnostic packet. The
diagnostic packet may be used in a DTE/DCE environment, and
then only to be sent by a DCE to a DTE. The diagnostic packet
may be originated by a DTE only in a DTE/DTE environment pro-
vided its generation can be suppressed when connected to a net-
work.
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). However, the logical channel identifier is set to 0.
PACKET LAYER LOGICAL INTERFACE Page 47
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 | 1 1 1 1 0 0 0 1 |
|---:---:---:---:---:---:---:---|
| Diagnostic code |
4 | |
|---:---:---:---:---:---:---:---|
| Diagnostic explanation |
5 | (Note 2) |
// //
| |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Note 2: The maximum length of the diagnostic explanation field
is three octets. Its actual length depends on the rea-
son the diagnostic packet was issued.
Figure 21 Diagnostic Packet Format
Diagnostic Code Field
_____________________
Octet 4 is the diagnostic code field; it contains information
regarding the error condition that resulted in the transmission
of the diagnostic packet. The coding of the diagnostic code
field follows CCITT X.25 recommendations.
Diagnostic Explanation Field
_________________________
When the diagnostic packet is issued as a result of the recep-
tion of an erroneous packet, this field contains the first
three octets of header information from the erroneous packet.
If the erroneous packet contained less than three octets, this
field contains only the integral octets, if any, that were
received by a DTE.
PACKET LAYER LOGICAL INTERFACE Page 48
X.PC Protocol Specification September 8, 1983
When the diagnostic packet is issued as a result of a timeout,
the diagnostic explanation field contains two octets.
Bits 8, 7, 6, and 5 of the first octet contain the general for-
mat identifier of the interface.
Bits 4 through 1 of the first octet and bits 8 through 1 of the
second octet are set to 0 if the restart timer expired (T10 or
T20 for DTE/DCE or DTE/DTE environments respectively) and give
the number of the logical channel on which the timeout occurred
if the reset timer (T12 or T22 for DTE/DCE or DTE/DTE environ-
ments respectively) or the clear timer (T13 or T23 for DTE/DCE
or DTE/DTE environments respectively) expired.
SECTION 4.11 Reject Packet Format
____________________
Figure 22 illustrates the format of the reject packet.
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).
Bits 8, 7, 6, and 5 of octet 2 contain the packet receive
sequence number P(R). P(R) is binary coded, where bit 5 is the
low order bit.
Bits 4, 3, 2, and 1 of octet 2 are set to 0.
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | L C I |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| P(R) | Reserved |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 0 1 0 0 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 22 Reject Packet Format
PACKET LAYER LOGICAL INTERFACE Page 49
X.PC Protocol Specification September 8, 1983
SECTION 4.12 Optional User Facilities Other Than X.25
These facilities are agreed upon for a period by the DTE and
DXE.
The reconnect facility allows virtual calls to be maintained if
the physical connection between the DTE and DXE is lost. It is
applied on a per-virtual-call basis.
A DTE requests this facility by including the request for
reconnect facility code and parameter in the facility field of
the call request packet, along with the DTE part of the recon-
nect key.
A DCE indicates acceptance of this request by including the
request for reconnect facility code and parameter in the facil-
ity field of the call accepted packet, along with the DCE part
of the reconnect key.
If the physical connection is lost, the DTE will reestablish
the physical connection, perform the packet layer restart pro-
cedure, and issue a call request packet on the same logical
channel. Included in the facility field of the call request
packet is the reconnect facility code and parameters. The
parameters include both the DTE and DCE reconnect key.
The DCE will match these keys against the keys for virtual
calls being maintained and will respond with a call accepted
packet with the reconnect key in the reconnect facility param-
eters in the facility field.
At this point the DTE and DCE exchange RR packets indicating
the P(R) of the next packet expected. This allows recovery of
any packets lost when the physical connection failed.
The DCE will maintain virtual calls for a specified time agreed
upon between the DTE and DCE.
SECTION 4.13 Optional User Facility Format
___________
The formats described in this section apply only to optional
user facilities that may be present in the call setup and call
clearing packets used in conjunction with virtual call service.
Only formats for X.25 user facilities that differ from standard
X.25 formats and for a number of user facilities other than
X.25 are described.
PACKET LAYER LOGICAL INTERFACE Page 50
X.PC Protocol Specification September 8, 1983
The facility field is present only when the DXE is using an
optional user facility requiring some indication in the call
request, incoming call, call accepted, call connected, clear
request, or clear indication packets.
A facility marker consisting of two octets separates requests
for X.25 facilities, as specified in CCITT recommendation X.25,
from requests for facilities other than X.25 that may also be
offered. The first octet is a facility code field, which is
set to zero, and the second octet is the facility parameter
field. The facility parameter field is set to either all 0's
or all 1's, depending on whether the facility requests follow-
ing the marker refer to facilities offered by the calling or
the called network respectively. For virtual calls within the
network and for DTE/DTE operation, the facility parameter field
is set to all 0's.
Requests for facilities other than X.25 offered by the calling
and called networks may be present simultaneously within the
facility field and, in such cases, two facility markers are
required with the facility parameter fields coded as described
above.
Within the facility field, requests for X.25 facilities precede
requests for facilities other than X.25. Facility markers need
be included only when requests for facilities other than X.25
are present.
4.13.1 Flow Control Parameter Packet Size
_____
Values from 4 to 8, corresponding to packet sizes of 16, 32,
64, 128, and 256, or a continuous subset of these values may be
offered. A packet size of 128 must always be available. The
maximum X.25 packet size is 1024 octets.
4.13.2 Flow Control Parameter Window Size
_____
Window sizes from 2 to 15 are valid. A window size of 2 must
always be available. The maximum number of data packets
allowed within the window is the window size divided by two.
PACKET LAYER LOGICAL INTERFACE Page 51
X.PC Protocol Specification September 8, 1983
4.13.3 Reconnect Facility
__________________
This section covers the facility code and the facility param-
eter fields of the reconnect facility.
Facility Code Field
___________________
The coding of the facility code field for the reconnect facil-
ity for facilities other than X.25 is:
Bit: 8 7 6 5 4 3 2 1
Code: 0 1 0 0 0 0 0 1
Facility Parameter Field
________________________
In call request packets, the first octet of the reconnect
facility parameter field contains the DTE part of the reconnect
key; the second octet contains the DCE part of the reconnect
key, which is also supplied by the DTE.
In call accepted packets, the DCE provides the DTE part of the
reconnect key in the first octet and the DCE part of the recon-
nect key in the second octet.
PACKET LAYER LOGICAL INTERFACE Page 52
X.PC Protocol Specification September 8, 1983
SECTION 5.0 DATA LINK LAYER SPECIFICATION
____________
X.PC's data link layer is responsible for the full duplex
transfer of network layer packets between the DTE and the DCE
in transparent, error-protected frames.
The data link layer procedure consists of the exchange of data
link frames formatted as specified in Section 5.1.
Each data link frame contains one packet.
SECTION 5.1 Framing Format
__________________________
Figure 23 illustrates the format of the data link frame.
Transparency is accomplished by using a length octet following
the start of the frame. The length octet indicates the number
of octets following the first cyclic redundancy check (CRC).
Octet: 1
Field: STX
Value: 0000 0010
Function: Denotes the start of a data link frame. This octet
is not included in the CRC1 calculation.
Octet: 2
Field: Length
Value: Variable
Function: Number of packet data octets following the first
CRC. If the value is zero, no packet data follows
CRC1, and CRC2 is not used. This octet is included
in the CRC1 calculation.
Octet: 3 - 5
Field: Packet data 1
Value: Variable
Function: Contains the first three bytes of packet data. This
octet is included in the CRC1 calculation.
Octet: 6, 7
Field: CRC1
Value: Variable
Function: Two bytes of CRC bits for error detection. The
algorithm used to generate and test check bits fol-
lows CCITT CRC-16. The length and packet data 1
octets are included in the CRC1 calculation.
DATA LINK LAYER SPECIFICATION Page 53
X.PC Protocol Specification September 8, 1983
Octet: 8 to length+7
Field: Packet data 2
Value: Variable
Function: Packets larger than three octets are transmitted in
two parts; this field contains packet octet 4 and
succeeding octets. The number of octets in this
field is contained in the length field. All octets
are included in the CRC2 calculation.
Octet: Length+8, length+9
Field: CRC2
Value: Variable
Function: Two octets of CRC bits for error detection. CRC2
uses the same algorithm as CRC1. CRC2 is present
only if packet data 2 octets are present, as indi-
cated by the length field being greater than zero.
Only packet data 2 octets are included in the CRC
calculation.
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
1 | STX |
|---:---:---:---:---:---:---:---|
2 | Length |
|---:---:---:---:---:---:---:---|
3 | Packet data 1 |
|- -|
4 | |
|- -|
5 | |
|---:---:---:---:---:---:---:---|
6 | CRC1 |
:- -|
7 | |
|---:---:---:---:---:---:---:---|
8 | |
// Packet data 2 //
| |
|---:---:---:---:---:---:---:---|
N | CRC2 |
|- -|
N+1 | |
|---:---:---:---:---:---:---:---|
Figure 23 X.PC Data Link Transmission Frame Format
DATA LINK LAYER SPECIFICATION Page 54
X.PC Protocol Specification September 8, 1983
SECTION 5.2 Maximum Data Link Frame Size
_____________
A data link frame can accommodate no more than 258 packet layer
octets. The maximum data link frame size, including overhead,
is 264 octets.
DATA LINK LAYER SPECIFICATION Page 55
X.PC Protocol Specification September 8, 1983
Appendix A, PACKET FORMATS
This appendix duplicates Figure 2 and Figures 8 through 22 from
Section 4 of the text. These figures illustrate packet for-
mats. They are presented here a second time for convenience in
comparing the formats.
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
Appendix A, PACKET FORMATS Page 56
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
Appendix A, PACKET FORMATS Page 57
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 1 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 9 Call Accepted and Call Connected Packet Format
Appendix A, PACKET FORMATS Page 58
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 1 0 0 1 1 |
|---:---:---:---:---:---:---:---|
| Clearing cause |
4 | |
|---:---:---:---:---:---:---:---|
| Diagnostic code |
5 | (Note 3) |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Note 2: Address format default is CCITT X.121.
Note 3: Diagnostic code is optional
Figure 10 Clear Request and Clear Indication Packet Format
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 1 0 1 1 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 11 Clear Confirmation Packet Format
Appendix A, PACKET FORMATS Page 59
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 | | |
|---:---:---:---:---:---:---:---|
| User data |
// //
| |
|---:---:---:---:---:---:---:---|
Note 1: Coded 0DQM, where D = D bit, Q = Q bit, and M = M bit
Figure 12 Data Packet Format
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 1 0 0 0 1 1 |
|---:---:---:---:---:---:---:---|
| Interrupt user data |
4 | |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 13 Interrupt Packet Format
Appendix A, PACKET FORMATS Page 60
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 1 0 0 1 1 1 |
|---:---:---:---:---:---:---:---|
4 | Interrupt user data |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 14 Interrupt Confirmation Packet Format
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | L C I |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| P(R) | Reserved |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 0 0 0 0 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 15 Receive Ready Packet Format
Appendix A, PACKET FORMATS Page 61
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) | Reserved |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 0 0 1 0 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 16 Receive Not Ready Packet Format
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | L C I |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| 0 0 0 0 0 0 0 0 |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 1 1 0 1 1 |
|---:---:---:---:---:---:---:---|
| Resetting cause |
4 | |
|---:---:---:---:---:---:---:---|
| Diagnostic code |
5 | (Note 2) |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Note 2: Diagnostic code is optional.
Figure 17 Reset Request and Reset Indication Packet Format
Appendix A, PACKET FORMATS Page 62
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 1 1 1 1 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 18 Reset Confirmation Packet Format
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | 0 0 0 0 |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| 0 0 0 0 0 0 0 0 |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 1 1 1 1 1 0 1 1 |
|---:---:---:---:---:---:---:---|
| Restarting cause |
4 | |
|---:---:---:---:---:---:---:---|
| Diagnostic code |
5 | (Note 2) |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Note 2: Diagnostic code is optional.
Figure 19 Restart Request and Restart Indication Packet Format
Appendix A, PACKET FORMATS Page 63
X.PC Protocol Specification September 8, 1983
Bits
8 7 6 5 4 3 2 1
Octet .---.---.---.---.---.---.---.---.
| G F I | 0 0 0 0 |
1 | (Note 1) | |
|---:---:---:---:---:---:---:---|
| P(R) | P(S) |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 1 1 1 1 1 1 1 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 20 Restart Confirmation Packet Format
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 | 1 1 1 1 0 0 0 1 |
|---:---:---:---:---:---:---:---|
| Diagnostic code |
4 | |
|---:---:---:---:---:---:---:---|
| Diagnostic explanation |
5 | (Note 2) |
// //
| |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Note 2: The maximum length of the diagnostic explanation field
is three octets. Its actual length depends on the rea-
son the diagnostics packet was issued.
Figure 21 Diagnostic Packet Format
Appendix A, PACKET FORMATS Page 64
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) | Reserved |
2 | | |
|---:---:---:---:---:---:---:---|
| Packet type identifier |
3 | 0 0 0 0 1 0 0 1 |
|---:---:---:---:---:---:---:---|
Note 1: Coded 1000
Figure 22 Reject Packet Format
Appendix A, PACKET FORMATS Page 65
X.PC Protocol Specification September 8, 1983
INDEX
Bandwidth utilization ............................. 4
Batch traffic ..................................... 5
Byte stuffing ..................................... 4, 6
Call accepted packet format ....................... 30, 31, 58
Call collision .................................... 10, 13
Call connected packet format ...................... 30, 31, 58
Call request packet format ........................ 26, 27, 57
Clear confirmation packet format .................. 35, 36, 59
Clear indication packet format .................... 33, 34, 59
Clear request packet format ....................... 33, 34, 59
Clearing cause field .............................. 34, 35, 43
Control packets ................................... 8
Counters .......................................... 16, 18, 19
Data link frame ................................... 3
Data link frame format ............................ 53
Data link layer ................................... 53
Data packet format ................................ 36, 37, 60
Data packet limit ................................. 14
Delivery confirmation bit (D bit) ................. 16, 23, 36
Diagnostic packet format .......................... 47, 48, 64
Duplicate packets ................................. 3, 22
Error control ..................................... 4, 7, 16,
53, 54
Error rate ........................................ 3
Flow control ...................................... 4, 7
Incoming call packet format ....................... 26, 27, 57
Interactive traffic ............................... 5
Interrupt confirmation packet format .............. 38, 39, 61
Interrupt packet format ........................... 37, 38, 60
Length encoding ................................... 4, 6
Logical channel identifier field .................. 24
Logical channels .................................. 8
Lost packets ...................................... 3, 16, 19,
INDEX Page 66
X.PC Protocol Specification September 8, 1983
21, 50
More data mark (M bit) ............................ 23, 36
Multiplexing ...................................... 7
Optional addressing facilities .................... 28, 32
Optional user facility ............................ 50
Optional user facility format ..................... 50
Out-of-sequence packet ............................ 19
Overhead .......................................... 4, 6, 13,
55
Packet layer entity ............................... 11
Packet numbering .................................. 13
Packet receive sequence number field .............. 24
Packet send sequence number field ................. 24
Packet structure .................................. 11
Packet type identifier field ...................... 24
Protocol identification ........................... 29
Qualifier bit (Q bit) ............................. 23
Receive not ready packet .......................... 16
Receive not ready packet format ................... 40, 41, 62
Receive ready packet .............................. 15
Receive ready packet format ....................... 39, 40, 61
Reconnect facility ................................ 4, 50, 52
Reconnect key ..................................... 50, 52
Reject packet format .............................. 49, 65
Reset confirmation packet format .................. 43, 44, 63
Reset indication packet format .................... 41, 42, 62
Reset request packet format ....................... 41, 42, 62
Restart indication packet format .................. 44
Restart request packet format ..................... 44
Throughput ........................................ 4
Timers ............................................ 16, 18, 19
Transmission line errors .......................... 3, 5
Window algorithm .................................. 4
Window size ....................................... 5, 51
INDEX Page 67
---cut here---end---cut here---
--Keith Petersen
Arpa: W8SDZ at 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
More information about the Comp.sources.unix
mailing list