The drawings contained in this Recommendation have been done in Autocad

Recommendation X.29

PROCEDURES FOR THE EXCHANGE OF CONTROL INFORMATION

AND USER DATA BETWEEN A PACKET

ASSEMBLY/DISASSEMBLY (PAD) FACILITY

AND A PACKET MODE DTE OR ANOTHER PAD

(provisional, Geneva, 1977; amended, Geneva, 1980,

Malaga-Torremolinos, 1984 and Melbourne, 1988)

Preface

The establishment in various countries of public data networks providing packet-switched data transmission services creates a need to produce standards to facilitate international interworking.

The CCITT,

considering

(a)	that Recommendations X.1 and X.2 define the user classes of service and facilities in a public data network, and Recommendation X.96 defines call progress signals;

(b)	that Recommendation X.3 defines the PAD in a public data network;

(c)	that Recommendation X.28 defines the DTE/DCE interface for a start-stop mode DTE accessing the PAD in a public data network;

(d)	that Recommendation X.25 defines the interface between the DTE and the DCE for DTEs operating in the packet mode in public data networks;

(e)	the need to allow interworking between a packet mode DTE and a non-packet mode DTE in the packet-switched transmission service;

(f)	the urgent need to allow interworking between a start-stop mode DTE in a public switched telephone network, public switched data network or a leased line and a packet mode DTE using the virtual call facility of the packet-switched transmission service;

(g)	the need to allow interworking between PADs;

(h)	that the packet mode DTE shall not be obliged to use the control procedures for PAD functions, but that some packet mode DTEs may wish to control specific functions of the PAD,

unanimously recommends that

(1)	the Recommendation X.29 procedures shall apply to the Recommendation X.25 interface between the DCE and the packet mode DTE;

(2)	the Recommendation X.29 procedures may be applied for interworking between PADs;

(3)	the procedures be as specified below in S 1 Procedures for the exchange of PAD control information and user data;

(4)	the manner in which user data is transferred be as specified below in S 2 User data transfer;

(5)	the procedures for the control of the PAD via PAD messages be as specified below in S 3 Procedures for the use of PAD messages;

(6)	the formats of the data fields which are transferable on a virtual call be as specified below in S 4 Formats.

iis considered within a national network these packet types or procedures may have a different form from those used in Recommendation X.25 but will have the same operational meaning.

Note 2 V The following items are for further study:

V	the use of the permanent virtual circuit service;

V	interworking between DTEs having interfaces to different data transmission services;

V	operation of nonVpacket mode DTEs in other than startVstop mode.

1	Procedures for the exchange of PAD control information and user data

1.1	The exchange of control information and user data between a PAD and a packet mode DTE or between PADs is performed by using user data fields defined in Recommendation X.25.

1.2	Annex A describes some of the characteristics of virtual calls as defined in Recommendation X.25, as related to the PAD representation of a startVstop mode DTE to a packet mode DTE. The characteristics described in Annex A also apply for interworking between PADs.

1.3	Call user data

The call user data field call user data field of incoming call or call request packets to or from the packet mode DTE or the PAD is comprised of two fields:

a)	the protocol identifier field protocol identifier field, and

b)	the call data field call data field.

The protocol identifier field is used for protocol identification purposes and the call data field contains user data.

A call request packet received by the PAD, containing no call user data field, will be accepted by the PAD.

If a call data field is present, the PAD will send it, unchanged, to the startVstop mode DTE, using the call data block of the incoming call PAD service signal (see ' 3.5.22, Recommendation X.28).

1.4	User sequences

1.4.1	User sequences are used to exchange user data between the PAD and the packet mode DTE or a PAD.

1.4.2	User sequences are conveyed in the user data fields of complete packet sequences with Q = 0, and in both directions on a virtual call. (See Recommendation X.25.)

1.4.3	There will be only one user sequence in a complete packet sequence.

1.4.4	The PAD will transmit all data packets with the D bit set to 0.

On reception of a data packet with the D bit set to 1, the PAD will transmit the corresponding acknowledgement as soon as possible.

virt

virtual call.

As no error correction procedure is in place from the PAD to the start-stop mode DTE, no guarantee of delivery can be implied from the acknowledgement.

1.5	PAD messages

1.5.1	PAD messages are used to exchange control information between the PAD and the packet mode DTE (or remote PAD). A PAD message consists of a control identifier field and a message code field possibly followed by a parameter field (see S 4.4 below).

1.5.2	PAD messages are conveyed in the user data fields of complete packet sequences with Q = 1 and in both directions on a virtual call. (See Recommendation X.25.)

1.5.3	There will be only one PAD message in a complete packet sequence.

1.5.4	The PAD will take into consideration a PAD message only when it has been completely received.

1.5.5	In the case where a parameter reference (see S 3 below) appears more than once in a PAD message, only the last appearance is taken into account.

1.5.6	The PAD will transmit all data packets with the D bit set to 0.

On reception of a data packet with both the Q bit and the D bit set to 1, the PAD will transmit the corresponding acknowledgement as soon as possible.

If the PAD does not support the D bit procedure, the PAD may reset the virtual call.

2	User data transfer

2.1	Data packets will be forwarded by the PAD when a set, read, or set and read PAD message is received, or under any of the other data forwarding conditions provided by the PAD (see Recommendation X.28, S 4.4).

2.2	The occurrence of a data forwarding condition will not cause the PAD to transmit empty data packets.

3	Procedures for the use of PAD messages

3.1	Procedures for reading, setting, and reading and setting of PAD parameters

3.1.1	The current values of PAD parameters may be changed and read by transmitting to the PAD a set, read, or set and read PAD message.

me

message as a data forwarding condition.

3.1.3	The PAD will respond to a valid read or set and read PAD message by transmitting a parameter indication PAD message. This PAD message will have

a parameter field containing a list of parameter references and current values (after any necessary modification) of the PAD parameters to which the received PAD message referred.

3.1.4	The PAD will not return a parameter indication PAD message in response to a valid set PAD message received.

3.1.5	Table 1/X.29 specifies the PAD's response of the PAD to set, set and read, and read PAD messages.

3.1.6	If the function of a character is duplicated by the selection of parameter values by use of the set or set and read PAD message, the PAD will consider these parameter changes as valid, and will respond as described in this Recommendation. After these changes are invoked, the PAD will follow the procedure described in Recommendation X.28, ' 3.3.2.

3.2	Procedures for inviting the PAD to clear

3.2.1	The invitation to clear PAD message is used to request that the PAD clears the virtual call, after transmission of all data previously transmitted to the startVstop mode DTE.

Note V The clear indication packet, which is transmitted by the PAD after delivery of the last character to the startVstop mode DTE, will have a clearing cause field set to DTE clearing.

3.3	Interrupt and discard procedures

3.3.1	If parameter 7 is set to 21, the PAD will transmit an interrupt packet with all bits of the interrupt user data field set to 0 followed by an indication of break PAD message to indicate that the PAD, at the request of the startVstop mode DTE, is discarding the user sequences received. The PAD message will contain an indication in its parameter field that parameter 8 has been set to 1 (discard output).

3.3.2	Before resuming data transmission to the PAD, the response to the indication of break PAD message shall be a set or set and read PAD message, indicating that parameter 8 should be set to 0 (normal data delivery).

Prior to sending this PAD message, any inVprogress complete packet sequence being transmitted to the PAD must be terminated (with a packet that will be discarded by the PAD) in accordance with Recommendation X.25 procedures.

TABLE 1/X.29

PAD messages transmitted by the PAD in response to set, set and read, and read PAD messages

PAD message received by the PAD

Action upon PAD parameters

Corresponding parameter indication PAD message transmitted to the

Type

Parameter field

packet mode DTE

Set

None

Reset all implemented Recommendation X.3 parameters to their initial values corresponding to the initial profile

None

List of selected parameters with the desired values

Set the selected parameters to the given values:

a)	if no error is encountered

b)	if the PAD fails to modify the	values of some parameters

a)	None

b)	List of these invalid parameters

(see Note)

Set and read

None

Reset all implemented Recommendation X.3 parameters to their initial values corresponding to the initial profile

List all implemented Recommendation X.3 parameters, and their initial values

List of selected parameters with the desired values

Set the selected parameters to the given values

List of these parameters with their new current values (see Note)

Read

None

None

List all implemented Recommendation X.3 parameters with their current values

List of selected parameters

None

List of these parameters with their current values (see Note)

Note - If any of the parameters contain an error, then the error bit is set and the value field is coded as described in Table 3/X.29.

3.3.3	If a PAD receives an indication of break PAD message which contains a parameter field as described in S 3.3.1 above, it will respond by transmitting a set PAD message as described in S 3.3.2 above and will transmit a break signal to the start-stop mode DTE. If a PAD receives an indication of break PAD message which does not contain a parameter field, it will not respond to the packet mode DTE or PAD but it will transmit a break signal to the start-stop mode DTE.

3.3.4	When the PAD transmits an interrupt packet after the receipt from the start-stop mode DTE of an interrupt PAD command signal or a break signal, when parameter 7 is set to 1, the interrupt user data field is coded in bits 8 to 1 as 00000001.

3.3.5	If the PAD receives an interrupt packet it will confirm it in accordance with Recommendation X.25 procedures. The PAD will not transmit the contents of the interrupt user data field to the start-stop DTE. The PAD will ignore the values of the interrupt user data field. It is for further study whether the coding of this field given in S 3.3.4 above causes a different response.

3.3.6	If parameter 7 is set to 5, the PAD will transmit an interrupt packet with all bits of the interrupt packet set to 0, followed by an indication of break PAD message. The PAD message will not contain a parameter field as described in S 4.4.7.

3.3.7	Some PADs may always send the break signal to the start-stop mode DTE upon receipt of an interrupt packet rather than upon receipt of an indication of break PAD message.

3.4	Procedure for resets

Virtual calls may be reset according to the procedures defined in Recommendation X.25. The effect of the resetting procedure on the value of PAD parameter 8 is to reset its value to 0 (normal data delivery). The current values of all other PAD parameters are not affected.

3.5	Error handling procedures by the PAD

3.5.1	If the PAD receives a set, read or set and read PAD message containing an invalid reference to a PAD parameter, the parameter field within the parameter indication PAD message transmitted by the PAD will contain an indication that this has occurred. The remaining valid references to PAD parameters are processed by the PAD.

Possible reasons for an invalid access to a PAD parameter are:

a)	the parameter reference has not been implemented in the PAD;

b)	the parameter value has not been implemented in the PAD or cannot be altered from the current setting;

c)	the parameter is a read-only one (set and set and read PAD messages only);

d)	the parameter follows an invalid parameter separator (see S 4.4.5.4 below).

3.5.2	The PAD will transmit an error PAD message containing the message code of an invalid PAD message received under the following conditions:

a)	if the PAD receives an unrecognizable message code;

b)	if the parameter field following a recognizable message code is incorrect or incompatible with the message code;

c)	if the parameter field following a recognizable message code has an invalid format;

d)	if the PAD receives an unsolicited parameter indication PAD message;

e)	if the PAD receives a PAD message that is too long.

3.5.3	The PAD will transmit an error PAD message if a PAD message containing less than 8 bits is received.

3.5.4	If the PAD receives an error PAD message it will not respond with a PAD message of any type. Subsequent action is for further study.

3.6	Procedures for inviting the PAD to reselect the called DTE

The reselection or reselection with TOA/NPI PAD message (Type of address/Numbering Plan Indicator) used by a packet mode DTE to request that the PAD clear the virtual call, after transmission to the start-stop mode DTE of all the previously transmitted data. Then, the PAD will establish a call to the reselected DTE.

Note - The TAO/NPI address subscription facility is designated in Recommendation X.2 for further study.

When the reselection PAD message is received, the PAD will transmit an error PAD message with an error type unauthorized reselection PAD message (00000110) under the following conditions:

a)	the virtual call has been established by the packet-mode DTE;

b)	the called DTE reselection prevention facility has been requested by the start-stop mode DTE;

c)	the reselection PAD message has been already received more than N times (where N is for further study).

The format of the reselection PAD message is given in S 4.4.9 below. The format of the reselection with TOA/NPI PAD message is given in S 4.4.10 below. These messages contain the information needed by the PAD to establish the new virtual call.

Upon receipt of the reselection or reselection with TOA/NPI PAD message, the PAD will:

-	transmit to the start-stop mode DTE all previously received data;

-	clear the virtual call that is established;

-	after having made the appropriate state changes as described in Recommendation X.28, S 3.2.5, establish a virtual call to

the reselected DTE. The call request packet sent by the PAD, will contain only the facilities subscribed by the start-stop mode DTE and/or assigned by default. Any other facilities contained in the reselection PAD message will be ignored. In particular:

i)	Closed User Group Signals - Independently by the CUG indicated in the reselection PAD message, the PAD will use the same CUG of the original call.

message

message contains the reverse charging facility.

iii)	Charging information:

V	facility assigned for an agreed contractual period: The information will be sent to the startVstop mode DTE at the clearing of each call (original and reselected), or at the clearing of the last reselected call. If the later procedure was selected, the PAD will send the total charging information, without sending the charge of the individual calls (original and reselected).

V	facility on a per call basis: The PAD follows the procedure indicated above, starting from the first charging information facility request (by the startVstop mode DTE or packet mode DTE).

iv)	RPOA selection: for further study

Note V The other facilities indicated in Table 4/X.28 with Note 2 are for further study.

Note V This procedure is an optional feature of the PAD. PADs which do not implement this feature will consider reselection and reselection with TOA/NPI PAD messages as invalid. PADs may implement this feature either by accepting (1) reselection PAD messages or (2) reselection and reselection with TOA/NPI PAD messages. The sending of reselection or reselection with TOA/NPI PAD messages by a PAD is for further study.

4	Formats

4.1	Introduction

Bits of octets are numbered 8 to 1 where bit 1 is the low order bit and is transmitted first. Octets of the call user data, of user sequences, of PAD messages and of interrupt user data are consecutively numbered starting from 1 and are transmitted in this order.

4.2	Call user data format (see Figure 1/X.29)

4.2.1	Protocol identifier format

The protocol identifier field protocol identifier field standardized by CCITT consists of four octets.

The first octet is coded as follows:

bits 8 and 7	= 00 for CCITT use

= 01 for national use

= 10 reserved for international user bodies

= 11 for DTEVDTE use.

CCCITT, subject to the rules of Recommendation X.244. All bits of octets 2, 3 and 4 are set to 0. These octets are reserved as a future mechanism for providing the called PAD or packet mode DTE with additional information pertinent to the calling party.

Fig. 1/X.29 = 6 cm

4.2.2	Call data format

Octets of the call data field will contain the user characters received by the PAD from the start-stop mode DTE during the call establishment phase. The coding of these octets is similar to that of user sequences (see S 4.3 below). The call data field is limited to 12 octets (see Figure 1/X.29).

4.3	User sequence format

4.3.1	The order of bit transmission from the PAD is the same as the order that bits are received from the start-stop mode DTE. The order of bit transmission to the start-stop mode DTE is the same as the order that bits are received.

4.3.2	No maximum is specified for the length of a user sequence.

4.4	Control message format

4.4.1	Bits 8, 7, 6, 5 of octet 1 of a user data field of complete packet sequences with Q = 1 are defined as the control identifier field, used to identify the facility, such as PAD, to be controlled. The control identifier field coding for PAD messages to control a PAD for a start-stop mode DTE is 0000. Other codings of the control identifier field are reserved for future standardization.

Note - The possibility of extending the control identifier field is for further study.

4.4.2	When the control identifier field (see S 4.4.1 above) is set to 0000, bits 4, 3, 2, 1 of octet 1 are defined as the message code field. The message code field is used to identify specific types of PAD messages, as given in Table 2/X.29.

TABLE 2/X.29

Type and coding of octet 1 of PAD messages

Message code

Type

Bit

s

4

3

2

1

Set PAD message

0

0

1

0

Read PAD message

0

1

0

0

Set and read PAD message

0

1

1

0

Parameter indication PAD message

0

0

0

0

Invitation to clear PAD message

0

0

0

1

Indication of break PAD message

0

0

1

1

Reselection PAD message

0

1

1

1

Error PAD message

0

1

0

1

Reselection with TOA/NPI

1

0

0

0

Note - The possibility of extending the message code field is for further study.

4.4.3	All PAD messages consist of a control identifier field (bits 8, 7, 6, 5 of octet 1 equal to 0000) and a message code field (bits 4, 3, 2, 1 of octet 1).

Set, read, set and read and parameter indication PAD messages consist of octet 1 which may be followed by one or more parameter fields. Each parameter field consists of a parameter reference octet and a parameter value octet.

The parameter value octets of the read PAD message contain the value 0.

The error PAD message consists of octet 1 and one or two octets giving the reason for the error.

The indication of break PAD message consists of octet 1 which may be followed by a parameter field.

The invitation to clear PAD message consists of octet 1 only.

4.4.4	The maximum length of PAD message is network dependent, but will be at least 128 octets.

4.4.5	Parameter field for set, read, set and read, and parameter indication PAD messages (see Figure 2/X.29)

A parameter field contained in one of these PAD messages consists of a reference field and a value field. A parameter field is two octets in length, except when the extension mechanism is used (see S 4.4.5.1 below).

ccoded in bits 7 to 1, where bit 1 is the low order bit. Reference fields need not be ordered by increasing parameter reference numbers.

The code 1111111 (decimal 127) in bits 7 to 1 of the reference field will be used for the extension of this field. Such coding will indicate that there is another octet following. The following octet is coded with the parameter reference of Recommendation X.3 minus 127.

4.4.5.2	In PAD messages received by the PAD, bit 8 of each octet will be ignored. In parameter indication PAD messages, bit 8 of each reference field set to 1 will indicate an invalid access to the referred parameter as described in S 3.5 above.

Fig. 2/X.29 = 13 cm

4.4.5.3	A parameter value field consists of a value of the parameter reference, identified as a decimal number in Recommendation X.3, and is binary coded in bits 8 to 1, where bit 1 is the low order bit. Value fields in read PAD messages are coded as all binary 0s. In set and set and read PAD messages, they will indicate the requested values of parameters. In parameter indication PAD messages, they will indicate the current values of PAD parameters, after modification if any. If bit 8 (error bit) is set to 1 in the preceding octet (i.e. the parameter reference field), the parameter value field will indicate the reason for the error, as given in Table 3/X.29.

4.4.5.4	Parameters not standardized by CCITT may be supported. The parameter separator is used in PAD messages to indicate the separation between parameters specified in Recommendation X.3 and any others implemented nationally or locally.

The parameter separator consists of a parameter field which contains a reference field set to 00000000 and a value field set to 00000000.

When present, the parameter separator and the national or local parameter fields must be placed after any CCITT standardized parameter fields in PAD messages.

Note - It is recommended that only the parameters defined in Recommendation X.3 are used when communicating with a PAD in a different country or network.

TABLE 3/X.29

Coding of parameter value field in case of error

Parameter value field code

Error type

bits

Decimal

8

7

6

5

4

3

2

1

No additional information

0

0

0

0

0

0

0

0

0

The parameter reference does not exist or has not been implemented in the PAD

0

0

0

0

0

0

0

1

1

The parameter value is invalid or has not been implemented in the PAD

0

0

0

0

0

0

1

0

2

The parameter value cannot be altered from the current setting

0

0

0

0

0

0

1

1

3

The parameter is read-only

0

0

0

0

0

1

0

0

4

The parameter follows an invalid parameter separator

0

0

0

0

0

1

0

1

5

Note - The value 0 is mandatory. Other values are optional.

4.4.6	Format of error PAD messages (see Figure 3/X.29)

Fig. 3/X.29 = 7 cm

4.4.6.1	Octet 2 of the error PAD message will be coded as shown in Table 4/X.29.

4.4.6.2	In cases b, c, d, e and f in Table 4/X.29, octet 3 of an error PAD message will contain the message code of the received PAD message.

4.4.7	Parameter field for indication of break PAD messages (see Figure 4/X.29)

This PAD message may either not contain a parameter field, or contain a parameter field consisting of 2 octets (i.e. one reference field and one value field) coded as follows: the reference field will be coded 00001000 (indicating parameter 8) and the value field will be coded 00000001 (indicating decimal 1).

TABLE 4/X.29

Coding and meaning of octet 2 of error PAD messages

Coding

Case

Meaning

Bits

8

7

6

5

4

3

2

1

a

Received PAD message contained less than eight bits

0

0

0

0

0

0

0

0

b

Unrecognized message code in received PAD message

0

0

0

0

0

0

1

0

c

Parameter field format of received PAD message was incorrect or incompatible with message code

0

0

0

0

0

1

0

0

d

Received PAD message did not contain an

integral number of octets

0

0

0

0

0

1

1

0

e

Received parameter indication PAD message was unsolicited

0

0

0

0

1

0

0

0

f

Received PAD message was too long

0

0

0

0

1

0

1

0

g

Unauthorized reselection PAD message

0

0

0

0

1

1

0

0

Fig. 4/X. 29 = 5 cm

4.4.8	Parameter field for invitation to clear PAD message (see Figure 5/X.29)

Fig. 5/X.29 = 5 cm

This PAD message will not contain a parameter field.

4.4.9	Reselection PAD message format

The format of this message is given in Figure 6/X.29.

Fig. 6/X.29 = 9 cm

4.4.9.1	Reselected DTE address length field

Bits 4, 3, 2 and 1 of the reselected DTE address length field indicate the length of the reselected DTE address in semi-octets. The address length is binary coded and bit 1 is the low order bit of the indicator.

4.4.9.2	Address field

Octet 3 and the following octets consist of the reselected DTE address. Each digit of the address is coded in a semi-octet in binary coded decimal with bit 5 or 1 being the low order bit of the digit.

Starting from the high order digit, the address is coded in octet 3 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 address field shall be rounded up to an integral number of octets by inserting zeros in bits 4, 3, 2 and 1 of the last octet of the field when necessary.

The reselected DTE address field should contain the international data number (DNIC + Network terminal number).

4.4.9.3	Facility length field

The octet following the reselected DTE address field indicates the length of the facility field, in octets. The facility length indicator is binary coded and bit 1 is the low order bit of the indicator.

4.4.9.4	Facility field

The facility field is present only when optional user facilities are included by the DTE. This field indicates the facilities that must be included in the facility field of the incoming call packet received by the reselected DTE (see S 3.6).

The coding of the facility field is defined in S 7 of Recommendation X.25.

The facility field contains an integral number of octets, the maximum length of the complete PAD message is restricted, as described in S 4.4.4 above.

4.4.9.5	Call user data field

Following the facility field, the call user data field may be present and has a maximum length of 12 octets.

Call user data when present in the call user data field of the reselection PAD message is included in the call user data field of the incoming call packet received by the reselected DTE.

4.4.10	Reselection with TOA/NPI PAD message format

The format of this message is given in Figure 7/X.29.

Note - The TOA/NPI address subscription facility is designated in Recommendation X.2 for further study.

Fig. 7/X.29 = 8 cm

4.4.10.1	Reselected DTE address length field

Octet 2 indicates the length of the reselected DTE address in semi-octets. The address length is binary coded and bit 1 is the low order bit of the indicator. The maximum value of the reselected DTE address length field is 17.

4.4.10.2	Reselected DTE address field

Octet 3 will consist of the TOA/NPI indication as described in Recommendation X.25. The following octets consist of the reselected DTE address. Each digit of the address is coded in a semi-octet in binary coded decimal with bit 5 or 1 being the low order bit of the digit. Starting from the high order digit, the address digits are coded in consecutive semi-octets. In each octet, the higher order digit is coded in bits 8, 7, 6 and 5.

4.4.10.3	Facility length field

The octet following the address field indicates the length of the facility field, in octets. The facility length indicator is binary coded and bit 1 is the low order bit of the indicator.

4.4.10.4	Facility field

(See S 4.4.9.4.)

4.4.10.5	Call user data field

(See S 4.4.9.5.)

ANNEX A

(to Recommendation X.29)

Characteristics of virtual calls and Recommendation X.25

as related to the PAD representation of

a start-stop mode DTE to a packet mode DTE

A.1	General interface characteristics

A.1.1	The mechanical, electrical, functional and procedural characteristics to activate, maintain and deactivate the physical access path between the DTE and the DCE will be in accordance with the physical level procedures of Recommendation X.25.

A.1.2	The link access procedure for data interchange across the link between the DTE and DCE will be in accordance with the link level procedures of Recommendation X.25.

A.1.3	The packet format and control procedures for the exchange of packets containing control information and user data between the DTE and the DCE will be in accordance with the packet level procedures of Recommenda-tion X.25.

A.2	Interface procedures for virtual call control

A.2.1	Incoming calls are indicated to the packet mode DTE as specified in Recommendation X.25. Call requests are indicated by the packet mode DTE as specified in Recommendation X.25. Any use of optional user facilities are indicated in accordance with SS 6 and 7 of Recommendation X.25.

A.2.2	The default throughput classes used by the PAD are determined by the data rates of the start-stop mode DTE (where exact correspondence is not obtained, the next higher throughput class is used).

A.2.3	The PAD and the packet mode DTE will use the clearing procedures specified in SS 4.1.7, 4.1.8 and 4.1.9 of Recommendation X.25.

A.3	Interface procedures for data transfer

A.3.1	Data transfer on a virtual call can only take place in the data transfer state and when flow control permits (see S 4.4 of Recommendation X.25). The same is true for the transfer of interrupt packets (see S 4.3 of Recommendation X.25).

A.3.2	Interrupt packets transmitted by the packet mode DTE will be confirmed by the PAD following the procedures in Recommendation X.25.

A.3.3	The reset procedure may be used by the packet mode DTE or the PAD to re-initialize the virtual call and will conform to the procedures described in S 4.4.3 of Recommendation X.25.

A.3.4	A reset of the virtual call originated by the packet mode DTE or due to network congestion may be indicated by the PAD to the start-stop mode DTE.

A.3.5	A reset procedure initiated by the PAD may be due either to:

a)	the receipt at the PAD of a request to reset from the non-packet mode DTE. The resetting cause contained in the reset indication packet will be DTE reset; or

b)	a PAD or network failure.

A.3.6	For calls received by the PAD with bit 7 of octet 1 in the incoming call packet set to 0, the PAD will set bit 7 of octet 1 in the call accepted packet to 0 and will set the D bit in transmitted data packets to 0.

Pending further study, and in the absence of bilateral agreement between Administrations (used in conjunction with the D bit modification facility), the following applies:

If the incoming call packet received by the PAD has bit 7 of octet 1 set to 1, the PAD may set bit 7 of octet 1 of the call accepted packet to 1.

Calls originated by the PAD will set bit 7 of octet 1 in call request packets to 0. The called DTE can indicate if it requires the support of the D bit procedure by setting bit 7 of octet 1 of call accepted packets to 1.

PAD procedures associated with the Delivery Confirmation (D) bit in data packets (see S 4.3.3 of Recommendation X.25) are described in SS 1.4.4 and 1.5.6.

A.4	Virtual call characteristics

A.4.1	Resetting

A.4.1.1	There may be a loss of data characters in any case of reset, as stated in Recommendation X.25. Characters generated by either of the DTEs prior to the reset indication or confirmation will not be delivered to the other DTE after the reset indication or confirmation.

A.4.2	Interrupt transfer

A.4.2.1	An interrupt packet is always delivered at or before the point in the data packet stream at which it was generated.

A.4.3	Call clearing

Data packets transmitted immediately before a clear request packet is sent, may be overtaken within the network by the clear request packet and subsequently be destroyed, as described in S 4.5 of Recommendation X.25.