W8SDZ@SIMTEL20.ARPA (Keith Petersen) (09/03/85)
---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@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